Podemos esperar pelo mecanismo de aplicativo PeopleSoft esperar que as mensagens assíncronas sejam concluídas?

Question

Eu estou tentando processar um upload de dados, onde estou tentando publicar as mensagens através do PeopleSoft sobre o intermediário de integração de forma assíncrona em um mecanismo de aplicativo. O ponto inteiro é poder enviar várias mensagens e consumi-las no mesmo nó. Antes de enviar as mensagens, estou armazenando os dados em uma tabela (digamos T1) para armazenar todos os valores de campo no arquivo de upload.

Ao consumir, estou tentando expor cada mensagem à interface do componente e as exceções são registradas na mesma tabela T1. Digamos a cada transação que estamos sinalizando o campo da tabela (digamos processed_flag= 'y').

Eu preciso de um mecanismo onde eu pudesse esperar por todas as mensagens assíncronas para concluir. Eu estou pensando em verificar a tabela T1, se houver linhas na tabela T1 onde processado_flag é 'n', basta fazer o sono de thread por mais tempo. Embora todas as mensagens não sejam processadas, mantenha-a dormindo e não deixe o mecanismo de aplicativo concluído.

O único benefício que posso obter é que não tenho que esperar por vários casos de uma vez ou não ter que fazer a chamada síncrona. Toda a ideia é usar o componente por diferentes transações (como se fosse usado por dizer 100 pessoas -> 100 transações).

A menos que essas 100 transações forem concluídas, seremos garantir que a tabela T1 mantenha um registro do que continua. Se algo está errado, pode registrar as exceções pegadas pelo CI.

Quaisquer comentários sobre esta abordagem seriam apreciados. Obrigado antecipadamente!

Answer 1

Estamos assumindo uma abordagem diferente. Mesmo que possamos validar os dados nessas tabelas antes que o App Engine seja concluído, toda a ideia para enviar as mensagens de forma assíncrona é de nenhum uso. Nesse caso, usar mensagens síncronas seria melhor e executar os processos em paralelo.

Então, decidimos permitir que o mecanismo de inscrição seja concluído e publique todos os pedaços de dados através de mensagens e verifique se as mensagens são completamente consumidas no mesmo nó.

.

1. Vamos atualizar a tabela T1, para todas as linhas processadas / bem-sucedidas / com falha à medida que continuarmos consumindo as mensagens e usá-las conforme necessário.

2. Manteremos uma auditoria ou contador para todas as linhas publicadas e consumidas. Desde que expondo o mesmo componente a várias transações seria um enorme impacto de desempenho. Queremos ter certeza de que ele funciona melhor, como se dissesse que 50 usuários estão atualizando as mesmas tabelas por trás do componente usando o mesmo IC (é claro, diferentes instâncias). Eu estarei completando minha prova de conceito e espero que seja muito melhor do que executar os processos em paralelo.

Espero que isso possa ajudar qualquer um que esteja lidando com esses problemas de upload. Obrigado!