2016-12-19 4 views
1

J'ai vu plus de quelques articles sur ce sujet, mais je n'arrive pas à trouver une solution à mon problème spécifique, que je pense est assez typique, à savoir: comment continuer à traiter les messages lorsqu'une erreur survient (Exception levée) en utilisant un séparateur/agrégateur.Spring Integration: Comment utiliser une "passerelle d'erreur" avec Splitter Aggregator lorsque l'exception est levée

La meilleure explication que j'ai trouvée est here. Mais il n'y a pas d'explication sur exactement quoi/comment fonctionnent les filtres/transformateurs. Et à la fin, l'auteur publie "Ça a marché!" mais sans publier un fichier SI.config.xml mis à jour. D'après ce que je comprends, l'idée est d'utiliser une "passerelle d'erreur", qui est en aval de la passerelle d'origine et après le séparateur. Le travail de cette passerelle serait si une exception est levée, pour faire face à cela, mais pour s'assurer (via un transformateur ou un filtre) que tous les messages le rendent à l'agrégateur.

Mon SI.config.xml très simplifié si plus ou moins comme ceci:

<int:gateway id="myGateway" ... /> // incoming gateway 
<int:chain ... input-channel="in" output-channel="out"> 
    <int:splitter ... /> 
    <int:service-activator /> 
    <int:aggregator /> 
</int:chain> 

Donc ma question est, où exactement à coller cette autre passerelle? Et comment configurer les filtres/transformateurs qui (d'après ce que je comprends) attraperaient le Message qui a lancé une Exception et le remettraient sur le bon canal (après l'avoir connecté ou autre ...) pour que tous les Messages parviennent à l'Aggregator.

J'ai regardé les échantillons SI, SO et les 2 SI (SI dans Acton et Pro SI) et je ne trouve pas d'exemple.

Répondre

0

La solution ressemble à:

<int:chain ... input-channel="in" output-channel="out"> 
    <int:splitter ... /> 
    <int:gateway request-channel="processChannel" errorChannel="processError"/> 
    <int:aggregator /> 
</int:chain> 

<int:chain input-channel="processChannel"> 
    <int:service-activator /> 
</int:chain> 

Le error handler sur le canal processError devraient consulter entrant ErrorMessage et retourne une compensation qui sera envoyée au aggregator.

Le ErrorMessage contient généralement MessagingException avec failedMessage lorsqu'une erreur est survenue. Ce failedMessage contient tous les en-têtes utiles pour aller de l'avant avec une compensation. Certains d'entre eux sont replyChannel et errorChannel, mais pour votre aggregator si vous avez besoin tous les correlationId, sequenceNumber, sequenceSize etc. En d'autres termes lorsque vous créez un message de compensation à envoyer avant l'aval pour la aggregator, vous devez copier tous les headers de que failedMessage.

Pour plus d'informations: http://docs.spring.io/spring-integration/docs/4.3.5.RELEASE/reference/html/configuration.html#namespace-errorhandler

+0

Bon, je vois ce que vous dites. Je n'ai pas compris que c'était si "facile", je n'avais jamais vu un exemple comme celui-ci. C'est parfaitement logique, mais je ne pense pas que je l'aurais jamais découvert par moi-même; c'est presque comme si vous ajoutez "gratuitement" une passerelle au milieu de la chaîne, alors que vous pourriez simplement utiliser un activateur de service. Mais bien sûr, l'utilisation d'une passerelle vous permet de définir un canal d'erreur ... et vous pouvez bien sûr ajouter un gestionnaire/service-activateur pour gérer l'exception, puis ajouter les en-têtes pour que le flux continue vers l'agrégateur. Merci beaucoup! –

+0

Vous pouvez trouver quelque chose de similaire dans le manuel de référence http://docs.spring.io/spring-integration/docs/4.3.5.RELEASE/reference/html/messaging-routing-chapter.html#chain, où nous parlons de chaîne à partir de la chaîne –

+0

Si vous êtes, le cas d'utilisation exact est abordé sous "Appel d'une chaîne à l'intérieur d'une chaîne". Je n'avais pas examiné cette section de très près parce que je ne pensais pas que c'était ce que je devais faire pour utiliser une «passerelle d'erreur». Mais oui, c'est bien expliqué là. Merci! –