Link Source or Target Records Using Shared IDs¶

Use Case¶

A common integration problem is that the source and target records need a shared record ID, driven by the need to link records and/or provide required data for other transactions.

Example 1¶

A typical example is to fetch master data from a Source of Record, send to a Source of Transaction, then later on use that ID to update the Source of Record. In this case, the SOR is SAP, while the SOT is Salesforce.

An IDoc is received from SAP which contains Customer information (specifically Sold-Tos), and is upserted into SFDC Accounts. The ET_MOSI_SAP_Key__c holds the SAP Customer ID.

Later, when a quotation created in SFDC (the Source of Transaction) needs to be created in SAP, a required field is the quotation's customer number, which was loaded in a previous operation.

When a quote is created in SFDC, an SFDC Outbound Message is sent to Jitterbit containing just the SFDC ID. A query uses that ID to get a customer Quote object, which has a relationship to Account and it's SAP_Key__c. The SAP_Key__c holds the SAP customer ID.

Here we map the SAP_Key__c to the SAP PARTN_NUMB.

Example 2¶

Another example is where a relationship in one system must be preserved in the other. In this case, it is the Account/Customer relationship to Contacts. Here, Contacts in SFDC are upserted into NetSuite.

This chain of operations queries for new or changed contacts, upserts them using the SOAP API, and on successful NetSuite updates, performs a Bulk update back to SFDC.

Two SFDC IDs are involved in the upsert to Netsuite. The contact ID is captured "(Id to Id), and also the Account ID (Account.NetSuite_Id_original__c to Account_NetSuite_Id_original__c).

Finally the SFDC Contact ID is upserted (Id to SFDC_Id__2_) and the Account ID is used to associate the contact to it's parent Account (Account_NetSuite_Id_original__c to company.internalId).