Noteworthy Points - Einsight2

Notes on importing BPEL4WS 1.1 eInsight BPM supports BPEL4WS version 1.0, but you can still import BPEL files based on version 1.1. When the import wizard encounters a version 1.1 feature that cannot be translated into 1.0, a warning appears on the Confirmation page indicating which features could not be imported and also providing suggestions for how to implement those features with eInsight BPM. Any features that are not supported are discarded during the import process. Three features specifically need to be addressed when importing from BPEL4WS 1.1: Variables specified by “type” or “element” With BPEL4WS 1.1, the new syntax for defining variables uses three attributes: messagetype, type, and element. Only “messagetype” is supported in version 1.0. If “type” or “element” variables are used in the imported BPEL file, you need to create a WSDL object with a WSDL message that is based on the respective “type” or “element”. Then, in the Business Process Properties, modify the corresponding Business Process attribute to use the WSDL message. Event handlers With BPEL4WS 1.1, event handlers allow an event-based decision to be performed continually on a separate thread. In version 1.0, the event-based decision performs an activity once and either times out or completes the process successfully. To implement a similar functionality in eInsight BPM, use Timer Events and Message Events for the event-based decision. Because event-based decisions only perform the activity once, implement the event-based decision within a while loop. Implement the while loop within a flow so it can execute in parallel to the rest of the Business Process. Version 1.1 uses an eventHandler method, while version 1.0 uses a pick element. The syntax of an eventHandlers element is very similar to that of a pick element. If the original BPEL code is structured similar to the following: <process> ... <eventHandlers> ... ... activity <process> In the new BPEL 1.0 code after import, the elements in italics below are transferred as is. To simulate the eventHandlers functionality, you can add new controls, such as those in bold text below. <process> ...

... ... <sequence> <sequence> <while name=”While” condition=”getContainerData(‘EHControl’, ‘value’, ‘/value’)”> <sequence> ... ... <sequence> activity Figure 101 illustrates an example of this implementation.

Scopes with local variables or correlation sets In BPEL4WS 1.1, variables and correlation sets can be associated with scopes locally. Version 1.0 only supports global versions. If any local variables or correlation sets are used in the imported BPEL file, they need to be redefined as global elements, making sure to keep all names unique. Configuring Load Balancing 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. eInsight BPM’s load balancing algorithm automatically distributes processing across multiple engines; however, eInsight BPM cannot load balance correlated messages. Important: The File eWay is not designed to work in an eInsight BPM loadbalancing scenario. Using a File eWay will result in all instances being sent to one engine rather than being distributed. To configure load balancing 1 For each affected Business Process, enable persistence 2 In the Environment Explorer, right-click the application server and then click Properties. 3 In the eInsight Engine Configuration properties, do the following: Set the Persistence Mode property to Persist to Database - Multiple Engines. Set the Application Mode property to Multiple Engine. 4 Click OK. 5 Configure all eInsight Engines to share the same database. Configuring Failover When the Business Process is configured for load balancing, eInsight BPM's failover capabilities ensure throughput of running Business Process instances. When Business Process instances encounter an engine failure, eInsight BPM load balances those instances across all available engines. As with load balancing, eInsight BPM’s failover capabilities are limited to non-correlated messages.

To configure failover 1 In the Environment Explorer, right-click the application server and then click Properties. 2 In the eInsight Engine Configuration properties, set the Engine Expiry Interval property to register itself as alive frequently enough to meet the demands of your system. 3 In the eInsight 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. Note: 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. Implementing the BPIM API The BPIM API contains one class, BPInstanceManager, that encapsulates all the required methods to access and manage Business Process instances. BPInstanceManager is instantiated with the hostname, administrative port, username, password, and the name of the deployed .ear file containing the Business Processes to monitor. Suspending, resuming, or terminating a Business Process instance requires key information to identify the Business Process instance. The key information is accessed by a call to getBPInstances, which requires the Business Process name and retrieves all running Business Process instances. The result is a HashMap with one row; the key is the Business Process type ID and the value is a list of Business Process IDs. Use the Business Process type ID and one of the Business Process IDs to uniquely identify the target Business Process instance. You can then call suspendBPInstance, resumeBPInstance, or terminateBPInstance against the instance. The type ID and Business Process ID are also required to access container data for a Business Process instance, since the specific Business Process instance must be identified. Again, this is handled by a call to getBPInstances. You can retrieve the value as a String for a specific node in the container once you have the container name, part name, and the XPath to reach the node. Use the following methods to find the node in the container and to query its value in an iterative way (to traverse the container). getContainers - Provides all the currently available containers for a running Business Process. getParts - Provides all the parts within a container, which is the root node of the XPath. There can be any number of child nodes under a part and in any depth in the container node. The child nodes can be accessed by constructing an XPath with the part as the context root. getPointers - Returns pointers resulting from an XPath query on the part. A pointer XPath is the full path from part. getContainerData - Returns the value of the node reached by the XPath pointer in the form of a String. By combining these four methods, you can access a node in a container and read its value. A fifth method, setContainerData, sets the value for a specific node and provides write access to the container.