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. |