Ir para o conteúdo

Capture alterações de dados com consultas baseadas em registro de data e hora no Jitterbit Design Studio

Caso de uso

Dados, como alterações de dados mestres ou novas transações, devem ser movidos de uma origem para um destino. Uma consultar periódica, sustentada por um cronograma, incluirá uma condição que usa um registro de data e hora para selecionar os registros da origem que devem ser processados no destino.

Há várias considerações:

  • Armazenamento persistente dos dados do registro de data e hora
  • Evite um 'loop infinito', onde as alterações feitas pelo Jitterbit no destino são captadas e aplicadas de volta à origem, e assim por diante.
  • O isolamento de alterações intencionais de alterações não intencionais na fonte, como dados alterados por um gatilho, não deve ser incluído, mas dados alterados por um usuário devem.

Há prós e contras nessa abordagem em comparação a uma abordagem de push baseada em eventos/em tempo real.

  • Prós:
    • Se o destino não estiver disponível, a origem continuará tentando mover os dados até que esteja concluído.
    • Pode 'retroceder' o registro de data e hora para permitir repetições
    • Pode começar relativamente rápido
    • Mais fácil de desenvolver e testar usando conjuntos de dados menores.
    • Pode controlar melhor o tamanho dos dados a serem processados.
    • Se um 'write-back' para a origem for implementado, você poderá rastrear a atividade de integração da origem ao destino.
  • Contras:
    • Aplicável somente se um registro de data e hora estiver disponível ou se uma condição de consultar puder ser construída.
    • Pesquisas/Consultas podem ser mais complicadas do que as baseadas em eventos.
      • O primeiro requer um armazenamento de dados de timestamp, consultas com condições e possivelmente outros filtros, e é sensível a alterações de esquema na fonte. No último, o Jitterbit está simplesmente recebendo um payload. Enquanto esse esquema não mudar, os sistemas estarão mais fracamente acoplados, o que é uma vantagem do ponto de vista do desenvolvimento.
    • Mova a sobrecarga administrativa da ferramenta de integração. Por exemplo, se você precisar interromper um fluxo ou precisar alterar/atualizar o cronograma no Jitterbit, que é uma alteração de configuração de software. Para muitas empresas, fazer uma alteração está sob um processo de controle de software e requer mais etapas. Com um processo orientado a eventos, a alteração é feita na fonte.
    • Como os timestamps geralmente são gerados pelo sistema, eles não acomodam regras de negócios, o que leva à inclusão de regras de negócios no middleware e scripts extensivos. Do ponto de vista da arquitetura empresarial, as regras de negócios devem ser mantidas apenas nos aplicativos. Como veremos neste exemplo, há scripts extensivos de regras de negócios.

Exemplo

Consultar NetSuite, atualizar Salesforce

anexo

JB Sync: Obter script de registro de data e hora

Os timestamps são armazenados no SFDC, e uma consultar obtém o ID de sincronização e o próprio timestamp. Observe que os timestamps são UTC, e os valores são retornados em uma matriz.

$result = SfLookupAll("<TAG>Salesforce Orgs/sysadmin@example.com</TAG>",
    "Select Id, Object_Last_Modified_Date_del__c from Jitterbit_Syncs__c where Object_Name_del__c = 'Ticket'");
$Jitterbit_SyncsId = Get($result,0,0);
$synctimestampticket = Get($result,0,1);

Obter Sync_Time

Use uma função do Salesforce para obter o horário atual, que será usado para atualizar o registro do JB Sync. Observe que isso está sendo feito antes da consultar NS em vez de depois do upsert SFDC, que é o método mais tradicional. No entanto, foi descoberto que os registros estavam sendo perdidos, pois as alterações estavam sendo feitas na fonte que aconteceram entre o momento em que a consultar foi feita e o momento em que o upsert terminou. A decisão foi tomada para usar essa abordagem, mesmo ao custo de pegar os mesmos registros na consultar de origem. Observe também que não há 'write-back' nos registros selecionados para atualizá-los com base em um upsert bem-sucedido no SFDC. Se isso fosse implementado, uma consultar poderia ser construída que não pegaria registros duplicados.

