Joe:
K understand that there will be a network cost, but I wouldn't discount it.
Consider this:
(a) By including a sleep(n seconds) function in your code, you are:
- basically providing the best response time of "n" seconds to your end
user, best case, in all cases.
- making your code dependent on other functions and systems (ie.
database functions) when upgrading
- altering your design to accomodate less than optimal design in the
other system
Also, if this "pending" status is basically milliseconds, then I can't
understand why there would be such a huge network cost.
So, for fun, consider this:
Create a filter guide that does the following:
(a) Sets an attribute called "transaction start time" to $TIMESTAMP$ if it
is $NULL$
(b) Increments a counter to count the number of times the web service is
called
(c) Call the web service, set the result
(d) Set an attirbute called "transaction stop time" to $TIMESTAMP$
(e) Check if the result is != "Pending". If so, exit.
(f) Check if "Transaction Stop time" - "Transaction Start Time" is greater
than some value (say 30 seconds). If so exit filter guide
(g) Goto (a)
In the end, you have data that tells you
- the average transaction time that the other system takes to process
- the number of times it had to call the system before it gave you a valid
result
Also, as they improve the performance of the other system, your code doesn't
need to change. Also, the response time to the user is "best case" always.
Just an idea.... HTH.
Terry
_____
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Joe Martin D'Souza
Sent: Wednesday, May 30, 2012 4:37 PM
To: [email protected]
Subject: Re: PAUSE or SLEEP a filters in between actions...
**
That's a solution, but with a higher cost on the network.. It was given a
thought and discarded because of the costs involved..
Joe
From: Terry Bootsma <mailto:[email protected]>
Sent: Wednesday, May 30, 2012 4:27 PM
Newsgroups: public.remedy.arsystem.general
To: [email protected]
Subject: Re: PAUSE or SLEEP a filters in between actions...
**
How about calling a filter guide that calls the WSDL until the output
doesn't equal "Pending" . (to prevent run-away code, put in a counter to a
maximum of 10 calls).... If you find output != Pending, then simply exit
the guide and continue processing.
Terry
_____
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Joe Martin D'Souza
Sent: Wednesday, May 30, 2012 4:06 PM
To: [email protected]
Subject: PAUSE or SLEEP a filters in between actions...
**
We are updating an identity management system (OIM) using its SPML based
WSDL.
During the operations to suspend or resume a user the output status of this
operation seems to always be 'pending' - which in reality is really an
intermediate status before 'success' or 'failure'. The lifespan of this
intermediate status is just a brief fraction of a second before the update
either succeeds or fails..
>From the service consumption point of view, this intermediate status of
'pending' is not quite meaningful other than the the fact that the WSDL call
was successful. Given a choice I would have rather had the option to wait
for those few micro seconds, at what point the status of either 'success'..
They have a operation in the same web service to query the status. Following
the update WSDL with a query WSDL is what I thought would be my answer to
getting the new status (although I do not like the option of have another
WSDL call when there could have been one)... This query however returns the
status of the the user pre update. Filters as we know have no 'SLEEP' type
action, else I could have used that to pause the filter operations in
between the update and query operation.
Ideally it would have been perfect if there was an ability to introduce a
pause between the two WSDL calls.
Is there any 'creative' way of inserting a pause in a filter operation that
maybe I do not know of?
Joe
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
