Pouvons-nous attendre que PeopleSoft Application Le moteur attendra les messages asynchrones à compléter?

Question

J'essaie de traiter un téléchargement de données où j'essaie de publier les messages via PeopleSoft sur un courtier d'intégration de manière asynchrone dans un moteur d'application. L'ensemble point est de pouvoir envoyer plusieurs messages et de les consommer dans le même noeud. Avant d'envoyer les messages, je stocke les données sur une table (disons T1) pour stocker toutes les valeurs de champ dans le fichier de téléchargement.

Tout en consommant, j'essaie d'exposer chaque message à l'interface de composant et que les exceptions sont connectées sur la même table T1. Disons pour chaque transaction que nous signalons le champ de la table (sons traitéed_flag= 'y').

J'ai besoin d'un mécanisme où je pouvais juste attendre que tous les messages asynchrones se terminent. Je pense que vous envisagez de vérifier la table T1, s'il y a des lignes sur la table T1 où Processed_Flag est 'n', rendez-vous simplement le fil de dormir pendant plus de temps. Bien que tous les messages ne soient pas traités, gardez le sommeil et ne laissez pas le moteur d'application compléter.

Le seul avantage que je puisse obtenir est que je n'ai pas besoin d'attendre de multiples instances à la fois ou n'a pas à faire l'appel synchrone. Toute l'idée est d'utiliser le composant par différentes transactions (comme s'il était utilisé par Say 100 personnes -> 100 Transactions).

Sauf si ces 100 transactions sont complètes, nous vous assurerons que la table T1 conserve un enregistrement de ce qui se passe et éteint. Si quelque chose ne va pas, il peut enregistrer les exceptions attrapées par le CI.

Tous les commentaires sur cette approche seraient appréciés. Merci d'avance!

Answer 1

Nous prenons une approche différente. Même si nous sommes en mesure de valider les données sur ces tables avant la fin de l'App complétant, toute l'idée d'envoyer les messages de manière asynchrone est sans usage. Dans ce cas, l'utilisation de messages synchrones serait mieux et exécuter les processus en parallèle.

Ainsi, nous avons décidé de laisser le moteur d'application compléter et de publier tous les morceaux de données via des messages et assurez-vous que les messages sont complètement consommés dans le même noeud.

1. Nous mettrons à jour le tableau T1, pour toutes les lignes traitées / réussies / défaillantes, car nous continuons à consommer les messages et à les utiliser au besoin.

2. Nous garderons un audit ou un compteur pour toutes les lignes publiées et consommées. Étant donné que l'exposant le même composant à plusieurs transactions serait un impact énorme de la performance. Nous voulons nous assurer qu'il fonctionne mieux, comme indiquer 50 utilisateurs mettant à jour les mêmes tables derrière le composant à l'aide du même CI (bien sûr différentes instances). Je finirai ma preuve de concept et j'espère que ce sera bien mieux que d'exécuter les processus en parallèle.

J'espère que cela peut aider n'importe lequel qui traite de ces problèmes de téléchargement. Merci!