Yes, I have seen this written about dozens of times.  But, I think I
have done everything right to prevent "zombie" messages and this
condition...

I have a very large flat file that I want to subdivide into numerous
smaller messages due to capacity issues.  (I would use an envelope but
then I would have hundreds of thousands of messages.) I also need my
output segregated into multiple files to accomodate business rules.

As my custom disassembler subdivides the message, it promotes 4
properties to the message context:
First_Indicator
Last_Indicator
Batch_ID
Batch_Type

The combination of Batch_ID and Batch_Type is always unique.
First_indicator is set to YES on the first message; otherwise it is set
to NO.
Last_indicator is set to NO on all messages but the last.

My orchestration consists mainly of a sequential convoy.  It correlates
on Batch_ID and Batch_Type.  It loops until Last_Indicator is set to
YES.

Delivery Notification is set to "transmitted" on the send port.
Ordered Delivery is set to true on both the send and receive ports.

I am using a file adapter, and appending to the output file.

I have run the same file through my pipeline and orchestration
repeatedly on my development system.  After correcting some initial
errors, I have had consistent results - the same output has been
produced 10 times consecutively.  (The output consists of 9 flat files
ranging in size from 39K to 5MB.)

But, the very first time I ran the process after deploying to my
testing environment, four of the orchestrations "Completed With
Discarded Messages".  (Interestingly they are the orchestrations that
would normally produce the smallest files.)  And sure enough, the file
sizes for these 4 files are all smaller than expected.

Unfortunately, I forgot to turn on message property tracking, but I can
still go into HAT for each of these orchestrations and examine the
message context.  I don't see any message with a Last_Indicator = YES
associated with any of these orchestrations.

My initial thoughts are that something didn't get carried over to the
testing environment.  But, what would that be?  Another thought is that
it has always been broken and I've just been lucky in my testing
environment.  And then I have to consider if I have discovered a bug.
I really don't understand how my loop and orchestration can terminate
when the "last" condition hasn't been met.  Obviously, I'm missing
something, but what?

Any suggestions will be appreciated.

Nevin

[ Post a follow-up to this message ]

I may have a resolution.  After turning on message property tracking, I
reran my test.  I got the same results on the test server as I did the
first time.  (At least things are consistent by server.)  HAT showed me
that 13 of my 300+ messages had "blanks" for the four custom message
context properties I had set.  And, these messages appear to contain
the data that is missing from my output.

Now, if the message context properties relevant to the subscription
were missing, that would explain my missing output.  What I don't
understand, however, is how the orchestration would "complete with
discarded messages", because the messages should never get to the
orchestration.

And the other big question is "why is the context missing"?  Is it an
error in my disassembler, or is it a BizTalk bug?  Well, I discovered
that my test server is missing BizTalk Service Pack 1, which is applied
to my development machine.  And, I found at least one knowledge base
article (kb884876) that may describe my problem.  (The resolution is to
install Service Pack 1.)  So, for now, I am having the server guys
apply Service Pack 1 to the test server, and I will re-test once that
has been applied.

[ Post a follow-up to this message ]

Hello.

Just to let you know I ran into some additional Complete with Discarded
Messages after I installed SP1 (never had many problems before installing SP
1
actually).  I think they relate mostly to Uniform Sequential Convoys.

I know of two additional KB’s.  One is KB892405.

Best of luck.

Stephen W. Thomas
http://www.biztalkgurus.com
http://geekswithblogs.net/sthomas/


"Nevin" wrote:

> I may have a resolution.  After turning on message property tracking, I
> reran my test.  I got the same results on the test server as I did the
> first time.  (At least things are consistent by server.)  HAT showed me
> that 13 of my 300+ messages had "blanks" for the four custom message
> context properties I had set.  And, these messages appear to contain
> the data that is missing from my output.
>
> Now, if the message context properties relevant to the subscription
> were missing, that would explain my missing output.  What I don't
> understand, however, is how the orchestration would "complete with
> discarded messages", because the messages should never get to the
> orchestration.
>
> And the other big question is "why is the context missing"?  Is it an
> error in my disassembler, or is it a BizTalk bug?  Well, I discovered
> that my test server is missing BizTalk Service Pack 1, which is applied
> to my development machine.  And, I found at least one knowledge base
> article (kb884876) that may describe my problem.  (The resolution is to
> install Service Pack 1.)  So, for now, I am having the server guys
> apply Service Pack 1 to the test server, and I will re-test once that
> has been applied.
>
>

[ Post a follow-up to this message ]

Application of Service Pack 1 resolved this issue.

[ Post a follow-up to this message ]