BizTalk Server Orchestration - Can we use a port type more than one time ?

This is Interesting: Free IT Magazines  
Home > Archive > BizTalk Server Orchestration > March 2005 > Can we use a port type more than one time ?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Can we use a port type more than one time ?
Yves Peneveyre

2005-03-16, 7:51 am

Hello !

I have a little problem with an orchestration which have 3 send ports that
have the same port type. These
ports are binded to a folder using the XMLTransmit pipeline.
The orchestration is called from a convoy (do not know if it does matter or
not...) and take an XML file for input.
The output is just the same file as the input one.

The steps to reproduce the problem are the following :
Drop an XML file produces a new XML file on the output side. Great, that is
what I want... !
But, when I drop a new XML file, nothing happens on the other side.
And when I drop a third XML file, the second one is going out.

It is like if BTS2004 hold a file, waiting for another file before dropping
it on the output.
Examining the orchestration with the HAT, I can see that the current
activity is the "Send" shape and stay here until I "Terminate Service" that
orchestrtion.

Using different port types for each send port fix the problem...

What happens ?
Why BTS2004 does not drop my files out ?
Can we use the same port type for more than one send port ?
Or anything else ?

I thank you very much in advance for your help.

Best Regards

Yves Peneveyre


Joerg Fischer

2005-03-16, 5:56 pm

Hi,

Can you send the orchestration to further analyse the issue?

Also, enrich the orchestration with DEBUG output (using an expression shape
and System.Diagnostics.Debug.WriteLine) to further analyse if the
orchestration really is stuck or if the problem resides somewhere else. The
orchestration debugger does not always indicate correct state information.

Do you habe any scopes in the orchestration with atomic transactions?

To answer your question: port types can and should be reused, so you are
taking the correct approach.

After placing the 2. message, what state remains the message in?

Sincerely

Joerg Fischer

"Yves Peneveyre" <ypeneveyre at lookware dot ch> wrote in message
news:#tp2qsiKFHA.3960@TK2MSFTNGP09.phx.gbl...
> Hello !
>
> I have a little problem with an orchestration which have 3 send ports that
> have the same port type. These
> ports are binded to a folder using the XMLTransmit pipeline.
> The orchestration is called from a convoy (do not know if it does matter

or
> not...) and take an XML file for input.
> The output is just the same file as the input one.
>
> The steps to reproduce the problem are the following :
> Drop an XML file produces a new XML file on the output side. Great, that

is
> what I want... !
> But, when I drop a new XML file, nothing happens on the other side.
> And when I drop a third XML file, the second one is going out.
>
> It is like if BTS2004 hold a file, waiting for another file before

dropping
> it on the output.
> Examining the orchestration with the HAT, I can see that the current
> activity is the "Send" shape and stay here until I "Terminate Service"

that
> orchestrtion.
>
> Using different port types for each send port fix the problem...
>
> What happens ?
> Why BTS2004 does not drop my files out ?
> Can we use the same port type for more than one send port ?
> Or anything else ?
>
> I thank you very much in advance for your help.
>
> Best Regards
>
> Yves Peneveyre
>
>



Yves Peneveyre

2005-03-16, 5:56 pm

Hello Joerg

I tried to put "Expression" shapes just before and just after "Send" shapes
to see what happens with DebugView.
And.....that is very strange. It seems working. I have all my "Before Send"
and "After Send" messages and the messages are going out.

To answer you question, I do not have any scope in that orcharstration nor
in the convoy calling it.
No transaction.

I am analysing further, but if you have other ideas you are welcome :-)

Many thanks


Yves Peneveyre


"Joerg Fischer >" <<NOT SPECIFIED> wrote in message
news:OTeiDIjKFHA.1176@TK2MSFTNGP12.phx.gbl...
> Hi,
>
> Can you send the orchestration to further analyse the issue?
>
> Also, enrich the orchestration with DEBUG output (using an expression

shape
> and System.Diagnostics.Debug.WriteLine) to further analyse if the
> orchestration really is stuck or if the problem resides somewhere else.

The
> orchestration debugger does not always indicate correct state information.
>
> Do you habe any scopes in the orchestration with atomic transactions?
>
> To answer your question: port types can and should be reused, so you are
> taking the correct approach.
>
> After placing the 2. message, what state remains the message in?
>
> Sincerely
>
> Joerg Fischer
>
> "Yves Peneveyre" <ypeneveyre at lookware dot ch> wrote in message
> news:#tp2qsiKFHA.3960@TK2MSFTNGP09.phx.gbl...
that[vbcol=seagreen]
> or
> is
> dropping
> that
>
>



Joerg Fischer

2005-03-23, 6:01 pm

Hi,

Can you send the orchestration?

Sincerely

Joerg Fischer

"Yves Peneveyre" <ypeneveyre at lookware dot ch> wrote in message
news:O$T1ikkKFHA.3512@TK2MSFTNGP15.phx.gbl...
> Hello Joerg
>
> I tried to put "Expression" shapes just before and just after "Send"

shapes
> to see what happens with DebugView.
> And.....that is very strange. It seems working. I have all my "Before

Send"
> and "After Send" messages and the messages are going out.
>
> To answer you question, I do not have any scope in that orcharstration nor
> in the convoy calling it.
> No transaction.
>
> I am analysing further, but if you have other ideas you are welcome :-)
>
> Many thanks
>
>
> Yves Peneveyre
>
>
> "Joerg Fischer >" <<NOT SPECIFIED> wrote in message
> news:OTeiDIjKFHA.1176@TK2MSFTNGP12.phx.gbl...
> shape
> The
information.[vbcol=seagreen]
> that
matter[vbcol=seagreen]
that[vbcol=seagreen]
>
>



Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com