This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Virtual property of type "object reference" is not updated

Hello !

In one of our sync project we used a virtual property of type "Object reference", with the following route: "UID_Person.CCC_JobCategory.Ident_Org".

We have created a mapping rule between our virtual property and the property of the LDAP target system where we want to push the value.


When we change the value of the CCC_JobCategory attribute of a Person who has an LDAPAccount (i.e. there is an entry in LDAPAccount with UID_Person set), no update is triggerred on the LDAPAccount.

If we manually trigger an update on the LDAPAccount object (by modifying an attribute like "street" for example), the LDAP_LDAPAccount_Update/(De)Activate process is triggered and updates the "street" attribute, but the LDAP attribute mapped to our virtualproperty is not set or changed if it was wrong.

It looks like our virtual property is doing nothing, and I'm afraid we may have misunderstood the way this type of virtual property worked.

Can someone please details the way it works, and when?

Thanks in advance for your help!

I'd love to post some screenshots but that seems to be impossible without an external hosting service...

  • Hi Robin,

    the virtual attributes are calculated during the execution of the synchronization or ad-hoc projection by the synchronization engine and only by the synchronization engine.

    In your use-case, you need to instruct the system that it should trigger such an ad-hoc projection to the target system.

    I propose two options:

    • Option A: You create a process that triggers in the UPDATE event on the Person table with the gen.condition $CCC_JobCategory[c]$ = True (only when this property has changed) that then fires the UPDATE event on the assigned LDAPAccount object. That should trigger the process LDP_Account_Update/(De-)Activate.
    • Option B: You use a custom column at the LDAPAccount and fill this column by a template from $UID_Person.CCC_JobCategory.Ident_Org$
  • Hello Markus,

    I read the doc below to which you referred in another post ...

    https://support.oneidentity.com/technical-documents/identity-manager/8.0/target-system-synchronization-reference-guide/13#TOPIC-863256

    ... but I didn't manage to understand the precise conditions in which the virtual attribute is pushed in the mapping or not.

    For instance, in Robin's example, I don't understand why an update of the "street" attribute does not launch the so-called "synchronization engine" and thereby compute and push the virtual attribute. I mean as soon as the street attribute is modified, I guess an UPDATE event is generated against the corresponding LDAPAccount and then we should be in your option A above from what I understand.

    In other words, what are the specific conditions in which a virtual attribute is pushed to a target system ? I didn't find the answer in the documentation.

    BTW, virtual attributes are apprently not mentioned in the table DPRJournalProperty ? Tell me if I am wrong.

    Many thanks.

    Michel

  • Hi Michel,

    speaking generally a virtual attribute is pushed out to a target system when a mapping rule exists that takes this attribute and writes it to a property at the target system. 

    The tricky thing is, to trigger the update process for, to stay with the sample, the LDAPAccount object when the object itself hasn't changed at all. And this is the case when the virtual property is defined as UID_Person.CCC_JobCategory.Ident_Org. And that's why I proposed option A that helps in firing the update event on LDAPAccount when the CCC_JobCategory changed at the Person.

    Why the virtual object doesn't flow to the target system when the street attribute is changed can depend on several reasons, for example, the mapping rule definition for the property and potentially the version of OneIM he is using. It could be as well, that he needs to set the parameter ForceSyncOf for the provisioning tasks of the LDAPAcccount, to contain the virtual property.

    I cannot confirm that virtual attributes are not logged to DPRJournalProperty. I have some of them in my data set.