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
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.
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.comwrote:
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,
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
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
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
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
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 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
I seem to remember that AL's don't have phasesphasing 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 wrote:
**
If your
(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 phasesphasing is only for Filters,
and that everything happens immediately.
Truly
] 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 phasesphasing is only for Filters,
and that everything happens immediately.
Truly...this would be easy enough
] 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
13 matches
Mail list logo
