[FOLIO-1081] High-level design of FOLIO workflow engine Created: 22/Feb/18 Updated: 12/Nov/18 Resolved: 01/Oct/18 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Mike Taylor | Assignee: | Mike Taylor |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 3 days, 2 hours | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue links: |
|
||||||||
| Sprint: | |||||||||
| Description |
|
Ongoing discussions. I created this issue mostly so I can file hours on it. |
| Comments |
| Comment by shale99 [ 25/Feb/18 ] |
|
An additional option would be to use the REST endpoint as an event key and the payload (json) as the event data. The event key would be comprised of the VERB + TENANT + RESPONSE-STATUS + RELATIVE-URL-ENDPOINT (calling this REST++ for short) We have all the event keys defined in the RAML files along with payload (response) examples. A workflow that is interested in a REST++ event, registers on Okapi or a dedicated mod-proxy / mod-workflow-proxy listens for these REST++ events. This would look something like this: Made up workflow: Automatic: Scan loans in loans table Note that this doesnt have to be an event coming from the UI, it can come from anything triggering a REST++ which should be everything As for implementing the workflow itself. Spring's state machine implementation seems like a very good choice for this - see attachments |
| Comment by shale99 [ 25/Feb/18 ] |
|
attached is a an example of Spring's state machine impl - i left out additional classes but can create a repo with them if needed some highlights:
|
| Comment by Mike Taylor [ 17/Apr/18 ] |
| Comment by Mike Taylor [ 01/Oct/18 ] |
|
I guess this stream of work reached its conclusion long ago, with the creation of https://github.com/indexdata/mod-workflow/blob/master/doc/folio-workflow-engine.md and related documents. |