Go to page:
Prev 1 2 3 4 5 6 7 8 9 10 11 12 13 Next
Debugging
The debug view of a process instance (accessible via the Debug tag) shows the BPEL source code. Clicking on the underlined variable names provides access to variable content. We can debug already completed instances or instances that are still running; this is called in-flight debugging. The debug view shows the current state of the instance. If we use in-flight debugging, the point where execution is paused is shown highlighted. The following figure shows the debug view of our process instance, once completed:
(continued)
(Full Size Image)
Clicking on the TravelResponse variable, for example, gives us the following output:
Overview of Other Console Functions
Using the BPEL Processes tab we can manage the process lifecycle and process state. The state of a process can be on or off. When the state of a process is off, new instances cannot be created and access to existing instances is blocked. The lifecycle of a process can be active or retired. When a process is retired, new instances cannot be created. Existing instances can, however, complete normally. We can also get configuration data, WSDL and endpoint locations, and a source view.
Under the Instances tab we can overview process instances. We can archive and purge instances, remove completed process instances, and supervise those that have not completed yet. A BPEL process instance can have the following states:
- Running
- Completed
- Canceled
- Stale
Under the Activities tab we can locate activities by name and find relations to instances and processes. An activity can also have four states: open, completed, canceled, or stale.
Deploying Processes
We have already mentioned that new processes can be deployed using BPEL Console. To do this we first have to generate the process JAR archive (using bpelc or obant). We then click the Deploy New Processes link on the Dashboard or BPEL Processes tabs. We then specify the full path to the process JAR archive and press the Deploy button, as shown on the screenshot below:
>
Management
BPEL Console also provides tools for BPEL domain management. These can be accessed by pressing the Manage BPEL Domain link in the upper right corner of the screen, which shows the following screen:
(Full Size Image)
The management console has the following important options:
- Configuration descriptor
- Setting the password
- Setting the logging configuration (trace)
- Thread allocation statistic
- Runtime performance statistic
- List of XPath extension functions
The configuration descriptor enables us to set various important parameters that affect the BPEL Server operation. These parameters include:
- Process instance stale check interval (specified in seconds)
- Allocation of invocation threads and load factor
- Instance cache size (minimum and maximum)
- Persistence and database parameters
- Recovery agent settings
- Audit trail and other settings
We can also set a parameter that defines the behavior of the server when performing the <assign> activity. This parameter is called Relax BPEL4WS1.1 spec assign rules. BPEL specification sets certain rules by assignments (discussed in Chapter 3). For example, null assignments are not allowed by default. If these rules are too restrictive for us, we can change the behavior by setting this parameter to true. However, doing this is not recommended because it can hinder portability of BPEL processes. The default value of this parameter is false.
Performance Tuning
The afore mentioned parameters on stale check, threads and load factor, cache size, etc. affect the performance of the Oracle BPEL Server. Together with the runtime performance statistic (Stats tab) and thread allocation statistic (Threads tab), they can be used to tune the performance. The runtime performance statistics provide comprehensive data about the execution time of processes and a breakdown of times by activities, as shown in the following screenshot:
(Full Size Image)
The thread allocation statistics provide information on the usage of threads and their allocation, and on the number of requests on BPEL processes, as shown in the next screenshot:
(Full Size Image)
When creating a BPEL process test instance, the Oracle BPEL Server provides an option through which we can perform stress tests. Stress tests enable us to monitor the performance and to do load testing of processes. With the performance statistic we can identify the possible bottlenecks and optimize the performance. To perform a stress test we simply select the Perform stress test option as shown in the following screenshot. We then have to specify the number of concurrent threads allocated to the process, number of loops for the test, and the delay between invocations. We also have to select whether to clear statistics before running the stress test. This way we can identify the most appropriate number of threads:
(Full Size Image)
Note that the default download edition of Oracle BPEL Process Manager on Windows platform bundles Oracle Lite as the database, which will not yield meaningful results for a stress test. The BPEL Server should be configured to use a production-quality database (Oracle, SQL Server, or DB2) before doing stress testing. A technical note on http://otn.oracle.com/bpel describes how to configure the Oracle BPEL Process Manager for a database server other than Oracle Lite.
Go to page:
Prev 1 2 3 4 5 6 7 8 9 10 11 12 13 Next
IE 7
Firefox 2.0
