Hi Doug,
Thank you for clarifying. The tread I started about this a couple of weeks
ago did not get down to any definite conclusion.
I am running AR Server 7.6.04, Windows 2008 R2, SQL Server 2008 R2, and
each service call is indeed committed in itself. Nothing is rolled back if
a later call fails. Immediately after the service-call, you can do
table-loops, set-fields and push-fields against the newly created/updated
data.
I guess I have to rewrite a kind of complex part of my application when
the BUG is finally fixed... I am doing three levels of service-calls to
create and update a number of records in two forms. Each record is updated
multiple times.
I am fine with the rollback being fixed, but I really need a way to do
multiple updates (adding values to a summary field) to the same record,
within one API-call.
I guess that I could just add an action after each service call to get the
a similar result:
Set-Fields: dummy = $PROCESS$ Application-Release-Pending
I do not like meddling with the filter phasing in this way though...
One of the few situations where I build real functionality into ACTLs is
in situations like this.
It would be great to have a check-box to be able to commit
filter-push-fields and filter-service-calls immediately. And also to have
a check-box for running a Push-Fields in phase 1.
The `! suffix and the dummy = $PROCESS$ Application-Release-Pending, is
really quite an ugly pair of triggers...
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Misi,
>
> This topic came up in a thread several weeks ago.
>
> If you make a service call from an active link, the entire operation within
> the service call is done correctly with a single transaction.
>
> If you make a service call from a filter, the entire service operation
is
> done
> within a transaction. HOWEVER, that service call is committed and is
not
> wrapped into the larger transaction that the filter is a part of from
the
> API
> call that triggered the filters.
>
> This last HOWEVER is not the desired behaviour and a bug has been
created
> on the
> topic. The problem is not the service itself but the fact that the service
> called from a filter is committed rather than being part of the
containing
> transaction.
>
>
> Now, there is likely one final oddity about this issue. Customers on
Sybase and
> SQL Server probably see everything working just fine and the service
call
> is
> part of the parent transaction and rollbacks occur correctly and such
but
> customers on Oracle and DB2 find the behavior I note above. This is
because
> Sybase and SQL Server have a concept of a nested transaction or
> transaction
> inside transaction. That is what happens in this case so those
databases
> have
> the commit but it is a child transaction of a parent and if the parent
rolls
> back, so does the child. But, Oracle and DB2 do not have the concept of
a
> nested transaction.
>
> I am calling this out not to say there is no issue -- there is an issue and
> it should not be committing after the service call. I am calling it out in
> case some customers look at this situation and wonder what you are
talking
> about and everything seems to be working.
>
> I cannot gaurantee that there is the difference in behavior (the system may
> have coded to close the parent transaction too), but just to observe
that
> there
> is this fundamental difference in functionality about nested
transactions
> so
> you may see different behavior on different databases.
>
>
> This bug is targetted to be fixed in a future release (no I don't know
which
> one or whether it is targetted for a patch or in fact anything at all about
> the timeline for fix).
>
> Doug "the minimaly helpful" Mueller
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
> Sent: Friday, April 08, 2011 1:10 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Push by an AL when error on FL
>
> Hi Doug,
>
> A follow up question on filters and transactions in connection with
filter-service-calls.
>
> My experience with this is that a filter-service-call is also performed
immediately, and that anything written to the database within the
service-call is committed immediately (before the service returns).
>
> In other words the filter-service-call is not rolled back if an error
occurs later in the filter processing.
>
> I want to make sure that this is by design, and that everyone is aware
of
> the situation.
>
> It is both dangerous and powerful (if you know what you are doing)...
>
> Best Regards - Misi, RRR AB, http://www.rrr.se
>
> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing. *
RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
logs.
> Find these products, and many free tools and utilities, at
http://rrr.se.
>
>> Be careful that you consider whether you are talking about Active Links or
>> Filters.
>> This question is about Active Links.
>> IF it was about filters, then the question about transactions and whether
>> the push is committed if the
>> main operation failed would all be true.
>> HOWEVER, this is about active links. Every action performed by an active
>> link is performed and committed
>> immediately. There is no delay. There is no transaction. Each action
for each active link is a discrete
>> operation and is performed to completion at the completion of the action.
>> My real question here is what is the bigger task you are doing. It seems
>> to me that you have BUSINESS
>> LOGIC encoded in active links. This is the error in your situation.
BUSINESS LOGIC for your application
>> should always be done in filters. Filters are run under a single
transaction and it is an all or none commit
>> (subject to your overrides of course). Active links are for screen
fiddling or for defaulting or for displaying
>> related data or the like. They should not be doing the business logic of
>> your application. Hence, there is
>> no reason for transactions or rollbacks or anything from active links.
It seems to me like you need to move your logic from active links to
filters. Then, the push field will not
>> commit unless the operation itself commits.
>> Something to think about,
>> Doug Mueller
>> ________________________________
>> From: Action Request System discussion list(ARSList)
>> [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
>> Sent: Thursday, April 07, 2011 10:01 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Push by an AL when error on FL
>> **
>> Yes, the entire stack of updates is part of a single transaction, if there
>> is an error at any point, everything rolls back.
>> From: Action Request System discussion list(ARSList)
>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Adam Neidzwiecki
>> Sent: Thursday, April 07, 2011 9:11 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Push by an AL when error on FL
>> **
>> Hello,
>> Anybody can help?
>> I am on a form A and have an AL to push to a form B.
>> This is happening when modifying A - no problem (no errors)
>> Now, if there is an error returned by a FL - attached to form A - further
>> down the execution order. Will this error stop a push action done by an
>> AL to a form B?
>> Thanks,
>> Adam
>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend
WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
> _______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
> _______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
