This page describes different use cases of jBPM in terms of scenarios.  Each scenario should be considered as an example to explain the use case and show how jBPM 4 can be used to support the use case.  This list of scenarios also will help us prioritize, focus and it might also serve to build out examples, demos or a set of screencasts later on.

This will help in demonstrating the value of jBPM in different concrete use cases.

Use cases showing a single functionality

Orchestrating Human Tasks

Prerequisites:

* Install distro
* Import examples project
* Server was started

Scenario:

* 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)
* Dynamically deploy process from designer
* In console start the process (with form)
* For each of the 2 tasks
   - log in as the task user
   - see task list
   - navigate to task form
   - complete task form
* Run through process execution by submitting task forms
* After completion, show report statistics (BI)

Who can help to come up with a good example process with only 2 human tasks and that the process and tasks are basically self-explaining ?

Orchestrating EJB's

This is basically Burr's demo he gave at JavaPolis 2 years ago.

Prerequisites:

* 3 existing EJB's all with one method that does a println

* They are deployed on a server

* The server is running

* jBPM is installed on that server

Scenario:

* build jPDL process that invokes the 3 ejb methods in sequence
* deploy the process
* run it

* show the ejbs were invoked in sequence

* go back to the process

* drag the transition end that connects the first with the second, and drop it on the last activity

* set the middle ejb activity aside and delete the transition that connects activity 2 to 3

* redeploy (includes automatic save)

* run the process again and show how easy the business logic was updated

Variations:

* show the same with 3 pojo methods in an enterprise environment.

* show how asynchronous continuations can be used to demarcate transactions

Transactional script

Use case:

A piece of automatic business logic needs to be executed.  But the execution should contain 'safe points'.  Which means that each step in the process should be executed in its own transaction.  If something happens later on, the process only needs to be restarted from the last 'safe point'.

Purpose:

* Show that jPDL allows for easy transaction demarcation

* Restarting after an exception happens automatically

Prerequisites:

* jBPM installed

* Server running

Scenario:

* 4 or 5 activities in a row

   * a pojo method invocation

   * an ejb method invocation

   * sending an email

   * updating a database with the sql activity

* show that the mailserver is not running

* start the process

* show how the pojo and ejb got executed in their own transaction

* show how the email transaction failed 3 times with incremental back off delay

* show how the job parked itself similar to a DLQ

* start the email server

* go to the console and find the job in error

* re-kick the execution

* now the email will be send and how the rest of the process is executed

Service orchestration

Purpose:

Interact with arbitrary services from a process.

The services may be described in WSDL, IDL or other description language.

Prerrequisites.

Take service description from WSDL, if available. See WSIF

Read inline service description

First priority: ESB invocation node.

Second priority Service publication

SEAM Pageflow

TODO

Competing consumers

TODO

Use cases showing other values

Business Intelligence

Purpose:

Show that by using a process to execute business logic, that you get the statistics for free.

Prerequisites:

* jBPM installed

* Process of average complexity

* Sample execution data

Scenario:

* Show the process and explain the steps

* Optionally step through an execution of the process.  Or maybe one scenario of a process execution.

* Then show the out-of-the-box statistics

jBPM Introduction Demo

Purpose:

Show how easy it is to get up and running with jBPM

Show how a combination of human tasks, POJO java code and service invocations can be orchestrated

Scenario:

* 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