Overview:

I have EDI documents (4010_850 purchase orders) that go out through the
Biztalk 2004 built-in EDI adapter.  It processes thousands of messages a day
and works fine... most of the time... every once in a while I get some
garbage data from the upstream system (not biztalk's fault). Sometimes its i
n
the form of a bad purchase order line item quantity (like 0 or just blank),
or sometimes its a bad shipping address (like blank).  These types of invali
d
data cause the EDI engine to fail out the send process.  I can find the
failed messages in the HAT (Reporting/EDI Reports) and when I look at it I
can see the nearly-EDI formatted message (its still in XML, and is structure
d
based on the _850Schema instead of its normal flat-file look).  Then I have
to walk-back-the-cat and find the original message, doctor it up, and send i
t
through.

What I thought I could do but it doesn't work:

I wrapped the send shape up in a Scope block and put an exception handler on
the scope... then set the send port's retry to 0 (it doesn't matter what the
retry count is, if the data's bad, its going to fail every time).  In the
exception part of the scope I put another send, but this time it just sends
the original message (not the EDI'ed one) to a dead-record folder, where I
can easily read it, fix it, and put it back into the receive port's pickup
folder.

The problem:

The EDI engine still throws a fit when it hits bad data  ('Check Condition
has not been met', or my favorite 'The document does not contain a required
element') but my exception block in the scope (I've tried biztalk's 'general
exception' and mscorlib's system.exception) does not catch the error, thus
I'm still having to do some spelunking to find the original record, fix it,
and repost it.

Is there a way to accomplish what I'm after?

I've used the tool that Scott Thomas put together (something like
SampleWMI.zip) that watches for suspended messages and dumps them out...
thats not what I want (basically because the suspended message is not in a
format I can use).

I really feel like I should be able to recover from an EDI send step from
within the orchestration.

Any thoughts or feedback appreciated.

[ Post a follow-up to this message ]

Hello.

Do you have delivery notification set to Transmitted on the Send Port?
Then, you should be able to catch the DeliveryNotificationException.  You
should also be able to catch the exception using System.Exception.

I do not have much experience with EDI, but I expect it work like Xml on the
Send Port using Delivery Notification.

Stephen W. Thomas
http://www.biztalkgurus.com


"Bizwhisperer" wrote:

> Overview:
>
> I have EDI documents (4010_850 purchase orders) that go out through the
> Biztalk 2004 built-in EDI adapter.  It processes thousands of messages a d
ay
> and works fine... most of the time... every once in a while I get some
> garbage data from the upstream system (not biztalk's fault). Sometimes its
 in
> the form of a bad purchase order line item quantity (like 0 or just blank)
,
> or sometimes its a bad shipping address (like blank).  These types of inva
lid
> data cause the EDI engine to fail out the send process.  I can find the
> failed messages in the HAT (Reporting/EDI Reports) and when I look at it I
> can see the nearly-EDI formatted message (its still in XML, and is structu
red
> based on the _850Schema instead of its normal flat-file look).  Then I hav
e
> to walk-back-the-cat and find the original message, doctor it up, and send
 it
> through.
>
> What I thought I could do but it doesn't work:
>
> I wrapped the send shape up in a Scope block and put an exception handler 
on
> the scope... then set the send port's retry to 0 (it doesn't matter what t
he
> retry count is, if the data's bad, its going to fail every time).  In the
> exception part of the scope I put another send, but this time it just send
s
> the original message (not the EDI'ed one) to a dead-record folder, where I
> can easily read it, fix it, and put it back into the receive port's pickup
> folder.
>
> The problem:
>
> The EDI engine still throws a fit when it hits bad data  ('Check Condition
> has not been met', or my favorite 'The document does not contain a require
d
> element') but my exception block in the scope (I've tried biztalk's 'gener
al
> exception' and mscorlib's system.exception) does not catch the error, thus
> I'm still having to do some spelunking to find the original record, fix it
,
> and repost it.
>
> Is there a way to accomplish what I'm after?
>
> I've used the tool that Scott Thomas put together (something like
> SampleWMI.zip) that watches for suspended messages and dumps them out...
> thats not what I want (basically because the suspended message is not in a
> format I can use).
>
> I really feel like I should be able to recover from an EDI send step from
> within the orchestration.
>
> Any thoughts or feedback appreciated.

[ Post a follow-up to this message ]

That did the trick! YOU ARE THE MAN.

"Stephen W. Thomas" wrote:
[vbcol=seagreen]
> Hello.
>
> Do you have delivery notification set to Transmitted on the Send Port?
> Then, you should be able to catch the DeliveryNotificationException.  You
> should also be able to catch the exception using System.Exception.
>
> I do not have much experience with EDI, but I expect it work like Xml on t
he
> Send Port using Delivery Notification.
>
> Stephen W. Thomas
> http://www.biztalkgurus.com
>
>
> "Bizwhisperer" wrote:
> 

[ Post a follow-up to this message ]