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"
