[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Async and workflow (was "Re: [provision] Batch Capability.")
Gary P Cole wrote: > 1) From my reading of the SPML1.0 specification, asynchronous requests > *are* just a client preference. I suppose that I could have missed > something, but I see no discussion of sync/async being determined by > the server, nor any discussion to suggest that a client must be > prepared to deal with an unexpected async requestID. In fact, quite > the opposite. The SPML 1.0 specification explicitly states that the > *client* must generate a globally unique value and must specify it as > the value of the "requestID" attribute in the SpmlRequest. Yes, in SPML 1.0 it is just a client preference. I brought it up during the SPML 2.0 discussions, which led it to becoming something controlled by the PSP. I haven't been following the 2.0 spec that closely, so if this got dropped it needs to be brought up again. The PSP must be allowed to convert any synchronous request into an asynchronous request, and the RA needs to be prepared to deal with it. If that isn't allowed, then one of two things happens: 1) The RA blocks on a synchronous request for days until the approver gets around to approving it. 2) The PSP returns a synchronous response, with some kind of proprietary indication that the request has been queued pending approval. The problem with the first approach is obvious. The problem with the second approach is that the RA has no standard way of knowing whether the request actually completed. > > > 3) I would strongly prefer to deal with workflow explicitly and > separately if possible. What sort of a "minimal interface for > workflow interaction" did you have in mind? Yes, I'm not sure SPML should get into the business of defining a workflow interface protocol, though really that does make some sense since I would venture that the majority of PSPs are going to have workflow of some form. At the very least we would need: 1) A standard way for an SpmlResponse to indicate that the request has been "queued". This could be because of workflow, or just because the PSP can't deal with the request immediately for some reason. Part of this is an identifier that the client can use to query the status of the request. 2) A standard way for a client to request the status of a queued request using the identifier returned by 1. This is similar to the async request operations but I really don't think it is the same thing. One difference is that the RA will probably not be able to cancel a workflow once it is in progress. It can only poll status. The next step then would be dealing with what we call "manual actions" and "work items". Manual actions are commonly used for approvals, but they are more general than that. I can easily imagine situations where a request sent to a PSP kicks off a workflow that then decides it needs more input from the RA. The RA then would need some kind of interface to search for it's work items and modify their contents, which would then resume the workflow and complete the original request. This is not all that hard and can be done with SPML 1.0 by defining proprietary object classes and operational attributes in the SpmlResponse. But if this will be that common, we should consider something more formal. I'm ok with having task status and work item editing handled with standard schemas rather than introducing new elements to the protocol. I'm not very fond though of having to pass back the identifier of the workflow task in a proprietary operational attribute, something more formal in the SpmlResponse would be nice. Jeff
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]