Modify operation in an RMI adapter implementation, Return attributes are not getting updated in TIM

[r***@gmail.com]

Hi All,

I am seeking out some guidance with respect to an issue I am currently facing with my RMI adapter development.


Problem Statement:
The return attribute from an RMI adapter to ISIM in modify operation are not getting updated in TIM.

Background:
For a business requirement, I am currently developing an RMI adapter using TIM 6.X and TDI 7.2 version. The target resource returns a hash value as a response to every add and modify operation. As a requirement, this hash values should be stored in TIM for recon purpose.

In the Add operation, after creating an account in the target system, I am able to send the hash value (which I got as a response from target) from TDI to TIM and TIM is able to add that attribute/value in the user account. However, in the modify mode when I send an updated hash value back to TIM those values are not getting added/modified/replaced.

The request from TIM to TDI looks something like this

S_WORKENTRY_ATTR
accountid:delete:1234567:S_OPCODE:DELETE, 112233445566778899:S_OPCODE:DELETE, 112233445566:S_OPCODE:ADD,
entryDN:unchanged:BIMPR12:S_OPCODE:UNDEFINED,
eruid:unchanged:BIMPR12:S_OPCODE:UNDEFINED,
ergroup:add:customer-dummy_w:S_OPCODE:ADD, public-dummy_w:S_OPCODE:ADD

In modify operation, I am not sending this hash value attribute to TDI as this hash value is generated by the target system on each operation (Add /Modify). Here the expectation is, on completion of Modify operation at the target, TDI will get an updated hash value which TDI should pass it to TIM to store the updated hash value in TIM.

While setting the updated values in the response to modify operation, I have tried setting the Attribute operation and value operation to all possible combination of Add, Replace, modify in TDI but none of them takes effect in TIM.
( ref: https://www.stephen-swann.co.uk/javadoc/tdi7.0/com/ibm/di/entry/Attribute.html#OPER

work.accountidhash.setOper(Packages.com.ibm.di.entry.Attribute.ATTRIBUTE_ADD);
work.accountidhash.setValueOper(i, Packages.com.ibm.di.entry.AttributeValue.AV_ADD);
)

[Rajan Arora]

Post by r***@gmail.com
Hi All,
I am seeking out some guidance with respect to an issue I am currently facing with my RMI adapter development.
The return attribute from an RMI adapter to ISIM in modify operation are not getting updated in TIM.
For a business requirement, I am currently developing an RMI adapter using TIM 6.X and TDI 7.2 version. The target resource returns a hash value as a response to every add and modify operation. As a requirement, this hash values should be stored in TIM for recon purpose.
In the Add operation, after creating an account in the target system, I am able to send the hash value (which I got as a response from target) from TDI to TIM and TIM is able to add that attribute/value in the user account. However, in the modify mode when I send an updated hash value back to TIM those values are not getting added/modified/replaced.
The request from TIM to TDI looks something like this
S_WORKENTRY_ATTR
accountid:delete:1234567:S_OPCODE:DELETE, 112233445566778899:S_OPCODE:DELETE, 112233445566:S_OPCODE:ADD,
entryDN:unchanged:BIMPR12:S_OPCODE:UNDEFINED,
eruid:unchanged:BIMPR12:S_OPCODE:UNDEFINED,
ergroup:add:customer-dummy_w:S_OPCODE:ADD, public-dummy_w:S_OPCODE:ADD
In modify operation, I am not sending this hash value attribute to TDI as this hash value is generated by the target system on each operation (Add /Modify). Here the expectation is, on completion of Modify operation at the target, TDI will get an updated hash value which TDI should pass it to TIM to store the updated hash value in TIM.
While setting the updated values in the response to modify operation, I have tried setting the Attribute operation and value operation to all possible combination of Add, Replace, modify in TDI but none of them takes effect in TIM.
( ref: https://www.stephen-swann.co.uk/javadoc/tdi7.0/com/ibm/di/entry/Attribute.html#OPER
work.accountidhash.setOper(Packages.com.ibm.di.entry.Attribute.ATTRIBUTE_ADD);
work.accountidhash.setValueOper(i, Packages.com.ibm.di.entry.AttributeValue.AV_ADD);
)

Did some more changes and analysis, I can see that TDI is setting the attribute Operation as Replace, however, TIM is rejecting it with a message as "NOT_IMPLEMENTED - ignoring return attribute list" and commit the local data.

Any idea why TIM reject the TDI response to replace the attribute values with "NOT_IMPLEMENTED - ignoring return attribute list" message


<Trace Level="MID">
<Time Millis="1542000904622"> 2018.11.12 16:35:04.622+11:00</Time>
<Server Format="IP">XXXXXXXXXXXX</Server>
<ProductId>CTGIM</ProductId>
<Component>com.ibm.itim.remoteservices.ejb.mediation</Component>
<ProductInstance>ITIM_Application_Cluster_Member1</ProductInstance>
<LogText><![CDATA[NOT_IMPLEMENTED - ignoring return attribute list, size=3]]></LogText>
<Source FileName="com.ibm.itim.remoteservices.ejb.mediation.Connector" Method="filterAndUpdateLocalAccount"/>
<Thread>SIBJMSRAThreadPool : 6</Thread>
</Trace>

