Ir para o conteúdo

Capture alterações de dados com valores de campo de origem no Jitterbit Design Studio

Caso de uso

Semelhante a Capturando alterações de dados com consultas baseadas em registro de data e hora, em vez de usar um timestamp 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 Ready To Send) 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 comerciais internas para determinar os dados a serem movidos. Os timestamps sozinhos frequentemente exigem filtragem complexa adicional para acomodar a lógica comercial.

Exemplo

Neste caso, tanto a origem quanto o destino usam um campo Ready_To_Sync e um campo 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 erro.

Primeiro, o script verifica se há dados a serem coletados, 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 é iniciada. Além disso, uma pesquisa de um campo no destino é feita. O principal cenário de sucesso é que os dados são atualizados no NetSuite e os dados principais 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 fonte.

anexo

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 depender da consultar na própria consultar SFDC, já que você pode capturar os IDs na consultar e inspecionar os registros. Além disso, a consultar SFDC só é ativada se tiver algo a fazer. Na consultar, ela verifica se Ready_to_Sync é true e também se um campo Sync_Error está vazio. O campo RTS é definido como true 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 o registro de destino do NetSuite para seu status Ready to Sync. Observe que RTS_Status foi adicionado manualmente ao formato de arquivo gerado pelo assistente.

anexo

//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 ID do NetSuite.

anexo

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

anexo

Observe que uma estrutura de arquivo simples e plana é 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 esta verificação. 0304 é executado para realizar 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 exigem processamento.

anexo

anexo

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.

anexo

A condição sempre é avaliada como verdadeira. O objetivo principal é capturar o id do SFDC para uso posterior na transformação e também capturar mensagens de erro do NS se o sucesso for falso. As condições podem ser usadas dessa forma para habilitar 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 SFDC. O requisito aqui era fazer isso usando uma atualização em massa para processamento mais rápido. Esta é uma captura de tela parcial:

anexo