updatePerson

Description
This transaction is used to update, correct, or add the details of a Person party and any of its associated business objects. If Critical Data Change processing is enabled, updates of noncritical data are processed immediately upon submission of the transaction request. If changes to critical data are submitted, the changes are held in a staging area, pending investigation prior to acceptance. An indicator representing the pending Critical Data Change is set on the Person record for all to see. Critical data is predefined. Default critical data for a Person is the first and last names, gender, social security or insurance number, date of birth, and address.
Web Services
Operation name: updatePerson
Service name: PartyService
Example
Update Jane's person party details to change her marital status to Married, expire her existing Primary Residence address, and add a new Primary Residence address.
Usage information
This transaction is a coarse-grained transaction. All business objects (with its critical and noncritical data elements) associated with a Person can be updated through this transaction.
Preconditions
Person must exist.
Mandatory input
  • PartyId
  • LastUpdateDate
Inquiry levels
Not applicable
Filter values
Not applicable
Transaction behavior

If Critical Data Change processing is not enabled, both critical and noncritical data submitted through this transaction is immediately processed and reflected in the existing party record. If configured, a notification of any resulting critical data change is generated.

If Critical Data Change processing is enabled, when InfoSphere® MDM recognizes any of the defined critical data in a transaction request, a record of the Critical Data Change is created and held pending for acceptance. A notification of the Critical Data Change request is generated upon creation of the Critical Data Change record.

All critical and noncritical data belonging to the same business object contained in the same update request is grouped into and treated as a single Critical Data Change. For example, gender, date of birth, and marital status all belong to the TCRMPersonBObj. If all are contained in an update request, a single Critical Data Change record is created with two critical and one noncritical data elements. This Critical Data Change must be accepted or rejected in its entirety as a single unit. In other words, noncritical data belonging to the same object as the critical data submitted for acceptance is handled in the same way as critical data. If there is no associated critical data pending, the update of noncritical data is processed immediately without having to go through the acceptance process.

Once a pending Critical Data Change request is created, an indicator is activated on the party record that prohibits the subject party from collapsing with other parties, splitting into new parties. A pending Critical Data Change indicator also prevents further updates of other critical data or noncritical data for the same object as the existing pending Critical Data Change. Further, a Person with a pending Critical Data Change is ignored by the “best match” rule in suspect processing until the indicator is off. This pending indicator is switched off when there is no associated unresolved Critical Data Change.

Request message
<TCRMTxType> updatePerson

<TCRMTxObject> TCRMPersonBObj

<TCRMObject> TCRMPersonBObj with associations

Optional business object:
Response objects
TCRMPersonBObj with associations
If Critical Data Change processing is enabled:
Optional business object:
Special Notes
  • Only one pending Critical Data Change is allowed at any given time. This rule will not be overridden by any other direct update transaction such as updatePartyCriticalData.
  • When this transaction is invoked through a composite transaction such as addParty or addPerson, and suspect processing is on, the best A1 match without any pending Critical Data Change will be updated even if the update involves critical data. The best A1 match with pending Critical Data Change will be skipped over even if the new party has identical critical data or only slightly different noncritical data.
  • As long as an update request does not contain any updates to instances of business objects that currently have an active pending Critical Data Change, the update response will indicate success. When the update request contains an instance of a business object that currently has a pending Critical Data Change, the update response will indicate failure. No partial update or add will be performed for any critical or noncritical data that was included in the failed update request.
  • Updates of the AccessDateValue business object as part of this transaction are dependent on the properties value of the global flag for attrib_access_date_value. If this flag is turned on, then this transaction can be used to update the AccessDateValue business object at the attribute level.