Vincular Registros de Origem Ou Destino Usando IDs Compartilhados

Caso de Uso

Um problema comum de integração é que os registros de origem e destino precisam de um ID de registro compartilhado, impulsionado pela necessidade de vincular registros e/ou fornecer dados necessários para outras transações.

Exemplo 1

Um exemplo típico é buscar dados mestre de uma Fonte de Registro, enviar para uma Fonte de Transação e, posteriormente, usar esse ID para atualizar a Fonte de Registro. Nesse caso, o SOR é SAP, enquanto o SOT é Salesforce.

Um IDoc é recebido da SAP que contém informações do cliente (especificamente Vendidos para) e é inserido em contas SFDC. O ET_MOSI_SAP_Key__c contém o ID do cliente SAP.

Posteriormente, quando uma cotação criada no SFDC (a Origem da Transação) precisar ser criada no SAP, um campo obrigatório é o número do cliente da cotação, que foi carregado em uma operação anterior.

Quando uma cotação é criada no SFDC, uma mensagem de saída do SFDC é enviada para o Jitterbit contendo apenas o ID do SFDC. Uma consultar usa esse ID para obter um objeto Cotação do cliente, que tem um relacionamento com Conta e é SAP_Key__c. O SAP_Key__c contém o ID do cliente SAP.

Aqui mapeamos o SAP_Key__c para o SAP PARTN_NUMB.

Exemplo 2

Outro exemplo é quando um relacionamento em um sistema deve ser preservado no outro. Neste caso, é a relação Conta/Cliente com Contactos. Aqui, os contatos no SFDC são inseridos no NetSuite.

Essa cadeia de operações consulta contatos novos ou alterados, atualiza-os usando a API SOAP e, em atualizações bem-sucedidas do NetSuite, executa uma atualização em massa de volta ao SFDC.

Dois IDs SFDC estão envolvidos no upsert para o Netsuite. O ID do contato é capturado "(Id para Id) e também o ID da conta (Account.NetSuite_Id_original__c para Account_NetSuite_Id_original__c).

Por fim, o ID do contato SFDC é atualizado (Id para SFDC_Id__2_) e o ID da conta é usado para associar o contato à sua conta pai (Account_NetSuite_Id_original__c para company.internalId).