prevent infinite loop in orchestration using bts.operation in filt

isabelledc

well ,

in one of my previous posts i followed the solution for preventing an
infinite loop...
that is "add a clause to the subscription filter on the Receive shape to
test that the BTS.Operation name is not the same as the one in your
orchestration."

If I did that (using double quotes round the operation-name )
the orchestration did not pick up the message....I suppose since the message
arrives through a regular adaptor ...there's no bts.operation in the
properties.
It only has this property once it passed the orchestration

How do you do something like this then...
I've solved it now by NOT using a direct bound port , but using the specify
later and filtering on my receive-port...

But I'd like to know how to do this using direct bound ports...


Isabelle

Jan Eliasen

On Mon, 3 Dec 2007 01:35:00 -0800, isabelledc
<> wrote:

>How do you do something like this then...
>I've solved it now by NOT using a direct bound port , but using the specify
>later and filtering on my receive-port...
>
>But I'd like to know how to do this using direct bound ports...
Well, it very much depends on your setup. Basically, if you have a
receive shape that filters on messagetype and nothing else, everything
which is that messagetype that is published to the messagebox will go
to your orchestration. A way out, off course, is to map the incoming
message to anothe rmessagetype inside your orchestration, and publish
that to the messagebox. That won't fullfill the filter on your receive
shape.

--
eliasen, representing himself and not the company he works for.

Private blog:

Private email:

isabelledc

So , You can't solve it unless you create a new messagetype and map
accordingly i suppose
or you could change some promoted property i presume so you can use this...


Either way it just doesn't work as 'simple' as is mentioned in the 8 tips
and tricks..


Perhaps it's recommended to use direct bound ports mostly for send-ports
anyhow?
I prefer putting as much as possible on receive and sendports
anyway...certainly filters. So by NOT USING a direct bound port on the
receiving end I can play with the filter-settings on the receive port,
and by USING a direct bound port on the sending end...i can change the
filter on the send port since the message is put back in the messagebox first.


"Jan Eliasen" wrote:

> On Mon, 3 Dec 2007 01:35:00 -0800, isabelledc
> <> wrote:
>
> >How do you do something like this then...
> >I've solved it now by NOT using a direct bound port , but using the specify
> >later and filtering on my receive-port...
> >
> >But I'd like to know how to do this using direct bound ports...
> Well, it very much depends on your setup. Basically, if you have a
> receive shape that filters on messagetype and nothing else, everything
> which is that messagetype that is published to the messagebox will go
> to your orchestration. A way out, off course, is to map the incoming
> message to anothe rmessagetype inside your orchestration, and publish
> that to the messagebox. That won't fullfill the filter on your receive
> shape.
>
> --
> eliasen, representing himself and not the company he works for.
>
> Private blog:
>
> Private email:
>

Jan Eliasen

On Mon, 3 Dec 2007 06:03:02 -0800, isabelledc
<> wrote:

>So , You can't solve it unless you create a new messagetype and map
>accordingly i suppose
>or you could change some promoted property i presume so you can use this...
Well, something needs to differ the messages your orchestrations
should pick up from the messages it shouldn't pickup. Unfortunately,
we don't have an "not exists" predicate to use in filters.

>Perhaps it's recommended to use direct bound ports mostly for send-ports
>anyhow?
No, definately not. using direct bound ports are a nice and beautiful
solution to routing... if you can get it working :-) Pitfalls are too
generic filters, which will let orchestrations and/or send ports pick
up something they weren't supposed to pick up.

>I prefer putting as much as possible on receive and sendports
>anyway...certainly filters. So by NOT USING a direct bound port on the
>receiving end I can play with the filter-settings on the receive port,
filter setting on the receive port? Do you mean the receive shape?

>and by USING a direct bound port on the sending end...i can change the
>filter on the send port since the message is put back in the messagebox first.
Yes.

--
eliasen, representing himself and not the company he works for.

Private blog:

Private email:

Jan Eliasen

On Mon, 3 Dec 2007 06:03:02 -0800, isabelledc
<> wrote:

>So , You can't solve it unless you create a new messagetype and map
>accordingly i suppose
>or you could change some promoted property i presume so you can use this...
Well, something needs to differ the messages your orchestrations
should pick up from the messages it shouldn't pickup. Unfortunately,
we don't have an "not exists" predicate to use in filters.

>Perhaps it's recommended to use direct bound ports mostly for send-ports
>anyhow?
No, definately not. using direct bound ports are a nice and beautiful
solution to routing... if you can get it working :-) Pitfalls are too
generic filters, which will let orchestrations and/or send ports pick
up something they weren't supposed to pick up.

