Capturar Cambios de Datos con Valores de Campo de Origen¶

Caso de Uso¶

Similar a Captura de cambios de datos con consultas basadas en marcas de tiempo, en lugar de usar una marca de tiempo para recoger los datos que se van a procesar, este patrón consulta el valor de un campo. Por lo general, la fuente utiliza activadores o reglas para identificar los registros que se modificarán y cambia el valor de un campo (como Listo para enviar) 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 usa sus reglas comerciales internas para determinar los datos que se van a mover. Las marcas de tiempo por sí solas suelen requerir un filtrado complejo adicional para adaptarse a la lógica empresarial.

Ejemplo¶

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

En primer lugar, la secuencia de comandos comprueba si se recopilarán datos, 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 inicia 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 está marcado como en un estado de error de sincronización y no se puede actualizar, y esa información se vuelve a escribir en el origen.

Primero, verifique si hay datos para recuperar usando un SFLookup liviano, que devolverá solo un registro. Si no se devuelve nada, entonces no comience la cadena de eventos. Desde el punto de vista del desarrollo, puede ser útil adoptar este enfoque en lugar de depender de la consultar en la consultar SFDC en sí, ya que puede capturar los ID en la consultar e inspeccionar los registros. Además, la consultar SFDC solo se activa si tiene algo que ver. En la consultar, comprueba 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 disparadores internos y será modificado por el proceso de 'reescritura'.

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 recoge al menos un registro, se inicia 0301. La transformación valida un campo y llama a 0199 utilizando un patrón similar a Procesar registros de destino condicionalmente. También verifica el registro de destino de NetSuite para su estado Listo para sincronizar. 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 plano 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 de 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 usa 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 propósito principal es capturar la identificación de SFDC para usarla más adelante en la transformación, y también capturar mensajes de error NS si el éxito 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: