2018-12-12 Technical Council Meeting Notes

 Camunda Workflow Proof-of-Concept Report

If we want to extend to modules, will need to extend annotations in APIs so that workflow can pick those up. Some of that work has been done. Similar to work being done for AES.

Camunda Tasklist web application looks a lot like the To-Do app prototype that has been designed. If Camunda tools good enough, then saves resources in the short term and puts off a Stripes-based to-do app until a future point.

Using BPMN would be a high bar to entry, not very user-friendly. Did not investigate simpler tools, outside of PoC. Do think possible to build an app, given some assumptions, that would be simpler.

Spring Boot: PoC used Spring Framework rather than Vert.x, no implications for Stripes.

PoC implemented such that FOLIO not built on top of Camunda, Camunda calls FOLIO, could envision a replacement if met requirements. BPMN gives nice standard way to divorce the engine from FOLIO proper.

Team to work on this would be 1 BE dev, 1 FE dev, 1 PO, part of UX, over 8 sprints. Using Camunda Cockpit and Camunda Tasklist as-is, Camunda Modeler, build out mod-workflow and mod-camunda. Would complete integration and give infrastructure for building applications that use workflow.

Jeremy Warren (BP3) says Camunda has best track record of OSS workflow engines for building in to other projects, highly configurable and customizable. The FOLIO use case of providing a central place to view your work and processes is a good match, they see this in many industries. Important to have right use cases to build.

NB: Cockpit is the administrative view to see all processes, their state and history. Would use Tasklist and Form Builder to quickly prototype workflows. Ideally, Camunda eventually running headless and FOLIO build app on top. Ideally would want some type of message bus. Camunda is agnostic over whether message bus would be active or passive. There is a requirement in cluster-mode, must subscribe to a queue rather than a topic; must ensure that only one instance of mod-camunda receives and acts on a message, would not want more than one clustered instance to initiate work based on the same message.

Idea: first release would meet needs of sysadmins, inspect workflows, unstick processes etc. through Camunda Cockpit.

First work would be to identify work that touches different modules and would benefit from workflow engine. Developers and librarians would use endpoints exposed by mod-workflow and mod-camunda to create model.

Report does not make a specific development path going forward, outlines the questions we would need to answer to determine that path.

If a messaging bus comes about, would then be able to subscribe to the message bus. It seems like there is a contract of some sort between the modules doing work and either Camunda or the messaging mechanism. Current implementation is very much like passive messaging, contracts would come up in an active pub-sub model.

Critical for RAML to specify the response JSON schema of every endpoint. (This seems in line with needs for the LDP prototype, needing to know the shape of the data returned.) (Do we have examples of endpoints where the schema are missing? Early on have been operating on paradigm where response is an echo of the input, are working on different paradigm. An omission. Jakub Skoczen will make a ticket for this.)

Will we create a PoC for dynamic creation of APIs?

Open question is how is this work prioritized against other work we have. One risk is that if this work is not prioritized then other modules will bake in their own workflows. This will be a question for PC. Q1 work has been planning with no Workflow and pulling devs for Workflow will change Q1 scope.

• To ensure we have visibility into the modules, what specific processes do we have that we have that would benefit
• Observation from Jeremy Huff:
  
  • We have some momentum and would be able to capitalize on the current momentum.
  • If we do not, then could have workflow build implicitly into hard-coded business logic.
  • Some of the processes encoded into BL modules rely on some reasonable assumptions but would require development to change, more expensive than using workflow.

Jakub: opens up the door for more customizing down the road through the engine. Concern is that feature planning is always further ahead of development, so current features being implemented will lose the benefits, have lost benefits for Q1 features. How many features in backlog would benefit? Features will also need to be re-estimate features with the presence of a workflow.

Need to identify composable units of work. BPMN provides a modeling notation to describe those units that and identify those units. PoC has identified the most granular units of work are the API calls through Okapi. Useful for the developers, not so much for the users. We may have an opportunity to gather things together into useful bundles.

Next Steps:

• Take to PC as an update
• Further discussion within TC to determine options for PC to weigh this NFR against scheduled work.