As of this writing, there is one sample BPEL process that comes with the ActiveBPEL™ engine. This document comes from the README.txt file included with the sample code.
The samples/loan_approval directory contains the files that
make up the example loan approval BPEL process, two auxiliary Web services
upon which it depends, two command-line test clients, and a BPEL process
client JSP page. The loan approval process is the same as the one used in the
BPEL specification Business Process
Execution Language for Web Services Version 1.1.
The values sent to the BPEL process and returned by the assessor and approver are read from a configuration file. See The Config File below.
You must have a working ActiveBPEL engine. See Installing and Configuring the ActiveBPEL Engine.
You need Ant in order to run the targets in the build.xml
file. You could do everything manually, but the rest of this document
assumes you have Ant.
The environment variable CATALINA_HOME must be defined so the
Ant script knows where to deploy everything.
If your ActiveBPEL engine installation is not running on "localhost:8080", change that string in the three files containing it:
bpel_example_config.xmlbpel_process/wsdl/loanapprover.wsdlbpel_process/wsdl/loanassessor.wsdlFrom the command line, navigate to the directory
<installdir>/activebpel-version/
samples/loan_approval (where "version" is a version number like 0.9.5.
All subsequent commands will be run from this directory.
To deploy the BPEL process, type
ant deploy
If the ActiveBPEL engine is running, soon after you deploy your BPEL process the ActiveBPEL engine will notice the .bpr file and read it. Your BPEL process is ready to use.
See Starting the ActiveBPEL Engine for instructions on starting and stopping the engine.
The deploy target calls three other targets: deploy-bpel, deploy-ws, and deploy-jsp. deploy-bpel creates and installs a .bpr archive file that contains the BPEL process information. deploy-ws creates and installs a .bpr file that contains the Web services. deploy-jsp creates and installs a .wsr file that contains the JSP page and supporting classes.
The Web services don't need to be in a .bpr file to be deployed, but doing so lets the ActiveBPEL engine find the file and hand the Web services over to Axis (a SOAP implementation). Using a .bpr file is only a convenience that simplifies deployment. The Web services are independent of the ActiveBPEL engine.
There is a simple command line client that tests the "assessor" and "approver" Web services. These services are used by the BPEL loan approval process. The test client calls each Web service and compares the returned result with the expected value found in the config file. To run the test client, type
ant ws-test-client
(The Web services themselves are deployed by the target deploy-ws as discussed above. However, the target ws-test-client does NOT depend upon the deploy-ws target. Why not? Because things happens too fast: if you deploy the Web services then immediately use the client the server may not have time to notice and (re)initialize the Web services. You must use either the deploy-ws or deploy targets before running the test client.)
The output is similar to JUnit output; if all is well, you will see
.. OK 2 tests; 0 errors
If one fails you will see something like
E. assessor expected result "low" does not match returned result "foo" ERROR 2 tests; 1 error
The Web services are deployed inside a .bpr file, the archive format used for deploying BPEL processes. This is not necessary; it is only a convenience. The ActiveBPEL engine will "notice" the .bpr file and hand our Web services to the Axis SOAP implementation. The engine does not "know" about the Web services directory and does not use any shortcuts to call the Web services.
To run a command-line client that calls the BPEL process Web service, type
ant client
The client compares the value returned by the BPEL process with the config file value /rundata/bpel-expected-response and prints either an OK or an ERROR message.
As discussed above in Testing the Web Services, you must deploy everything before using this client.
Instead of running the command line clients, you can use the JSP page at http://localhost:8080/bpel_example_client_page/index.jsp. (Again, if your Tomcat installation is not running at localhost:8080, modify the URL accordingly.)
The page displays many of the values from the config file and lets you edit them. Clicking the "Apply for a Loan" button saves the values you entered to the deployed copy of the config file, sends the loan application request to the BPEL process, and displays the response.
The file bpel_example_config.xml contains values used by the test client, the two auxiliary Web services, and the Web services test client.
To deploy the config file manually, type
ant deploy-config
The Ant targets that compile the clients and deploy the Web services all make sure the config file is deployed.
In order to properly set the value /rundata/bpel-expected-response, you have to understand the example loan approval BPEL process. Here it is, in pseudo-code:
if (amount < 10000) {
if (assessor returns "low")
return "yes"
else
return approver response
}
else
return approver response
If the assessor Web service encounters an error, it returns "high". If the approver encounters an error, it returns "no".
Instances of RuntimeParams are
responsible for reading the config file. They do so in the constructor. This
means that each time a RuntimeParams object is created the config
file is re-parsed, allowing the config file changes to be recognized
immediately. For example, Web services create a RuntimeParams
object each time they are called. That means you can change the config file
and deploy it and the next time a Web service is called it will use the new
values.