Re: Infinite output messages for one input message

Hi Dave,

My intent was to use a transform shape within my orchestration as you
described. However I was told that mappings in a port are faster/more
efficient than a transform in an orchstration. So I thought I would try that
way. I've lost so much time that I will go back to my original method which
you've described.

Yes the orchestration is pretty bland, but I was just wanted to bind the
receive and send ports first. My design for this orchestration was to
receive MainOut and make some more modifications before finally outputting
it. I wanted the map on the receive port to create MainOut and then I could
work with it.

I think you are right when you say that my orchestration receives MainOut
naturally. It seems to be confusing the way you have to map it or the
language that's used: If I add a receive port to my orchestration that
receives MainIn messages (even though the port will map it to MainOut), the
receive shape that I add to my orchestration must be set to receive MainIn
messages otherwise I cannot link the port and shape together!

By the way you were right about the original processing of infinite
messages: I ran a test where I dropped my one input message, but first I
stopped the send port. I waited about 10-15 seconds before stopping the
orchestration as well. In the Group Activity Hub I saw dozens of instances of
my orchestration waiting to output messages! ;-)

Thanks for all of your time!!

"Dave" wrote:

On Apr 17, 4:34 pm, Tony Hedge <TonyHe...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Hi Dave,

Your logic makes a lot of sense and it sounds like that is what is
happening. I will try to map the opchestration directly to the receive port
as opposed to the message box. I was having some difficulty doing this
earlier because I want my orchestration to work with the xml file from the
result of the map, which is MainOut.xml. Mapping to the receive port means
that my orchestration will receive MainIn.xml. Is that right?

Thanks... Hedge

"Dave" wrote:
On Apr 17, 4:04 pm, Tony Hedge <TonyHe...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Hello all,

Any help at all would be greatly appreciated, I think the following is
simple to follow. I'm using BizTalk 2006...

I have a schema that produces the following xml:
<MainIn>
<InA>
<InAElement1></InAElement1>
<InAElement2></InAElement2>
</InInA>
<InB>
<InBElement1></InBElement1>
<InBElement2></InBElement2>
</InB>
.....
<InF>
<InFElement1></InFElement1>
<InFElement2></InFElement2>
</InF>
</MainIn>

I have another schema that produces the following xml:
<MainOut>
<OutElement1></OutElement1>
<OutElement2></OutElement2>
<OutElement3></OutElement3>
<OutElement4></OutElement4>
</MainOut>

I have a map with MainIn as the source schema and MainOut as the destination
schema. I have reduced mappings to the following two direct node mappings for
testing:
InAElement1 to OutElement1
InBElement1 to OutElement2

I have a receive port tied to this map, so that when I drop a xml file
matching schema MainIn.xsd it will put an MainOut.xml file in the message
box. I then have a very simple orchestration that receives MainOut.xml files
from the message box and send it out to a send port. Sounds pretty simple and
it *almost* works...

However when I drop a MainIn.xml file with one 'record', I get back infinite
MainOut.xml files in the folder tied to the send port!!! File after file is
being generated. What is causing one input xml to produce so many messages???
The situation is as simple as I've described. I have no functoids in my map,
and only a receive port, receive message shape, send message shape, and send
port in my orchestration. This is driving me crazy!! A client is going to
be sending us xml files almost identical to MainIn.xsd, and I have to output
almost identical to MainOut.xml so I need to know what's causing this
behavior. Thanks in advance for any help. :-)

Tony Hedge

You might try binding your orchestration to your receive port..
It seems to me that the map in your receive port is creating a message
of type MainOut, and the presence of this in your messagebox is
causing the orchestration to activate. Your orchestration (I'm
guessing!) is then publishing this message to the messagebox to be
picked up by the send port. However, this message is also of type
MainOut, thereby causing another orchestration to activate, publish
another message etc. etc.

Couple of solutions:
1. Bind the receive port to the orchestration, ditto the sent port
2. Do the mapping inside the orchestration i.e. your orchestration
activates on receipt of a MainIn and creates a MainOut

From the way you describe your solution do you even need an
orchestration? You could just do the transform as you describe it in
your receive port and then use a suitably filtered send port to
transmit the message

Hope this helps!
Dave

I haven't done this in quite a while but no, I don't think that's
correct. Your receive port will apply the map to MainIn and then pass
MainOut to your orchestration (note: you need to bind your
orchestration to this receive port in orchestration designer or else
select 'specify later' and bind your receive port at deploy time).

If doing this is causing you trouble then you could remove the map
from your receive port and apply it within the orchestration i.e. the
orchestration receives MainIn, applies the map (within a construct
message shape) to create MainOut and then publishes this MainOut
message. From your brief overview of the scenario I don't think it
will make a difference to your overall functionality.

Going one step further (and as I've already mentioned) if all that
your orchestration is doing is routing the message to a send port I
would suggest that you drop the orchestration altogether. Create a
send port that is filtered based on BTS.ReceivePortName = X (where x
is the name of your receive port)
This way the MainIn message is mapped to a MainOut by your receive
port and then your send port will forward this MainOut message to its
destination.

Dave


.

Relevant Pages

  • Re: Infinite output messages for one input message
    ... I will try to map the opchestration directly to the receive port ... that my orchestration will receive MainIn.xml. ... I have a receive port tied to this map, so that when I drop a xml file ...
    (microsoft.public.biztalk.general)
  • Re: System.OutOfMemoryException was thrown
    ... Receive Location configured with the Sql Adapter picks up messages that ... Send Port subscribes to the above messages and then Send Ports Send ... Logical Port in orchestration is then bound to physical MQ port end point. ... Exception type: PersistenceItemException ...
    (microsoft.public.biztalk.general)
  • Deployment Error. Object reference not set to an instance of an ob
    ... Reading binding information for assembly ... "Graham.Corp.Ecom.Enterprise.Common.orchIDocInternalError" port ... Orchestration port is bound to send port ... assemblies. ...
    (microsoft.public.biztalk.general)
  • Re: Infinite output messages for one input message
    ... I will try to map the opchestration directly to the receive port ... that my orchestration will receive MainIn.xml. ... of type MainOut, and the presence of this in your messagebox is ...
    (microsoft.public.biztalk.general)
  • Re: Infinite output messages for one input message
    ... To be sure you have to UNENLIST not only stop your send port. ... Yes the orchestration is pretty bland, but I was just wanted to bind the ... I wanted the map on the receive port to create MainOut and then I ...
    (microsoft.public.biztalk.general)