BizTalk Server Applications Integration - BizTalk Scriptor AIC

This is Interesting: Free IT Magazines  
Home > Archive > BizTalk Server Applications Integration > March 2004 > BizTalk Scriptor AIC





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 BizTalk Scriptor AIC
Tim Goodsell

2004-02-23, 3:35 pm

I have a message port which executes a Scriptor AIC (VB
Script)

If an error occurs when executing the AIC how does one
pass the error message back so it appears in the App Log
and the document being processed goes into the suspend
queue

I have tried MSCSEexcute = 0 and using Err.Raise but it
doesn't work. I am using BizTalk 2002 and SP1.

Thanks

Tim
Everett Yang

2004-02-24, 1:36 am

You will have to log the error in your code. BizTalk will only monitor the
AIC for completion or failure. It does not process the reason for failure.


Sincerely,


Everett Yang
DSI - Microsoft BizTalk Server

This posting is provided “AS IS” with no warranties, and confers no rights.
Subscribe at
http://support.microsoft.com/defaul...msdn/nospam.asp
&SD=msdn

Tim Goodsell

2004-02-24, 8:37 am

When you say 'Log the Error in the code ', do you mean
use Err.Raise

All I want to do is to when an error occurs is for

1) BizTalk to put the document being processed in the
suspend queue
2) a meaningful error message to be put in the Windows App
Log

I have tried using the following code within a simple
external VB script file

'-----------------------------------------
On Error Resume Next

Err.Raise vbObjectError + 10000, "Something is
wrong", "custom error"

MSCSExecute = 0
'-------------------------------------------

but nothing happens, document does not go in the suspend
queue and no error in the app log

BizTalk 2002 without SP 1 seem to work ok, any errors
would be properly dealt with, since applying SP1 I have
had this problem . If I remove the 'On error resume next'
then I get a couple of cryptic error messages in the app
log and the doc remains stuck in work queue.

Regards

Tim


>-----Original Message-----
>You will have to log the error in your code. BizTalk

will only monitor the
>AIC for completion or failure. It does not process the

reason for failure.
>
>
>Sincerely,
>
>
>Everett Yang
>DSI - Microsoft BizTalk Server
>
>This posting is provided "AS IS" with no warranties, and

confers no rights.
>Subscribe at
>http://support.microsoft.com/default.aspx?

scid=/servicedesks/msdn/nospam.asp
>&SD=msdn
>
>.
>

Everett Yang

2004-03-01, 12:36 pm

BizTalk is not going to handle the descriptive error coming back from an
AIC. With an AIC call, BizTalk will mostly just monitor for either
completion or failure. If it fails, BizTalk reports transport failure. If
you want detailed error, you need to write to the event log yourself within
your code.

Sincerely,


Everett Yang
DSI - Microsoft BizTalk Server

This posting is provided “AS IS” with no warranties, and confers no rights.
Subscribe at
http://support.microsoft.com/defaul...msdn/nospam.asp
&SD=msdn

Tim Goodsell

2004-03-01, 4:38 pm

Thanks for that Everett

The only thing I don't understand is that pre SP1 if an
error occured in the Scriptor AIC then (if 'On Error
Resume Next' was not coded in)

a) The error appeared in the Windows App Log (under
BizTalk Error)

b) The document being processed ended up in the suspend
queue

The above mentioned was great. Now after applying SP1 the
functionality has changed. If you don't put in 'On Error
resume Next' then you get

a) A couple or fairly horrendous uninformative error
messages in the App Log

b) The document being processed remains in the Work Queue

If you put in 'On error resume next' then nothing happens
when an error occurs. I can write the error to the app log
within the code but if you return MSCSExecute=0 shouldn't
BizTalk put the document is the suspend queue

Regards

Tim


>-----Original Message-----
>BizTalk is not going to handle the descriptive error

coming back from an
>AIC. With an AIC call, BizTalk will mostly just monitor

for either
>completion or failure. If it fails, BizTalk reports

transport failure. If
>you want detailed error, you need to write to the event

log yourself within
>your code.
>
>Sincerely,
>
>
>Everett Yang
>DSI - Microsoft BizTalk Server
>
>This posting is provided "AS IS" with no warranties, and

confers no rights.
>Subscribe at
>http://support.microsoft.com/default.aspx?

scid=/servicedesks/msdn/nospam.asp
>&SD=msdn
>
>.
>

Jan Eliasen

2004-03-18, 2:00 pm

On Mon, 1 Mar 2004 13:23:14 -0800, "Tim Goodsell"
<anonymous@discussions.microsoft.com> wrote:

Hi

If the AIC fails, then BizTalk will write an error in the eventlog,
but t isn't very informative. The best place to give a good
description of what went wrong is the code that failed. Therefore, the
responsibility for writing the error to the eventlog has been placed
on the AIC it self.. it makes sense :-)
[color=darkred]
>Thanks for that Everett
>
>The only thing I don't understand is that pre SP1 if an
>error occured in the Scriptor AIC then (if 'On Error
>Resume Next' was not coded in)
>
>a) The error appeared in the Windows App Log (under
>BizTalk Error)
>
>b) The document being processed ended up in the suspend
>queue
>
>The above mentioned was great. Now after applying SP1 the
>functionality has changed. If you don't put in 'On Error
>resume Next' then you get
>
>a) A couple or fairly horrendous uninformative error
>messages in the App Log
>
>b) The document being processed remains in the Work Queue
>
>If you put in 'On error resume next' then nothing happens
>when an error occurs. I can write the error to the app log
>within the code but if you return MSCSExecute=0 shouldn't
>BizTalk put the document is the suspend queue
>
>Regards
>
>Tim
>
>
>coming back from an
>for either
>transport failure. If
>log yourself within
>confers no rights.
>scid=/servicedesks/msdn/nospam.asp

--
Jan Eliasen, representing himself and not the company he works for.
MCP in Microsoft BizTalk Server
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com