<Trace Level="MAX">
<Time Millis="1542000904628"> 2018.11.12 16:35:04.628+11:00</Time>
<Server Format="IP">XXXXXXXXXXXX</Server>
<ProductId>CTGIM</ProductId>
<Component>com.ibm.itim.remoteservices.ejb.mediation</Component>
<ProductInstance>ITIM_Application_Cluster_Member1</ProductInstance>
<LogText><![CDATA[Local change data:
C customoperation [TIM_delete]
C ergroup [customer-dummy_w, public-dummy_w]
C accountidhash [526404758660
]]></LogText>
<Source FileName="com.ibm.itim.remoteservices.ejb.mediation.Connector" Method="filterAndUpdateLocalObject"/>
<Thread>SIBJMSRAThreadPool : 6</Thread>
</Trace>

[Enio Padilla]

Hi Rajan,

I may be wrong, but I don't think there is a way to do an update back in TIM from a modify request. Take a look at the PDF file in the link below, is a custom adapter development guide from TIM v5.1 but it is mostly still relevant:

https://www.ibm.com/developerworks/community/forums/atom/download/attachment_14924271_im51-tdi-rmi-adapter-devref.pdf?nodeId=596cd840-eaf9-46a5-a521-83097e57188b

In particular read in page 37, the section named "How to create a RETURN entry and pass it back to dispatcher", as you can see there, if you pass any attributes in the return entry to TIM for a modify, it will interpret it as if that value couldn't be updated, and because that value doesn't match the previous value I believe that's why it's failing.

Can you trigger a filtered reconciliation for that account in the modify workflow, after the modify completes to get the updated attribute?

[Franzw]

Post by Enio Padilla
Hi Rajan,
https://www.ibm.com/developerworks/community/forums/atom/download/attachment_14924271_im51-tdi-rmi-adapter-devref.pdf?nodeId=596cd840-eaf9-46a5-a521-83097e57188b
In particular read in page 37, the section named "How to create a RETURN entry and pass it back to dispatcher", as you can see there, if you pass any attributes in the return entry to TIM for a modify, it will interpret it as if that value couldn't be updated, and because that value doesn't match the previous value I believe that's why it's failing.
Can you trigger a filtered reconciliation for that account in the modify workflow, after the modify completes to get the updated attribute?

I am pretty sure you can send back attributes on both add/modify operations. The reason for this is that a system may create/modify other attributes as the result (think Exchange as an example).

IIRC this was discussed in the Connection Security forum (https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000000259) a couple of years back - I do not have it handy here so I will have to locate it...

And this should really be discussed there as this is ISIM functionality and not SDI/TDI...

Regards
Franz Wolfhagen

[Alon Kendler]

Sounds like an RFE is in place.
The Developer guide (CNU2QEN) clearly states you can return an implicit value when ADD operation is triggered. nothing about MOD

Returning Implicit Attributes

On some resources, after an add operation, values of attributes that were not in the add request are set to some default by the resource itself. To return these attributes to ITIM, include them in the return entry and set the attribute operation to ATTRIBUTE_ADD and attribute value operation to AV_ADD. For example,

retWorkAttribute.addValue(retLookupAttr.getValue(j));

retWorkAttribute.setOper(Packages.com.ibm.di.entry.Attribute.ATTRIBUTE_ADD); retWorkAttribute.setValueOper(j,Packages.com.ibm.di.entry.AttributeValue.AV_ADD);

[Franzw]

Post by Alon Kendler
Sounds like an RFE is in place.
The Developer guide (CNU2QEN) clearly states you can return an implicit value when ADD operation is triggered. nothing about MOD
Returning Implicit Attributes
On some resources, after an add operation, values of attributes that were not in the add request are set to some default by the resource itself. To return these attributes to ITIM, include them in the return entry and set the attribute operation to ATTRIBUTE_ADD and attribute value operation to AV_ADD. For example,
retWorkAttribute.addValue(retLookupAttr.getValue(j));
retWorkAttribute.setOper(Packages.com.ibm.di.entry.Attribute.ATTRIBUTE_ADD); retWorkAttribute.setValueOper(j,Packages.com.ibm.di.entry.AttributeValue.AV_ADD);

Hey - it is unfair to read the documentation ;-)

But yes - and you are probably right - but let me just make a couple of things clear. If you compare the scenario with add then you have another complexity - the attribute could exist and is modified. This can be tricky - but you nsure that it is included on the account always ($(AO) object) in the service def. You would need to exclude it from the modify operation in the adapter logic, but update it if changed and send it back as modified if applicable.

If not available I would believe that the ATTRIBUTE_ADD method would also work in a modify situation - but that has to be tried out and potentially RFEed...

ATTRIBUTE_REPLACE I would guess would also work if one chose NOT to include the specific attribute - that would probably be simpler than what I have outlined above.

The reason I believe this would work is that in ISIM this is basically translated into standard ldap (actually jndi) operations - I do not think there are specific checks based on operation - but if one is trying to replace/modify an attribute that does not exist the system will probably object...

So some care has to be applied and careful design is needed - it looks so simple but it is not....

HTH
Regards
Franz Wolfhagen