Additive Message Header Properties?

[Steve A.]

Is there a way to call an endpoint and maintain the original message header properties?

Basically, I need to call a web service via the wsdl transport to get a new payload, but I don't want to lose my original message header properties.  

Functionally, the purpose of the web service call is to enrich the message--not to replace it.  I could conceive of having a pipeline of web service calls whereby the message is enhanced.

I know I can create a custom component and call the web service manually via web service client call, but I was hoping I could do it without any custom code.

Or, is there some other way like using the collection-aggregator-router to merge the original message with the new message created by the web service call?

Thanks in advance,

Steve

[Andrew Perepelytsya]

Hi Steve,

In any case, Mule can't guess which parts you want preserved. I'd implement this enricher as a custom component, although use component bindings to have cleaner interfaces.

HTH,
Andrew

On Oct 24, 2009 5:55 PM, "Steve A." <steve@...> wrote:


Is there a way to call an endpoint and maintain the original message header
properties?

Basically, I need to call a web service via the wsdl transport to get a new
payload, but I don't want to lose my original message header properties.

Functionally, the purpose of the web service call is to enrich the
message--not to replace it.  I could conceive of having a pipeline of web
service calls whereby the message is enhanced.

I know I can create a custom component and call the web service manually via
web service client call, but I was hoping I could do it without any custom
code.

Or, is there some other way like using the collection-aggregator-router to
merge the original message with the new message created by the web service
call?

Thanks in advance,

Steve
--
View this message in context: http://www.nabble.com/Additive-Message-Header-Properties--tp26043432p26043432.html
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Steve A.]

True, but it would be nice to be able to specify which properties to keep.

Actually, I was thinking the ideal solution would be a property of the chaining-router (e.g. collect="true") which would accumulate the messages into an Object[] payload instead of replacing them.

Thoughts?

Steve

Andrew Perepelytsya wrote:

Hi Steve,

In any case, Mule can't guess which parts you want preserved. I'd implement
this enricher as a custom component, although use component bindings to have
cleaner interfaces.

[antoine.borg]

Using the chaining router is an interesting idea since this router:
1 - Maintains state
2 - Can store whichever properties you want it to.

Consequently it seems to be ideal.  My only objection is that storing
message properties is not a "routing" task and therefore should be done
inside a component as Andrew suggests.

One innovative way of doing it would be as follows:

1 - Configure a service called "Collector" which has a component that
has a single method which will accept MuleEventContext and will
store/keep the properties in some structure.
2 - Send copies of the messages to this service. On the inbound side,
use the wiretap pattern for this but use multiple routers on the
outbound end so that you won't interfere with your flow.
3 - When you need the list of collected properties, issue a request to
the Collector. This request would trigger another method in the class
that returns the list.  This could be done in a transformer but best
practice dictates that it's done inside a component using Component
Bindings.

The flexibility in this approach is that you can design Collector to use
some sort of correlation ID to maintain multiple lists for multiple
messages.

HTH

A

Steve A. wrote:

> True, but it would be nice to be able to specify which properties to keep.
>
> Actually, I was thinking the ideal solution would be a property of the
> chaining-router (e.g. collect="true") which would accumulate the messages
> into an Object[] payload instead of replacing them.
>
> Thoughts?
>
> Steve
>
> Andrew Perepelytsya wrote:
>  
>> Hi Steve,
>>
>> In any case, Mule can't guess which parts you want preserved. I'd
>> implement
>> this enricher as a custom component, although use component bindings to
>> have
>> cleaner interfaces.
>>
>>
>>    
>
>  

--

Antoine Borg, Director of Services | Tel: [phone]
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM

See our full schedule of Mule and Android courses:
http://www.ricston.com/courses/schedules/

email: _antoine.borg_@... <mailto:antoine.borg@...> |
blog: blog.ricston.com <http://blog.ricston.com> | web: ricston.com
<http://www.ricston.com/>



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve A.]

Antoine, Thanks for the reply and related Custom Aggregation blog entry. Actually, upon further review, I thinking the collection-async-reply-router might work for me. I might check it out. If it doesn't, then certainly something similar would be great for the chaining router out of the box. Steve

antoine.borg wrote:

Using the chaining router is an interesting idea since this router: 1 - Maintains state 2 - Can store whichever properties you want it to. Consequently it seems to be ideal. My only objection is that storing message properties is not a "routing" task and therefore should be done inside a component as Andrew suggests. One innovative way of doing it would be as follows: 1 - Configure a service called "Collector" which has a component that has a single method which will accept MuleEventContext and will store/keep the properties in some structure. 2 - Send copies of the messages to this service. On the inbound side, use the wiretap pattern for this but use multiple routers on the outbound end so that you won't interfere with your flow. 3 - When you need the list of collected properties, issue a request to the Collector. This request would trigger another method in the class that returns the list. This could be done in a transformer but best practice dictates that it's done inside a component using Component Bindings. The flexibility in this approach is that you can design Collector to use some sort of correlation ID to maintain multiple lists for multiple messages.