Workflow (was "Re: [provision] Re: Async and workflow")

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Jeff Larson wrote:

>> 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.   

This is the sort of thing that we could define as a separate 
capability.  That makes it optional, and it's easy for the requestor to 
tell whether it is supported.

> 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.

Perhaps this part is no more than "async conversion".  The provider can 
refuse to cancel an operation that is a workflow...

>
> 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. 

Would it make sense for the provider to issue some sort of callback to 
the requestor (e.g., for contact information)?  I find it hard to 
imagine an RA that is a program modifying the contents of a workitem.  
It seems like this would be a *person* looking for workitems and 
modifying their contents, or perhaps replying to an email from the 
provider.  The provider's email could contains a link to a dialog that 
requests specific information from the person and applies it to the 
request/workitem.

>
> 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.

Assuming that the requirement holds, I think we could formalize the 
notion that an SpmlResponse may contain a (server-generated) requestID. 
(I described one approach just a minute ago in my email titled "Async 
Conversion".)

gpc