Sipity Technical Overview 

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 Working from the following diagram: http://goo.gl/zNQeFZ Please go to the above link. 

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 Processing::StrategyAc tion The named actions that can be taken within the strategy. 

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::StrategyR ole Defines valid Roles for a given Strategy. 

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 

Common Application Entry Keep routes generic (and don’t name a param :action_name) Sipity Technical Overview 

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 

Sipity Technical Overview Any additional questions? 

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