[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Workflow (was "Re: [provision] Re: Async and workflow")
> > 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. I wouldn't recommend getting into a callbacks. Everything can be done with RA initiated communications, callbacks just add complexity. Why can't an RA be a person? I would imagine a lot of the time it will be a person interacting with a system that happens to also be an RA. That was the case in the original PeopleSoft demo. Granted, the RA application has to be built with the notion of work item support in mind. PeopleSoft isn't of course, but something designed for SPML could be. When the person gets the email with the link to the dialog, what are they interacting with? The fact that SPML is being used implies that the client wants to be in control of the user interface, so there needs to be something on the RA side of the fence that processes work items, and that is going to need an API. This can either be the same RA application that started the request or a different one, but they both use SPML to communicate with the PSP. > > 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".) > Works for me. Jeff
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]