Sipity Technical Overview

Database and design discussion concerning task oriented workflow tool.

Transcript

1. Sipity Technical Overview
2. Introduction Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame jfriesen@nd.edu @jeremyfriesen github.com/jeremyf ndlib.github.io Presentation at goo.gl/cESnSo
3. 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?
4. Sipity Technical Overview Working from the following diagram: http://goo.gl/zNQeFZ Please go to the above link.
5. 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.
6. 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.
7. Sipity Technical Overview Processing::StrategySt ate The named states for the given workflow. Note, a processing entity belongs to both strategy and strategy state.
8. Sipity Technical Overview Processing::StrategyAc tion The named actions that can be taken within the strategy.
9. 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!!!!!!!!!!!!!!!
10. Sipity Technical Overview Processing::StrategyR ole Defines valid Roles for a given Strategy.
11. Sipity Technical Overview Processing::StrategySt ateActionPermission Defines all of the actions that can be taken in the given state by the given strategy role
12. 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.
13. 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.
14. 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.
15. 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
16. 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.
17. 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
18. Common Application Entry Keep routes generic (and don’t name a param :action_name) Sipity Technical Overview
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. Sipity Technical Overview Any additional questions?
26. Thank You Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame jfriesen@nd.edu @jeremyfriesen github.com/jeremyf ndlib.github.io Presentation at goo.gl/cESnSo