Vincular registros de origem ou destino usando IDs compartilhados no Jitterbit Design Studio
Caso de uso
Um problema comum de integração é que os registros de origem e destino precisam de um ID de registro compartilhado, motivado pela necessidade de vincular registros e/ou fornecer dados necessários para outras transações.
Exemplo 1
Um exemplo típico é buscar dados mestres de uma Fonte de Registro, enviar para uma Fonte de Transação e, mais tarde, usar esse ID para atualizar a Fonte de Registro. Nesse caso, o SOR é SAP, enquanto o SOT é Salesforce.
Um IDoc é recebido do SAP que contém informações do Cliente (especificamente Sold-Tos) 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 será o número do cliente da cotação, que foi carregado em uma operação anterior.
Quando uma cotação é criada no SFDC, uma SFDC Outbound Message é enviada ao Jitterbit contendo apenas o SFDC ID. Uma consultar usa esse ID para obter um objeto Quote do cliente, que tem um relacionamento com Account e seu SAP_Key__c. O SAP_Key__c contém o SAP customer ID.
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, é o relacionamento Conta/Cliente para Contatos. Aqui, Contatos no SFDC são inseridos no NetSuite.
Essa cadeia de operações consulta contatos novos ou alterados, os insere novamente usando a API SOAP e, em atualizações bem-sucedidas do NetSuite, executa uma atualização em massa de volta para o SFDC.
Dois IDs SFDC estão envolvidos no upsert para o Netsuite. O ID de contato é capturado "(Id para Id), e também o ID da conta (Account.NetSuite_Id_original__c para Account_NetSuite_Id_original__c).
Finalmente, o ID de contato do SFDC é inserido (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).