Capturar cambios de datos con valores de campos de origen en Jitterbit Design Studio

Caso de uso

Similar a Captura de cambios de datos con consultas basadas en marcas de tiempo, en lugar de utilizar una marca de tiempo para seleccionar los datos que se van a procesar, este patrón consulta el valor de un campo. Normalmente, la fuente utiliza activadores o reglas para identificar los registros que se van a modificar y cambia el valor de un campo (como Ready To Send) de falso a verdadero. La consultar en Jitterbit utilizará ese campo en la condición. La ventaja aquí sobre el uso de marcas de tiempo es que el sistema de origen utiliza sus reglas comerciales internas para determinar los datos que se van a mover. Las marcas de tiempo por sí solas con frecuencia requieren un filtrado complejo adicional para adaptarse a la lógica comercial.

Ejemplo

En este caso, tanto el origen como el destino utilizan un campo Ready_To_Sync y un campo Sync_Error. Si ese destino tiene un campo Sync_Error, no se debe realizar ninguna actualización y se debe actualizar el registro de origen para que se pueda revisar y corregir. Como veremos, este tipo de sincronización mutua requiere comprobaciones previas antes de la actualización, rutas de éxito y de error.

En primer lugar, el secuencia de comandos comprueba si hay datos que se deben recoger, que es la operación que contiene la programación. A continuación, se ejecuta una consultar para obtener el resto de los datos y tiene dos comprobaciones. Si los datos entrantes no son válidos, se lanza una actualización. Además, se realiza una búsqueda de un campo en el destino. El principal escenario de éxito es que los datos se actualizan en NetSuite y los datos clave se vuelven a escribir en el destino. El escenario de error es que el registro de destino se marca como en un estado de error de sincronización y no se puede actualizar, y esa información se vuelve a escribir en la fuente.

En primer lugar, verifique si hay algún dato que se pueda recuperar utilizando un SFLookup liviano, que devolverá solo un único registro. Si no se devuelve nada, no inicie la cadena de eventos. Desde un punto de vista de desarrollo, puede ser útil adoptar este enfoque en lugar de confiar en la consultar en la consultar SFDC en sí, ya que puede capturar los identificadores en la consultar e inspeccionar los registros. Además, la consultar SFDC solo se activa si tiene algo que hacer. En la consultar, verifica si Ready_to_Sync es verdadero y también si un campo Sync_Error está vacío. El campo RTS se establece en verdadero con activadores internos y se modificará mediante el proceso de "escritura diferida".

soql =
"SELECT Id FROM Account WHERE (Account_Status__c like '%Active%' or Account_Status__c like '%Terminated%' or Client_ID__c != null) AND NetSuite_Id_original__c != Null and Ready_to_Sync__c = true and Sync_Error__c = Null and (Sync_Error_Code__c < 1 or Sync_Error_Code__c = Null)";
result = SfLookup("<TAG>Salesforce Orgs/companyname(Sandbox)</TAG>",soql);
If(Length(result)>0,RunOperation("<TAG>Operations/03 SF->NS Update Customer/0301 Query SF Accounts</TAG>"))

Suponiendo que se selecciona al menos un registro, se lanza 0301. La transformación valida un campo y llama a 0199 utilizando un patrón similar a Procesamiento de registros de destino de manera condicional. También verifica el estado Listo para sincronizar del registro de destino de NetSuite. Tenga en cuenta que RTS_Status se agregó manualmente al formato de archivo generado por el asistente.

//Check if NS record's Ready to Sync Status. If false, can update. But if true, then have a sync error. Do not update and set source SFDC record's Sync Error to '1'
RunOperation("<TAG>Operations/03 SF->NS Update Customer/0302 Check NS Customer RTS Check</TAG>");
WriteToOperationLog("NSCheckResult: "+$NSCheckResult);
//Need to know in advance the RTS status. If have any with RTS Status = false, then process the NS Update. If all records have RTS status = true, then skip the NS Customer Update and only run the Account Update.
//Use $arrNsCheckResult to store the values, then can check array to see if any are false, in which case can run the NS Customer Update
Set($arrNSCheckResult,$NSCheckResult,-1);
$NSCheckResult

A la operación 0302 se le pasa el Id. de NetSuite.

La transformación de respuesta permite que la operación evalúe el resultado de la consultar.

Tenga en cuenta que se utiliza una estructura de archivo plana simple.

WriteToOperationLog("Id: "+searchResponse$searchResult$recordList$record.Customer$internalId+" RTS val: "+searchResponse$searchResult$recordList$record.Customer$customFieldList$Ready_To_Sync$value$);

If(searchResponse$searchResult$recordList$record.Customer$customFieldList$Ready_To_Sync$value$==true,$NSCheckResult=true,$NSCheckResult=false)

En la siguiente operación ejecutamos esta comprobación. 0304 se ejecuta para realizar la actualización a NetSuite y 0306 se ejecuta para condiciones de error.

// To handle edge case if all the NS records returned are RTS = true
RunOp=false;
WriteToOperationLog("arrNSCheckResult: "+$arrNSCheckResult);
count=Length($arrNSCheckResult);i=0;
While(i<count,
If($arrNSCheckResult[i]==0,RunOp=true);
i++);

If(RunOp,RunOperation("<TAG>Operations/03 SF->NS Update Customer/0304 Update NS Customer</TAG>"));
//Run this regardless
RunOperation("<TAG>Operations/03 SF->NS Update Customer/0306 Prep RTS Error</TAG>");

En 0306, leemos el destino de origen y filtramos los registros que no requieren procesamiento.

0304 actualiza la cuenta de NetSuite y utiliza la respuesta para crear un archivo con la información del código de error y RTS.

La condición siempre se evalúa como verdadera. El objetivo principal es capturar el ID de SFDC para su uso posterior en la transformación y también capturar mensajes de error de NS si el resultado es falso. Las condiciones se pueden utilizar de esta manera para habilitar el preprocesamiento de registros individuales.

$NSCustId="";
$errormessage="";
If(jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse.status$isSuccess== true,
WriteToOperationLog("Success NS Id: "+FindByPos(SourceInstanceCount(),
jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse#.baseRef$1$RecordRef$internalId
));
//If success run op to update SFDC record
$SFCustId = $CustIdList[SourceInstanceCount()-1];
$NSUpdateMessage = FindByPos(SourceInstanceCount(),
jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse.status$statusDetail#.message$);
$NSCustId = FindByPos(SourceInstanceCount(),
jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse#.baseRef$1$RecordRef$internalId
);
WriteToOperationLog("Success SFDC Id is :"+ $SFCustId);
WriteToOperationLog("Netsuite Update Message :"+ $NSUpdateMessage);
);

__

If(jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse.status$isSuccess== false,
$errormessage="NS Data Error: "+GetEnvironmentName()+" "+
FindByPos(SourceInstanceCount(),
jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse#.baseRef$1$RecordRef$internalId)+ " Message: "+
SumString(jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse.status$statusDetail#.message$,".",false);
$SFCustId = $CustIdList[SourceInstanceCount()-1];
WriteToOperationLog($errormessage);
);

true

Y finalmente, 0305 actualiza SFDC. El requisito aquí era hacerlo mediante una actualización masiva para un procesamiento más rápido. Esta es una captura de pantalla parcial: