Hi,
If something has been pushed and committed, it is not possible to reverse.
If you have a series of active links that trigger on something, for
instance submit, an error will stop any actions and ACTLs that has not yet
been executed. The actual submit will also be stopped in this case.
It is good practice to build filters to control things to 100%, as ACTLs
may be circumvented by your users. Filters can never be bypassed.
This is kind of a rule of thumb for me:
- Put your business rules in FLTRs
- Create ACLTs to give the user early feedback, but build FLTRs as well to
prevent anything to slip through
- Use simple built-in tools such as permissions, required fields,
patterns, etc if possible, as opposed to building 100 ACTLs to give the
user a slightly better experience...
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.
> Thank you Misi for this info.
>
> I wonder now - is there a way that a FL errror stopped AL push action (on
> the same form).
>
>
> Regards,
> Adam
>
> On Fri, Apr 8, 2011 at 2:11 PM, Misi Mladoniczky <m...@rrr.se> wrote:
>
>> 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"
>>
>
> _______________________________________________________________________________
> 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"
