Hi,
It behaves as it always has.
For example:
ACTL with three push-fields
Action 1: Push (commited)
Action 2: Push (error)
Action 3: Push (not run due to previous error)
If you get an error in Action 2, Action 3 will not run. But the push in
Action 1 has already been applied to the database.
If you have the same thing in a FLTR, or several filters:
Action 1: Push (rolled back)
Action 2: Push (error)
Action 3: Push (not run due to previous error)
In this case nothing will be committed to the database.
If you are doing filter-service-calls, it works pretty much as an ACTL:
Action 1: Service-Call
Service-FLTR: Action: Push (commited)
Action 2: Service-Call
Service-FLTR: Action: Push (error)
Action 3: Service-Call
Service-FLTR: Action: Push (not run due to previous error)
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.
> Guys,
>
>
> Was this always like this (all the version of ARS) that FL's error will
> not
> stop AL push on the same form?
>
> Not quite sure why I was thinking that it should stop it. Maybe I saw
> somehow a different behaviour.
>
>
> Thanks,
> Adam
>
>
> On Fri, Apr 8, 2011 at 10:10 AM, Misi Mladoniczky <m...@rrr.se> wrote:
>
>> 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"
