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 <[email protected]> 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 <[email protected]> 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:[email protected]] On Behalf Of LJ LongWing > >> > Sent: Thursday, April 07, 2011 10:01 AM > >> > To: [email protected] > >> > 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:[email protected]] On Behalf Of Adam Neidzwiecki > >> > Sent: Thursday, April 07, 2011 9:11 AM > >> > To: [email protected] > >> > 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"
