A Forum reader recently asked this question:

“I’m trying to use a QUERY on the RELATIONSHIPS class-name, using the original PublisherCommandTransform coming with the Driver. The SOBID contains the IDs for relationships (manger, managedBy), but I cannot find them – and I get this error:

XDSParse: QUERY attribute 'SOBID' has incorrect schema format

And here are some insights from Martyn Durrant …


The availability of the Relationships Data on the Publisher Channel will depend on whether the iDoc has been created by a PFAL transaction of by a Change Pointers transaction. Remember, the Query will only look at the iDoc which has prompted the Publisher event – the Query will not access the SAP-HR database.

A PFAL transaction will generate an iDoc, which contains all data about the SAP-HR object. So if you have an “S” class object in a PFAL-generated iDoc, then if the SAP-HR object has relationships, the query will give you those relationships.

However, if the iDoc is generated by Change Pointers, then only the changed data will be in the iDoc – and so only changed data will be available in any Query against the iDoc.

Remember also that the Date Handling setting in your Connector Configuration will also affect what data you see in a RELATIONSHIPS Query.

If you have specified that you do not want future dated data on the Publisher Channel, then the XML coming from a PFAL iDoc or a Change Pointers iDoc will not have any future dated Relationships.

If you have specified that you do not want past dated data on the Publisher Channel, then the XML coming from a PFAL iDoc or Change Pointers iDoc will not have any past dated Relationships. This can give you real problems in Change Pointer prompted iDocs.


Suppose you have two B relationships from an “S” object (let’s say Position 50000002 has had Positions 50000004 and 50000006 reporting to it since 14 January last year). Then the B Relationship for 50000004 will have a date range of 2005011499991231, and the B Relationship
for 50000006 will also have a date range of 2005011499991231.

Also suppose the existing B relationship with 50000005 is removed and a new B Relationship
with Position 50000023 is added. Then the Change Pointers iDoc will show that the B relationship for 50000004 has been changed to have a date range of 2005011420060814, and the new B relationship for 50000023 has a date range of 2006081499991231 – the iDoc will not have any reference to the B relationship with 50000006.

If your IDM Connector does not process past data, then the XML generated from the iDoc will only show the relationship with 50000023, the change to the Relationship with 50000004 will not appear (because it is past-dated) and the relationship with 50000006 will not appear (because it was not in the Change Pointer iDoc).

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

No Comments
Aug 30, 2006
12:00 am
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow