Messages en temps réel

Le système prend en charge les appels de service Web destinés à un système tiers, c'est à dire l'envoi de messages en temps réel.

Le système prend en charge une fonctionnalité spéciale pour l'envoi de messages email en temps réel. Pour plus d'informations, voir Envoyer des emails.

Pour le formatage et l'acheminement des autres types de messages en temps réel, le système utilise également le type de message sortant et la configuration du système tiers. Lors de la configuration des messages en temps réel, une étape supplémentaire est requise afin de définir le mécanisme d'acheminement à l'aide d'un émetteur de message. Le système prend en charge l'acheminement des messages via HTTP et via JMS. A noter que pour l'acheminement HTTP, le système prend également en charge l'envoi de messages avec un format JSON.

Comme pour les messages en quasi-temps réel, le lancement d'un message sortant peut s'effectuer à partir d'un script. Quand un message en temps réel est ajouté, le système l'achemine immédiatement vers le système tiers. Si le système tiers envoie un message de réponse, le système l'enregistre dans le message sortant. Si le type du message sortant pour le système tiers est associé à du code XSL de réponse, celui-ci est appliqué pour transformer la réponse. Dans ce cas, le système enregistre également la réponse brute dans le message sortant. A noter que l'objet métier Message sortant doit être configuré pour que la réponse XML soit capturée dans son schéma.

Toute erreur détectée implique l'attribution de l'état Erreur au message sortant. Le processus d'appel doit vérifier l'état du message sortant et lancer une action appropriée. Quand l'état du message sortant repasse à En attente, le message est traité à nouveau.

L'installation standard comporte deux services fonctionnels : Répartiteur de messages sortants (F1-OutmsgDispatcher) et Médiateur de message sortant (F1-OutmsgMediator) qui facilitent les appels de service Web. Ces deux services sont similaires ; ils permettent au script appelant de configurer le fonctionnement suivant (les différences étant notées) :

• La détection éventuelle des anomalies rencontrées lors de l'envoi des messages. L'interception des erreurs permet au script d'appel d'interroger les erreurs survenues et d'entreprendre toute autre action appropriée via un programme.
• La persistance éventuelle du message envoyé en tant qu'enregistrement de message sortant à part entière.

  • Si un message persistant est souhaité, il est recommandé d'utiliser le répartiteur de messages sortants. Ce service fonctionnel crée le message par l'intermédiaire d'un traitement d'objet métier standard et s'appuie sur la logique du message sortant pour l'acheminer et stocker l'enregistrement. Le message est acheminé après l'algorithme de prétraitement d'objet métier et après que l'enregistrement est devenu persistant, mais avant le post-traitement de l'objet métier et l'exécution des plug-ins d'audit. Si vous devez envoyer l'ID de message sortant dans le cadre du message, voir Capturer l'ID de message sortant dans le message pour plus d'informations.

  • Si le message ne doit pas être persistant, il est recommandé d'utiliser le médiateur de message sortant. Comme indiqué, le répartiteur de message sortant crée l'enregistrement de message sortant et s'appuie sur la logique du message sortant pour l'acheminer. S'il ne doit pas être persistant, il est ensuite supprimé. A l'opposé, le médiateur de message sortant exécute les algorithmes de prétraitement d'objet métier, puis achemine explicitement le message sans créer d'enregistrement de message. Ceci est plus efficace pour les scénarios qui ne nécessitent pas de persistance. Notez que le médiateur de message sortant prend également en charge la persistance, mais en créant les enregistrements sans faire appel à un traitement d'objet métier. Ce n'est pas recommandé. Le répartiteur est l'option à favoriser si la persistance est souhaitée.

Pour plus d'informations, voir les descriptions des deux services fonctionnels.