Java Reference
In-Depth Information
The sendCustomerVerificationEmail method takes the customer's id and should send a notification.
We leave the functionality of actually sending the e-mail to the reader, but you can 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'll 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 triggers 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 we'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(
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 EL found in Java Server 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());
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:
Number customerId = (Number) executionService.getVariable(pi.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.
Search WWH ::

Custom Search