Topic
  • 5 replies
  • Latest Post - ‏2013-12-02T20:29:18Z by Victor.w
Victor.w
Victor.w
6 Posts

Pinned topic requesterName propagated through all LastUpdateUser

‏2013-11-29T19:35:41Z |

Hi,

Since requesterName is a mandatory field in OOTB MDM, currently when specifying requsterName, all child components LastUpdateUser will be overwritten by the value speicified of requesterName even provided with different names.

 

 Is there any configuration which can turn the overwritting behavior off so that LastUpdateUser names can be persisted?

  • SJH
    SJH
    5 Posts

    Re: requesterName propagated through all LastUpdateUser

    ‏2013-12-01T15:06:12Z  

     The value provided by the requesterName is the only value that will update any changed objects/child objects within that single service call and this is by design to support auditing -- to provide traceability to the system/user executing the transaction and the changes made in that transaction.    What is the requirement where one would not want that level of audit?  How would two different users make changes to objects in a single service call? 

     

     

     

  • Victor.w
    Victor.w
    6 Posts

    Re: requesterName propagated through all LastUpdateUser

    ‏2013-12-01T20:47:18Z  
    • SJH
    • ‏2013-12-01T15:06:12Z

     The value provided by the requesterName is the only value that will update any changed objects/child objects within that single service call and this is by design to support auditing -- to provide traceability to the system/user executing the transaction and the changes made in that transaction.    What is the requirement where one would not want that level of audit?  How would two different users make changes to objects in a single service call? 

     

     

     

    in updateParty service, by design, it is suggested to update all fine-grained objects at once. We have requirement to inherit all auditing fields from legacy source systems, by which means we have to insert different LastUpdateName for update.

  • FabioV
    FabioV
    1 Post

    Re: requesterName propagated through all LastUpdateUser

    ‏2013-12-02T08:25:06Z  
    • Victor.w
    • ‏2013-12-01T20:47:18Z

    in updateParty service, by design, it is suggested to update all fine-grained objects at once. We have requirement to inherit all auditing fields from legacy source systems, by which means we have to insert different LastUpdateName for update.

    Use a different user for every source system?

  • SJH
    SJH
    5 Posts

    Re: requesterName propagated through all LastUpdateUser

    ‏2013-12-02T15:26:41Z  
    • Victor.w
    • ‏2013-12-01T20:47:18Z

    in updateParty service, by design, it is suggested to update all fine-grained objects at once. We have requirement to inherit all auditing fields from legacy source systems, by which means we have to insert different LastUpdateName for update.

    LastUpdateUser represents the user that executes the updateParty service and is an MDM-based audit field.  If you need a source-based audit field you will need to provide that value as extension attribute.  Is this a one-time value population on initial load?

    Once you have loaded the information in the system from the sources - are you not managing (add/update) the information in MDM?  In this case, the requesterName should be the true audit value as the information is managed in MDM.

     

     

  • Victor.w
    Victor.w
    6 Posts

    Re: requesterName propagated through all LastUpdateUser

    ‏2013-12-02T20:29:18Z  
    • SJH
    • ‏2013-12-02T15:26:41Z

    LastUpdateUser represents the user that executes the updateParty service and is an MDM-based audit field.  If you need a source-based audit field you will need to provide that value as extension attribute.  Is this a one-time value population on initial load?

    Once you have loaded the information in the system from the sources - are you not managing (add/update) the information in MDM?  In this case, the requesterName should be the true audit value as the information is managed in MDM.

     

     

    The issue is even we created extension fields say XLastUpdateUser, so from legacy system, we are able to migrate different names according to objects.

    However, in cases where we really need to take advantage of requesterName propagating through, it won't be able to set in XLastUpdateUser but OOTB LastUpdateUser field. I know you would then suggest getting and setting from DWLControl, however, we don't want LastUpdateUser/XLastUpdateUser set twice where consistent view for our auditing purpose will be defeated.

    What I am thinking is really IBM should consider adding a global switch to turn on/off requesterName propagation and if possible introduce a interim fix.