Chris Restall

I hate to xpost from another forum but I've burned up two days on this and am starting to get desparate...

I thought I had proven to myself that I could use direct binding to
the messagebox with logical orchestration ports and correlation, it works but I always
get the following non-resumable error:

"The instance completed without consuming all of its messages. The
instance and its unconsumed messages have been suspended."

Not sure I understand this as the messages all process fine.


I basically set up a proof of concept scenario to simulate partners sending us their PO's, us processing it and sending ot to another partner. Then getting a POAck from the second partner back and correlating it to the orchestration that handld the original PO.:


1. I have a receive shape in an orchestration that has a filter for
specific messages coming in based on a promoted property, this
orchestration takes a PO doc type from a direct message box bound
logical recieve port.


2. Properties for routing are set in the PO message. I initialize a
correlation set with a value from the PO Message and send the message to
a direct bound to message box logical send port.


3.Right below the send, I have a 2nd receieve shape with Following
correlation set using the same as the Initializing in the send shape above.
It receives POAck messages from a direct messagebox bound logical
receieve port.


4.Properties for routing are set in the message. The POAck message is
sent out to a direct messagebox bound send port to be picked up by a
filtering physical send port for outbound transport.


Everything works as it should and correlation is occuring. My POack goies to where it should...

But I get that zombie message every time. Reading up on the zombie messgae, the causes don't really seem like they fit anything I'm doing.

If I bind the 2nd logical receieve port (for POAcks) to a physical recieve port in the BT administration
tool, everything works with no error message.


The problem is I will never know what Physical port my POAck will
come in on (there are many avenues in our solution), thats why direct
binding to the messagebox is necessary.

The HAT Message flow viewer for the suspended orchestration shows the state as complete and eacj step being OK. I've read a ton of documentation on correlation and it seems like this is somethiong that should be possible. My POC is basically the

Am I doing something wrong or is this just the nature of how correlation must work(physical receieve port binding is mandatory)

Any advise is greatly appreciated..



Re: BizTalk R2 General Correlation Zombie error

Leonid Ganeline - MVP

Do you have any test ports with subscription to these messages (With the same subsriptions as in orchestration)





Re: BizTalk R2 General Correlation Zombie error

mitre

Hi Leonid,

To isolate the problem, I bound all of the logical ports to physical ports except the 2nd receive (receive for the POAck) which I am using the same correlation set in my followed as the correlation in the previous PO send shape used for initialization.

The instance subscription generated looks like this:

http://Microsoft.Samples.BizTalk.Orchestrations.Correlation.PropertySchema.PurchaseOrderID == PO1234 And

http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://Microsoft.Samples.BizTalk.Orchestrations.Correlation.POAck#POAck

This tells me that the dehydrated orchestration instance should be re-hydrated and pick up where it left off when a POAck with a PurchaseOrderID of "PO1234" is published to the messagebox and subscribed to by this receieve.

My correlation set in this POC is basically one property, the PO1234 value for purchaseOrderID. This works but I still get the zombie message. Not sure what message is unconsumed here, it's correlating and processing my POAck. Now if I change this 2nd receive to use a physical receivePort, the ReceivePortID is added to the instance subscription and it works with no error message:

The instance subscription generated looks like this:

http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {750A2CCD-97F1-4D84-AFE9-342087C73A2D} And

http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://Microsoft.Samples.BizTalk.Orchestrations.Correlation.Invoice#Invoice And

http://Microsoft.Samples.BizTalk.Orchestrations.Correlation.PropertySchema.PurchaseOrderID == PO1234

Not sure if this is a bug or limitation but it seems odd that simple correlation would require a message to come through a specific, physical, Receive Port even when direct binding to the messagebox is used. The subscription is specific enough that it already can locate the orchestration instance and the process appears to work OK, why is a ReceievePortID required here





Re: BizTalk R2 General Correlation Zombie error

Leonid Ganeline - MVP

The zombie is created when 1) the message is published and it has the appropriate subscription in this moment; 2) then instance-subscriber is finished and does not consume the message.
Sure you know it, but try to analize why 2) happened. Look at the HAT to Sent and Received messages. Try to make snaps the "after" and "before" statuses.
I can't see any errors in yours tasks.





Re: BizTalk R2 General Correlation Zombie error

mitre

Hi Leonid,

Yeah, 2) puzzles me. If my POAck was not being consumed by the orchestration, or the service instance was ending before completing processing of themessage, why does my POAck get picked up by a physical bound send port, the last step in the orchestration. I've used debugview and trace statements as well and can see the correlation happening as it should in the orchestration. HAT message viewing looks completely normal, the ,service status is aways OK, even on the suspended service instance, all steps show as OK.and a state of started for the PO part of the process.

