Compensation and BizTalk state rollback (please help!)
Web Server forum
Back To The Forum Home!Search!Private Messaging System

Web Server Talk Web Server Talk > Web Servers reviews > BizTalk Server > BizTalk Server Orchestration > Compensation and BizTalk state rollback (please help!)




  Last Thread   Next Thread Next
  Show Printable Version Email this Page Subscribe to this Thread      Post New Thread    Post A Reply      

    Compensation and BizTalk state rollback (please help!)  
João Martins


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
01-31-06 12:58 PM

Hello,

I have a question regarding "state rollback" when an exception occurs and
compensation is started. I have researched a lot both in the web and in the
documentation, but there is almost no information regarding this kind of
scenarios (either few people really use compensation, of few people blog/pos
t
about it  ).

In my scenario, I have a sequence of steps that are executed inside several
atomic transactions. Each of these has individual compensation code to
"manually" roll-back the changes.

The first step in the orchestration is logging a "Action Initiaded" message
in an Sql database, and doing an application-specific lock for the process
(something like marking a set of records as being "checked-out" for the
duration of the BizTalk process). The compensation for this shape also adds 
a
new log indicating that an error has occurred, and undoes the "checkout".
These two operations happen as a block and can't be separated.
No exception handlers were used.

Problem: I need to log the specific exception that occurred. However, as you
know, the BizTalk state (variables, messages, ...) is "rolled back" during
compensation, which means that I cannot, for example, set a global variable
with the exception message to be used in the compensation shape I described,
because the information is simply not there anymore.

The "obvious" way, and my first attempt, was to persist the error message
outside BizTalk (ex: sql, esso, ...), and then read it back on in my
compensation, but this is innefficient, adds further dependencies, and raise
s
the problem of having to clear up that repository, so I kept looking for
solutions.

The second attempt consisted of creating an exception handler enclosing all
the shapes that have compensations. In that exception handler, I log the
error and undo the checkout, which effectively consists of moving the
compensation code of the first shape to the exception handler.
After this, I simply use the compensate shape inside the "handled" block, to
call the default compensation on the inner shapes in the appropriate order.

The problem with this solution, although it works, is that I am doing the
undo-checkout before all the other compensation steps, and this causes two
kinds of problems: funcionally, to the end user of this process, the
information is made available (=undo checkout) before it should; technically
,
the however, the other compensation shapes all assume that my information is
still "locked", which causes inconsistencies.

Can you tell me of any other approaches I could/should follow?

Is there a way to store the exception that occured somewhere (I would say
"compensation context", if that existed), so that it can be used in my
compensation shapes?

I am in a serious problem here, so if any help would be greatly appreciated.


Thanks,
João Martins





[ Post a follow-up to this message ]



    RE: Compensation and BizTalk state rollback (please help!)  
João Martins


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
01-31-06 11:59 PM

I just noticed I messed up in the third paragraph of my question. Here's a
rephrase:

The first step in the orchestration is logging a "Action Initiaded" message
in an Sql database, and doing an application-specific lock for the process
(something like marking a set of records as being "checked-out" for the
duration of the BizTalk process). These two operations happen as a block and
can't be separated.
The compensation for this shape adds a new log indicating that an error has
occurred, and undoes the "checkout".
No exception handlers were used in the entire orchestration


Any help greatly appreciated.
-j

"João Martins" wrote:

> Hello,
>
> I have a question regarding "state rollback" when an exception occurs and
> compensation is started. I have researched a lot both in the web and in th
e
> documentation, but there is almost no information regarding this kind of
> scenarios (either few people really use compensation, of few people blog/p
ost
> about it  ).
>
> In my scenario, I have a sequence of steps that are executed inside severa
l
> atomic transactions. Each of these has individual compensation code to
> "manually" roll-back the changes.
>
> The first step in the orchestration is logging a "Action Initiaded" messag
e
> in an Sql database, and doing an application-specific lock for the process
> (something like marking a set of records as being "checked-out" for the
> duration of the BizTalk process). The compensation for this shape also add
s a
> new log indicating that an error has occurred, and undoes the "checkout".
> These two operations happen as a block and can't be separated.
> No exception handlers were used.
>
> Problem: I need to log the specific exception that occurred. However, as y
ou
> know, the BizTalk state (variables, messages, ...) is "rolled back" during
> compensation, which means that I cannot, for example, set a global variabl
e
> with the exception message to be used in the compensation shape I describe
d,
> because the information is simply not there anymore.
>
> The "obvious" way, and my first attempt, was to persist the error message
> outside BizTalk (ex: sql, esso, ...), and then read it back on in my
> compensation, but this is innefficient, adds further dependencies, and rai
ses
> the problem of having to clear up that repository, so I kept looking for
> solutions.
>
> The second attempt consisted of creating an exception handler enclosing al
l
> the shapes that have compensations. In that exception handler, I log the
> error and undo the checkout, which effectively consists of moving the
> compensation code of the first shape to the exception handler.
> After this, I simply use the compensate shape inside the "handled" block, 
to
> call the default compensation on the inner shapes in the appropriate order
.
>
> The problem with this solution, although it works, is that I am doing the
> undo-checkout before all the other compensation steps, and this causes two
> kinds of problems: funcionally, to the end user of this process, the
> information is made available (=undo checkout) before it should; technical
ly,
> the however, the other compensation shapes all assume that my information 
is
> still "locked", which causes inconsistencies.
>
> Can you tell me of any other approaches I could/should follow?
>
> Is there a way to store the exception that occured somewhere (I would say
> "compensation context", if that existed), so that it can be used in my
> compensation shapes?
>
> I am in a serious problem here, so if any help would be greatly appreciate
d.
>
>
> Thanks,
> João Martins





[ Post a follow-up to this message ]



    Sponsored Links  




 





   All times are GMT. The time now is 09:47 PM.      Post New Thread    Post A Reply      
  Last Thread   Next Thread Next


Most Popular forums 

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 
Medical and Health forum | Computer Games Reviews | Graphics design forum

Back To The Top
Home | Usercp | Faq | Register