Implement req-resp port with two separated receive and send ports?

[v.k.e]

The idea was to configure in the BizTalk Explorer static port of
request-response type and use it in the orchestration by means of two direct
bound ports for receiveing inbound and sending outbound messages

After receiving inbound message from adapter with assisted direct bound port
I tried to use two promoted properties to send response message to adapter
BTS.EpmRRCorrelationToken and BTS.RouteDirectToTP and one helper correlation
set for promoting this properties while sending:

outMsg(BTS.EpmRRCorrelationToken) = inMsg(BTS.EpmRRCorrelationToken);
outMsg(BTS.RouteDirectToTP) = true;

And it's work! Adapter accept this message (susbcription condition was
realized), but after failed with this NACK message text:
A response message for two-way receive port "RR_Receive_Port" is being
suspended as the messaging engine could not correlate the response to an
existing request message. This usually happens when the host process has been
recycled.

Does anybody know how can i make this work ?

P.S. Sorry for my English ...

[Saravana Kumar]

BizTalk internally implies a completely asyn processing no matter whether you
communication is Sync or Async. BizTalk achieves it in a clever way by its
highly tunned pub/sub mechanism.

When looking at it initially, the scenario will look simple just play with
BTS.EpmRRCorrelationToken and BTS.RouteDirectToTP promoted property and
you'll achive the desired sychronous pattern seamlessly, but the reality is
BizTalk does quite bit of magic against the basic pub/sub architecture when
it comes to this two properties.

Read the post by Yossi, it explain all about it

http://www.sabratech.co.uk/blogs/yossidahan/2006/06/sync-to-async-conversion.html
--
Regards,
Saravana Kumar
http://www.biztalk247.com/v1/
http://www.digitaldeposit.net/blog
[Please mark the response as "Answer" if it solves your problem.]

[v.k.e]

Yossi Dahan wrote:
"To my surprise - the message published to the message box had the
EpmRRCorrelationToken property in a not promoted state, regadless of my best
efforts. It seems as if BizTalk is actually ensuring that it is not promoted"

It's not true. I use BizTalk Server 2006 for testing this.
EpmRRCorrelationToken and RouteDirectToTP properties was successfully
promoted and my response message fiailed after subscription was realized.
That's not the point.

[v.k.e]

Yossi Dahan wrote:
"To my surprise - the message published to the message box had the
EpmRRCorrelationToken property in a not promoted state, regadless of my best
efforts. It seems as if BizTalk is actually ensuring that it is not promoted"

It's not true. I use BizTalk Server 2006 for testing this.

EpmRRCorrelationToken property was successfully promoted and my response

[v.k.e]

Yossi Dahan wrote:
"To my surprise - the message published to the message box had the
EpmRRCorrelationToken property in a not promoted state, regadless of my best
efforts. It seems as if BizTalk is actually ensuring that it is not promoted"

It's not true. I using BizTalk Server 2006 for testing this.

EpmRRCorrelationToken property was successfully promoted and my response
message fiailed after subscription was realized. That's not the point.

[askf...@mailinator.com]

I'm trying to implement a similar solution, did you manage to get this
working?

On 2 May, 12:58, v.k.e <v...@discussions.microsoft.com> wrote:
> The idea was to configure in the BizTalk Explorer static port of
> request-response type and use it in the orchestration by means of two direct
> bound ports for receiveing inbound and sending outbound messages
>
> After receiving inbound message from adapter with assisted direct bound port
> I tried to use two promoted properties to send response message to adapter

> BTS.EpmRRCorrelationTokenand BTS.RouteDirectToTP and one helper correlation

[v.k.e]

No. I think the fact is that instance-subscription, originating by
static-port has property Request/Response = False . Apparently the "magic"
Saravana Kumar mentioned occurs exactly when login orchestration
request-response port binds to physical port. I.e. some additional tuning
that affects on adapter behaviour is created.

[v.k.e]

"sorry, misprint: "logic orchestration" instead "login orchestration"

[askf...@mailinator.com]

That's a shame, and annoying, I'll have to go back to the drawing
board I think.

On 10 May, 06:36, v.k.e <v...@discussions.microsoft.com> wrote:
> "sorry, misprint: "logic orchestration" instead "login orchestration"
>
> "v.k.e" wrote:
> > No. I think the fact is that instance-subscription, originating by
> > static-port has property Request/Response = False . Apparently the "magic"
> > Saravana Kumar mentioned occurs exactly when login orchestration
> > request-response port binds to physical port. I.e. some additional tuning
> > that affects on adapter behaviour is created.
>