Introduction Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame [email protected] @jeremyfriesen github.com/jeremyf ndlib.github.io Presentation at goo.gl/cESnSo
Sipity Technical Overview General Concerns for Workflow ● Given who I am, what objects can I perform actions on? ● Given an object, what actions can I perform? ● Given an action is taken, what should happen? ○ Event logging? ○ Notifications? ○ Update to persistence? ○ Processing state change? ○ Other?
Sipity Technical Overview Processing::Entity A proxy for an object that will be going through a workflow. With a proxy, we don’t store workflow state on the base object.
Sipity Technical Overview Processing::Strategy The workflow through which a Processing::Entity will be mediated. If you were to name the workflow concept (i.e. Mediate ETDs) that would be the strategy.
Sipity Technical Overview Processing::StrategySt ate The named states for the given workflow. Note, a processing entity belongs to both strategy and strategy state.
Sipity Technical Overview Role A named proxy for a set of responsibilities (i.e. actions that can be taken). Convention is to use a verb. The role is “Approving ETD Submissions”. This is not a group of people!!!!!!!!!!!!!!!
Sipity Technical Overview Processing::StrategySt ateActionPermission Defines all of the actions that can be taken in the given state by the given strategy role
Sipity Technical Overview Processing::Actor A proxy for something that can act on the Processing::Entity. We can expand an Actor into an array of users.
Sipity Technical Overview Processing::StrategyRe sponsibility For each and every Entity that uses the given Strategy (e.g. workflow), the given Actor has the given StrategyRole.
Sipity Technical Overview Processing::EntitySpec ificResponsibility For the given Entity that uses the given Strategy (e.g. workflow), the given Actor has the given StrategyRole.
Sipity Technical Overview Processing::Notifiable Context When actions are taken we can send one or more emails. This gets complicated. Expand roles into actor emails. Query to find recipients
Sipity Technical Overview Prerequisites and Action Registry If certain actions are required to be completed before other actions can be taken…these are responsible for enforcement.
Sipity Technical Overview Processing Queries Concepts ● AREL - allows for any ActiveRecord adapter ● Coercion - ensure we have predictable objects ● @api public vs. private methods ● Lots of Documentation ● Lots of Specs Here there be dragons
Schema to Define Workflows ● Ensures configuration is correct. ● Allows for the rules to generate the data from the schema to change. ● I did not look for nor adapt a standard for describing workflows. Given an actual data file we can run a data processor/generator to populate the database. Sipity Technical Overview
Debug View to See State Diagram Since permissions are at the strategy and the entity level seeing the full details of who and what have permissions is helpful. This is itself a permissioned action within Sipity. Sipity Technical Overview
Script to Generate State Machine Diagram You will want a diagram that tells you who can do what at each given state as well as any emails that are to be sent. Sipity Technical Overview
What I wish Sipity had: ● An Action’s form defined via JSON…because we are allowing custom workflow actions and states ● Better conceptual separation between a state changing action and a non-state changing action (e.g. show) ● Database representation of callback hooks ○ Currently defined via conventions but it’s opaque ● Convergence on Presenter objects; Decorators hurt Sipity Technical Overview
Valuable Features: ● Coercion functions, though I’d converge on PowerConverter ● Processing Entity as proxy for object ● Separation of Roles vs. Groups ● Actor as proxy for someone that does something (I’d rename it to Agent in the future) ● Actions can be taken on behalf of someone else ● Lots of documented high-level concepts Sipity Technical Overview
On the horizon we will be leveraging Sipity for… ● Hesburgh Libraries’s Project Request and Prioritization workflow ● Capturing presentation submissions and building conference schedules for our multiple Excellence in Undergraduage Research (XUR) confrences each year Sipity Technical Overview
Thank You Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame [email protected] @jeremyfriesen github.com/jeremyf ndlib.github.io Presentation at goo.gl/cESnSo
jeremyf
guvalif
ivargrimstad
keitaro1020
mski_iksm
mpyw
terukinakano
mrstsgk
iwaken71
star_zero
mackee
kin29
yusukebe
jonrohan
smashingmag
addyosmani
rasmusluckow
keavy
3n
philhawksworth
caitiem20
searls
reverentgeek
cassininazir
brettharned