The Environment represents the physical configuration of the Business Process Project. This section outlines how to create Environments for basic Business Process Projects and for Business Processes that include a user activity. In a production environment, the Java CAPS Environment is like to be more complex than the examples shown here. Once you create an Environment for BPM, you must configure the BPM Engine properties, located on the Properties window of the application server.
The components in a Project that contains a basic Business Process will vary depending on the external systems and other components used in the Project.
In NetBeans, click the Environment Explorer tab.
Right-click the Repository name and then click New Environment.
Name the Environment.
Right-click the Environment, point to New, and then click Logical Host.
Name the Logical Host.
Right-click the Logical Host, point to New, and then click the type of application server on which you are deploying.
Name and configure the application server.
Add and configure any necessary external systems to the Environment.
Configure the BPM Engine properties described in Configuring the BPM Engine.
Click Save All.
The components in a Project that contains a basic Business Process will vary depending on the external systems and other components used in the Project.
In the Environment Explorer, expand Environment1.
Right-click the Repository name and then click New Environment.
Name the Environment.
Right-click the Environment, point to New, and then click Logical Host.
Name the Logical Host.
Right-click the Logical Host, point to New, and then click the type of application server on which you are deploying.
Name and configure the application server.
Add and configure any necessary external systems to the Environment.
To access the Worklist Manager for task completion, you need to add and configure a Worklist Manager External System. If the user activity includes eVision web pages, you need to add an eVision External System as well.
Configure the Worklist Manager.
Configure the BPM Engine properties described in Configuring the BPM Engine.
Click Save All.
In BPM you can expose a Business Process as a web service and you can invoke web services from a Business Process. The Environment for each type of web service Business Process require different components.
The Properties window for the BPM Engine configures several aspects of the BPM Engine, including debugging, database connection, load balancing, failover and recovery, and so on. Table 1 lists and describes each property.
Table 1 BPM Engine Properties
Description |
|
---|---|
An indicator of whether the Business Process Debugger is enabled. This is not recommended for production environments because it impacts performance. |
|
The port on which the Business Process Debugger starts. |
|
An indicator of whether you are balancing processes across multiple BPM Engines. Select from the following options: |
|
The number of milliseconds to wait to process a message that has been placed in waiting. Messages are placed in waiting for various reasons, such as when the maximum number of concurrent instances is reached. |
|
An indicator of whether instance data is persisted to the monitoring and recovery database.
|
|
An indicator of whether data can be recovered to a previous state in case of failure. Persistence must be enabled in the Persistance Mode and Application Mode properties for recovery to be enabled. |
|
The number of seconds for the BPM Engine to wait to register itself as alive. For more information, see Configuring Failover. |
|
The elapsed time period before moving running Business Process instances from an unavailable engine to an available engine. This is used in conjunction with the Engine Expiry Interval property for configuring failover. |
|
The number of records to recover at one time. Sun does not recommend setting this higher than 100. |
|
The type and version of database you are using for monitoring and recovery. If you are using an Oracle 10g database, select Oracle 9i. |
|
The name of the machine on which the database resides. |
|
The port number on which the database is listening. |
|
The name for the connect descriptor (for Oracle databases only). This is the TNS name of the database, and is required to access the database using the OCI driver to access the database. If you are not using the OCI driver, leave this property blank. |
|
The name of the database. For Oracle, this is the SID name. |
|
The login ID for the monitoring and recovery database owner. The user name is defined in the database scripts you ran when creating the database tables (by default, bpm6user). |
|
The password for the monitoring and recovery database owner. The password is defined in the database scripts you ran when creating the database tables (by default, bpm6user). |
|
The maximum number of physical connections the pool should keep available at all times. 0 (zero) indicates that there is no maximum. The pool size depends on the transaction volume and response time. If the pool size is too big, you may end up with too many connections with the database. Sun recommends setting this no higher than 60. |
|
The number of retries to establish a connection with the database. |
|
The number of milliseconds to wait between each attempt to access the database. This property is used in conjunction with Database Connection Retries. |
|
The initial and minimum number of physical connections the pool should keep available at all times. 0 (zero) indicates that there should be no physical connections in the pool and the new connections should be created as needed. If the pool size is too small, you might experience longer connection times due to the existing number of physical connections. |
|
The maximum number of seconds that a physical connection will remain unused before it is closed. 0 (zero) indicates that there is no limit. |
|
Enables monitoring of Business Processes through the Enterprise Manager Monitor. If monitoring is enabled, persistence must also be enabled in the Application Mode and Persistence Mode properties. |
|
The time in milliseconds between transfers of data from the monitoring and recovery database tables to the Business Process reporting tables. |
|
The number of records at which the buffer contents is transferred to the database (if the thread buffer time lag is not expired). Monitoring data is collected in a memory buffer and is transferred to the monitoring tables based on either the buffer size or the buffer time lag, whichever occurs first. |
|
The time in seconds between transfers of data from the buffer to the monitoring table (if the buffer has not reached the thread buffer size). |
|
The time in milliseconds between transfers of data from the buffer to activity monitoring table. |
|
The maximum number of work items the BPM Engine can submit to the integration server at a given time for execution. A work item is an activity or group of activities in a Business Process submitted as a single unit of work to be run on an integration server thread. |
|
Specifies the percentage of the total Work Item Submit Limit threads that can be used for invoke activities, as opposed to other types of activities. Setting this ratio to 100% can cause a deadlock. |
|
Specifies whether database scripts will be run automatically. |
When a Business Process needs to be scaled to meet heavier processing needs, you can distribute the Business Process across multiple engines to increase throughput. BPM’s load balancing algorithm automatically distributes processing across multiple engines; however, BPM cannot load balance correlated messages.
The File Adapter is not designed to work in an BPM load-balancing scenario. Using a File Adapter will result in all instances being sent to one engine rather than being distributed.
For each affected Business Process, enable persistence.
In the Environment Explorer, right-click the application server and then click Properties.
In the BPM Engine Configuration properties, do the following:
Configure all BPM Engines to share the same database.
When the Business Process is configured for load balancing, BPM’s failover capabilities ensure throughput of running Business Process instances. When Business Process instances encounter an engine failure, BPM load balances those instances across all available engines. As with load balancing, BPM’s failover capabilities are limited to non-correlated messages.
In the Environment Explorer, right-click the application server and then click Properties.
In the BPM Engine Configuration properties, set the Engine Expiry Interval property to register itself as alive frequently enough to meet the demands of your system.
In the BPM Engine Configuration properties, set the Failover Grace Period property to the optimal elapsed time period before moving running Business Process instances from an unavailable engine to an available engine.
Optimizing these two property setting might require some testing. The Engine Expiry Interval property also applies to the interval for the recovery of dangling instances.