- Use QUERY action
- Connector retrieves ALL available messages on channel (“queue”)
- Utilize Full vs. Diff channel
- Full – Returns all the fields regardless of which ones were updated
- Diff – Returns only the fields that were updated
- Use a Route shape by @op attribute (CREATE, UPDATE, DELETE) to decide action against destination app
- Retrieve each MDM object independently. May need to make several passes to fully populate a record in the destination app (e.g. NetSuite customer with address list)
IMPORTANT: Connector auto-acks upon receiving messages before passing all the docs into the process. This removes them from the channel. This means if the process fails you cannot re-query the channel to retrieve the messages again. The process is responsible for delivering the message to the final destination.
Rare but troublesome: You can get multiple updates for the same record at once if multiple updates were sent from other apps before the given channel was queried. This can cause API issues when syncing back to the apps. Because our connectors typically batch requests, it’s possible to have multiple updates for the same record in the same physical request. Most applications such as SFDC and NS will reject the entire batch. Mitigate with frequent polling and/or elaborate in-process dupe checking….
- No need to re-import operation after modifying MDM model fields. Just manually update profile(s) to match model schema.
- When creating a new record in destination app, upon success immediately upsert MDM with new “entity ID” to establish linkage. This allows any MDM child objects to be published.