Hi,
This is related to the same issue ...
Can the bpel process instance id be inserted an a message exchange
property on each message exchange coming from a single process instance ?
it does'nt solve all the issues I have (and it's different from
propagating the id coming from the JBI client of the bpel process) ...
is that sensible ?
Roger
This is exactly what I meant.
Sorry if this has not been very clear ;-)
The only problem was I have no idea where / how
to store / retrieve this correlation id ...
On 3/29/07, Alex Boisvert <[EMAIL PROTECTED]> wrote:
So how about this:
-set the JBI correlation id on the instance when the engine receives a
one-way message or a request (overwrite if already present)
-copy JBI correlation id on all outgoing mex
Does that meet your simple-problem-simple-solution criteria? (Maybe
that's
what you meant all along? :))
alex
On 3/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>
> You're quite true when you imply that the actual ServiceMix
> correlation id does not cover all the possible cases.
> I'm quite sure that for rather complex scenarios, this
> very limited feature will be unusable.
>
> The aim is to provide a basic feature that can provide meaningful
> information in the most common cases. The idea is that all JBI
exchanges
> that are related together will have the same correlation id. This
id is
> usually
> set by the first component sending the JBI exchange (usually a BC
acting
> as a consumer in the JBI meaning of the term). The most obvious
> cases where this will fail is when a component aggregates several
> unrelated
> messages to produce another message (be it a bpel process or another
> component).
>
> As there is no way to do that in a pure JBI way, ServiceMix relies on
its
> components to behave correctly and set the correlation id on related
> exchanges. So, for simple components, everything will work
> transparently and no additional code is required. But Ode is
> a complex component ...
>
> As for a global tracking system, this will certainly fail at some
point
> as I said earlier, but things can always be improved ... For example
> a JBI exchange could have a list of exchange ids that were directly
used
> to create an exchange (in case of an aggregation), so that we could
> go up the chain of exchanges to the first one(s) ...
>
> So in short, this feature is a basic implementation that certainly
does
> not
> cover all the possibles cases and thus requires a simple solution :-)
>
>
