Projetar para Resiliência Usando o Oracle Integration

Use essas melhores práticas ao projetar suas integrações resilientes.

Integrações de Design

Este é um fluxo de integração de entrada básico que recebe solicitações de um aplicativo upstream por meio de uma API REST, analisa, valida e envia para o aplicativo downstream.

Pode haver um caso em que o aplicativo downstream não responde quando o aplicativo upstream está enviando solicitações. Essas solicitações não serão confirmadas pelo downstream. Haverá muitos desses desafios de processamento, como batch, correlação/fluxos de mensagens complexas e limitação.

Vamos dar um exemplo de criação de entidades na nuvem do Oracle Financials usando as APIs REST. As solicitações devem ser recebidas por um Ponto Final REST de Integração. Você deverá ser capaz de acelerar dinamicamente as solicitações que atingem o Financials Cloud e rastrear o status das solicitações e reenviar todas as solicitações com falha. Para esta solução, três integrações e um banco de dados Autonomous Transaction Processing são mostrados. A implementação do estacionamento pode ser feita usando várias tecnologias de armazenamento, como banco de dados ou Coherence. No entanto, estamos usando uma tabela de banco de dados Autonomous Transaction Processing para simplificar.

Descrição da ilustração oic_extended_parkinglot_eh.png

Na imagem mostrada, quando o aplicativo upstream envia a solicitação, a Integração de Solicitação Persistente a envia para o banco de dados e reconhece o aplicativo upstream. No banco de dados, o padrão de estacionamento armazena metadados de solicitação e informações de status e processará a solicitação de entrada com base no pedido recebido. Cada mensagem é estacionada no armazenamento por x minutos (tempo de estacionamento) para que o fluxo de integração tenha a chance de limitar o número de mensagens processadas simultaneamente.

Uma integração orquestrada do Dispatcher de Programação é acionada por uma programação. Você pode programar esta execução de integração para copiar solicitações do banco de dados em uma data e hora de sua escolha. Também é possível definir a frequência da integração. Essas solicitações são transferidas para a integração do processador Assíncrono. A integração assíncrona do processador processará as solicitações de entrada e as enviará para o aplicativo downstream.

Componentes de Design

O design de alto nível tem três integrações e um banco de dados. Estamos tomando a criação de conta como exemplo, mas, na realidade, pode ser qualquer objeto de negócios exposto por qualquer API REST do Oracle SaaS.

Pós-solicitações

A integração Solicitar Persister expõe um ponto final de trigger REST, que pode ser chamado por um aplicativo upstream (cliente) para POST as solicitações de criação de conta.

Essa integração persistente carrega solicitações de criação de conta no banco de dados Autonomous Transaction Processing imediatamente após o recebimento dos aplicativos clientes e confirma um recebimento com HTTP 202/Accepted. O ID da Conta e toda a carga útil são persistidos na tabela de estacionamento para processamento subsequente.

Carregar solicitações na tabela de estacionamento

O banco de dados Autonomous Transaction Processing contém a tabela de estacionamento na qual todas as solicitações recebidas são estacionadas antes do processamento. Para simplificar, uma tabela simples é mostrada para persistir o payload e rastrear o status da solicitação e qualquer informação de erro.

O payload de solicitação JSON de criação de Conta é totalmente armazenado na tabela de estacionamento como uma string. Pode haver casos de uso para armazenar como CLOB ou uma string codificada em que não é desejável ter um payload visível na tabela. No entanto, armazenar o payload como json fornece uma oportunidade de alterar o payload durante ressubmissões de erro.

Se quiser, você poderá armazenar toda a solicitação JSON na tabela. Você pode fazer isso em dois estágios:

• Um estágio Write usando a amostra JSON do payload de solicitação para criar o arquivo de esquema.
• Uma operação Read Entire File de estágio usando esquema opaco.

  Fornece o valor codificado base64 da string de payload JSON. Em seguida, a função incorporada decodebase64(opaqueElement) pode ser usada no mapeador (ou designação) para obter o valor da string JSON !. O arquivo xsd do esquema opaco usado durante a leitura do estágio está disponível em GitHub, que é discutido mais adiante nesta solução.

Solicitações de Despacho de Acordo com a Programação

A Integração Programada está programada para ser executada na frequência necessária. Em cada execução, ele extrai um número configurado de solicitações e loops, despachando cada solicitação para uma integração do Processador Assíncrono para processamento.

Você pode configurar para extrair várias solicitações como um parâmetro programado para acelerar ou acelerar o processamento de solicitações e também para alterar dinamicamente o valor. Por exemplo, você pode configurar uma tabela de forma que as solicitações da tabela de estacionamento sejam extraídas com base no status das solicitações. Você pode extrair as solicitações de status NEW e ERROR_RETRY e transmiti-las para processamento.

