That’s what I was asking them. They said that they ‘do stuff’ with our input internally before the record is marked true or false for active after which the status changes to a success or a failure if the operation to change the active value fails.. So what we are getting is actually a synchronous result of a ‘pending’ status.
One of the things we discussed with them is that if this is how their design is, if it is possible for them to consume a web service I have already created on the integration form, where they can query for their requestID and psoID (a combination that is unique on the integration form) and update the status field there using our custom WSDL that I created, when their operation is complete.. I have an update operation defined on the WSDL.. psoID is a unique person identifier on OIM and requestID is the ID of unique requests sent to OIM using their SPML services.. So this combo is always unique for every SPML request.. That way we can at least inform the user that the operation has been successfully accepted, will need some processing time and that they will get notified as soon as its complete.. which is possible through a filter notification as soon as an update is received from the WSDL I have created.. I’m personally not thrilled by this solution that much although I partly contributed to the idea. Its not truly real time when it could have been that considering that the lifespan of that intermediate status averages way below a tenth of a second.. From: Randeep Atwal Sent: Wednesday, May 30, 2012 4:45 PM Newsgroups: public.remedy.arsystem.general To: [email protected] Subject: Re: PAUSE or SLEEP a filters in between actions... ** ** If the call is actually synchronous, I'd tell the OIM side folks to expose the 'new status' Make it their problem; if they claim to provide a synchronous service, they should be able to show you the 'new status' straight away in the output response of the first call. If it is really an asynchronous service, you could get wild variations in response in prod environment, so I'd check that with them. (Especially if their downstream dependencies are undergoing maintenance) If it is asynchronous, you have to consider the non happy path scenario (ie more than a millisecond), and I'd still urge escalations in that case. Better to check that with them before coding based on what you see in a dev happy day scenario is my parting comment :-) Sent from my BlackBerry device on the Rogers Wireless Network -------------------------------------------------------------------------------- From: Joe Martin D'Souza <[email protected]> Sender: "Action Request System discussion list(ARSList)" <[email protected]> Date: Wed, 30 May 2012 16:35:55 -0400 To: <[email protected]> ReplyTo: [email protected] Subject: Re: PAUSE or SLEEP a filters in between actions... Randeep, Agreed about the blocking the thread concern, but that isn’t really a concern on this particular case.. It is noticed that the transitional status of pending is only a brief milli second.. However both synchronous as well as asynchronous WSDL calls returns that same transitional status. This status considering that operation is almost real time, is no value to me. I would rather know right off the bat if it failed or succeeded. The risk to blocking the thread because of the insignificant time involved is a risk I think I am prepared to take.. I did think of the escalation bit too (that’s basically the design of many BMC apps where such integrations are concerned like BMC CLM product)... But in our case we are doing a very synchronous task of enabling or disabling a user.. Once the request is sent, I’d rather know the results immediately.. Like switching on or off a light.. After clicking that switch I really do not want to be told by a light switch that my operation is accepted and that light may be turned off or on after 5 minutes.. Please come back and check the status of that light again.. I do appreciate your inputs though.. very valid points.. Joe From: Randeep Atwal Sent: Wednesday, May 30, 2012 4:23 PM Newsgroups: public.remedy.arsystem.general To: [email protected] Subject: Re: PAUSE or SLEEP a filters in between actions... ** ** I would recommend not waiting since the thread is blocked and this isn't good for thread scalability. I'd suggest: When you call the service, set your transaction status to sent, and populate a 'confim/retry datetime' for now plus x seconds) An escalation in a dedicated pool every minute, or what you consider a suitable period, to look for records where the transaction status is 'sent', and 'confim/retry datetime' > $TIMESTAMP' and should set a retry display field to trip a filter to call their second service to confirm completion, and mark the transaction as 'complete' (and set a archive/delete date for when you want this transaction archived or deleted) If their end is not complete, trigger a resend. Keep a count of retries and stop retrying when x number of retries is met. Also, set the 'confim/retry datetime' that expands with each retry, so you are not flooding them with retries after the target system comes up from e.g. Maintenance. This ideally has all transactions in a seperate ar form. Sent from my BlackBerry device on the Rogers Wireless Network -------------------------------------------------------------------------------- From: "Shellman, David" <[email protected]> Sender: "Action Request System discussion list(ARSList)" <[email protected]> Date: Wed, 30 May 2012 16:10:46 -0400 To: <[email protected]> ReplyTo: [email protected] Subject: Re: PAUSE or SLEEP a filters in between actions... Joe, I've used a simple counter in a filter guide to cause a pause in a filter operation. Basically the old programming loop counter to slow down a process. The filter guide loops until the counter reaches a set value. Dave On May 30, 2012, at 4:05 PM, "Joe Martin D'Souza" <[email protected]> wrote: ** 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
