Projects:JBPM Integration/Functional Documentation

Contents 1 Overview 1.1 Purpose 1.2 Scope 1.2.1 Prototype 1.2.2 Basic Platform integration 1.2.3 Initial refactor of key processes 1.2.4 Completion of Platform integration 1.2.5 Refactor of all Openbravo processes 1.3 References 2 Design Considerations 2.1 Assumptions 2.2 Dependencies 2.3 Constraints 3 Glossary 4 Functional Requirements 4.1 User roles & profiles 4.2 Business process definition 4.3 User stories 4.3.1 Document approvals - signing authority 4.3.2 Document approvals - department or customer approval 4.3.3 Event-driven workflow 4.3.4 Workflow processes that can spawn other workflow processes 4.4 Functional requirements based on business processes 4.4.1 Data history 4.5 User Interface Mockups 5 Technical Requirements 6 Non-Functional Requirements 7 Open Discussion Items 8 Closed Discussion Items

Overview

JBoss jBPM is a flexible, extensible framework for process languages.

Purpose

The purpose of this project is double:

• first to enhance Openbravo platform so it is possible to define Openbravo business processes through jBPM. It aims as well to embed jBPM web console into Openbravo ERP user interface so it is possible for Openbravo users to interact with runtime tasks generated by jBPM process executions and administer/monitor runtime instances.
• second to refactor most of Openbravo business processes so they are by default implemented by jBPM definition and this way make it easier for consultants to adapt business logic to specific customer requirements

Scope

As described in the Purpose section the scope of this project is very wide. In order to deliver results in an iterative manner the project is split into at least five phases:

1. Prototype
2. Basic Platform integration
3. Initial refactor of key processes
4. Completion of Platform integration
5. Refactor of all Openbravo processes

Note: After completing the first planned phase: prototype the planning for the following steps needs to be re-examined depending on the experience gained in implementing the prototype.

Prototype

The planned deliverable for this phase is a module which can be deployed into current Openbravo ERP.

This module is intended as a simple prototype with no intention of continued maintenance or upgrade paths.

The prototype will demonstrate how an integration of a jBPM workflow with existing or new processes implemented as Openbravo ERP processes could look like.

This module should implement/demonstrate the following:

1. Include the jBPM engine (runtime) into the running Openbravo instance. More specifically include the parts shown as 'Embeddable' in the graphic shown in the jBPM userguide (Chapter 1. Introduction) .
2. Include the jBPM Web console into a window or popup callable from openbravo
   1. This inclusion will be very simple; Some window in openbravo will show the web console, no access control will be done at this stage.
   2. The purpose of the Web console is to provide an interface callable from openbravo to allow users to work this process instances, as well as allows process administrators to monitor/administrate processes.
3. Provide a simple fixed, hardcoded mapping of jBPM identities to Openbravo ERP users and roles to map jBPM actors to Openbravo users.
4. The prototype will include a single selected process: approval of a purchase order modeled as a jBPM workflow.
5. The workflow will be executed as an jBPM workflow utilizing/integrating the standard Openbravo ERP purchase order PL-process.
6. The definition of the workflow will be done using the standalone, eclipse-based jPDL designer application. No graph-based modeling of a workflow directly inside the ERP is intended at this stage.
7. The integration of the modeled jBPM workflow and the Openbravo ERP process will be hardcoded and not yet generalized for the prototype.

Basic Platform integration

Planned deliverables for this stage are proper integration of jBPM based workflows with the Openbravo ERP platform.

This basic integration is planned to include the following:

1. Configurable mapping of jBPM identities to Openbravo ERP users & roles
2. Proper integration of the JBPM web console into the Openbravo ERP user interface.
   1. This include a window where the web console will be embedded.
   2. With the current Openbravo ERP user interface, there will be no always visible area/widget to show i.e. the currently running / available process instances for a user.
3. Designing the integration of jBPM workflow state management and Openbravo ERP document states
   1. Example here is flexible definition of document states and which transitions are allowed and how they are mapped to the workflow.
4. Design a flexible calling convention to allow the execution of a workflow node to call an Openbravo ERP process (either DAL/java-based, or PL-based)
   1. This calling convention will likely include calling the process via the Quartz background process system already existing in Openbravo ERP.
   2. This needs to allow passing values in both directions workflow -> process implementation and back

