You understand the "why" behind business processes and have identified types of problems that might be well suited to this technology. Now, you want to understand how—after all, it all sounds so nebulous and abstract. How do you describe and speak about a workflow, exactly?

It turns out, happily, that you probably already know most of what you need to describe a workflow engine. This is part of why a workflow engine is so powerful—it formalizes and facilitates solutions you're already struggling to build in other technologies. In fact, when you draw an activity diagram, the result is likely directly translatable into a workflow. As you'll see, a lot of the constructs used to build a business process are familiar. We've discussed many of them in our discussions of Spring Integration and Spring Batch and of the map/reduce pattern with GridGain.

One metric by which you might judge an engine is how well it lets you express workflow patterns. The workflow patterns describe different idioms that you might apply to a pattern. All patterns ultimately are built out of any mixture of a few key concepts (see Table 23-2), many of which we've discussed in other chapters of this book, as with Spring Batch and Spring Integration.

You want to build a jBPM solution and need to know the simplest way to get the JARs. There are many supported workflows for jBPM, so it isn't clear where to begin for what role. For a business analyst, the path is different than for a programmer, whose task it will be to employ jBPM, not deploy it. You will need a few libraries first.

You can use jBPM as an API, rather than as a server or service. This integration is the most natural to a developer, but not, for example, to a business user. We'll use Maven to get the dependencies.

While we'll focus on embedding jBPM in this chapter, it's useful to see the other ways you can integrate jBPM into your architecture.

For this example, we're using a few libraries for AOP, transactions, the core Spring context, and, of course, jBPM itself.

If you're looking to find out more, read the documentation, and get the downloadable binaries for exploration, check out http://jboss.org/jbossjbpm/. There, you can find a lot of useful information.

Because we're looking to embed it, we'll simply use the libraries.

<dependency>
  <groupId>org.jbpm.jbpm4</groupId>
  <artifactId>jbpm-jpdl</artifactId>
  <version>4.3</version>
 </dependency>

<dependency>
  <groupId>javax.annotation</groupId>
  <artifactId>jsr250-api</artifactId>
  <version>1.0</version>
 </dependency>

<dependency>
  <groupId>commons-dbcp</groupId>
  <artifactId>commons-dbcp</artifactId>
  <version>1.2.1</version>
  <exclusions>
    <exclusion>
      <groupId>xerces</groupId>
      <artifactId>xercesImpl</artifactId>
    </exclusion>
  </exclusions>
 </dependency>

 <dependency>
  <groupId>xerces</groupId>
  <artifactId>xercesImpl</artifactId>
  <version>2.7.1</version>
 </dependency>

 <dependency>
  <groupId>commons-lang</groupId>
  <artifactId>commons-lang</artifactId>
  <version>2.2</version>
 </dependency>

 <dependency>
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <version>1.1</version>
 </dependency>

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-entitymanager</artifactId>
  <version>3.4.0.GA</version>
 </dependency>

 <dependency>
  <groupId>javax.persistence</groupId>
  <artifactId>persistence-api</artifactId>
  <version>1.0</version>
 </dependency>

<repository>
  <id>jboss</id>
  <url>http://repository.jboss.com/maven2/</url>
 </repository>

It's hard to find an exhaustive or conclusive list of supported databases for jBPM, but because it's built on Hibernate, you can expect it's going to work on the big-name databases: Oracle, SQL Server, MySQL, PostgreSQL, and so forth. In this example, we're using PostgreSQL 8.3.

<dependency>
   <groupId>postgresql</groupId>
   <artifactId>postgresql</artifactId>
   <version>8.3-603.jdbc3</version>
 </dependency>

You want to use jBPM 4 (the newest, and current, release at the time of this writing) but you've got a Spring-based architecture and want to make use of jBPM from within a Spring application context.

