Capturar Alterações de Dados com Valores de Campo de Origem¶

Caso de Uso¶

Semelhante a Capturando alterações de dados com consultas baseadas em carimbo de data/hora, em vez de usar um carimbo de data/hora para coletar dados a serem processados, esse padrão consulta o valor em um campo. Normalmente, a origem usa gatilhos ou regras para identificar registros a serem alterados e altera o valor em um campo (como Pronto para enviar) de falso para verdadeiro. A consultar no Jitterbit usará esse campo na condição. A vantagem aqui sobre o uso de timestamps é que o sistema de origem usa suas regras internas de negócios para determinar os dados a serem movidos. Os carimbos de data e hora sozinhos frequentemente requerem filtragem complexa adicional para acomodar a lógica de negócios.

Exemplo¶

Nesse caso, a origem e o destino usam um campo Ready_To_Sync e Sync_Error. Se esse destino tiver um Sync_Error, nenhuma atualização deve ser feita e o registro de origem deve ser atualizado para que possa ser revisado e corrigido. Como veremos, esse tipo de sincronização mútua requer pré-verificações antes da atualização, caminhos de sucesso e de erro.

Primeiro, o script verifica se há algum dado a ser coletado, que é a operação que contém o agendamento. Em seguida, uma consultar é executada para buscar o restante dos dados e tem duas verificações. Se os dados recebidos forem inválidos, uma atualização será lançada. Além disso, é feita uma pesquisa de um campo no destino. O principal cenário de sucesso é que os dados são atualizados no NetSuite e os dados-chave são gravados de volta no destino. O cenário de erro é que o registro de destino é sinalizado como estando em um status de erro de sincronização e não pode ser atualizado, e essas informações são gravadas de volta na origem.

Primeiro, verifique se há algum dado a ser recuperado usando um SFLookup leve, que retornará apenas um único registro. Se nada for retornado, não inicie a cadeia de eventos. Do ponto de vista do desenvolvimento, pode ser útil adotar essa abordagem em vez de confiar na consultar na própria consultar SFDC, pois você pode capturar os IDs na consultar e inspecionar os registros. Além disso, a consultar SFDC só é ativada se tiver algo a ver. Na consultar, ele verifica se Ready_to_Sync é verdadeiro e também se um campo Sync_Error está vazio. O campo RTS é definido como verdadeiro com gatilhos internos e será modificado pelo processo de 'write-back'.

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>"))

Supondo que pelo menos um registro seja selecionado, então 0301 é iniciado. A transformação valida um campo e chama 0199 usando um padrão semelhante a Processando registros de destino condicionalmente. Ele também verifica se o registro de destino do NetSuite está pronto para sincronizar. Observe que RTS_Status foi adicionado manualmente ao formato de arquivo gerado pelo assistente.

//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 operação 0302 recebe o NetSuite Id.

A transformação de resposta permite que a operação avalie o resultado da consultar.

Observe que uma estrutura simples de arquivo simples é usada.

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)

Na próxima operação, executamos essa verificação. 0304 é executado para executar a atualização do NetSuite e 0306 é executado para condições de erro.

// 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>");

Em 0306, lemos o destino de origem e filtramos os registros que não requerem processamento.

0304 atualiza a conta NetSuite e usa a resposta para criar um arquivo com as informações do RTS e do código de erro.

A condição sempre é avaliada como verdadeira. O objetivo principal é capturar o id SFDC para uso posterior na transformação e também capturar mensagens de erro NS se o sucesso for falso. As condições podem ser usadas dessa maneira para permitir o pré-processamento de registros individuais.

$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

E finalmente 0305 atualiza o SFDC. O requisito aqui era fazer isso usando uma atualização em massa para um processamento mais rápido. Esta é uma captura de tela parcial: