Capturar cambios de datos con una API de API Manager o un extremo HTTP en Jitterbit Design Studio

Caso de uso

En este patrón, en lugar de que Jitterbit consulte o lea una fuente, una fuente externa envía una carga útil a Jitterbit, donde una operación actúa como alojar. Normalmente, la carga útil es un registro único que se procesa inmediatamente hasta el destino, lo que es diferente de una consultar periódica que se ocupa de un lote de registros. Se debe tener en cuenta la escalabilidad, en términos de la cantidad de registros que se pueden recibir en un período corto de tiempo, así como el uso de llamadas asincrónicas si se requiere un acuse de recibo a la fuente.

Ejemplo 1 - API

A continuación, se muestra un ejemplo en el que se envía la carga útil completa en lugar de solo un ID. En este caso, la fuente, Five9, envía una carga útil a la plataforma API de Jitterbit. La primera operación recibe los datos y la segunda los inserta en SFDC.

La variable interna Jitterbit se utiliza para obtener los campos (llamados i, a, d, etc.) y asignarlos a variables globales, luego ejecutar la operación de inserción 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)

Las variables globales se asignan a la transformación y se procesan.

Este patrón es menos complejo que los patrones de Captura de cambios de datos con consultas basadas en marcas de tiempo o Captura de cambios de datos con valores de campo de origen. Obviamente, las reglas de negocio relacionadas con cuándo enviar datos en este caso están incorporadas en la aplicación de origen. De lo contrario, la herramienta de integración debe incorporarlas, lo que genera más complejidad. Independientemente del enfoque, Jitterbit puede adaptarse a él.

Ejemplo 2 - API

A continuación se muestra otro ejemplo que utiliza la plataforma API Jitterbit.

Se recibe un mensaje saliente de SFDC que contiene un único ID, que se pasa a una consultar y, a su vez, se envía un IDoc de SAP a SAP.

Al observar la configuración de la API, se selecciona el nombre del proyecto y la operación específica. Además, tenga en cuenta que está marcada la opción "variable del sistema", que es la respuesta al mensaje saliente.

La transformación captura los identificadores de entrada. Un mensaje de salida puede contener más de un registro.

La lógica de este secuencia de comandos recorrerá cada ID, la asignará a la variable global $accountId y la pasará a la siguiente operación. La variable del sistema (como se solicita en la configuración de la API ) se asigna al XML estándar esperado por el mensaje saliente.

Ejemplo 3 - HTTP

El sistema de origen es SFDC y el de destino es SAP. La operación Jitterbit utiliza un Extremo HTTP. Una alternativa a utilizar un Extremo HTTP con un agente privado (y evitar abrir puertos en sus firewalls) es utilizar la plataforma API Jitterbit, que está diseñada para manejar escenarios de alto tráfico y es el método preferido.

Esta operación está configurada para utilizar un Extremo HTTP y responder con un reconocimiento.

El extremo HTTP está configurado para responder con una variable global. Como nota al margen, si SFDC no recibe una respuesta, el mensaje saliente se volverá a enviar después de un período de tiempo. Es una buena práctica enviar el acuse de recibo lo antes posible.

La transformación asigna el XML entrante a una estructura de archivo plana.

En el "Id" nodo, se asignan variables globales y se escribe información en el registro de operaciones.

$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;

El secuencia de comandos posterior a la operación carga el reconocimiento en una variable global, que el extremo HTTP está configurado para pasar de vuelta.

$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>
 ';

Después de que se ejecuta la primera operación, se ejecuta una consultar de Salesforce utilizando el Id. de la carga útil.

Aquí, la variable global de la primera operación se utiliza con la notación '[]':

Este es un patrón común. En lugar de cargar la carga útil entrante con todos los datos, solo se pasa un ID al registro y se usa en una consultar. También es común usar variables globales en lugar de escribir archivos temporales, lo que es más común con consultas periódicas y lotes de datos. Dado que las variables globales son específicas de las operaciones encadenadas, incluso si los mensajes se reciben más rápido de lo que una sola cadena puede completar, los valores de las variables no se sobrescribirán. Si se usaron archivos temporales, eso puede ser un problema a menos que se hayan tomado medidas adicionales, como agregar un GUID al nombre del archivo, para que los archivos sean únicos.