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"
