Logging / History [JBPM-1994]

• Transactional storage of the history of a process execution (not software logging)
• Do we have a good name for this ?
• Log pluggability is in place
• Basic pluggability infrastructure is in place
• TODO
• HistoryRecords generated during process execution need to be created
• HistoryRecords need to merge themselves into the History DB schema
• Schema for storing history information needs to be build
• Filtering the history storage should be based on features
• We should not place the burden on the users to link log filtering to the features that remain available

Database schema

Analyse the DB schema

Compatibility needs to be installed in the project

Database schema

* Analyse the DB schema
* Developmemt process for DB evolution [JBPM-1995]

Project Structure

(add this to developer docs in wiki)

API package refactoring [JBPM-1997]

* api
   - the public api (client services, client, activity, eventlisteners)
   - all other modules should have package names that include ..internal..

* config

Test suite consolidation [JBPM-1996]

* jpdl
   - parsing jpdl
   - jpdl activity impl
   - base jpdl test suite jpdl/src/test/java
   - base jpdl test suite should be able to access jpdl impl and pvm impl classes

* examples --> jpdl/src/test/examples
   - can be merged into jpdl module
   - works against public api and jpdl
   - part of test suite
   - included in docs
   - examples project in distro
   - compile time checking on api usage only

* test-db --> jpdl/src/test/examples/org/jbpm/examples/advanced
   - can be merged into jpdl module
   - more elaborate functional testing
   - works against public api and jpdl
   - part of test suite
   - compile time checking on api usage only

* task ?

Task management

* assignment

  - distinction between assignable user and groups [JBPM-1998]

* context data

* task definition

  - add outcomes [JBPM-1999]

* process integration
   - variables
   - signal execution upon completion

   - provide outcome to signal mapping [JBPM-1999]

* external presentation
   - web form [JBPM-2000]
   - email
   - db record

* reporting
   - history JBPM-1994
   - how was the workload in this department last month

* monitoring
   - e.g. notify me when the resource alloction in group x goes beyond 80%

* embedded / standalone

In scope for jBPM 4.0.0.GA

jPDL

* Environments in order of priority (installer, qa, docs)
       1) JBoss 5.0.0
       2) Tomcat latest
       3) JBoss 4.2.3
* Examples and test-db need to run with cactus on the target container
* Local EJB in scope
* Remote EJB out of scope

Logging / History

* Transactional storage of the history of a process execution (not software logging)
* Do we have a good name for this ?
* Log pluggability is in place
* Basic pluggability infrastructure is in place
* TODO
    o HistoryRecords generated during process execution need to be created
    o HistoryRecords need to merge themselves into the History DB schema
    o Schema for storing history information needs to be build

Console

* management
* task management
* process management
* reporting (strategical dashboard)
* monitoring (analythical dashboard)
* roles ?

Designer
*

Scenario 1
* Install distro
* Import examples project (done)
* Execute example test in eclipse (done)
* Create new process definition file with designer wizard (done)
   * Declare couple of variables
   * Create 2 human task activities
      - Generate task form with designer
      - Using variables declared in the process
      - Associate task form with task activity
        (this should be done automatically by using the designer task form generation)
   * Create esb service activity
      - ESB is assumed running and having a service
   * Create Include Java pojo
      - Write minimal PrintLn activity
* Start AS
    - the one you installed jbpm in
    - maybe installer can generate start-server.bat script in jbpm instsallation directory ?
* Dynamically deploy process from designer
    - might involve defining the process archive package
* In console start the process (with form)
* For each task,
   - log in as the task user
   - see task list
   - navigate to task form
   - complete task form
* Run through process execution by submitting task forms
* Show reports including this execution

optional extension:
* redeploy an update to the process

Scenario 2
* Burr's demo
* Existing: 3 Session EJB's with 1 method
* jPDL process orchestrates these 3 methods
* jPDL process gets updated and redeployed
* No redeployment of the ejbs
--> ejb invocation activity

Variation:

* show how 2 pojo methods

* in case you want to execute those asynchronous, show how this can be done with 2 MDBs

* show how this can be done easily in a process with 2 asynchronous continuations

* other variations: show how you can implement competing consumers with jpdl

BPMN

* api will be PVM based so process language and BPMN neutral
* jPDL will use bpmn terminology on a best effort basis
* jPDL 4 will drive the activity types and we'll select the BPMN
  symbol that matches the jPDL activity type
* the BPMN interpretation of the notational element that we pick must
  match exactly with the jpdl element.  if not, we need to clearly indicate
  grafically that notation is jPDL specific
* we'll also go over the most common BPMN elements and see if we
  can come up with meaningfull jPDL for all the elements.

Task Management

* basic task model

- task activity creates task when execution arrives.
- tasks can have a map of variables
- upon creations, optionally data is passed from the execution into the task scope
- users can complete tasks and provide data optionally
- a special piece of information that can be supplied with the task completion is the outcome
- the potential outcomes are stored in task definition
- the task activity will implement the task definition interface
- upon completion of a task, the execution signal and parameters need to be provided
- by default, the outcome will map to the signal and hence bind to the outgoing transition
- task data will be stored as process variables, same techniques apply as the process variable scoping
- a TaskHandler interface will have methods for all task-processexecution integration
     createTask(Execution)
     taskCompleted(Task)
- The default task handler will use the task outcome as the signal that is given on the execution.
- Custom task handlers can be specified to overwrite this default behaviour

* assignment

* sub tasks
   - dynamic
   - for grouping (3 out of 5) (with a certain outcome ?)

Roadmap

jBPM 4.0.0.Alpha2 (March 1st)

* identity spi [JBPM-1860]
* integrate identity component [JBPM-1993]
* introduce distinction between users and groups
* process definition attachments
* review console dao and compare with current process and execution service
* variable declaration in jpdl
* task form url and form type property (explain to heiko for review)

* installer with profiles for all target containers
* introduce console (process management)

jBPM 4.0.0.Beta1 (April 1st)

* get facelets generation work in jbpm 4 (beginning of iteration so that heiko could include this later in this iteration)
   no designer support yet
* alternative form generation can be prototyped

* define process archive packaging strategy
* define how to deploy process archives on the target containers
* task management and task forms
    - starting a process
       - associated to process definition
       - authorization ?
    - perform a task in the middle of the process
       - associated to task list
    - task assignment

jBPM 4.0.0.Beta2 (May 1st)

jBPM 4.0.0.CR1 (June 1st)

jBPM 4.0.0.GA (July 1st)

Ideas for jBPM 4 after GA

1) Migration Aspects
* DB schema
* jPDL process files
* custom activities
* user components using
    - client api
    - db schema
    - hibernate api / hql
* select 1 or 2 key customers and assist them with migration
    - leverage that knowledge in building migration
* set up infrastructure to capture knowledge that we build up: wiki page ?
* This effort can be started as of CR earliest
* Not a requirement to release 4.0.0.GA

2) Spring support
Task for a new hire ?

3) Logging / History
Filtering the history storage should be based on features
We should not place the burden on the users to link log filtering to the features that remain available

Links/Resources

Work 2.0 Peter Fingar
Orbeon
NetKernel
OrganisationalManagement (Meuhlen)
http://in.relation.to/service/File/2994