Earlier versions of Spring shipped with a custom bean for use with Spring (org.jbpm.pvm.internal.cfg.SpringConfiguration). Now, however, the initialization is so simple there's no real need, and the class has been removed. We'll create a factory for our jBPM configuration that can be reused across projects. The balance of the configuration is fairly boilerplate transaction management and Hibernate integration, with some caveats. Andries Inzé started the project to integrate Spring and jBPM, and so much of the great work here is because of his efforts, on top of the great work behind jBPM itself, of course.

There are many ways to use jBPM. One approach is to use it as a stand-alone process server, perhaps deployed using JBoss. This solution exposes a console into which you can deploy business processes and even test out the process and watch it move state forward. As it's written using Hibernate, it's not too difficult to get it working on JBoss's EJB environment. So, you might use it as a service. Indeed, JBoss itself supports deploying processes to a directory and loading those, with some configuration.

For our purposes, we want to flip that deployment on its head. We want to embed, rather than deploy to, jBPM, in the same way that we can use Spring to invert control for other things such as remote services, message driven POJOs, and the HibernateTemplate.

In this example, we'll host jBPM's services in the Spring context, just like we might any other Hibernate services. jBPM is, fundamentally, a runtime that stores its state and jobs in a database. It uses Hibernate as its persistence mechanism (though it may eventually move to a strict JPA–based model). When jBPM, with Hibernate, interacts with the database, it uses transactions and avails itself of many of the features that Hibernate provides to build a sophisticated object graph mapped to a database schema. Naturally, this isn't so bad, except that in order to use jBPM with other services inside of Spring, particularly ones that leverage transactions (other database resources, XA functionality including but not limited to JMS, other Hibernate models, and so forth), you need to exert control over jBPM's transactions. Otherwise, jBPM will commit and begin transactions independent of the Spring container's transaction lifecycle.

