Capture Cambios de Datos con una API de Harmony o un Extremo HTTP

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 un alojar. Normalmente, la carga útil es un registro único que se procesa inmediatamente hasta el destino, lo cual es diferente de una consultar periódica que trata 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 corto período de tiempo, así como el uso de llamadas asíncronas 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 toda la carga útil en lugar de solo una identificación. En este caso, la fuente, Five9, envía una carga útil a la plataforma API Jitterbit. La primera operación recibe los datos, la segunda inserta los datos 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 comerciales relacionadas con cuándo enviar datos en este caso están integradas en la aplicación de origen. De lo contrario, la herramienta de integración tiene que incorporarlos, lo que genera una mayor complejidad. Independientemente del enfoque, Jitterbit puede adaptarse a ello.

Ejemplo 2: API

Aquí hay otro ejemplo que utiliza la plataforma API Jitterbit.

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

Echando un vistazo a 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 'variable del sistema', que es la respuesta al mensaje saliente.

La transformación captura los ID entrantes. Un mensaje saliente puede contener más de un registro.

La lógica de este secuencia de comandos recorrerá cada ID, lo asignará a la variable global $accountId y lo 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 destino es SAP. La operación Jitterbit utiliza un Extremo HTTP. Una alternativa al uso de un Extremo HTTP con un Agente Privado (y evitar abrir puertos en sus firewalls) es usar 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 reenviará 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 sin formato.

En el "Id", se asignan variables globales y la información se escribe 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 devolver.

$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 ejecutar 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 del registro y se utiliza en una consultar. También es común usar variables globales en lugar de escribir archivos temporales, lo cual es más común con consultas periódicas y lotes de datos. Dado que las variables globales son específicas de operaciones encadenadas, incluso si los mensajes se reciben más rápido de lo que puede completar una sola cadena, los valores de las variables no se sobrescribirán. Si se utilizaron archivos temporales, eso puede ser un problema a menos que se tomen medidas adicionales, como agregar una guía al nombre del archivo, para que los archivos sean únicos.