Possiamo aspettare che il motore dell'applicazione PeopleSoft attendesse i messaggi asincroni da completare?

Question

Sto cercando di elaborare un caricamento dei dati in cui sto cercando di pubblicare i messaggi attraverso PeopleSoft oltre il broker di integrazione in modo asincrono in un motore applicativo. L'intero punto è essere in grado di inviare diversi messaggi e consumarli nello stesso nodo. Prima di inviare i messaggi, sto memorizzando i dati su una tabella (diciamo T1) per memorizzare tutti i valori di campo nel file di caricamento.

Durante il consumo che sto cercando di esporre ogni messaggio all'interfaccia del componente e le eccezioni vengono registrate sulla stessa tabella T1. Diciamo per ogni transazione che stiamo segnalando il campo della tabella (dire processed_flag= 'y').

Ho bisogno di un meccanismo in cui avrei potuto aspettare tutti i messaggi asincroni da completare. Sto pensando di controllare la tabella T1, se ci sono delle righe sulla tabella T1 dove elaborad_FLAG è 'n', fai semplicemente il sonno del filo per più tempo. Mentre tutti i messaggi non vengono elaborati, tenerlo addormentato e non lasciare completare il motore dell'applicazione.

L'unico vantaggio che posso ottenere è che non devo aspettare più istanze contemporaneamente o non dover effettuare la chiamata sincrona. L'intera idea è quella di utilizzare il componente da parte di transazioni diverse (come se fosse usato dai 100 persone -> 100 transazioni).

A meno che tali 100 transazioni siano complete, saremo assicurati che T1 Table mandano un record di ciò che accade e spento. Se qualcosa non va, può registrare le eccezioni catturate dal ci.

Qualsiasi commento su questo approccio sarebbe apprezzato. Grazie in anticipo!

Answer 1

stiamo prendendo un approccio diverso. Anche se siamo in grado di convalidare i dati su quelle tabelle prima del completamento dell'App Engine, l'intera idea di inviare i messaggi in modo asincrono non è utile. In tal caso, l'utilizzo di messaggi sincroni sarebbe meglio e gestire i processi in parallelo.

Quindi, abbiamo deciso di consentire al motore di applicazione completare e pubblicare tutti i pezzi di dati tramite messaggi e assicurati che i messaggi siano completamente consumati nello stesso nodo.

.

1. Aggiorneremo la tabella T1, per tutte le righe elaborate / riuscite / non riuscite mentre continuiamo a consumare i messaggi e li usiamo come necessario.

2. terremo un audit o un banco per tutte le file pubblicate e consumate. Dal momento che esporre lo stesso componente a più transazioni sarebbe un enorme impatto sulle prestazioni. Vogliamo assicurarci che funzioni meglio, come se dicesse 50 utenti aggiornano le stesse tabelle dietro il componente utilizzando la stessa CI (ovviamente diversi istanze). Completerò la mia prova del concetto e spero che sarà molto meglio che correre i processi in parallelo.

Spero che questo possa aiutare qualcuno a che ha a che fare con questi problemi di caricamento. Grazie!