| Author |
BizTalk Mapper - maintaining state information
|
|
| Nikolai 2004-04-26, 2:35 am |
| In one of my orchestrations I am using the BizTalk mapper with external scripting functoids to lookup/validate data (with complex stored procs & error handling) i.e. convert incoming supplier IDs to internal IDs and log errors if it doesn't exist.
One of my requirements is to gather all validation errors returned in my functions and return these to process originator.
So far I have only been able to log errors to the event log and return default data to the mapper. But I really need to be able to terminate the orchestration after mapping and send a notification stating the source document is invalid for the following r
easons...
Should I look at using a custom pipeline component instead, or looping in the orchestration, or something else? Any tips =)
| |
| Christof 2004-04-26, 7:35 am |
| What about throwing exceptions? Are they visible in your orchestration?
Can't they be catched?
Kind regards,
Christof
"Nikolai" <anonymous@discussions.microsoft.com> wrote in message
news:FB554FD0-93AC-4060-A874-DC43AB76313E@microsoft.com...
> In one of my orchestrations I am using the BizTalk mapper with external
scripting functoids to lookup/validate data (with complex stored procs &
error handling) i.e. convert incoming supplier IDs to internal IDs and log
errors if it doesn't exist.
>
> One of my requirements is to gather all validation errors returned in my
functions and return these to process originator.
>
> So far I have only been able to log errors to the event log and return
default data to the mapper. But I really need to be able to terminate the
orchestration after mapping and send a notification stating the source
document is invalid for the following reasons...
>
> Should I look at using a custom pipeline component instead, or looping in
the orchestration, or something else? Any tips =)
| |
| Nikolai 2004-04-26, 6:43 pm |
| It is quite strange any errors raised from the mapper are not caught by the exception handling blocks in the orchestration. The orchestration completes and dehydrates and you have to search through past messages to view the tracked errors i.e. DB could no
t connect etc. The best I can achieve is using the error handling application blocks to handle errors and log to pre defined event logs and email notifications.
The approach I am currently looking at is looping through xmlNodes within the orchestration and performing my lookup operations using expressions, and returning validation errors via output parameters. If an error occurs the catch block can deal with it.
| |
| Christof 2004-04-27, 3:35 pm |
| thx for the feedback
"Nikolai" <anonymous@discussions.microsoft.com> wrote in message
news:0D7877CA-5FFC-409D-AE8C-AB9EBCFBF44A@microsoft.com...
> It is quite strange any errors raised from the mapper are not caught by
the exception handling blocks in the orchestration. The orchestration
completes and dehydrates and you have to search through past messages to
view the tracked errors i.e. DB could not connect etc. The best I can
achieve is using the error handling application blocks to handle errors and
log to pre defined event logs and email notifications.
>
> The approach I am currently looking at is looping through xmlNodes within
the orchestration and performing my lookup operations using expressions, and
returning validation errors via output parameters. If an error occurs the
catch block can deal with it.
|
|
|
|