Bugs
CIT Identity Broker should NOT return update from NIM back to NIM as ADD
This issue relates to another situation wherby the expected response from a connected system is different for Novell Identity Manager (NIM) than for FIM.
Here is the process that currently occurs at CIT:
1. A new record for a person is created in eDirectory at CIT
2. The NIM driver for Identity Broker sends the new record to IdB
3. IdB acknowledges the new record to NIM and sends back the unique number to use to associate that record
4. On next poll of IdB by NIM, IdB sends the new record from item 1 as an ADD
5. NIM processes the record as an add
6. During the ADD processing NIM identifies that it already has a record for that person & changes the add to a modify
7. NIM processing contines to process data from the record as a modify, potentially sending updates to other connected systems
Here is the process that NIM would expect to see:
1. A new record for a person is created in eDirectory at CIT
2. The NIM driver for Identity Broker sends the new record to IdB
3. IdB acknowledges the new record to NIM and sends back the unique number to use to associate that record
4. On next poll of IdB by NIM, IdB does NOT send any information back to NIM, the new record will apear in IdB as a complete record but is not passed to NIM as an update.
I.e. Because NIM uses the acknowledgement from IdB as an indication that the record was recieved by the connected system it doesn't need the ADD to be sent back, when the ADD from IdB is seen by NIM it thinks that it is an actual add for that person... I realise that FIM does require the new record to be seen as an add, however NIM does not.
In summary here is what I would like to see: If an add / modify is sent by NIM to IdB that should NOT be presented back to NIM as an add / modify it shuld just update IdB and IdB should effectively consider that the add / modify has already been sent to NIM.
NIM 3075 patch.zip
ST-FullTransaction-2012-05-09.xml
Customer support service by UserEcho
Hey Patrick, I have assigned this issue to you given the help you have provided on other NIM / IdB related issues.
I would have called to discuss with you first... but you are lucky and have a public holiday today.
Please call me if you need any further explanation.
Very lucky indeed!
Understand the issue, I'll work with Adam tomorrow to see how much effort will be involved in this and I'll get back to you ASAP.
Hi Nick,
I've attached some debug assemblies which may resolve the issue. It's not a guarantee, but it's the only thing we can attempt without changing the Identity Broker service as well.
If it doesn't work we'll have to invest some more time in it. You should at least get a different result to before, so let us know if you notice any differences between before and now.
Hey Patrick, still no success, actually the response I get back from IdB is the same, it sends me an ADD record... I will paste some relevent parts of the Novell IdM tracefile to explain (I think). I will also upload the entire log-file.
The following log entries relate to the detail that was sent by NIM to IdB and immediate response from IdB to NIM (this response is correct by the way):
9/05/2012 14:32:55.46v: 0 CIT Driver L3 ST:Submitting document to subscriber shim:
9/05/2012 14:32:55.46v: 0 CIT Driver L3 ST:
<nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.10.4747">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="person" event-id="W2K3-R2-001-NDS#20120509043255#99#1" qualified-src-dn="O=RES\OU=Users\OU=User\CN=AA102976" src-dn="\SAWWFT\RES\Users\User\AA102976" src-entry-id="36825">
<association state="migrate"></association>
<add-attr attr-name="cn">
<value naming="true" timestamp="1306073921#32" type="string">AA102976</value>
</add-attr>
<add-attr attr-name="fullName">
<value timestamp="1311557269#18" type="string">Aardvaark, Jane</value>
</add-attr>
<add-attr attr-name="givenName">
<value timestamp="1311252610#25" type="string">Jane</value>
</add-attr>
<add-attr attr-name="objectGUID">
<value timestamp="1306073921#33" type="octet">5Qr/WKisoEqCddbcGIRXrw==</value>
</add-attr>
<add-attr attr-name="sn">
<value timestamp="1311287319#2" type="string">Aardvaark</value>
</add-attr>
<add-attr attr-name="workforceID">
<value timestamp="1306073921#8" type="string">102976</value>
</add-attr>
</add>
</input>
</nds>
9/05/2012 14:32:55.46v: 0 CIT Driver L3 ST:UnifySubscriptionShim: execute start
9/05/2012 14:32:55.47v: 0 CIT Driver L3 ST:UnifySubscriptionShim: createWebServiceInterface: URL: http://192.168.16.230:59990/IdentityBroker/NIMDriver.svc?wsdl
9/05/2012 14:32:55.47v: 0 CIT Driver L3 ST:UnifySubscriptionShim: createWebServiceInterface: Creating service
9/05/2012 14:32:55.48v: 0 CIT Driver L3 ST:UnifySubscriptionShim: createWebServiceInterface: Creating interface
9/05/2012 14:32:55.50v: 0 CIT Driver L3 ST:UnifySubscriptionShim: createWebServiceInterface: Returning port
9/05/2012 14:32:56.77v: 0 CIT Driver L3 ST:UnifySubscriptionShim: execute end
9/05/2012 14:32:56.77v: 0 CIT Driver L3 ST:SubscriptionShim.execute() returned:
9/05/2012 14:32:56.77v: 0 CIT Driver L3 ST:
<nds dtdversion="1.0" ndsversion="8.5">
<output>
<response event-id="W2K3-R2-001-NDS#20120509043255#99#1" level="success"/>
<add-association dest-dn="\SAWWFT\RES\Users\User\AA102976" dest-entry-id="36825" event-id="W2K3-R2-001-NDS#20120509043255#99#1">5Qr/WKisoEqCddbcGIRXrw==</add-association>
</output>
</nds>
The following is the next poll & the result back from IdB:
9/05/2012 14:33:12.00v: 0 CIT Driver L3 PT:UnifyPublicationShim: polling
9/05/2012 14:33:12.00v: 0 CIT Driver L3 PT:UnifyPublicationShim: createWebServiceInterface: URL: http://192.168.16.230:59990/IdentityBroker/NIMDriver.svc?wsdl
9/05/2012 14:33:12.00v: 0 CIT Driver L3 PT:UnifyPublicationShim: createWebServiceInterface: Creating service
9/05/2012 14:33:12.01v: 0 CIT Driver L3 PT:UnifyPublicationShim: createWebServiceInterface: Creating interface
9/05/2012 14:33:12.03v: 0 CIT Driver L3 PT:UnifyPublicationShim: createWebServiceInterface: Returning port
9/05/2012 14:33:12.70v: 0 CIT Driver L3 PT:Receiving DOM document from application.
9/05/2012 14:33:12.70v: 0 CIT Driver L3 PT:
<nds dtdversion="1.0" ndsversion="8.5">
<input>
<add class-name="person" event-id="1" src-entry-id="5Qr/WKisoEqCddbcGIRXrw==">
<association>5Qr/WKisoEqCddbcGIRXrw==</association>
<add-attr attr-name="fullName">
<value>Aardvaark, Jane</value>
</add-attr>
<add-attr attr-name="sn">
<value>Aardvaark</value>
</add-attr>
<add-attr attr-name="givenName">
<value>Jane</value>
</add-attr>
<add-attr attr-name="objectGUID">
<value>5Qr/WKisoEqCddbcGIRXrw==</value>
</add-attr>
<add-attr attr-name="cn">
<value>AA102976</value>
</add-attr>
<add-attr attr-name="workforceID">
<value>102976</value>
</add-attr>
</add>
</input>
</nds>
As you can see this appears to be an ADD for the record that was just added to IdB by NIM.
Novell IdM Trace
Hey Patrick, thanks for looking at this... no luck so far. Tell me if you need more information?
Shouldn't need more info, but the problem now is there's nothing more we can do to fix it in the NIM adapter without changing the Identity Broker service as well, which may be difficult and time-consuming.
I'll work with Adam when we're both free to see if we can find an easy way to make it work.
Patrick / Adam,
Can I please get an ETA on this? - the priority should probably have been set higher than major. This is (as I undertand things) the last issue to resolve to get the solution in Prod and closed out.
Thanks,
Brad
As we have other critical issues at the moment this has, in the short term, been put to the side.
If it is preventing further work from taking place it should have been raised to Blocker originally.
I will endeavour to look at this with Adam this afternoon but we have no timeframe on a solution yet.
Hi Nick,
Adam and I are struggling without an environment, so I took a quick look at the NIM environment you've set up in Brisbane and it looks like you've already changed it to match the solution you're working on?
If that's the case, is there any way we can work in there with you? Basically what we'd like to do is;
To do this I believe we'll need to be able to
Is this something we could potentially arrange for?
Hey Patrick, yes, good idea.
I guess the primary issue here is the difference between FIM and Novell IdM. FIM expects the add to be presented back as an add (confirming import)... NIM works on the basis that the change sent to IdB (and acknowledged) has been accepted, anything returned by IdB on the next poll is expected to be a new transaction.
Anyway, what's the best way to deal with this?
Maybe we should schedule a Lync session & I can show you the basics of the NIM console so that you can do the following:
1. Start & Stop the driver
2. Send a record to IdB from NIM
3. View trace / logs etc in NIM
Hey Nick,
What actually errors in NIM? If it is getting the existing object back as an add and it already has an association it should happily match up to that in the association engine and send through the attributes as modifies. They will then be seen to be the same and will be dumped by the optimise routine.
Hey Eddie, no actual errors... what ends up happening is that the driver processes the Add from IdB & then re-sends the attributes back to IdB. So no error, just inefficient with lots of unnecessary processing.
Yep, understood. The issue for us is the change we made should have stopped changes from being reflected back. We'd like to use your environment firstly to confirm that it's working incorrectly in the same way we expect it's working incorrectly, and then to debug it and find out why.
Happy to have a Lync session. Few meetings today, so check and see if anything works for you, if not then we can do it first thing Monday.
Hi Nick,
Update on where we are:
On the subsequent poll I now see:
22/05/2012 11:35:04.25v: 0 CIT Driver L3 PT:UnifyPublicationShim: polling
22/05/2012 11:35:04.25v: 0 CIT Driver L3 PT:UnifyPublicationShim: createWebServiceInterface: URL: http://192.168.16.106:59990/IdentityBroker/NIMDriver.svc?wsdl
22/05/2012 11:35:04.25v: 0 CIT Driver L3 PT:UnifyPublicationShim: createWebServiceInterface: Creating service
22/05/2012 11:35:04.26v: 0 CIT Driver L3 PT:UnifyPublicationShim: createWebServiceInterface: Creating interface
22/05/2012 11:35:04.28v: 0 CIT Driver L3 PT:UnifyPublicationShim: createWebServiceInterface: Returning port
And no XML response seems to be provided after that. This suggests to me that we may have fixed it, but I'd like to confirm one more thing before I reverted those two parameters for you to test yourself:
We were occasionally seeing some errors caused by changes of type "Modify DN" being raised. I'm not sure if something we did caused this, but can you think of any reason why it would be doing that or have you seen it in the past?
Hey Patrick, looks very promising! I think there may have been "Modify DN" errors may have been related to the original implementation when IdB was returning the IdBID (rather than GUID) for the association value.
Alright - straight after lunch I'll revert those two attributes, apply the change to your environment (it's only in mine right now) then let you confirm. I'll let you know when it's been done.
I've applied the fix, reconfigured the environment and jumped off your machines. Resume the active RDP sessions and do whatever you need to test.
If you're satisfied with the fix, I'll package it up for you to apply on site.
Thanks again for all the help, particularly around using NIM - it should be much easier to make changes in the future and will make completing the last few pieces that we're missing easier too.
Thanks Patrick, I will look at it now.
Hey Patrick Love Your Work! Certainly fixes my issue, well done.
Hi Nick,
The attached zip contains all the files you'll need to update. It needs to be applied to the current candidate release of IdB 3.0.7, and will be included in the final release of 3.0.7 when that roles around.
Any more problems, let us know.