+1, thanks Scott for the idea and explanation!
Jacques
Le 17/03/2016 10:51, Jacopo Cappellato a écrit :
Thanks to all of you for your valuable feedback.
For now we could, as recommended by Scott, improve the documentation to
make it clear when and how the auth and in-validate events can safely be
used(i.e. to call services that don't change the status of any system).
Regards,
Jacopo
On Tue, Feb 23, 2016 at 11:41 PM, Scott Gray <scott.g...@hotwaxsystems.com>
wrote:
I've been aware of this for a while and always assumed that the intention
was for the auth and in-validate events to only use idempotent services
that exist to validate the service call. I don't mind if we remove them
for async calls but we do lose the feature that the caller is immediately
notified that the job they've executed isn't valid.
The other option is to improve the documentation for these events so devs
aren't taken by surprise.
Regards
Scott
On 23 February 2016 at 22:59, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
Taher,
yours are all valid questions and I don't have a precise answer for them:
it may be that it was done by design (as Gil said for example to allow
the
creation in the queue of "valid" jobs only) or just for a copy/paste
pattern...
Jacopo
On Tue, Feb 23, 2016 at 10:35 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:
Hi Taher,
The only thing i can see around this matter is if the seca fail during
invoke, no job is created ?
My 0,02 cts
Gil
On 23/02/2016 10:27, Taher Alkhateeb wrote:
Hi Jacopo,
So to understand correctly, you want to disable all SECA executions
(triggered by evalRules) when the call happens to runAsync.
Any idea why it was there in the first place? It seems strange to have
such
a flaw in the design deep in the service engine. If an async service
eventually triggers all ECAs, why did anyone go through the effort of
putting that code in runAsync! BTW I'm not objecting to your proposal,
merely commenting on the oddness of having that piece of code in there
in
the first place.
Taher Alkhateeb
On Tue, Feb 23, 2016 at 10:51 AM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
Hi Taher,
yes you are in the right place: the proposal is to remove, from the
ServiceDispatcher.runAsync method, the code following the two comments:
// pre-auth ECA
and
// pre-validate ECA
Jacopo
On Tue, Feb 23, 2016 at 7:10 AM, Taher Alkhateeb <
slidingfilame...@gmail.com
wrote:
Hi Jacopo,
I'm trying to find where the logic described above is happening, am I
in
the right place at ServiceDispatcher on the runAsync method right next
to
the checking of pre-auth ECA rules?
Taher Alkhateeb
On Mon, Feb 22, 2016 at 5:45 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
Hi all,
I am sharing here the result of an analysis that Nameet Jain and I did
to
figure out why, under some circumstances the same seca service was
executed
twice.
The problem is that, when a service is executed as "async" the secas
attached to the "auth" and "in-validate" events are executed two times:
at
the time of the call and later at the time of execution.
Here are the details:
when you call a service using the async method the following events
occur
immediately (i.e. synchronously at the time of the call):
1) all SECAs with event="auth" are executed
2) the user authorization to call the service is checked
3) all SECAs with event="in-validate" are executed
4) the service input parameters are validated
5) the service is submitted for later execution (e.g. added to the
JobSandbox)
After some time, the job scheduler picks the job from the queue and
then
executes it with a *sync* call; at this point all the events that you
would
expect to be executed during a sync call occur:
1) all SECAs with event="auth" are executed
2) the user authorization to call the service is checked
3) all SECAs with event="in-validate" are executed
4) the service input parameters are validated
5) all SECAs with event="invoke" are executed
6) the service is executed
7) all SECAs with event="out-validate" are executed
8) the service output parameters are validated
9) all SECAs with event="return" are executed
10) there are also other SECAs that are scheduled for execution at
transaction level; the ones with events: "commit", "global-commit",
"global-commit-post-run", "global-rollback"
As you can see the steps #1, #2, #3 and #4 are executed twice when the
service is called with the runAsync method and specifically all the
SECAs
of events "auth" and "in-validate" are executed twice.
Proposed fix: we could simply remove the execution of "auth" and
"in-validate" secas when the async service is invoked, and defer their
execution at the time the service is actually executed (i.e. picked
from
the queue and run).
Any comments?
Jacopo
