Integration Server 10.15 | Publish-Subscribe Developer’s Guide | Synchronizing Data Between Multiple Resources | Setting Up Key Cross-Referencing in the Source Integration Server | Setting up the Source Integration Server
 
Setting up the Source Integration Server
To set up key cross‑referencing in the source Integration Server:
*Create a trigger to subscribe to the source resource’s notification document, if applicable. You only need to define a trigger that subscribes to the notification document if the source resource publishes the notification document (i.e., either an adapter notification or other native document). If the source directly passes the notification document to a service as input, you do not need to define a trigger. If you need to define a trigger, define the trigger that:
*Subscribes to the publishable document type that defines the notification document (i.e., either an adapter notification or other native document).
*Defines the trigger service to be the service that builds the canonical document from the notification document.
For more information, see webMethods Service Development Help.
*Create the trigger service that builds the canonical document and publishes the canonical document to propagate the data change to all target resources. You need to create a service that puts the data change information into a neutral format that all targets understand. The neutral format is the canonical document.
The service builds the canonical document by mapping information from the notification document to the canonical document. To obtain the canonical ID for the canonical document, the service uses the built‑in key cross‑referencing services pub.synchronization.xref:getCanonicalKey and/or pub.synchronization.xref:createXReference, as shown in the sample logic below. After forming the canonical document, your service publishes the canonical document.
Step
Description
1
Determine whether there is already a canonical ID. Invoke the pub.synchronization.xref:getCanonicalKey service to locate a row in the cross‑reference table for the source object. If the row already exists, a canonical ID already exists for the source object. Pass the getCanonicalKey service the following inputs that identify the source object:
In this input variable...
Specify...
appId
The identification of the application (e.g., CRM system).
objectId
The string that you assigned to identify the object (e.g., Account). This string is referred to as the object ID.
nativeId
The native ID from the notification document (e.g., adapter notification), which was received as input to your service.
If the getCanonicalKey service finds a row in the cross‑reference table that matches the input information, it returns the value of the canonical ID in the canonicalKey output variable. If no row is found, the value of the canonicalKey output variable is blank (i.e., an empty string). For more information about the getCanonicalKey service, see pub.synchronization.xref:getCanonicalKey.
2
Split logic based on whether the canonical ID already exists. Use a BRANCH flow step to split the logic. Set the Switch property of the BRANCH flow step to canonicalKey.
3
Build a sequence of steps to execute when the canonical ID does not already exist. Under the BRANCH flow step is a single sequence of steps that should be executed only if a canonical 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 canonicalKey variable to the Label field to determine whether to execute the sequence. Because the canonicalKey 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 a null.
4
If there is no canonical ID, define one. If a row for the source object is not found in the cross‑reference table, there is no canonical ID for the source object. Define a canonical ID by adding a row to the cross‑reference table to cross‑reference the source native ID with a canonical ID. You add the row by invoking the pub.synchronization.xref:createXReference service. Pass the createXReference service the following:
In this input variable...
Specify...
appId
The identification of the application (e.g., CRM system).
objectId
The object type (e.g., Account).
nativeId
The native ID from the notification document (e.g., adapter notification), which was received as input to your service.
canonicalKey
(optional) The value you want to assign the canonical ID.
If you do not specify a value for the canonicalKey input variable, the createXReference service generates a canonical ID for you. For more information about the createXReference service, see pub.synchronization.xref:createXReference.
5
Build the canonical document. Map fields from the notification document (e.g., adapter notification) to the fields of the canonical document. Make sure you map the canonical ID generated in the last step to the canonical ID field of the canonical document.
The notification document has the structure that you previously defined with a the publishable document type. See Defining How a Source Resource Sends Notification of a Data Change. Similarly, the canonical document has the structure that you previously defined with a publishable document type. See Defining the Structure of the Canonical Document.
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 canonical document.
6
Publish the canonical document. After the service has formed the canonical document, invoke the pub.publish:publish service to publish the canonical document to the messaging provider.