...
"WF" refers to an envisioned workflow system which knows the approval workflows and can tell each participant what its next step is.
Version 1: Synapse interacts with User. This is not feasible since the User-Synapse interaction is synchronous while the Synapse-WF interaction is meant to be asynchronous (at least for the SWF workflow system). | Version 2: Synapse starts workflow; Worker interacts with User via email |
|---|---|
| |
Below we see an alternative for synchronous user interaction.
...
The following variation has the properties that (1) interaction between Synapse and the User is synchronous, (2) there is no representation of the required workflow in the client, (3) there is no representation of the workflow *state* in the back end:
This approach is based on the pattern used by "Basic Authentication", e.g. http://httpd.apache.org/docs/1.3/howto/auth.html#basicworks
in which a request can be denied, the denial containing information about what's required for the request to be approved.
Note: the "/accessRequest" service 'knows' to check that eula 456 is signed before adding user to group 789
changed services:
GET /layer: has to check whether there is an approval process and, if so, include the final step in the rejection
new services:
/accessRequest: checks precondition; can (1) add user to group or (2) add Role to User
POST /approvalProcess: creates an approvalProcess object whose parent is a Layer and
whose content is the sequence of requests that need to be fulfilled (specific to the layer)
POST /accessRequirements: creates an object containing the requirements for adding a User
to the ACL for an entity (e.g. the user must have signed a certain EULA)Design considerations:
System does not track the 'state' of the approval process. That's left to the client. The risk is that the process might have to start over if it fails partway, but the benefit is in simplifying the server.
How do you set up an approval process?
POST /accessRequirements
POST /approvalProcess
...
Here we have the added complexity of an external IRBACT. An "IRB ACT daemon" is added to send approval requests to the IRB and ACTand to listen for replies. The interaction with the user is asynchronous: While waiting for approval the user may do other things (though not access the requested layer). Finally she receives an email saying the request was approved.
Some open questions:
- How does Synapse know not to wait for any more steps, once it gets the final reply from WF (the workflow is not yet done)?
- When Synapse asks "next step" can it refer to a specifc workflow instance (and avoid getting an approval step for some other user)?
New/Modified Synapse Services
Request account (initiates tier 1 workflow as a side effect)
Download access request (initiates tier 2 or tier 2 workflow as a side effect, depending on the layer)
Sign tier 1 agreement
Sign tier 2 agreement
IRB approval of submitted request