On the zombie message for the service suspend, HAT Message Flow also shows all steps as Status 'OK', State 'Complete'. If I switch to the Orchestration debugger, it looks like it starts with an Initialization step, shows every step in my orchestration and ends with another Initialization step Is that normal That last initialization step would seem like it could cause the issue, not sure how or why it would happen though.





Re: BizTalk R2 General Correlation Zombie error

Leonid Ganeline - MVP

Zombie, huh...
Are you mention http://msdn2.microsoft.com/en-us/library/bb203853.aspx "Zombies in BizTalk Server 2006"
See an exelent article in BizTalk HotRod (issue 1).
Seems the source of this zombie is outside the orchestration. Where ..





Re: BizTalk R2 General Correlation Zombie error

mitre

The conditions specified in this article are different then my scenario. To make matters more interesting, simply using a Physical bound receieve port instead of a direct bound one fixes the issue. Won't work for my scenario though as I require direct to messagebox binding.

So the question is, what externally would cause this My proof of concept at this point is nothing more then the the MSDN example for correlation except I changed the 2nd receieve port to be direct instead of a physical bound port.

It's a very easy "issue" to duplicate, simly download the MSDN correlation example from here: http://msdn2.microsoft.com/en-us/biztalk/aa937647.aspx change the second receieve port in the orchestartion to be direct bound to the messagebox.





Re: BizTalk R2 General Correlation Zombie error


Re: BizTalk R2 General Correlation Zombie error

mitre

yes, simply change the invoice recieve to be direct to message box.




Re: BizTalk R2 General Correlation Zombie error

Leonid Ganeline - MVP

Wow,
I've repeate your case. It works exactly as you said.
[After I changed the all file port settings from c:\ to something different, of course]
After changing the second receive port shape to Direct, added tracing to the orchestration.
Droped PO message: the orch started.
Droped Invoice message: the orch successfuly finished. But I've got the suspended (not-resumable) instance of the orch with Error information "The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended."
One more time:
The message goes to the subscription (to the orch). Orch works as has to. But... look up.
I've checked all subscriptions in process. They all are as predicted.
I've manualy recreated ports and bind them to orch. Error keeps going.
Looks like an error in BizTalk
Hey, MSFT guys, could you, please, answer





Re: BizTalk R2 General Correlation Zombie error

mitre

Thanks for looking into this Leonid. I really hope it is resolveable as Direct binding to the messagebox is key to my architecture.





Re: BizTalk R2 General Correlation Zombie error

Leonid Ganeline - MVP

Direct "binding" works great. I have a lot of projects with it. Frankly, I prefer using this kind of subscription. It works.
This is something wrong with THIS case. Maybe we don't understand something
Regards,
Leonid Ganeline





Re: BizTalk R2 General Correlation Zombie error

mitre

Exactly, it's pure pub/sub.. very bus like and flexible. I can't see that I am doing anything wrong here, even in the biztalk help files for direct binding and correlation:

ms-help://MS.BTS.2006/BTS06CoreDocs/html/1839184b-408e-4ac6-94a4-a0eb708183f6.htm

"and for a non-activating Receive shape the subscription is the message type and the correlation set. Every Receive shape always includes the message type as part of its subscription."

Nothing is mentioned about a ReceivePortID for NON-Activating receive shapes. There is a blurb about receive shapes below having receiveportID in the subscription, IF there is no filter croteria, again not in this case.

My solution has many, many receieve ports that a correlating document could enter the system by, I really hope this is not a limitation and someone from MS can provide a workaround.





Re: BizTalk R2 General Correlation Zombie error

Jody Petroni

Hi,

I had a similar problem where I had a sequential convoy (direct binding), correlating on message type. The issue for me was that I was batching the messages together and after a timeout was sending the message to a Direct Port. The problem was that in my case, the message I was sending out was the same type as I was correlating on - So after it was sent to the Dynamic Port the orchestration was in the process of finishing while the message is being delivered to the message box - hence the Zombie.

The solution was to create a copy of the schema (with new namespace of course) and create a map and send the new message (new type from map) to the dynamic port. This resolved the issue for me.

So in short if you are sending the same message type out of an orchestration as the correlation (on message type) you will get a Zombie every time!!!

Hope this helps.






Re: BizTalk R2 General Correlation Zombie error

Chris Restall

Thanks Jody, Thats good to know.

It still seems kind of weird to me. I was actually seeing this on the receive back in of the correlating message not on the send from the orchestration. I'm not using dymanic ports at all, just direct ports to the messagebox.

When the message is sent out of the orchestration, it dehydrates. Upon receipt of the correlated message (of the same type) it correlates properly and finishes then I get that error. Not sure what you mean by:

"So after it was sent to the Dynamic Port the orchestration was in the process of finishing while the message is being delivered to the message box "

I did try your fix and it works but it sucks that I have to take the hit and redundancy of a duplicate schema.