2019-06-07 - System Operations and Management SIG Agenda and Notes
- Ingolf Kuss
- Tod Olson
Date
Attendees
- Dale Arntson
- Kathleen Berry
- Steve Bischof
- Christopher Creswell
- Greg Delisle
- Robert Douglas
- Anton Emelianov (Deactivated)
- jackie.gottlieb@duke.edu (Deactivated)
- Ian Hardy
- Jeremy Huff
- Hkaplanian
- Tod Olson
- Philip Robinson
- zeno.tajoli
- patty.wanninger
- Alexander Soto
Goals
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 5 | Welcome | Ingolf | |
| Ingolf | Are there topics I need to address in next week's (June 13) SIG Conveners' round in the Product Council ?
Meeting Notes The majority of the group considers this a full-time professional position. Some raise objections, that the communication with a tech writer will produce additional work for the group. The group has already written documentations themselves and will continue to do so. A tech writer is seen more as an editor who will standardize the documentations. Also, continuous upgrades of the documentation is something which should be monitored by a professional who is just occupied with documentation (unlike the group members who have many other responsibilities or even work part-time om FOLIO). | ||
| 45 | Continue discussion on Workflow Proposal | Feedback of SysOps SIG to PC is due by June 13th. Jeremy Huffis a developer at TAMU who was chiefly involved in the design and implementation of the FOLIO Workflow PoC in November and December 2018. Jeremy offers to speak about the BP3 Workflow PoC (Link to the Initial Workflow Whitepaper and the Final Workflow PoC Report deliverd to the TC and PC). Alternatively, Jereny could explain use-cases at TAMU for a workflow engine . Meeting Notes Jeremy's slides: https://docs.google.com/presentation/d/18TRSRTTMP6mrH0qnZ3YsEWl9W6RLtT6YZIK16dGC8GM/ FOLIO has two kinds of backend modules: business logic modules and storage modules. Implementing workflows in FOLIO will give institutions the possibility to implement their institutional policies againts the FOLIO system without the need to version modules. They won't have to hard-code their workflows in the BL modules (which would make sense if these workflows would be applicable also to other institutions). Workflows are a layer on top of FOLIO. Without workflows, one will have a massive proliferation of system properties (as in Koha). Workflows leverage the microservice approach. The PoC makes use of the Spring framework, because Camunda already has Spring-Boot integration. Therefore, a parent project spring-module-core is among the architectural decisions of the PoC. This module integrates any Okapi module to the Spring framework (The Okapi modules have been developed with Vertex). Two other backend modules are proposed by the PoC: mod-workflow and mod-camunda. mod-workflow is the generalized view of workflows regardless of a workflow engine. Through mod-workflows, one creates, updates and deletes workflows. mod-workflows has no mention in the current Workflow Proposal. We have to insist that it will be part of the development (it is not clear if it was dropped or if it was just not mentioned in the proposal in favor of a higher-level overview). For mod-camunda will provide for the possibility to exchange the workflow engine. The prospect of this possibility eliminates much of the concerns which were raised against the workflow proposal in our discussion last week. mod-workflow exposes a read-only API for all tasks expressed by Okapi modules. It exposes an API for CRUD operations on the workflow domain. Thus, it allos the user to create, update and delete workflows. It also allows for activation and deactivation of workflows. mod-camunda is an Okapi module with an embedded Camunda engine. When versioning the APIs in FOLIO, workflows help to get a clear picture where it breaks, they keep track of this. Though writing a workflow would be a specialized skill, it would require an understanding of the backend APIs. The flexibility to add something on top of the layer of FOLIO without needing to change the code. A meta-layer of implementation. When we have similar workflows it may be easier to share modifications (of modules) between institutions. Workflows will have to be upgraded when there are upgrades to the modules (viz. the module APIs). Workflows are vulnerable to the advancement of FOLIO. Workflows are a more nimble kind of implementation (than coding). Further reading: Guidelines for deciding whether to use a rules engine | |
| 10 | UMass workflow analysis for acquisitions and a little for circulation | Steven explained an acquisition workflow at UMass which they like to be automated. He also showed a circ workflow. Discussion A Dashboard / To-Do List is desirable to have. One wouldn't want a blank screen upon log-in but rather a Task-List, a dashboard, a day-to-day to-do list. | |
I summarize our feedback to the Workflow Proposal : Pro: (pro workflows in general)
(pro specific concepts of the FOLIO workflow proposal)
Objections:
| |||
Topics for the next meetings: Setting up the FOLIO Data Warehouse — Implications for System Administrators will be scheduled for after the D.C. meeting | Ingolf will invite Nassib Nassar for one of the next sessions | ||
A Big Topic for a future meeting — will take a whole session (at least) Securing Okapi - FOLIO Security considered a pre-requiste for in-place upgrades I scheduled this with Jo Drexl for 06/28 |