0
Answered

Chris21 Writeback failed

Huu Tran 1 year ago in UNIFYBroker/Frontier ichris/chris21 • updated 11 months ago 24

Basically, Chris21 does not allow write null into 'detemailad' field but there is no mechanism in the connector to choose not to export null value (FIM does have this feature though). The error message:


20180119,23:59:52,UNIFY Identity Broker,Update,Error,"Chris 21
Exception occured after [00:00:00.7170553] duration.

System.IO.InvalidDataException: Result record has an invalid ""status"" attribute value.

status=""fail"" existing.
status=""ok"" expected. Line: GTR,F76U81 0    Y3661W25     5910 005U2YNI97 0 42:cbr=""DETupd"",detnumber=""506797"",detworkphone,detemailad,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"",error01=""BRE085detemailad:Value may not be empty."",status=""fail""

Chris21 GTR returned no additional error messages.
   at Unify.Product.IdentityBroker.Chris21Agent.CheckStatusAttribute(IChris21CommandLine chris21GtrCommandLine)
   at Unify.Product.IdentityBroker.Chris21Agent.StandardResultCheck(IChris21Record resultRecord, String module, IChris21ConnectorInformation connectorRequest)
   at Unify.Product.IdentityBroker.Chris21Agent.<Update>d__1a.MoveNext()",Normal
20180119,23:59:52,UNIFY Identity Broker,UpdateEntity,Error,"Chris 21
Exception occured after [00:00:00.7170553] duration.

Affected Versions:
Fixed by Version:

Answer

Answer

Hi Huu,

Upgrading may resolve this issue - the latest release includes a fix where entities were being "updated" (with no changes) in upstream systems even if no values were changed. With the latest version, the solution will not attempt to export changes for entities when their email hasn't changed.

Under review

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?



Answer

Hi Huu,

Upgrading may resolve this issue - the latest release includes a fix where entities were being "updated" (with no changes) in upstream systems even if no values were changed. With the latest version, the solution will not attempt to export changes for entities when their email hasn't changed.

Under review

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