Capture Alterações de Dados com uma API Harmony Ou Endpoint HTTP

Caso de Uso

Nesse padrão, em vez de o Jitterbit consultar ou ler uma fonte, uma fonte externa envia uma payload para o Jitterbit, onde uma operação atua como um hospedar. Normalmente, a payload é um único registro que é processado imediatamente até o destino, o que é diferente de uma consultar periódica que lida com um lote de registros. Deve-se considerar a escalabilidade, em termos do número de registros que podem ser recebidos em um curto período de tempo, bem como o uso de chamadas assíncronas se for necessária uma confirmação de volta à fonte.

Exemplo 1 – API

Aqui está um exemplo em que toda a payload é enviada em vez de apenas um ID. Nesse caso, a fonte, Five9, está enviando uma payload para a plataforma API Jitterbit. 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 às variáveis globais e, em seguida, 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.

Esse padrão é menos complexo que os padrões em Capturando alterações de dados com consultas baseadas em carimbo de data/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 estão incorporadas na aplicação de origem. Caso contrário, a ferramenta de integração terá que incorporá-los, o que acarreta maior complexidade. Independentemente da abordagem, o Jitterbit pode acomodá-la.

Exemplo 2 – API

Aqui está outro exemplo usando a plataforma API Jitterbit.

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 ao 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 a 'variável do sistema' está marcada, que é a resposta à 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á-o à variável global $accountId e passará-o para a próxima operação. A variável do sistema (conforme solicitado 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 destino é SAP. A operação Jitterbit está usando um HTTP Endpoint. Uma alternativa ao uso de um Endpoint HTTP com um Agente Privado (e evitar a abertura de portas em seus firewalls) é usar a plataforma API Jitterbit, que foi projetada para lidar com cenários de alto tráfego e é o método preferido.

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

O endpoint HTTP está configurado para responder com uma variável global. Além disso, 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 a confirmação o mais rápido possível.

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

No "Id", as 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 a confirmação em uma variável global, que o endpoint HTTP está configurado para transmitir de volta.

$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 do 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 recebida 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 que as mensagens sejam 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 sejam tomadas, como anexar um guia ao nome do arquivo, para tornar os arquivos exclusivos.