Administrator Administrator [
http://community.jboss.org/people/admin] modified the
document:
"jBPM3 Design Documentation"
To view the document, visit:
http://community.jboss.org/docs/DOC-15934
--------------------------------------------------------------
The purpose of this article is to gather design documents and diagrams together.
***
#Design_Diagrams Design Diagrams
****
#Product_Components Product Components
****
#Process_definition_and_instance Process definition and instance
****
#Node_hierarchy Node hierarchy
****
#Asynchronous_node Asynchronous node
****
#Timer Timer
***
#Project_Modules Project Modules
***
#Tooling_Interfaces Tooling Interfaces
****
#Graphical_process_designer Graphical process designer
****
#Web_console Web console
***
#Database Database
****
#Compatibility Compatibility
****
#Schema Schema
*****
#Definition_data Definition data
*****
#Execution_data Execution data
***
#API_Usage API Usage
****
#Starting_a_process_instance Starting a process instance
****
#Signaling_a_token Signaling a token
****
#Retrieving_a_task_list Retrieving a task list
***
#Test_Coverage Test Coverage
****
#Continuous_integration Continuous integration
****
#Areas_of_attention Areas of attention
h3. Design Diagrams
h4. Product Components
http://community.jboss.org/servlet/JiveServlet/showImage/102-15934-3-9952...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15934-3-...
h4. Process definition and instance
http://community.jboss.org/servlet/JiveServlet/showImage/102-15934-3-9971...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15934-3-...
h4. Node hierarchy
http://community.jboss.org/servlet/JiveServlet/showImage/102-15934-3-9973...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15934-3-...
h4. Asynchronous node
http://community.jboss.org/servlet/JiveServlet/showImage/102-15934-3-9974...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15934-3-...
h4. Timer
http://community.jboss.org/servlet/JiveServlet/showImage/102-15934-3-9972...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15934-3-...
h3. Project Modules
|| Module || Description ||
| core | Process engine codebase and the project test suite. |
| db | Database schema scripts for every version (since 3.2.2), plus the scripts to
generate the new jBPM DB schema scripts for every new version when it is being released.
|
| distribution | Product installer. The idea was that this installer would be the
interface between the project and the product. Instead, the SOA platform build does an
automated installation and then a script cherry picks files from the installation. |
| enterprise | Message and scheduler services based on JMS and EJB timers respectively.
Those services are not used in the product. Instead, the JCA inflow services are used.
|
| examples | Sample processes that ship with the product. |
| identity | Identity component containing the classes for users, groups and memberships.
|
| simulation | Process analysis and optimization tool donated by Camunda GmbH
(
http://www.camunda.com/). Not part of the product. |
| userguide | User guide in the docbook format. Note that these docs are decoupled from
the product docs. Changes must be propagated to the docs team separately. |
h3.
h3. Tooling Interfaces
h4. Graphical process designer
GPD depends on the file src/main/etc/version.info.xml in the distribution module. This
file contains the locations of the jar files that are needed to create a new project. The
tooling expects the following folder layout:
|| Directory || Contents ||
| lib | binaries and dependencies |
| src | source jars |
| config | configuration resources |
| examples | sample processes |
For deployment, a servlet that accepts process archives with file upload has to be
configured. This features was only added for usage during development. So after we found
out that this imposed a security problem, then we proposed to remove the servlet. But the
latest product decision was to secure the servlet.
h4. Web console
The console just uses the jBPM 3 API and libraries directly and it should be configured to
connect to a data source.
h3. Database
h4. Compatibility
jBPM uses Hibernate as ORM framework. This means that, theoretically, jBPM is compatible
with any Hibernate-compatible database (ie any database for which there exists a Hibernate
dialect). However, extensive compatibility testing is done on the databases which are
listed as certified databases for the SOA-P (and more).
jBPM is continuously evaluated with the relational database systems listed in
http://community.jboss.org/docs/DOC-13763 jBPM3 Platform Support.
h4. Schema
The following sections will discuss the jBPM schema. Refer to
http://community.jboss.org/docs/DOC-11086 Jbpm31DataModel for diagrams of the definition
and execution data models.
h5. Definition data
* JBPM_PROCESSDEFINITION: general process definition data (name, description, etc).
* JBPM_NODE: data about one node in the process definition. All node types will store
common data in this table.
* JBPM_TRANSITION: every record in this table represents one transition between two nodes
of the process definition.
* JBPM_EVENT: static data about events that are triggered during process execution.
* JBPM_ACTION: user code related to the process definition.
* JBPM_DELEGATION: information about user code that uses delegation classes.
* JBPM_EXCEPTIONHANDLER: information about exception handlers attached to certain process
definition scopes. Relates to JBPM_ACTION for the actual delegation to custom Java
exception handlers.
* JBPM_VARIABLEACCESS: stores the read/write and mapping information for variables when
variables are passed to for example subprocesses.
* JBPM_TASK: contains static information about tasks: task name, properties (blocking,
duedate, etc.), assignee expression.
* JBPM_MODULEDEFINITION: generic table that stores for example (a part of) a task
definition, a process definition start task, etc.
* JBPM_SWIMLANE: static description of a task swimlane. Contains an expression or a
reference to a delegation class for the actual assignment at runtime.
* JBPM_TASKCONTROLLER: Stores the reference to a user code delegation class that
implements task controller functionality.
* JBPM_ID_USER/GROUP/MEMBERSHIP: user/group data for the default identity component
h5. Execution data
* JBPM_PROCESSINSTANCE: general data about an execution of a process definition.
* JBPM_TOKEN: stores the actual pointers that indicate the current state of a process
instance. The jBPM model is based on a hierarchical tree of tokens. The
JBPM_PROCESSINSTANCE table refers to a so-called 'root-token' that is created when
the process instance is created. The tree of tokens can be constructed using this
token-rootToken-processInstance relationship.
* JBPM_VARIABLEINSTANCE: runtime data in the form of process variables are stored in this
table. Multiple columns such as 'datevalue_', 'longvalue_',
'stringvalue_', etc are used to store the actual variables depending on the
variable types.
* JBPM_BYTEARRAY/JBPM_BYTEBLOCK: tables used to store binary data (eg binary variables).
* JBPM_SWIMLANEINSTANCE: contains runtime evaluations of assignment
expressions/delegations.
* JBPM_TASKINSTANCE: runtime tasks (ie with a runtime actor and token reference).
* JBPM_POOLEDACTOR/JBPM_TASKACTORPOOL: when task assignment expressions resolve to a group
of actors (a so-called 'pool of actors'), the runtime evaluations are stored in
these two tables.
* JBPM_JOB: stores runtime job information that is used to execute jobs, and in particular
asynchronous continuations of process logic, by the job executor.
* JBPM_TIMER: timers are a specific type of jobs that are executable by the jBPM job
executor. However, timers need additional information such as 'transitionName'
(transition taken when te timer fires), the task to which the timer is attached to, etc.
All this extra runtime information is stored in this table.
* JBPM_LOG: generic table that contains all historical/audit data generated by the jBPM
engine. This table has quite some columns to store the different types of historical
events. At runtime, this table can get seriously big, and maintenance scripts should be
developed to keep performance decent.
h3. API Usage
h4. Starting a process instance
http://community.jboss.org/servlet/JiveServlet/showImage/102-15934-3-9968...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15934-3-...
h4. Signaling a token
http://community.jboss.org/servlet/JiveServlet/showImage/102-15934-3-9969...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15934-3-...
h4. Retrieving a task list
http://community.jboss.org/servlet/JiveServlet/showImage/102-15934-3-9970...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15934-3-...
h3. Test Coverage
h4. Continuous integration
The project leverages the
http://http://hudson.jboss.org/hudson/view/jBPM/ Hudson
installation maintained by JBoss QA. The codebase also provides scripts and configuration
files to set up a local Hudson server useful for troubleshooting purposes. Visit
http://community.jboss.org/docs/DOC-12865 jBPM3 Hudson Setup for a step-by-step guide.
h4. Areas of attention
From support cases, our experience is that only one set of tests is
lacking: Controlled concurrency testing. Though those are not easy to set up. This means
that we need to simulate in a controlled fashion optimistic locking exceptions. One test
thread should control multiple threads (at minimal 2), each performing some competing
operation on jBPM. For example, a signal and a timer that are performed on the same
token. Those then should lead to a hibernate optimistic locking exception and then a
rollback of one of those transactions. Depending on the DB implementation of locking,
deadlocks could arise as well. Analyzing which of those situations can occur and building
controlled tests for those is the next effort that should be done for jBPM to be able to
better support the product. Also the join behavior should get attention in this context.
Then these tests should be executed on all databases so that those different behaviors can
be analyzed and documented.
A significant amount of research is necessary to explore
this path. One direction we've been thinking about is using the java debugger
capabilities to achieve this. In that case, the unit test could pretend to be a debugging
tool that puts breakpoints and steers the execution in a controlled fashion to optimistic
locking exceptions.
--------------------------------------------------------------
Comment by going to Community
[
http://community.jboss.org/docs/DOC-15934]
Create a new document in jBPM at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]