Administrator Administrator [http://community.jboss.org/people/admin] modified the document: "JbpmMeetingTomHeikoJanuary2009" To view the document, visit: http://community.jboss.org/docs/DOC-13281 -------------------------------------------------------------- h3. Logging / History [ https://jira.jboss.org/jira/browse/JBPM-1994 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 h3. Database schema Analyse the DB schema Compatibility needs to be installed in the project h3. Database schema * Analyse the DB schema * Developmemt process for DB evolution [ https://jira.jboss.org/jira/browse/JBPM-1995 JBPM-1995] h3. Project Structure (add this to developer docs in wiki) h4. API package refactoring [ https://jira.jboss.org/jira/browse/JBPM-1997 JBPM-1997] * api    - the public api (client services, client, activity, eventlisteners)    - all other modules should have package names that include ..internal.. * config h4. Test suite consolidation [ https://jira.jboss.org/jira/browse/JBPM-1996 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 ? h3. Task management * assignment   - distinction between assignable user and groups [ https://jira.jboss.org/jira/browse/JBPM-1998 JBPM-1998] * context data * task definition   - add outcomes [ https://jira.jboss.org/jira/browse/JBPM-1999 JBPM-1999] * process integration    - variables    - signal execution upon completion    - provide outcome to signal mapping [ https://jira.jboss.org/jira/browse/JBPM-1999 JBPM-1999] * external presentation    - web form [ https://jira.jboss.org/jira/browse/JBPM-2000 JBPM-2000]    - email    - db record * reporting    - history https://jira.jboss.org/jira/browse/JBPM-1994 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 h3. 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 ?) h3. Roadmap *jBPM 4.0.0.Alpha2 (March 1st)* * identity spi [ https://jira.jboss.org/jira/browse/JBPM-1860 JBPM-1860] * integrate identity component [ https://jira.jboss.org/jira/browse/JBPM-1993 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)* h3. 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 h3. Links/Resources Work 2.0 Peter Fingar Orbeon NetKernel OrganisationalManagement (Meuhlen) http://in.relation.to/service/File/2994 http://in.relation.to/service/File/2994 -------------------------------------------------------------- Comment by going to Community [http://community.jboss.org/docs/DOC-13281] Create a new document in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]