Chris21 Writeback failed

What is the use case here? I don't believe we've had this particular issue come up. Do you want to ever update this field (does this apply to some or all records)?

If you only need some records to behave this way, could you please let me know what happens if you perform the update without the detemailad field in the statement?

Hi Adam,

It is to write back email address into Chris21. I believe Chris21 Link performed outgoing sync (hence update in Chris21) without before AD can generate an email address for users.

Can you pls let me know how can I perform the update without the detemailad field?

Okay, so doesn't sound like an unusual use case then. I'll get some advise on the order of operations.

In the meantime, please try this in the GTR form (it might help decide whether this feature request makes sense in the connector):

cbr="DETupd",detnumber="506797",detworkphone,translation="Ring A M",dettitle="Ms",detsurname="Ring",detdatejnd="2001-11-26",detcontdat,detg1name1="Anna",detg1name2="Marie-Jean",detg1name3,detprefnm,detserdate="2001-11-26",detworkph,detbirdate="1980-06-14",detsex="2",detcntrynm="1101",detcitcd="1101",detcommence="Z",detmardate,detaltnbr,detbutton,detmarcd,detpaytype="INB",detusertag="SHSSTEA",detdatetag="2015-08-27",edegsuind="Y",detsupflag="Q",detwcsasrn,detmobile,detage="0",detservice="0"

GTR result:

cbr="DETupd",detnumber="506797",detworkphone,translation="Ring A M",dettitle="Ms",detsurname="Ring",detdatejnd="2001-11-26",detcontdat,detg1name1="Anna",detg1name2="Marie-Jean",detg1name3,detprefnm,detserdate="2001-11-26",detworkph,detbirdate="1980-06-14",detsex="2",detcntrynm="1101",detcitcd="1101",detcommence="Z",detmardate,detaltnbr,detbutton,detmarcd,detpaytype="INB",detusertag="627448",detdatetag="2018-01-22",edegsuind="Y",detsupflag="Q",detwcsasrn,detmobile,detage="0",detservice="0",gw_transactionid="106",detemailad="Anna.Ring@monashhealth.org",updatetag="627448  ;80122103634",status="ok"

I've added this feature request to the backlog. I'll get back to you on the topic of ensuring that it doesn't export in Plus.

Hi Huu,

Which version of Identity Broker Plus are you running? If you are not on v5.1.1 RTM, could you please upgrade to it (download available from here).

It is v5.1.0 and all the plugins are 5.1.0.1 expect for AD is 5.1.1

IDB PLUS was installed before I was assigned to the project.

So I just confirm that upgrading to v5.1.1 will fix the issue?

Is it correct that the issue was an incorrectly formatted value being exported to the object class? Instead of multiple object classes a semi-colon separated value was being exported?

Nope Adam. Incorrectly formatted export is the cause of AD-provisioning issue. It is a separate one.

Ah that's right. Did the upgrade fix up the issue?

The upgrade indeed reduce the severity of the issue. There aren't thousand of writebacks ( =  thousand of errors) anymore. I have not chance to test it again but I envision the core issue is still unresolved. In the solution, there are 2 writeback fields: email and telephone. for a new person, if phone field is populated but email isn't created in time, the error will come up.

I believe that is why FIM has option of exporting null value.

Huu

Thanks for the update. Yes, there's an item on the backlog for the connector to investigate this.

Hi Adam,

Monash Health has restarted the project. I just want to follow up the status of the issue as it is one of the outstanding item. It is great if you can indicate the timeframe.

Thanks,

Huu

What is the impact? I was under the impression that there was almost no impact now that most of the exports won't be attempted.

Hi Adam,

The impact in this project is failure of export writing back new user into Chris21 when AD has not generated an email address. Are we able to have an option of suspending exporing/writeback until emailaddress is generated?

Regards,

Huu

So just some errors? It's on the backlog, the priority will be bumped up if there's actually an impact to the business.

Or am I misreading that. You have a use case to export new users and can't achieve that?

Hi Adam,

That is correct. I did DEV implementation and this issue surfaced. When going into UAT, there will surely be a test case of onboardinh a new user and I dont think there tester will pass the case with this error. 

I can live with a delayed export (wait for all writeback attributes poulated) but I dont think I can convince them to ignore the error. 

Can you pls suggest a way moving forward. 

Thanks,

Huu

I can live with a delayed export.

The feature request is on the backlog.

I don't think I can convince them to ignore the error.

If you delay the export wouldn't that stop it from happening?

For the backlog item, could you confirm that the cbr="CBRadd" works when detemailad is omitted? Also, would you need control over which fields behave in the new manner? As well as control over whether it happens for just add, update or both?

Thanks.

Hi Adam,

My VPN access has not been re-enable yet hence I cannot test. Regarding to controlling the write-back, I believe different source systems have different schema and constraints. The solution should be flexible to allow checking for those constraint in IdentityBroker Plus before doing the writeback to avoid such error.

Regards,

Huu