Integration Server 10.15 | Publish-Subscribe Developer’s Guide | Synchronizing Data Between Multiple Resources | Setting Up Key Cross-Referencing in the Target Integration Server
 
Setting Up Key Cross-Referencing in the Target Integration Server
The canonical document is published to the target Integration Servers. This section describes how to define the logic for a target Integration Server to:
*Receive the canonical document.
*Use the canonical document to build a document to inform the target resource of the data change. This document has a structure that is native to the target resource.
*Send the native document to the target resource, so the target resource can make the equivalent data change.
You create a service to build the native document and send it to the target resource. The logic to build the native document uses built-in services for key cross‑referencing, which are described in Built-In Services for Key Cross-Referencing. In this chapter, the service that receives the canonical document and builds a native document is referred to as an update service.
The following diagram highlights the part of data synchronization that this section addresses.
To set up key cross‑referencing in the target Integration Server:
*Create a trigger that subscribes to the canonical document that the source server publishes. On the target Integration Servers, define a trigger that:
*Subscribes to the publishable document type that defines the canonical document.
*Defines the trigger service to be the service that builds the builds a native document for the target resource.
For more information, see webMethods Service Development Help.
*Create an IS document type that defines the structure of the document that the target Integration Server needs to send to the target resource to notify it of a data change. For more information about how to create IS document types, see webMethods Service Development Help.
*Create the trigger service that uses the canonical document to build the target native document and sends the native document to the target resource. The service receives the canonical document, which contains the description of the data change to make. However, typically the target resource will not understand the canonical document. Rather, the target resource requires a document in its own native format.
The service can build the native document for the target resource by mapping information from the canonical document to the target resource’s native document format. Make sure you include the native ID in this document. To obtain the native ID, invoke the pub.synchronization.xref:getNativeId built‑in service. If the native ID is cross‑referenced with the canonical ID in the cross‑reference table, this service returns the native ID. If no cross‑reference has been set up for the object, you will need to determine the best way to obtain the native ID.
After forming the native document, the trigger service interacts with the target resource to make the data change.
Note:
For a description of the built‑in services that webMethods provides for key cross‑referencing, see Built-In Services for Key Cross-Referencing.
The following shows sample logic for the update service. See the table after the diagram for more information.
Step
Description
1
Obtain the native ID for the target object if there is an entry for the target object in the cross-reference table. Invoke the pub.synchronization.xref:getNativeId service to locate a row in the cross-reference table for the target object. If the row already exists, the row contains the native ID for the target object. Pass the getNativeId service the following inputs that identify the target object:
In this input variable...
Specify...
appId
The identification of the application (e.g., Billing system).
objectId
The object type (e.g., Account).
canonicalKey
The canonical ID from the canonical document, which was received as input to your service.
If the getNativeId service finds a row that matches the input information, it returns the value of the native ID in the nativeId output variable. If no row is found, the value of the nativeId output variable is blank (i.e., an empty string). For more information about the getNativeId service, see the pub.synchronization.xref:getNativeId.
2
Split logic based on whether a native ID was obtained for the target resource. Use a BRANCH flow step to split the logic. Set the Switch property of the BRANCH flow step to nativeId, to indicate that you want to split logic based on the value of the nativeId pipeline variable.
3
Build a sequence of steps to execute when the native ID is not obtained. Under the BRANCH flow step is a single sequence of steps to perform only if a native ID was not found. Note that the Label property for the SEQUENCE flow step is set to blank. At run time, the server matches the value of the nativeID variable to the label field to determine whether to execute the sequence. Because the nativeId variable is set to blank (i.e., an empty string), the Label field must also be blank.
Important:
Do not use $null for the Label property. An empty string is not considered null.
4
If no native ID was obtained, specify one. If a native ID was not found, add a row to the cross‑reference table for the target object to cross‑reference the target native ID with the canonical ID by invoking the pub.synchronization.xref:insertXReference service. Pass the insertXReference service:
In this input variable...
Specify...
appId
The identification of the application (e.g., Billing system).
objectId
The object type (e.g., Account).
nativeId
The native ID for the object in the target resource. You must determine what the native ID should be.
canonicalKey
The canonical ID from the canonical document, which was received as input to your service.
For more information about the insertXReference service, see the pub.synchronization.xref:insertXReference.
5
Build the native document for the target resource. To build the native document, map fields from the canonical document to the fields of native document. Also map the native ID to the native document.
The canonical document has the structure that you previously defined with a publishable document type. See Defining the Structure of the Canonical Document. Similarly, the native document has the structure that you previously defined with an IS document type.
Note:
Although this sample logic shows only a single MAP flow step, you might need to use additional flow steps or possibly create a separate service to build the native document for the target resource.
6
Invoke a service to send the native document to the target resource, so the target resource can make the equivalent change. Create a service that sends the native document to the target.
If you use an adapter with your target resource, you can use an adapter service to update the target resource. For more information about adapter services, see the documentation for your adapter.