Hi Misi, I am new subscriber for this arslist.Yesterday i posted an issue, which i was having in consuming the Seibel WebService. But i dont think so it got posted.Can u pls help me in how to post the issue to the arslist.
Thanks&Regards, B.Vikram. On Fri, Apr 8, 2011 at 7:14 PM, Misi Mladoniczky <m...@rrr.se> wrote: > 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