$Sync_Time = GetUTCFormattedDateTime(
    LoginToSalesforceAndGetTimestamp("<TAG>Salesforce Orgs/sysadmin@example.com</TAG>","UTC"),"UTC",false);

Passe a variável global synctimestampticket para a consultar

anexo

Mapeamento

Uma condição é usada para filtrar ainda mais os dados.

anexo

Doença

O requisito era filtrar determinados sites com base em datas até que a implementação nacional fosse concluída. Como a consultar não filtra com base nos requisitos de data de alteração, uma condição é usada dentro da transformação.

Os dados de entrada são gravados no log de operação. Em seguida, os IDs internos do local são verificados e, se o local estiver no escopo, a última modificação do registro por valor é verificada e, se feita pelo Jitterbit, é sinalizada para ser ignorada.

Como os valores LMB dependem do ambiente, é feita uma verificação no ambiente atual.

Em seguida, o registro é verificado em relação a uma lista de intervalos de datas, já que os registros anteriores a um determinado horário são excluídos. Se o registro passar em todos os testes, ele será usado.

WriteToOperationLog(
"----------"+"\r\n"+
"Int id: "+searchResponse$searchResult$recordList$record.SalesOrder$internalId+"\r\n"+
"Ord id: "+searchResponse$searchResult$recordList$record.SalesOrder$tranId$ +"\r\n"+
"LMD: " +searchResponse$searchResult$recordList$record.SalesOrder$lastModifiedDate$+"\r\n"+
"Loc: " +searchResponse$searchResult$recordList$record.SalesOrder$location$internalId+"\r\n"+
"LMB: " +searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId+"\r\n"+
"Cust:" +searchResponse$searchResult$recordList$record.SalesOrder$entity$internalId);
If(searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==25||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==6||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==3||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==10||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==4||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==18||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==26||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==29||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==16||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==22||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==14||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==15||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==35||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==19||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==17||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==12||`FIM DA TABELA`


 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==84,

 $loccheck = true,
 $loccheck = false);
//exclude changes in NS made by Jitterbit
If($loccheck && GetEnvironmentName()=='DEV',
 If(
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='9836'||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='9837'||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='9838',
 $idcheck = false,
 $idcheck = true));
If($loccheck && GetEnvironmentName()=='PROD',
 If(
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='10780'||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='10781'||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='9631',
 $idcheck = false,
 $idcheck = true));
Case(
 $loccheck==false, $result=false;WriteToOperationLog("Skip loc"),
$loccheck==true && $idcheck == false, $result = false; WriteToOperationLog("Skip id"),
$loccheck==true && $idcheck == true,$result = true; WriteToOperationLog("Pass")
 );

// region & timestamp check
If($result == true && (searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==4||`FIM DA TABELA`
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==26),
//check create date not before point in time when region went live. For these two regions, that is 2015-09-13T13:00:00Z
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-09-13T13:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("Colo Region ticket before 2015-09-13"))
);
If($result == true && searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==18,
//check create date not before point in time when region went live.
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-09-20T13:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("Williston Region ticket before 2015-09-20"))
);
If($result == true && searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==29,
//check create date not before point in time when region went live.
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-09-23T16:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("Caspar Region ticket before 2015-09-23")
 )
);
//AR
If($result == true && searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==16,
//check create date not before point in time when region went live.
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-10-04T12:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("AR Region ticket before 2015-10-4")
 )
);
//DFW
If($result == true && searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==22||`FIM DA TABELA`
searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==14||`FIM DA TABELA`
searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==15||`FIM DA TABELA`
searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==17||`FIM DA TABELA`
searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==35,
//check create date not before point in time when region went live.
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-10-11T08:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("DFW Region ticket before 2015-10-11")
 )
);
$result

Após os dados serem gravados em um arquivo temporário, Update Jitterbit Syncs é chamado:

attachment

anexo

anexo

Por fim, a operação A02 é chamada se houver algum registro para processar.