Contact web service changes

The ContactAPI web service lets an external system manipulate contact data in PolicyCenter. ContactManager calls this web service.

Transaction IDs no longer used

In version 7.0, some methods took a transaction ID, which represented a unique identifier for an update request. If a request is duplicated later, PolicyCenter identifies it as duplicate by its transaction ID and does not repeat the request.

In 8.0, methods no longer take transaction IDs. Instead, they have the annotation @WsiCheckDuplicateExternalTransaction, which automatically enforces unique transaction IDs based on SOAP headers. This change affects the following methods:

  • updateContact
  • removeContact
  • mergeContacts

If the web service client is another Guidewire application, you can set the transaction ID with the method ContactAPIUtil.setTransactionId.

New methods for address book client API

The ABClientAPI published by ContactManager 8.0 has the following new methods to help manage changes to contact information:

  • pendingUpdateApproved
  • pendingCreateApproved
  • pendingUpdateRejected
  • pendingCreateRejected

These methods are intended as callbacks from the ContactAPI web service that the InsuranceSuite applications PolicyCenter, BillingCenter, and ClaimCenter publish for ContactManager to call. However, each application differs in how its implementation of the ContactAPI web service uses the methods call back to the ABClientAPI that ContactManager publishes.

PolicyCenter does not generate pending changes for ContactManager, so the callback methods are not called in the default configuration. PolicyCenter throws an exception.

See also