|
Home > Archive > BizTalk Server Orchestration > August 2005 > Try/Catch Scope for Send process
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Try/Catch Scope for Send process
|
|
| Bizwhisperer 2005-08-03, 5:51 pm |
| 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 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 invalid
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 structured
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 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 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.
| |
| Stephen W. Thomas 2005-08-04, 2:47 am |
| 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 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 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 invalid
> 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 structured
> 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 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 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.
| |
| Bizwhisperer 2005-08-04, 5:56 pm |
| 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 the
> Send Port using Delivery Notification.
>
> Stephen W. Thomas
> http://www.biztalkgurus.com
>
>
> "Bizwhisperer" wrote:
>
|
|
|
|
|