[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: Java Source File WorkflowEngine.java    
Issue links:
Blocks
is blocked by FOLIO-1042 Look at https://airflow.apache.org/ Open
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)
The data associated with the event key would be the data returned when this event is called

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.
When a registered event occurs (response time, not at request time of course) - this event is sent to the workflow that registered on this event

This would look something like this:

Made up workflow:

Automatic: Scan loans in loans table
Automatic: If loan due date is in the past mark as overdue
Automatic: Calculate fine and update DB
Automatic: Send email to users
Automatic: If due date is more than 2 weeks ago send notification to librarian
Manual: Librarian looks at notifications in UI and confirms they are handling or not
1. the REST++ event comes in
2. if the REST++ event is met (lets say status:200, tenant:a , verb: put, endpoint: abc) forward event + payload to the workflow that registered
3. The step in the workflow handling this event will parse the json and see if the librarian indicated that they are handling or not (on vacation...)
4. and decide to either continue with the workflow or stop with error, etc...

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:

  • simple chaining of a workflow
  • guards to validate data per state
  • run actions before, after a state completes, during a transition between states
  • forking into multiple paths
  • decisions based on output of an action to decide which path to continue in
  • joining of diverged paths back into a single flow
  • error handler so that if there is an error during a state you get to handle
  • listeners on anything in the workflow
  • dynamically put together a workflow
  • define multiple states - you can have a single workflow that has two initial states that join up at one point ...
  • etc... (a bunch of other things)
  • needs to run in an executedBlocking in vertx but all calls within that can be async
Comment by Mike Taylor [ 17/Apr/18 ]

See also: https://jira.indexdata.com/browse/INTFOLIO-12

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.

Generated at Thu Feb 08 23:10:41 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.