So, with just the Shapes you list, you would never receive that message.

That specific message means Zombie Messages have been created for a Correlation that no longer exists.

Here's a blog post describing the simplest Singleton implementation with a Zombie warning: https://fehlberg.wordpress.com/2008/06/06/biztalk-singleton-orchestration-design/

Thanks for replying to me.

Unfortunately I can say that I am receiving that message with just those shapes, everything I can find talks about zombie messages but that doesn't seem to apply here.  I have just rebuilt the Orchestration from scratch using exactly those shapes only (forgot to say all inside a single scope with an exception handler set to General Exception) and am still getting this message.  My individual maps test fine and everything works fine without the second construct message shape.

I am at a loss to understand this and will upload images as soon as I am 'verified'

• Edited by rocstat 20 hours 30 minutes ago

Hi, I'm new to BizTalk and am having trouble with a simple Orchestration I am trying to build.

I'm looking to receive a flat file which could contain multiple orders and am debatching it in the Pipeline.  I then have an Orchestration which receives this message, recombines it with the File Header and will then transform the message a couple of times to produce the final message which is sent out.  I have tested the orchestration can combine the message correctly (the Construct Single Order shape) and with a Send shape straight after it works fine.  However whenever I add an additional transform shape (ConstructMessage_1) the Orchestration fails with the message 'The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended.'  To be clear this occurs even when the input file has only one order and therefore only one message is processed.

I've tried numerous combinations of the position of the second transform and cannot get this to work (the final solution will have a number of Decide shapes to determine which transforms to run). I am sure there is something very simple I'm missing and would appreciate your help.  

I can't post images at the moment but will post one of the orchestration as soon as I am able, sequence of shapes is below

Receive Shape - receives debatched message

Construct Message Shape - ConstructSingleOrder, containing

  - Message Assignment (where I retrieve the Header information from the debatched message and assign it to a message)

  - Transform Shape (where I map the Header message and the body message into a single message)

Then I have another Construct message shape (ConstructMessage_1) containing a single Transform shape)

Finally a Send shape

• Edited by rocstat Thursday, February 26, 2015 9:00 AM

Let me clarify one thing.  You can get that error of you are Initializing a Correlation Set on that first Receive Shape.

Unfortunately not initializing a correlation set, Receive Port properties are

Activate - True

Description - Empty

Filter Expression - Empty

Initializing Correlation Sets - Empty

Message - OrderBody

Name - ReceiveSingleMessage

Object Type - Receive

Operation - ReceivePort...

Report to Analyst - True

Thanks

Look at the Message tab of the Suspended Orchestration instance.  That may give you a clue as to where the phantom message are coming from.

The message is the debatched message that is received by the Receive shape before it is mapped by my construct shape.  This is unusual because if there is no second message construct shape then it is processed correctly by the first message construct shape however it is not even making it through there when there is a later transform shape.

Thanks again for your help

OK, so I added a 1 minute delay between each stage of the orchestration to see if I could catch the message at any point before it suspends however it just suspends immediately before the first delay (immediately after the receive shape)

When I remove the final construct shape I can watch each stage of the orchestration as the messages are constructed and then delayed for 1 minute.  It seems that the presence of the final transform shape is suspending the instance at point of receive.

I have tested the final construct statement in it's own orchestration and it works on it's own however using the call orchestration shape once again causes the initial error.