Faire interagir/communiquer 2 travaux
Posté : mer. 05 août 2020, 14:00:49
Bonjour.
Je cherche comment faire communiquer 2 travaux (au sens job) pour que l'un pose une question à l'autre et reçoive la réponse, donc de manière synchrone (ce qui fait que j'ai éliminé l'utilisation des DTAQ, plus dédiées à des processus asynchrones de mon point de vue). J'explique le contexte :
Pour réaliser un calcul, il est nécessaire de rechercher beaucoup de paramètres dans différentes tables, plutôt bien peuplées, ce qui ralentit le processus. Comme ce processus est exposé en web service et doit être très réactif, je cherche à l'accélérer.
Mon idée, c'était de lancer un travail "de fond" qui chargerait tous les paramètres, puis qui se mettrait en attente de sollicitation pour effectuer le calcul et en renvoyer la réponse au solliciteur, puis qui se remettrait à attendre.
J'ai pensé au début utiliser les API socket (qui semblent tout à fait appropriées pour ce genre de configuration client/serveur), mais j'ai peur que l'instanciation de la connexion soit pénalisant pour un service web (mais je n'ai pas testé).
J'ai commencé à faire des tests avec des envois de messages (via API QMHSNDM) à une MSGQ scrutée par le travail de fond (via API QMHRCVM), et qui renvoie la réponse sous forme de réponse au message (via API QMHSNDRM). Mais je me heurte aux clés de messages que je n'arrive pas à faire coïncider entre celui qui poste le message (le programme qui sollicite un calcul) et celui qui le reçoit (le travail de fond) : l'API QMHSNDM renvoie une clé (ex. : 1), et l'API QMHRCVM reçoit le message avec une clé différente (ex : 17). Je n'arrive donc pas à envoyer la réponse au message d'origine, puisque je n'arrive pas à avoir sa clé.
Je vais essayer de passer des messages non *INQ avec des GUID pour être sûr que la réponse corresponde à la demande, mais j'ai l'impression de m'embarquer dans quelque chose de très complexe et fragile (si les programmes se décalent entre les demandes et les réponses, ça risque d'être joyeux).
Quelqu'un a-t'il déjà essayé ce genre de chose ? Avez-vous des conseils à me donner pour faire ce genre de processus ?
Merci.
Je cherche comment faire communiquer 2 travaux (au sens job) pour que l'un pose une question à l'autre et reçoive la réponse, donc de manière synchrone (ce qui fait que j'ai éliminé l'utilisation des DTAQ, plus dédiées à des processus asynchrones de mon point de vue). J'explique le contexte :
Pour réaliser un calcul, il est nécessaire de rechercher beaucoup de paramètres dans différentes tables, plutôt bien peuplées, ce qui ralentit le processus. Comme ce processus est exposé en web service et doit être très réactif, je cherche à l'accélérer.
Mon idée, c'était de lancer un travail "de fond" qui chargerait tous les paramètres, puis qui se mettrait en attente de sollicitation pour effectuer le calcul et en renvoyer la réponse au solliciteur, puis qui se remettrait à attendre.
J'ai pensé au début utiliser les API socket (qui semblent tout à fait appropriées pour ce genre de configuration client/serveur), mais j'ai peur que l'instanciation de la connexion soit pénalisant pour un service web (mais je n'ai pas testé).
J'ai commencé à faire des tests avec des envois de messages (via API QMHSNDM) à une MSGQ scrutée par le travail de fond (via API QMHRCVM), et qui renvoie la réponse sous forme de réponse au message (via API QMHSNDRM). Mais je me heurte aux clés de messages que je n'arrive pas à faire coïncider entre celui qui poste le message (le programme qui sollicite un calcul) et celui qui le reçoit (le travail de fond) : l'API QMHSNDM renvoie une clé (ex. : 1), et l'API QMHRCVM reçoit le message avec une clé différente (ex : 17). Je n'arrive donc pas à envoyer la réponse au message d'origine, puisque je n'arrive pas à avoir sa clé.
Je vais essayer de passer des messages non *INQ avec des GUID pour être sûr que la réponse corresponde à la demande, mais j'ai l'impression de m'embarquer dans quelque chose de très complexe et fragile (si les programmes se décalent entre les demandes et les réponses, ça risque d'être joyeux).
Quelqu'un a-t'il déjà essayé ce genre de chose ? Avez-vous des conseils à me donner pour faire ce genre de processus ?
Merci.