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"