Hi, The Filter Service Call behavior has been very consistent since the introduction of Filter Service Calls.
I can see the logic in actually NOT treating it as part of the same transaction. Since I found out how it worked, I had to redesign our internal RRR invoicing application, and instead make use of the fact that it did not belong to the calling transaction. I will install version 8.1 patch001 now, and report back how it behaves. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): * 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. > Misi, > > Filter service calls should be part of the same transaction as the API call. > > Active Link service calls are a single API call to the server and are treated > as a > single transaction within themselves. > > > Now, we have recently found that an APPLICATION-DELETE-ENTRY call that is done > with > a Set Fields $PROCESS$ operation surround themselves with their own > transaction > which is a nested transaction within the larger API transaction for SQL Server > and > Sybase but which commits and then starts a new transaction for Oracle. This > is > something that is a special case and will be fixed but is only for this > specific > situation. > > > I expect Service calls called by a filter to be in the same transaction with > the > filter and not a separate transaction. If not, this is a bug. > > Doug > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky > Sent: Monday, September 09, 2013 12:24 PM > To: arslist@ARSLIST.ORG > Subject: Re: Remedy Rollback Functionality > > Hi Doug, > > It clarifies things to some degree. > > A year or so ago, maybe more, you stated that a Service Call from a filter > should be treated within the same transaction as the calling filter. > > My findings at the time were that they did not. > > You stated that if that was not the case, it was a bug. > > I have not verified this in both 7.6 and 8.0. Can you please elaborate on your > earlier comment? Will Filter Service Calls be treated as separate transactions > in the future as well? > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): > * 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. > >> To be clear, Active Links are client side operations and each operation is >> independent of each other >> operation. So, in this case, the different actions that take independent >> actions to the database are in >> separate API calls and are separate transactions. >> >> Filters fire within the context of an API call and are a single transaction >> to >> the environment. So, if you do >> 20 pushes, they are all done as one unit of work in a single database >> transaction (unless of course you do a >> "commit transaction" step in your workflow to defeat us....) NOTE that >> even >> if you override the phasing, >> it is still one transaction within a filter - again, unless you specifically >> have a workflow operation that does >> a commit transaction. >> >> So, now you know what is and what is not in a transaction. >> >> This also emphasizes when you should be using different parts of workflow. >> >> Active links are for screen fiddling - changing the screen, pre-loading >> data, >> doing lookups.... >> Filters are for business logic - all the real process logic that you are >> performing.... >> >> It sounds like what you are doing here is business logic and you should be >> doing it in filters. If you are not >> saving the parent record, you can get them all in a single filter >> transaction >> by using a Service call as has been >> already mentioned. >> >> Remember, active links fire when you are in the browser or windows client >> only. They are not fired by any >> automated program interaction or web service interaction or anything but the >> BMC clients. Filters on the >> other hand are fired for ALL interaction from whatever source. This is >> further emphasis that business logic >> should be in filters so that it is processed no matter what the interaction. >> >> >> I hope this helps clarify things, >> >> Doug Mueller >> >> From: Action Request System discussion list(ARSList) >> [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, Lj >> Sent: Monday, September 09, 2013 7:32 AM >> To: arslist@ARSLIST.ORG >> Subject: Re: Remedy Rollback Functionality >> >> ** >> I seem to remember that AL's don't have phases....phasing is only for >> Filters, >> and that everything happens immediately. >> >> Truly...this would be easy enough to test...as you said...if someone simply >> wanted to :) >> >> On Mon, Sep 9, 2013 at 8:27 AM, Rick Cook >> <remedyr...@gmail.com<mailto:remedyr...@gmail.com>> wrote: >> ** >> If your assertion is that the AL Push is in itself a separate DB action, >> then >> yes, that would stand and the Filter actions would be separate transaction >> sets, subject to their own rollback. I think whether it is treated as a >> separate DB action is the question on the table here. >> >> Is it processed as a separate transaction, or as a different phase within >> the >> same transaction set? I seem to recall AL Push actions kind of running in a >> Phase 1.5 type of way. I would suggest that Sahil export a record from >> forms >> F1 and F2 in the DB, turn on Filter/SQL logs and run the transaction to see >> what actually changes in the records at the DB level, comparing the >> post-transaction records to the saved copy. That will show whether there is >> anything to worry about regarding AL actions and rollback. >> Rick >> >> On Mon, Sep 9, 2013 at 7:13 AM, Longwing, Lj >> <llongw...@usgs.gov<mailto:llongw...@usgs.gov>> wrote: >> ** >> Rick, >> I believe that you are incorrect in this statement. Sahil specifically >> states >> that the AL in question is doing a Push action. While you are correct that >> actions on 'current' record are all part of a single transaction, a Push is >> a >> separate and standalone transaction (I believe)....so while if there are >> errors in AL2, the 'save' won't commit, I believe that anything that >> happened >> with a push will have already been committed to the DB, and not rolled back. >> >> On Mon, Sep 9, 2013 at 8:10 AM, Rick Cook >> <remedyr...@gmail.com<mailto:remedyr...@gmail.com>> wrote: >> ** >> Guys, you're all missing something. Active Link actions that fire at the >> client level only perform actions against a displayed COPY of the record in >> the DB. Those changes aren't committed to the DB until a Save action (i.e. >> Commit Changes/Save) occurs. So from a DB perspective, there are no AL >> transactions to roll back, because they weren't sent there until a DB action >> (Modify/Create) occurs. >> Since all DB-based transactions can be rolled back, as you all correctly >> mentioned, the net result of that rollback is a record that, at the DB >> level, >> is entirely what it had been prior to the initiation of the transaction. >> What >> displays on the client may be different, but that, again, is just a copy, an >> overlay, if you will. >> >> Rick >> >> On Mon, Sep 9, 2013 at 6:52 AM, Misi Mladoniczky >> <m...@rrr.se<mailto:m...@rrr.se>> wrote: >> Hi, >> >> I agree completely with L.J. here. Use filters. >> >> There is one instance though where filters do not roll back, and that is if >> you do Filter Service Calls to perform any database stuff. This in not that >> common though. >> >> Best Regards - Misi, RRR AB, http://rrr.se >> >>> The simple answer, is do it with Filters. Change your two active links to >>> be a single active link with a service action, have filters triggered on >>> service that perform the actions of both active links. >>> >>> This has multiple benefits, less activity between client and server, which >>> gives a better performance experience, secondly, the benefit you are >>> looking for of transaction integrity. >>> >>> >>> On Mon, Sep 9, 2013 at 7:15 AM, Sahil >>> <pathania.sa...@gmail.com<mailto:pathania.sa...@gmail.com>> wrote: >>> >>>> ** >>>> Thanks for the answer >>>> >>>> Then how the data integrity be maintained. If a operation is performed and >>>> change request is created along with task. This action is performed by two >>>> ALs. Now if one AL is failed then one request gets created and other not. >>>> ?? >>>> >>>> >>>> regards >>>> sahil >>>> >>>> >>>> On Mon, Sep 9, 2013 at 3:10 PM, Longwing, Lj >>>> <llongw...@usgs.gov<mailto:llongw...@usgs.gov>> wrote: >>>> >>>>> ** >>>>> No, Active links are each separate transactions, so action 1 does not >>>>> roll back. >>>>> >>>>> >>>>> On Mon, Sep 9, 2013 at 4:27 AM, Sahil Pathania >>>>> <pathania.sa...@gmail.com<mailto:pathania.sa...@gmail.com>>wrote: >>>>> >>>>>> Hello Experts, >>>>>> >>>>>> I just wanted to know the rollback functionality of ARS. >>>>>> >>>>>> I am saving request on the form. I have 3 Active links A1, A2 and A3 >>>>>> which push data to the form F1 F2 and F2. >>>>>> >>>>>> Once A1 Active link fires and commit the data to form F1, then network >>>>>> error comes and A2 could not fire. >>>>>> >>>>>> Does remedy rollback the transition on F1. >>>>>> >>>>>> >>>>>> I know it happens in case of filter but not sure about Active links.. >>>>>> >>>>>> Remedy ARS 7.6.04, oracle DB >>>>>> >>>>>> >>>>>> regards >>>>>> Sahil >>>>>> >>>>>> >>>>>> _______________________________________________________________________________ >>>>>> UNSUBSCRIBE or access ARSlist Archives at >>>>>> www.arslist.org<http://www.arslist.org> >>>>>> "Where the Answers Are, and have been for 20 years" >>>>>> >>>>> >>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>> >>>> >>>> >>>> >>>> -- >>>> *Cheers!!* >>>> *Sahil Pathania* >>>> >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at >>> www.arslist.org<http://www.arslist.org> >>> "Where the Answers Are, and have been for 20 years" >>> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at >> www.arslist.org<http://www.arslist.org> >> "Where the Answers Are, and have been for 20 years" >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"