Initial refactor of key processes

Deliverables are refactored versions of a number of selected existing Openbravo ERP processes so that they fit into a jBPM workflow.

Candidates for the processes might come from procurement, sales and project management. Or more general the processes dealing with documents.

Completion of Platform integration

In this phase the integration of jBPM into the Openbravo ERP platform should be completed.

At this stage the detailed steps or deliverables are hard to define so this proposes just some ideas and needs to be finalized during the project execution

1. Integration of the user interfaces needed by ERP users to achieve their daily activites regarding workflow.
   1. This could mean a customized widget which is always present on the ERP userinface for a user.
   2. One possible implementation could be a widget which can be placed onto the 'My Openbravo' custom page in the planned new Openbravo ERP UI.
   3. This would imply a dependency on the new user interface project
2. Another possible deliverable in this phase could be a perhaps simplified editor inside the ERP user interface to allow consusltants to directly define, modify or extend workflow definitions without resorting to an external, standalone process design tool.

Refactor of all Openbravo processes

This phase should extend the initial refactor of Openbravo ERP processes to all the available processes in ERP.

It needs to be defined if this phase should be postponed until all PL-based processes are moved to java/DAL-based processes which would include a dependency on the completion of a project to redo all PL-based processes with java/DAL.

References

1. jBPM homepage
2. jBPM Userguide - Chaper 1. Introduction

Design Considerations

Assumptions

Dependencies

Constraints

Glossary

Functional Requirements

User roles & profiles

Business process definition

User stories

Document approvals - signing authority

This is a common requirement, most usually for Purchase Order approvals.

1. Person 1 should be able to enter a PO and save it in Draft mode regardless of his or her signing authority
2. But if the PO is for a total amount greater than Person 1’s signing authority, Person 1 cannot ‘complete’ the PO.
3. Instead, Person 1’s supervisor “Person 2”, or even Person 2’s supervisor, must approve.
   1. Approval must come from the a person whose signing authority amount exceeds the amount of the PO
4. In some cases there are requirements that each person in the management structure up to and including the person with the correct signoff authority must approve the Document.

Document approvals - department or customer approval

This is a somewhat different requirement where specific individuals from specific business partners or organizations must sign off on a document before the document can be completed

Example of this is that there are certain kinds of sales orders that go through a round of review for approval by several third party companies / vendors who are involved with the contract this order pertains to.

1. Person 1 creates a sales order and saves it. The document type of the order specifies that approval is required from the vendors involved in this contract.
2. The system blocks direct completion of the order.
3. Approval requests are created to all involved vendors and the order is blocked for completion until they are received.
4. Once all approvals are received the order can be completed.

Event-driven workflow

After an sales order is processed and the goods are shipped a sales invoice should only be created in the event the customer confirm the reception of the delivery. A period reminder should be sent to the customer after the goods are ship until the confirmation is received.

1. Person 1 creates a sales in the system
2. No invoice can be created directly
3. When the goods shipments in processed in the system and periodic timer is started which fires every 7 days until cancelled
4. When the timer fires a reminder is sent to the customer to ask if the delivery has been received
5. In the event that a confirmation is received (either automatically via mail and directly entered into the system, or i.e. via phone and entered by an User) the order state is changed and the creation of an invoice is triggered

Workflow processes that can spawn other workflow processes

A sales order drives the creation and processing of several Purchase Orders to get inventory from multiple vendors to satisfy the order.

1. A sales order is created and the system checks if all inventory are in stock
2. If some inventory is not on stock the system creates the necessary purchase orders / Requisition
3. Per created PO / requisition a new workflow is spawned which manages / tracks its progress
4. The SO is put in a waiting state until the all necessary inventory is received.
5. The event triggered for this condition is linked to the corresponding state transition in the PO / requisition workflow.
6. At this point, the Sales Order is released for packaging and shipment, allocating the specific inventory items that were received via the related POs.
7. One consolidation shipment is therefore sent out to the customer

Functional requirements based on business processes

Data history

User Interface Mockups

Technical Requirements

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items

Category: Projects ERP