Update, Feb 2015: AlphaFlow on plone has been replaced by a home-grown postgres/django application called "wf", which runs on host wf-prd.fnal.gov. And there was much rejoicing.
So as of Feb 2015, this redmine project will also contain documentation on the "wf" suite.
- work_flow_ora (http://cdcvs.fnal.gov/cgi-bin/fnal-only/cvsweb.cgi/infra/work_flow/work_flow_ora/)
The oracle part is really 3 separate logical components:
1) Persistence of signature history. Who signed what, when; persisted for all time in our master MISCOMP database.
2) Person-in-role calculation (wf_role_lib). For certain Well-Known Roles (org-chart derived and/or system administrative roles), calculate who is in the role (and who else would be authorized to "put on the hat").
3) Proxy/hats. "Who may I be proxy for?" "Who may be proxy for me?" "Who is proxying for me?" "Put on the hat." "Take off the hat".
There are python "wrapper" scripts that provide python access to the Oracle packages:
- work_flow_api (http://cdcvs.fnal.gov/cgi-bin/fnal-only/cvsweb.cgi/infra/work_flow/work_flow_api/)
- alpha_flow_api (http://cdcvs.fnal.gov/cgi-bin/fnal-only/cvsweb.cgi/infra/alpha_flow/alpha_flow_api/)
And there is the "wf" electronic signature engine that provides the signing interface for any app that chooses to use it (currently only MISER and LEAVE_REQUEST):
There are two existing applications using the wf engine; the work_flow definitions for these two applications are:
- miser (http://cdcvs.fnal.gov/cgi-bin/fnal-only/cvsweb.cgi/infra/purchase_request/wf/miser_wf_def/)
- leave_request (http://cdcvs.fnal.gov/cgi-bin/fnal-only/cvsweb.cgi/infra/purchase_request/wf/leave_request_wf_def/)
Overview: An application has "items" that need to be signed. The application should:
a) define a WORK_FLOW (state machine, stored in the wf_db; see the miser_wf_def or leave_request_wf_def for example python code; uses the wf_def_loader utility to make it easier to load the work_flow definition into the wf db and make sure it follows all rules, etc.). [NB: no public interfaces for this within the WF application, anybody choosing to use the new WF engine will need to work directly with developers in order to load a new workflow definition into the database].
b) define a callback URL that can be used by the oracle WORK_FLOW code to retrieve the persons-in-roles for each work_flow_item. (The application is free to call the WORK_FLOW.WF_ROLE_LIB functions if needed to calculate WHO is in each role, but the application itself must know which roles are required).
c) define a VIEW url that can be used to VIEW the wf_item from the wf site when it is being signed (what the signer sees when signing the item)
d) OPTIONAL: define a callback URL that should be called when an item is signed as it moves through the work_flow.
A WF admin/developer will load the workflow state machine into the WF database.
An Oracle admin/developer will update the WORK_FLOW data so that Oracle knows when to call the new workflow state machine (start at https://appora-cert.fnal.gov/pls/cert/wf_maint_lib.html and go to the WORK_FLOWS link (right-hand side)).
Useful URLs to know about:
- Oracle Open WF Item report (what MISCOMP thinks is open): https://appora-cert.fnal.gov/work_flow_ora/www/open_wf_item_report.html
- WF open WF Item report (what the WF engine thinks it is working on): https://wf-prd.fnal.gov/wf/wf_items/
- Oracle WF utilities: https://appora-cert.fnal.gov/pls/cert/wf_maint_lib.html