Esse Despachador Programado então percorre o número extraído de solicitações e transfere cada solicitação para o processador Assíncrono para a criação da conta. Certifique-se de que o fluxo do Scheduler (pai) chame um fluxo de Integração Assíncrona (filho) unidirecional. O processador Assíncrono não retorna nenhuma resposta, portanto, o thread do scheduler é liberado para voltar e percorrer o restante das solicitações e despachá-las. Isso garante que os threads do scheduler destinados ao caso de uso especial da programação não sejam mantidos no processamento a longo prazo. A lógica de negócios do processamento de solicitações em si é tratada por recursos de processamento assíncronos disponíveis no Oracle Integrations.

Aqui estão algumas práticas recomendadas para orquestração programada: Sempre dissocie a lógica de programação com a lógica de negócios usando uma Transferência Assíncrona da integração programada. Isso garantirá que os threads do scheduler não sejam usados para a criação da conta.

• As orquestrações programadas destinam-se a atender a requisitos específicos de programação de fluxos, e liberá-los usando a entrega Assíncrona torna a solução escalável e eficiente ao processar um grande número de solicitações.
• As orquestrações programadas não devem ser usadas como um substituto para as orquestrações Orientadas por Aplicativo.

Você pode adicionar ações à integração orquestrada. Se você usar a ação for-each, poderá percorrer um elemento repetitivo e executar uma ou mais ações dentro do escopo da ação for-each. O número de iterações de loop é baseado em um elemento de repetição selecionado pelo usuário. Por exemplo, você pode ter uma integração na qual fez download de vários arquivos e deseja fazer loop sobre a saída dos arquivos. A ação for-each permite que você execute esta tarefa. Observe que Processar Itens em Paralelo pode ser selecionado para alguns dos loops for-each. Isso garantirá que as atividades dentro do loop for-each sejam agrupadas por integração e executadas em paralelo. Há certas condições em que a integração ignorará o paralelismo. Nesses casos, o grau de paralelismo será definido como 1 para evitar problemas de concorrência.

Criar Conta

A integração assíncrona do processador processará as solicitações de entrada do Despachador Programado e as enviará para o aplicativo downstream.

O processador assíncrono expõe uma interface REST. É importante que essa integração seja modelada como um fluxo assíncrono unidirecional para liberar a integração do scheduler. Quando você configurar a integração assíncrona de uma maneira, certifique-se de que o trigger REST exponha um método POST e o fluxo REST não retorne uma resposta ao cliente.

1. Você pode configurar esses dois no assistente Configurar Ponto Final Rest.
   1. Na tela de integração, no painel Acionadores, clique em REST se os adaptadores REST ainda não estiverem listados.
   2. Arraste sua conexão de integração para o ícone de mais abaixo de INICIAR na tela. Isso exibe o assistente de configuração Configurar Ponto Final REST.
2. Na página Informações Básicas do assistente, selecione POST na lista drop-down para Qual ação você deseja executar no ponto final?
3. Selecione o Configurar um payload de solicitação para este ponto final.

Como o fluxo assíncrono faz a criação real da conta, será responsável por atualizar o status da solicitação na tabela de estacionamento. Após a criação bem-sucedida de uma conta, a coluna STATUS na tabela do estacionamento é atualizada para PROCESSED.

Tratar Solicitações com Falha

O reenvio de solicitações com falha pode ser controlado na tabela de estacionamentos. Um handler de erro de nível de escopo trata todas as falhas durante a criação da conta e atualiza o status para ERRORED em caso de erros. Os detalhes do motivo e do erro também são atualizados na tabela do estacionamento. Isso é útil para determinar se a solicitação pode ser reenviada posteriormente. Também é possível enviar e-mails de notificação de erro aos administradores de integração.

Os handlers de falha definiram solicitações com falha para o status ERRORED na tabela de estacionamento. Essas solicitações podem ser atualizadas na tabela para o status ERROR_RETRY e serão selecionadas na próxima programação para reprocessamento devido aos critérios de seleção da chamada do banco de dados do Autonomous Transaction Processing do Despachador Programado.

Existem várias opções para acionar tais ressubmissões:

• A atualização de solicitações ERRORED para ERROR_RETRY pode ser executada por um administrador no banco de dados.
• Você pode até adicionar um fluxo de integração de Reenvio que seja executado diariamente ou em qualquer frequência desejada e atualiza todos os registros ERRODOS para ERROR_RETRY.
• O handler de falha da integração do Processador Assíncrono pode definir o status como ERROR_RETRY diretamente, para que cada falha seja reenviada automaticamente na próxima programação.

Correção de Carga Útil

O armazenamento da carga útil de criação da conta na tabela de estacionamento nos deu uma maneira de corrigir a carga útil de erros de dados antes do reenvio. Atualize o payload e defina a coluna de status como ERROR_RETRY para reenviar uma solicitação com o payload corrigido.