Execute as próximas operações condicionalmente usando cadeias de operação no Jitterbit Design Studio

Caso de uso

Um objetivo comum de design de integração é ativar fluxos de operação com base em uma condição. O mais comum é executar uma operação e, se bem-sucedida, executar uma segunda, e assim por diante. O Jitterbit suporta isso muito facilmente, já que as operações podem ser vinculadas usando um caminho On Success (bem como um caminho On Failure). Mas frequentemente, uma operação deve ser chamada com base em um valor de dados, como um resultado que é true ou false ou com base em um valor retornado de uma consultar.

Exemplo 1

O caminho 'Em caso de sucesso' é mostrado entre a operação 020 Query Items e a operação 021 NetSuite Upsert NonInventorySalesItem.

O Caminho Condicional está entre a operação 020 e Update Jitterbit Syncs. Neste caso, um script pós-operação chama outra operação. Ele é condicional no sentido de que não será executado se a consultar 020 falhar, e também é executado após a operação ter terminado, mas antes de executar a operação 021.

Neste exemplo, uma consultar é executada e, dependendo dos valores, duas outras operações são executadas.

Um nó de condição é usado para avaliar cada registro de entrada.

Um script é chamado e os valores de origem são passados para ele.

ArgumentList é usado para atribuir os valores de entrada às variáveis locais e verificar se eles se aplicam na declaração Case

Retornando o controle de volta para a condição, se "Error" for passado de volta, então uma operação é invocada, caso contrário, ela é pulada. De volta à transformação ...

Há também outra chamada de operação que está incorporada dentro do RTS_Status. Observe que o Jitterbit executa scripts do construtor de fórmulas de cima para baixo, então esse script é executado por último.

Aqui, o RunOperation é chamado para capturar um status no sistema de destino.

Exemplo 2

Um exemplo diferente mostra o uso de um script para organizar os fluxos de operação:

Você pode ver que há um padrão mix-n-match. Uma série de operações são chamadas que, por sua vez, chamam outras operações.

O script chama apenas quatro operações. Note que RunOperation(), por padrão, executará de forma síncrona. Ou seja, ele esperará a operação (e todas as suas operações encadeadas) terminarem antes de executar a próxima. A outra opção é executar de forma assíncrona.

Essa orquestração envolve a Jitterbit API Platform sendo chamada por um serviço web externo e inserindo dados no SFDC.

O script inicia a operação de forma assíncrona ("false"). Isso é feito para que a resposta do serviço web seja a mais rápida possível, já que esse é um fluxo de dados de alto volume. Caso contrário, a resposta tem que esperar pela inserção do salesforce, o que levaria muito tempo.

Observe que 'nenhuma resposta' está selecionado.