Capture alterações de dados com uma API do API Manager ou endpoint HTTP no Jitterbit Design Studio

Caso de uso

Neste padrão, em vez do Jitterbit consultar ou ler uma fonte, uma fonte externa está enviando uma payload para o Jitterbit, onde uma operação atua como um hospedar. Normalmente, a payload é um único registro que é processado imediatamente para o destino, o que é diferente de uma consultar periódica que lida com um lote de registros. É preciso considerar a escalabilidade, em termos do número de registros que podem ser recebidos em um curto período de tempo, bem como usar chamadas assíncronas se um reconhecimento de volta para a fonte for necessário.

Exemplo 1 - API

Aqui está um exemplo em que todo o payload é enviado em vez de apenas um ID. Neste caso, a fonte, Five9, está enviando um payload para a Jitterbit API Platform. A primeira operação recebe os dados, a segunda insere os dados no SFDC.

A variável interna Jitterbit é usada para obter os campos (chamados i, a, d, etc.) e atribuí-los a variáveis globais, depois executar a operação de inserção SFDC:

$i=$jitterbit.api.request.body.i;
$a=$jitterbit.api.request.body.a;
$d=$jitterbit.api.request.body.d;
$e=$jitterbit.api.request.body.e;
$f=$jitterbit.api.request.body.f;
$h=$jitterbit.api.request.body.h;
$k=$jitterbit.api.request.body.k;
$l=$jitterbit.api.request.body.l;
$m=$jitterbit.api.request.body.m;
$n=$jitterbit.api.request.body.n;
$p=$jitterbit.api.request.body.p;
$q=$jitterbit.api.request.body.q;
$r=$jitterbit.api.request.body.r;
$s=$jitterbit.api.request.body.s;
$t=$jitterbit.api.request.body.t;
$u=$jitterbit.api.request.body.u;
$y=$jitterbit.api.request.body.y;
RunOperation("<TAG>Operations/Inbound from Five9/Insert Tasks</TAG>",false)

As variáveis globais são atribuídas à transformação e processadas.

Este padrão é menos complexo do que os padrões em Capturando alterações de dados com consultas baseadas em registro de data e hora ou Capturando alterações de dados com valores de campo de origem. Obviamente, as regras de negócios relacionadas a quando enviar dados neste caso são incorporadas no aplicativo de origem. Caso contrário, a ferramenta de integração tem que incorporá-las, o que leva a mais complexidade. Independentemente da abordagem, o Jitterbit pode acomodá-la.

Exemplo 2 - API

Aqui está outro exemplo usando a plataforma Jitterbit API.

Uma mensagem de saída é recebida do SFDC contendo um único ID, que é passado para uma consultar e, por sua vez, um SAP IDoc é enviado para o SAP.

Dando uma olhada na configuração da API, o nome do projeto e a operação específica são selecionados. Além disso, observe que 'variável do sistema' é verificada, que é a resposta de volta para a mensagem de saída.

A transformação captura os IDs de entrada. Uma mensagem de saída pode conter mais de um registro.

A lógica neste script percorrerá cada ID, atribuirá à variável global $accountId e a passará para a próxima operação. A variável do sistema (conforme chamada na configuração da API ) é atribuída ao XML padrão esperado pela mensagem de saída.

Exemplo 3 - HTTP

O sistema de origem é SFDC e o alvo é SAP. A operação Jitterbit está usando um HTTP Endpoint. Uma alternativa ao uso de um HTTP Endpoint com um agente privado (e evitar abrir portas em seus firewalls) é usar a plataforma Jitterbit API, que é projetada para lidar com cenários de alto tráfego e é o método mais preferido.

Esta operação é configurada para usar um Endpoint HTTP e responder com uma confirmação.

O endpoint HTTP é configurado para responder com uma variável global. Em uma nota lateral, se o SFDC não receber uma resposta, a mensagem de saída será reenviada após um período de tempo. É uma boa prática enviar o reconhecimento de volta o mais rápido possível.

A transformação mapeia o XML de entrada para uma estrutura de arquivo simples.

No "Id" nó, variáveis globais são atribuídas e as informações são gravadas no Log de Operações.

$WorkOrderId = Envelope$Body$notifications$Notification.sObject$Id$;
$QuotedWorkOrderId = Quote($WorkOrderId);
$WorkOrderIdsQueryString = $WorkOrderIdsQueryString + $QuotedWorkOrderId + ",";
$WorkOrderIdsClean = RTrimChars($WorkOrderIdsQueryString, ",");
WriteToOperationLog(" ");
WriteToOperationLog("(" + TargetInstanceCount() + ")");
WriteToOperationLog("Work Order Id: " + $WorkOrderId);
WriteToOperationLog("Ids String: " + $WorkOrderIdsQueryString);
WriteToOperationLog("Clean Ids String: " + $WorkOrderIdsClean);
$WorkOrderId;

O script pós-operação carrega o reconhecimento em uma variável global, que o endpoint HTTP é configurado para repassar.

$salesforce.ack=
'<?xml version="1.0" encoding="UTF-8"?><Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://soap.sforce.com/2005/09/outbound">
 <Body>
 <ns:notificationsResponse>
 <ns:Ack>1</ns:Ack>
 </ns:notificationsResponse>
 </Body>
 </Envelope>
 ';

Após a execução da primeira operação, uma consultar do Salesforce é executada usando o ID da payload.

Aqui, a variável global da primeira operação é usada com a notação '[]':

Este é um padrão comum. Em vez de carregar a payload de entrada com todos os dados, apenas um ID para o registro é passado e usado em uma consultar. Também é comum usar variáveis globais em vez de escrever arquivos temporários, o que é mais comum com consultas periódicas e lotes de dados. Como as variáveis globais são específicas para operações encadeadas, mesmo se as mensagens estiverem sendo recebidas mais rápido do que uma única cadeia pode ser concluída, os valores das variáveis não serão substituídos. Se arquivos temporários foram usados, isso pode ser um problema, a menos que medidas extras tenham sido tomadas, como anexar um guid ao nome do arquivo, para tornar os arquivos exclusivos.