Workflow in FOLIO

Plan Forward - May 2019

​

Mike Gorrell

Long Term Vision

Workflow in FOLIO is a system that allows the library to:

• Define a sequence of triggers, steps and flow criteria that collectively can be called a workflow
• Execute those defined workflows
• Integrate manual/human tasks into workflows as steps, triggers or flow criteria
• Integrate workflow with FOLIO Apps/Modules and Data to automate processes
• Enable workflow to integrate manual and automated steps

Workflow Pieces

In order to achieve the long term vision there will need to be 5 key components of the Workflow system:

1. The workflow engine - the thing that executes workflow. The FOLIO project has identified Camunda as the best candidate for that engine.
2. A workflow editor - a tool that allows you to create workflows
3. A console that allows a site to manage, view and debug (if necessary) workflows
4. An app that allows individuals to participate in workflow. This is the “To-Do App”
5. Software methods to interact with FOLIO Modules to facilitate automated activity as defined in workflow steps/triggers

Integration with FOLIO

Message Queue: A system that allows for publishers and subscribers to exchange information on a message “bus”

• FOLIO activity happens and events are published to the bus
• Workflow subscribes to those events and takes appropriate action
• When a Workflow needs to trigger activity by a module it would use the existing APIs - not publish messages to the queue

In this way we can minimize the integration needs between FOLIO and the Workflow system

To Do App

Data

module

module

module

Data

Workflow

module

(mod-

camunda)

Data

Workflow Management Console

Workflow Editor

message queue

A strategy for getting there

There is plenty of work required to make the long term vision a reality. But we can achieve a solid return on investment before we are “all the way” there.

First - focus on workflows that orchestrate/manage manual activities

This would allow us to focus on core pieces of the overall workflow solution, but allow us to avoid the most complex aspects - interacting deeply with Apps and Data.

Eventually expand to be more comprehensive

​

Shorter Term Vision

Workflow in FOLIO is a system that allows the library to:

• Define a sequence of triggers, steps and flow criteria that collectively can be called a workflow
• Execute those defined workflows
• Integrate manual/human tasks into workflows as steps, triggers or flow criteria
• Integrate workflow with FOLIO Apps/Modules and Data to automate processes
• Enable workflow to integrate manual and automated steps

Wait on these aspects

What work is required?

• Define/edit workflows in the Camunda Editor
• Finish the building of Mod-Camunda (started in PoC)
• Build the To-Do app
• Leverage Camunda Cockpit for Workflow Management Console
• Define/implement mechanism to trigger workflows from FOLIO activity
• Leverage FOLIO message queue system

What work is avoided by the initial approach

• No work needed to have modules/apps be tightly integrated with Workflow
• Don’t have to wait for Message Queue to be implemented
• Don’t worry about building/reskinning the Workflow Builder as a native FOLIO app
• Smaller subsets of workflows that can be modeled limits scope

Examples

​

1. Patron initiated one-time acquisition of a book
2. Claiming process
3. Database Trial request
4. Renew subscription

Workflow diagram - symbols and meanings

Trigger to kick-off Workflow

To-Do App interaction

Manual task

A separate workflow

A decision point

End of Workflow

Workflow triggered Automatic function (not manual)

Patron initiated one-time acquisition of a book

Confirmation email to patron

Yes

Yes

Yes

No

No

No

Alert Acquisitions Staff

Alert Patron

Alert Patron

Alert Acquisitions Staff

No

Yes

Alert Patron(s)

To-Do App notify Staff

Check for Existence

Evaluate Purchase

Evaluate Purchase

Yes

Yes

No

No

Alert Patron

Claiming process

Yes

No

DONE!

Set reminder

Determine Method

EDI

*as defined by the Orders app

Manual

Automated but not EDI

Email

Phone

Print & Mail

Vendor System

Reminder Shows up in To-Do App

Send Email

Print Claim details and mail to Vendor

Call Vendor

Enter Claim details in Vendor System

Set reminder

Close Claiming Record

Send Vendor formatted Email

Set reminder

Send EDI Claim

Set reminder

Yes

No

Database Trial Request

Confirmation email to patron

Yes

Yes

Yes

No

No

Set Auto Reminder

Alert Requester

No

Alert Requester

To-Do App notify Staff

Check for Existence

Setup Trial Record

Evaluate Trial Request

Initiate Contact with Vendor

Set Auto Reminder

(Trial End)

Close Trial

Electronic Resource Setup - Trial

Confirmation email to patron

Yes

No

To-Do App notify Staff

Update Trial Resource Record

Set Auto Reminder

(Trial End)

No

Yes

Ticket for EZ Proxy and Trials page setup

Register IPs/Passwords with Vendor

End

Renew a Subscription

Yes

No

To-Do App notify Staff

Evaluate Subscription

Retrieve Invoice (FTP Site)

Upload files to EDI

Pay Invoice(s)

Update Subscription Record

Done

Relationship to Proof of Concept

The PoC Concluded:

Design/Development Needs

These estimates assume 2 week sprints with 3 FTE team (product owner, front-end developer, back-end developer) with some specific tasks needing the skills of a UX designer.

1. Integrate the formal messaging service from Okapi when it is defined and available. Effort estimate: 2 sprint cycles; effort estimate confidence: medium.
2. Dashboarding component that utilizes Camunda task metadata to display in-flight workflows and errors. Effort estimate: 3 sprint cycles; effort estimate confidence: low; will need UX design work.
3. Design a mechanism for importing BPMN XML documents into mod-workflow from Camunda Modeler. Effort estimate: 1 sprint cycle; effort estimate confidence: medium.
4. Design, document, and implement a pattern for annotating Okapi module API contracts to specify which ones would be displayed in the Camunda Modeler (and perhaps subsequently in the Workflow App) as steps. Effort estimate: 1 sprint cycle; effort estimate confidence: high.
5. Design, document and implement a pattern for Okapi modules to identify events that trigger a state change in the workflow process engine. Effort estimate: 1 sprint cycle; effort estimate confidence: high.
6. Retrofit existing Okapi endpoints to accommodate annotations to the API contracts. Effort estimate: work to be distributed to teams responsible for existing modules.

​

Proof of Concept excluded To-Do app, which this approach includes.

Required

NOT Required at this time

ROUGH Order of Magnitude Estimate

Assume a team of 1 UX Designer, 1 Front End Dev, 1 Back-end Dev and 1 PO:

• Integration of Camunda - the workflow engine - the thing that executes workflow. 1 month
• Integration of Camunda’s Modeler (workflow editor) - 2 weeks
• Integration of Camunda’s Cockpit (console that allows a site to manage, view and debug (if necessary) workflows) - 6 weeks
• The “To-Do App” - 4 Months
• Integration with email service/other ‘lightweight’ integrations - 2 months

TOTAL: 6-9 Months

When would we get to fuller solution?

Requires availability of:

• Resources
• Technical dependencies: Message Queue

To be determined

Next Steps

• Validate approach - technically; PoC members and Core Platform team
• Create better estimates for work
• Present to PC for prioritization
• Identify team/resources
• Schedule work