jBPM 4 is built cleanly, in such a way that delegating the life cycle of the system to another container (such as JBoss's microcontainer or Spring) is feasible. The jBPM 4 and Spring integration builds on top of this, providing a recipe for accessing key services that jBPM provides at runtime. This is the key to the integration. With jBPM available to your beans as just another bean in the container, you can leverage it just like you might a Hibernate session or a JMS queue connection. Similarly, you can hide its use behind service methods that you expose to your applications clients.

Imagine exposing a service method for creating customer entities. It might use Hibernate to save the new record to the database, use JMS to trigger integration with an external financial system the company uses, and use jBPM to start a business process for fulfillment. This is a very robust, well-rounded service. You can use the services like you might any other transactional service—confident that the containing transaction will envelope the transactions of the jBPM process.

We will build a simple application context that contains the common elements you'll need to start using jBPM in your application, and then see where you may want to customize the solution to your environment.

In the example for jBPM 4, we will build a solution that models a simple customer registration workflow. In so doing, you will get a feeling for how you would set up the example, as well as get a chance to see a (very simple) jBPM solution. The namespaces of the work we'll do will sit below com.apress.springrecipes.jbpm.jbpm4.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:tx="http://www.springframework.org/schema/tx" 

xmlns:p="http://www.springframework.org/schema/p"
        xmlns:util="http://www.springframework.org/schema/util" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:aop="http://www.springframework.org/schema/aop" 

xmlns:context="http://www.springframework.org/schema/context"
        xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">

                                ...

</beans>

<context:annotation-config />

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
p:location="jbpm4.properties" p:ignoreUnresolvablePlaceholders="true" />

<bean id="sessionFactory"
        class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean"
        p:dataSource-ref="dataSource"
        p:schemaUpdate="true">
                <property name="hibernateProperties">
                        <props>
                                <prop key="hibernate.dialect">${dataSource.dialect}</prop>
                                <prop key="hibernate.show_sql">true</prop>
                                <prop key="hibernate.hbm2ddl.auto">create-drop</prop>
                                <prop key="hibernate.jdbc.batch_size">20</prop>
                                <prop key="hibernate.show_sql">true</prop>
                                <prop key="hibernate.use_sql_comments">true</prop>
                        </props>
                </property>

<property name="mappingLocations">
                        <list>
                                <value>classpath:jbpm.execution.hbm.xml</value>
                                <value>classpath:jbpm.repository.hbm.xml</value>
                                <value>classpath:jbpm.task.hbm.xml</value>
                                <value>classpath:jbpm.history.hbm.xml</value>
                        </list>
                </property>
                <property name="annotatedClasses" ref="annotatedHibernateClasses" />
        </bean>

        <util:list id="annotatedHibernateClasses" />

hibernate.configFile=hibernate.cfg.xml
dataSource.password=sep
dataSource.username=sep
dataSource.databaseName=sep
dataSource.driverClassName=org.postgresql.Driver
dataSource.dialect=org.hibernate.dialect.PostgreSQLDialect
dataSource.serverName=sep
dataSource.url=jdbc:postgresql://${dataSource.serverName}/${dataSource.databaseName}
dataSource.properties=user=${dataSource.username};databaseName=${dataSource.databaseName};serverName=${dataSource.serverName};password=${dataSource.password}

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
                destroy-method="close" p:driverClassName="${dataSource.driverClassName}"
                p:username="${dataSource.username}" p:password="${dataSource.password}"
                p:url="${dataSource.url}" />

        <bean id="transactionManager"
                class="org.springframework.orm.hibernate3.HibernateTransactionManager"
                p:sessionFactory-ref="sessionFactory" />

<bean   id="hibernateTemplate"
                class="org.springframework.orm.hibernate3.HibernateTemplate"
                p:sessionFactory-ref="sessionFactory"  />

<bean id="processEngine" class="com.apress.springrecipes.jbpm.jbpm4.CustomSpringFactory">
        <property name="jbpmCfg" value="jbpm.cfg.xml"/>
    </bean>

package com.apress.springrecipes.jbpm.jbpm4;

import org.jbpm.api.ProcessEngine;
import org.jbpm.pvm.internal.cfg.ConfigurationImpl;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.FactoryBean;
import org.springframework.beans.factory.InitializingBean;

import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;


/**
 * A custom {@link org.springframework.beans.factory.BeanFactory} that we can
 * use to setup the {@link org.jbpm.api.ProcessEngine}. This is based on jBPM's {@link 

org.jbpm.pvm.internal.processengine.SpringHelper}.
 */
public class CustomSpringFactory implements FactoryBean, InitializingBean, 

ApplicationContextAware {
    private ApplicationContext applicationContext;
    private ProcessEngine processEngine;
    private String jbpmCfg;

    public void setJbpmCfg(final String jbpmCfg) {
        this.jbpmCfg = jbpmCfg;
    }

    @Override
    public Object getObject() throws Exception {
        return processEngine;
    }

    @Override
    public Class<?> getObjectType() {
        return ProcessEngine.class;
    }

    @Override
    public boolean isSingleton() {
        return true;
    }

@Override
    public void afterPropertiesSet() throws Exception {
        processEngine = new ConfigurationImpl().springInitiated(applicationContext).

setResource(jbpmCfg).buildProcessEngine();
    }

    @Override
    public void setApplicationContext(final ApplicationContext applicationContext)
        throws BeansException {
        this.applicationContext = applicationContext;
    }
}

<?xml version="1.0" encoding="UTF-8"?>
<jbpm-configuration>
    <import resource="jbpm.default.cfg.xml"/>
    <import resource="jbpm.jpdl.cfg.xml"/>
    <import resource="jbpm.identity.cfg.xml"/>
    <import resource="jbpm.tx.spring.cfg.xml"/>

    <process-engine-context>
        <repository-service/>
        <repository-cache/>
        <execution-service/>
        <history-service/>
        <management-service/>
        <identity-service/>
        <task-service/>
        <command-service>
            <retry-interceptor/>
            <environment-interceptor/>
            <spring-transaction-interceptor/>
        </command-service>
        <script-manager default-expression-language="juel" default-script-language="juel" 

read-contexts="execution, environment, process-engine, spring" write-context="">
            <script-language name="juel" factory="org.jbpm.pvm.internal.script.

JuelScriptEngineFactory"/>
        </script-manager>
        <id-generator/>
        <types resource="jbpm.variable.types.xml"/>
        <address-resolver/>
        <business-calendar>
            <monday hours="9:00-12:00 and 12:30-17:00"/>
            <tuesday hours="9:00-12:00 and 12:30-17:00"/>
            <wednesday hours="9:00-12:00 and 12:30-17:00"/>

<thursday hours="9:00-12:00 and 12:30-17:00"/>
            <friday hours="9:00-12:00 and 12:30-17:00"/>
            <holiday period="01/07/2008 - 31/08/2008"/>
        </business-calendar>
    </process-engine-context>
    <transaction-context>
        <repository-session/>
        <db-session/>
        <message-session/>
        <timer-session/>
        <history-session/>
        <hibernate-session current="true"/>
    </transaction-context>
</jbpm-configuration>

In the previous recipe, you configured Spring and jBPM, such that Spring's is successfully hosting jBPM. You set about writing a business process and now want to work with jBPM inside of your service code and to be able to delegate actions to Spring beans from within a business process.

Use Spring normally, injecting the services as you need them. For access within your business process, you can simply reference the services as you would any other process or environment variable in a business process. jBPM will expose beans using the jBPM expression language, and you can then just reference them by name.

In this recipe, we'll work through a simple example so you can see the pieces of a typical integration with Spring and jBPM. We've already laid the groundwork in the previous example. Here, we'll actually build a simple Java service that works with Spring to move the process state forward.

The use case is a user registration, like the one described in Figure 23-1.

There are four steps:

This is a simple use of a business process. It abstracts away the process of incorporating and processing a new Customer. Conceivably, the Customer object could have come from any number of channels: somebody sitting taking phone calls inputs them manually, the user self-subscribes to the system, in a batch process, and so on. All of these different channels can create and reuse this business process, though. When the processing for a new customer is standardized, the challenge becomes about surfacing the functionality for as many end users as possible.

Because the user could conceivably wait a few days or weeks (it's arbitrary) before checking the e-mail and clicking the confirm link, state needs to be maintained but not burden the system. jBPM, and indeed most workflow engines, passivate state for you, allowing a process to wait on external events (signals). Indeed, because you've decomposed your process into a series of isolated steps, each of which contributes to the larger goal while remaining independently useful, you get the best of both worlds: stateful processes and stateless scalability. The state of the global business process is maintained and is persistent throughout the state of customer's sign-up, but you get the benefits of not keeping things in memory when there's no progress in the business process, thus freeing up the memory to handle other requests.

To build our solution, we need to build a simple CustomerService class and configure it appropriately. We'll integrate jBPM and tailor transaction management for the CustomerService class. We'll also make our bean responsible for deploying the process definitions for us as the bean starts up, so that if they weren't already deployed, they will be.

The XML for the application context is stark and simple.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:tx="http://www.springframework.org/schema/tx" 

xmlns:p="http://www.springframework.org/schema/p"
       xmlns:util="http://www.springframework.org/schema/util" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-3.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-3.0.xsd

http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
                                                 ">
    <import resource="jbpm4-context.xml"/>

    <context:annotation-config/>

    <tx:advice id="txAdvice" transaction-manager="transactionManager">
        <tx:attributes>
            <tx:method propagation="REQUIRED" name="*"/>
        </tx:attributes>
    </tx:advice>

    <aop:config>
        <aop:advisor advice-ref="txAdvice" pointcut="execution(* 

com.apress.springrecipes..jbpm4.*.*(..))"/>
    </aop:config>

    <util:list id="annotatedHibernateClasses">
        <value>com.apress.springrecipes.jbpm.jbpm4.customers.Customer</value>
    </util:list>

    <bean id="customerService" class="com.apress.springrecipes.jbpm.jbpm4.customers.

CustomerServiceImpl">
        <property name="processDefinitions">
            <list>
                <value>/process-definitions/RegisterCustomer.jpdl.xml</value>
            </list>
        </property>
    </bean>
</beans>

The first few elements are familiar: we set up the AOP–based transaction management and apply it to the services deployed under the jbpm4 package in our solution. Next, we override the List bean (with id annotatedHibernateClasses) that we created for the last recipe (jbpm4-context.xml) to provide the session factory with a collection of annotated entities, here, the Customer entity. Finally, we have a bean to handle the customerService bean. This bean leverages Hibernate (through the HibernateTemplate instance) to handle persistence, and it leverages jBPM (through the SpringConfiguration instance) to handle BPM. We provide the customerService bean with a list of business processes we want to ensure are deployed, which the bean handles as part of its duties in its post-initialization phase (the method annotated with @PostConstruct will be run after the bean's been configured to let the user inject custom initialization logic). In this case, we're deploying only one business process. Note that the business process file's name needs to end in jpdl.xml; otherwise, jBPM won't deploy it. The customerService bean is an implementation of the interface CustomerService, whose definition is as follows:

package com.apress.springrecipes.jbpm.jbpm4.customers;

public interface CustomerService {

        void sendWelcomeEmail(Long customerId);

        void deauthorizeCustomer(Long customerId);

        void authorizeCustomer(Long customerId);

        Customer getCustomerById(Long customerId);

        Customer createCustomer(String email, String password, String firstName, 

String lastName);

        void sendCustomerVerificationEmail(Long customerId);
}

The interface is trivial and only provides creation and mutation services for a Customer record. The implementation is where we see all the pieces come together.

package com.apress.springrecipes.jbpm.jbpm4.customers;

CustomerServiceImpl is a simple class. At the top, we've injected three dependencies: springConfiguration (which doesn't get used, though its configuration is worth noting because you may use it to access other services), repositoryService, and executionService. The class provides a few salient methods (some of which are required by its interface, CustomerService):

In the bean, setupProcessDefinitions is run when the bean is created. It iterates through the processDefinitions collection and deploys the resource whose path it is given. If you monitor the logs, you'll witness SQL being issued against the database, creating the runtime structure of your process definition inside the database.

You've built a service that uses jBPM to create a working service. We've seen how jBPM is configured, and we've even built a service for a business requirement (the sign-up of customers). The last element that remains is the process definition itself. What does a business process definition look like? How does a process definition reference Spring beans?

We'll build a process definition that codifies the steps diagrammed in Figure 23-1 at the beginning of the chapter. This process definition will reference Spring beans using the JBoss expression language. Finally, we'll walk through how the business process uses our customerService bean and how the customerService bean uses the business process to handle the customer's sign-up.

Let's examine the business process itself (RegisterCustomer.jpdl.xml). In jBPM, a business process is built using jPDL. You can use the Eclipse plug-in to model jBPM processes, but the jPDL schema is so simple that you don't really need it. This is not like BPEL where it can become all but intolerably complicated to write the code by hand. What follows is the XML for the business process:

<?xml version="1.0" encoding="UTF-8"?>
<process name="RegisterCustomer" xmlns="http://jbpm.org/4.0/jpdl">

        <start>
                <transition to="send-verification-email" />
        </start>

        <java name="send-verification-email" expr="#{customerService}"
                method="sendCustomerVerificationEmail">
                <arg> <object expr="#{customerId}" /> </arg>
                <transition to="confirm-receipt-of-verification-email" />
        </java>

        <state name="confirm-receipt-of-verification-email">
                <transition to="send-welcome-email" />
        </state>

        <java name="send-welcome-email"
                        expr="#{customerService}" method="sendWelcomeEmail">
                <arg> <object expr="#{customerId}" /> </arg>
        </java>

</process>

In the customerService bean, a client will use createCustomer to create a customer record. In a real-world example, you might imagine exposing these services as a SOAP endpoint to be consumed by various clients, such as a web application or other business applications. You can imagine it being called as a result of a successful form on a web site. When it executes, it creates a new Customer object and uses Hibernate to persist it. Inside the createCustomer method, we use jBPM to start the business process to track the Customer. This is done with the startProcessInstanceByKey method. In the invocation, we give jBPM variables through a Map<String,Object> instance (acting as something of a context for the process variables). Those variables are accessible inside the business process as Expression Language expressions and allow you to parameterize the business process in much the same way you might parameterize a macro or a Java method. We give the process instance a custom business key, instead of letting it generate its own.

executionService.startProcessInstanceByKey(
        REGISTER_CUSTOMER_PROCESS_KEY, vars, Long.toString(customer.getId()));

The last parameter is the key. Here, we're using the String ID of the customer as the key. This makes it easy to find the process instance later, though you could also query for the process instance, predicating on process variables that, taken together, should make the process instance unique. You might also query by roles or users assigned to certain tasks, or simply note the ID of the business process itself in your domain model and reference that later when looking up the process instance. Here, we know that there's only ever going to be one sign-up process for a customer, so we key it with a valid ID that will work only once: the Customer's id value.

When the process starts, it will start executing the steps in your process definition. First, it will go to the <start> element. It will evaluate the one transition it has and proceed through that transition to the next step, send-verification-email.

Once in the java element named send-verification-email, jBPM will invoke the method sendCustomerVerificationEmail on the customerService bean in Spring. It uses an Expression Language construct to reference the Spring bean by name:

<java name="send-verification-email"
        expr="#{customerService}"
        method="sendCustomerVerificationEmail">
        ...
</java>

The sendCustomerVerificationEmail method takes the customer's ID and sends a notification. We leave the functionality of actually sending the e-mail to you—just imagine a unique, hashed link being generated and embedded in the body of the e-mail that lets the server trace the request back to a customer.

Once the process has left the send-verification-email java element, it'll proceed to confirm-receipt-of-verification-email state, where it will wait indefinitely before proceeding. This is called a wait state. An external event is needed to tell it to proceed. In our scenario, this event will come when the user clicks on the link in the e-mail, which, for the sake of the demonstration, will trigger the invocation of the authorizeCustomer method on our customerService bean. This method expects a customer ID as a parameter.

Inside authorizeCustomer, the service queries the server for the any processes waiting at the confirm-receipt-of-verification-email state and having this customer's ID. We know that there's only one instance of this process, but the query returns a collection of Execution instances. We then iterate through the collection, signaling (with the Execution instance's signalExecutionById method) the transition from a wait state to the next state. When a node in jBPM moves from one to another, it takes a transition. As you've seen before, it does so implicitly. Here, however, in the wait state, we have to explicitly tell it to take a transition to signal that it can proceed to the next node.

for (Execution execution : executions) {
                Execution subExecution = execution.findActiveExecutionIn(
                        "confirm-receipt-of-verification-email");
                executionService.signalExecutionById(subExecution.getId());
        }

The authorizeCustomer method also updates the Customer entity, marking it as authorized.

From there, execution proceeds to the send-welcome-email java element. As before, the java element will be used to invoke a method on the customerService bean. This time, it will invoke sendWelcomeEmail to send the newly registered Customer a welcome e-mail.

The name of the process (what we use when we call startProcessInstanceByKey) is in the process element. Here, that name is RegisterCustomer.

Many of the expressions are in the JBoss expression language, which works very similarly to the unified Expression Language (EL) found in JavaServer Faces, or the Spring EL. You can use the EL here to reference parameters to the process.

You'll recall that when we invoked the service method for createCustomer, it, in turn, kicked off a business process whose progression the rest of the code followed. We use a Map<String,Object> to parameterize the business process. In this case, our Map<String,Object> was called vars.

Map<String, Object> vars = new HashMap<String, Object>();
    vars.put("customerId", customer.getId());
    executionService.startProcessInstanceByKey(
     REGISTER_CUSTOMER_PROCESS_KEY,
     vars,
     Long.toString(customer.getId()));

From within the running process, you can access the parameters from Java or as an EL expression. To access the parameter using the EL, use something like: #{customerId}. To access the parameter from Java code at runtime, use the following:

Number customerId = (Number) executionService.getVariable(subExecution.getId(), 

"customerId") ;

At this point, you've got a working business process that lives inside of a Spring context, and you've got a working grasp of the constructs required to build a process.