Hello

I have an orchestration that loops on a port, and it may happen that an
error occurs on a loop. When this happens, I would like the orchestration to
log the error and continue on the remaining loops, if any.

The problem I have now, is that when this occurs, the error is logged, but
by BTS itself, instead of my own error handling mechanism. Furthermore, the
orchestration stops there, without continuing with the remaining loops.


The current orchestration uses a SQL adapter port. The first 20 or so
records are correctly put in the database, but one of them have an error in
date formatting. When the error comes back (the error is provoked because I
accidentally trucate the string representing the date, but this is not the
point), I want to be able to log the error and keep on with processing the
other records (I cannot use an updategram, as some of you may suggest,
because I don't know upfront if a given record is new or already exists in
the database).

Since the data comes from an external source, there is a possibility that
there are errors in it. But I want to stop processing on error such as
"cannot connect to server", for instance.

What I have tried so far, which does not work:

- Make the orchestration's transaction "Long running".
- Put the Send shape into a scope, with the following properties set:
- Synchronized: true
- Transaction Type: Long running
- The port with SQL adapter:
- Delivery notification: Transmitted
- Communication direction: Send-receive
- Binding: Specify Later
- Put 3 exception handlers in the scope:
- Microsoft.XLANGs.BaseTypes.DeliveryFailureException
- System.Web.Services.SoapException
- System.Exception

The combination of the settings listed above does not enable me to cacth the
exceptions.

Thank you
Michel

[ Post a follow-up to this message ]

Never mind, got fixed with SP1
"Michel Prévost" <michel.prevost@cactuscommerce.this.is.to.be.removed.com>
wrote in message news:uSPMFyQGFHA.2156@TK2MSFTNGP09.phx.gbl...
> Hello
>
> I have an orchestration that loops on a port, and it may happen that an
> error occurs on a loop. When this happens, I would like the orchestration
> to
> log the error and continue on the remaining loops, if any.
>
> The problem I have now, is that when this occurs, the error is logged, but
> by BTS itself, instead of my own error handling mechanism. Furthermore,
> the
> orchestration stops there, without continuing with the remaining loops.
>
>
> The current orchestration uses a SQL adapter port. The first 20 or so
> records are correctly put in the database, but one of them have an error
> in
> date formatting. When the error comes back (the error is provoked because
> I
> accidentally trucate the string representing the date, but this is not the
> point), I want to be able to log the error and keep on with processing the
> other records (I cannot use an updategram, as some of you may suggest,
> because I don't know upfront if a given record is new or already exists in
> the database).
>
> Since the data comes from an external source, there is a possibility that
> there are errors in it. But I want to stop processing on error such as
> "cannot connect to server", for instance.
>
> What I have tried so far, which does not work:
>
> - Make the orchestration's transaction "Long running".
> - Put the Send shape into a scope, with the following properties set:
>    - Synchronized: true
>    - Transaction Type: Long running
> - The port with SQL adapter:
>    - Delivery notification: Transmitted
>    - Communication direction: Send-receive
>    - Binding: Specify Later
> - Put 3 exception handlers in the scope:
>    - Microsoft.XLANGs.BaseTypes.DeliveryFailureException
>    - System.Web.Services.SoapException
>    - System.Exception
>
> The combination of the settings listed above does not enable me to cacth
> the
> exceptions.
>
> Thank you
> Michel
>
>

[ Post a follow-up to this message ]