>I prefer putting as much as possible on receive and sendports
>anyway...certainly filters. So by NOT USING a direct bound port on the
>receiving end I can play with the filter-settings on the receive port,
filter setting on the receive port? Do you mean the receive shape?

>and by USING a direct bound port on the sending end...i can change the
>filter on the send port since the message is put back in the messagebox first.
Yes.

--
eliasen, representing himself and not the company he works for.

Private blog:

Private email:

Jan Eliasen

On Mon, 3 Dec 2007 06:03:02 -0800, isabelledc
<> wrote:

>So , You can't solve it unless you create a new messagetype and map
>accordingly i suppose
>or you could change some promoted property i presume so you can use this...
Well, something needs to differ the messages your orchestrations
should pick up from the messages it shouldn't pickup. Unfortunately,
we don't have an "not exists" predicate to use in filters.

>Perhaps it's recommended to use direct bound ports mostly for send-ports
>anyhow?
No, definately not. using direct bound ports are a nice and beautiful
solution to routing... if you can get it working :-) Pitfalls are too
generic filters, which will let orchestrations and/or send ports pick
up something they weren't supposed to pick up.

>I prefer putting as much as possible on receive and sendports
>anyway...certainly filters. So by NOT USING a direct bound port on the
>receiving end I can play with the filter-settings on the receive port,
filter setting on the receive port? Do you mean the receive shape?

>and by USING a direct bound port on the sending end...i can change the
>filter on the send port since the message is put back in the messagebox first.
Yes.

--
eliasen, representing himself and not the company he works for.

Private blog:

Private email:

Jan Eliasen

On Mon, 3 Dec 2007 06:03:02 -0800, isabelledc
<> wrote:

>So , You can't solve it unless you create a new messagetype and map
>accordingly i suppose
>or you could change some promoted property i presume so you can use this...
Well, something needs to differ the messages your orchestrations
should pick up from the messages it shouldn't pickup. Unfortunately,
we don't have an "not exists" predicate to use in filters.

>Perhaps it's recommended to use direct bound ports mostly for send-ports
>anyhow?
No, definately not. using direct bound ports are a nice and beautiful
solution to routing... if you can get it working :-) Pitfalls are too
generic filters, which will let orchestrations and/or send ports pick
up something they weren't supposed to pick up.

>I prefer putting as much as possible on receive and sendports
>anyway...certainly filters. So by NOT USING a direct bound port on the
>receiving end I can play with the filter-settings on the receive port,
filter setting on the receive port? Do you mean the receive shape?

>and by USING a direct bound port on the sending end...i can change the
>filter on the send port since the message is put back in the messagebox first.
Yes.

--
eliasen, representing himself and not the company he works for.

Private blog:

Private email:

isabelledc

oops sorry, you're right no filters on receiveports
(guess this was bts2002 that jumped out one more time where you put filters
on
channels)

What I ment to say was...
I like using as much as possible the 'non-coded' possibilities instead of
putting the
filter in the orchestrations receive shape for instance...simply because if
you want to change something I can do it without rebuilding/deploying....

I've solved it now by not using a direct bound port on the receive end and
just picking up message that come from a specific port using the binding
property in bts admin. This port receives lots of other types of messages as
well but there i use the 'hidden' filter of the messagetype that is in the
orchestration.

On the sendport side I do use direct bound ports and i select only those
message that have the BTS.operation set to the orchestration-operation and
some other stuff too (promoted property and message type)

This seems to work OK, so I'm happy....

"Jan Eliasen" wrote:

> On Mon, 3 Dec 2007 06:03:02 -0800, isabelledc
> <isabelledc@discussions.microsoft.com> wrote:
>
> >So , You can't solve it unless you create a new messagetype and map
> >accordingly i suppose
> >or you could change some promoted property i presume so you can use this...
> Well, something needs to differ the messages your orchestrations
> should pick up from the messages it shouldn't pickup. Unfortunately,
> we don't have an "not exists" predicate to use in filters.
>
> >Perhaps it's recommended to use direct bound ports mostly for send-ports
> >anyhow?
> No, definately not. using direct bound ports are a nice and beautiful
> solution to routing... if you can get it working :-) Pitfalls are too
> generic filters, which will let orchestrations and/or send ports pick
> up something they weren't supposed to pick up.
>
> >I prefer putting as much as possible on receive and sendports
> >anyway...certainly filters. So by NOT USING a direct bound port on the
> >receiving end I can play with the filter-settings on the receive port,
> filter setting on the receive port? Do you mean the receive shape?
>
> >and by USING a direct bound port on the sending end...i can change the
> >filter on the send port since the message is put back in the messagebox first.
> Yes.
>
> --
> eliasen, representing himself and not the company he works for.
>
> Private blog:
>
> Private email:
>