Execute as Próximas Operações Condicionalmente Usando Cadeias de Operação¶

Caso de Uso¶

Um objetivo comum do projeto de integração é ativar os fluxos de operação com base em uma condição. O mais comum é realizar uma operação e, se for bem-sucedida, realizar uma segunda, e assim por diante. O Jitterbit oferece suporte a isso com muita facilidade, pois 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 verdadeiro ou falso ou com base em um valor retornado de uma consultar.

Exemplo 1¶

O caminho 'On Success' é 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. Nesse caso, um script pós-operação chama outra operação. É condicional no sentido de que não será executada se a consultar 020 falhar e também será executada após a conclusão da operação, mas antes de executar a operação 021.

Neste exemplo, uma consultar é executada e dependendo dos valores, outras duas 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 recebidos a variáveis locais e verificar se eles se aplicam à instrução Case

Retornando o controle de volta para a condição, se "Error" for retornado, uma operação será invocada, caso contrário, ela será ignorada. De volta à transformação ...

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

Aqui, a RunOperation é chamada para capturar um status no sistema de destino.

Exemplo 2¶

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

Você pode ver que existe um padrão mix-n-match. Chama-se uma série de operações que, por sua vez, chamam outras operações.

O script chama apenas quatro operações. Observe que RunOperation(), por padrão, será executado de forma síncrona. Ou seja, ele vai esperar a operação (e todas as suas operações encadeadas) terminar 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 da Web externo e inserindo dados no SFDC.

O script inicia a operação de forma assíncrona ("falso"). Isso é feito para que a resposta do web service seja a mais rápida possível, já que se trata de um fluxo de dados de alto volume. Caso contrário, a resposta terá que aguardar a inserção da força de vendas, o que demoraria muito.

Observe que 'sem resposta' está selecionado.