Java4BPEL - Java Class extension activity for WSO2 BPS

java4bpel

java4bpel is an extension for Apache ODE and WSO2 BPS. java4bpel introduces new BPEL extension activity called invokeClass, which can be used to invoke a JAVA class.

Project home page

 http://hasithaa.github.io/java4bpel/

Project git location

https://github.com/hasithaa/java4bpel

User Guide 

https://github.com/hasithaa/java4bpel/wiki
 

Clone project from 

https://github.com/hasithaa/java4bpel.git

WSO2 BPS 3.2.0 - Performance Tuning - Know When, Why and How

• Following instructions are only applied to WSO2 BPS 3.2.0 . 
• All configuration files are located under $WSO2BPS-3.2.0_HOME/repository/conf/ directory

JDBC connections.

When ?

• When your application requires high throughput  

Why ?

• BPS server has two engines; Apache ODE BPEL processor and HumanTask engine. These two engines are tightly coupled with database layer. They persist every instance data into database. Thus to function BPS properly, you need to allocate enough database connections for BPS datasource.
• Both these engine share same BPS datasource and db connections. Thus generally we are recommending to allocate db connections 50-50 manner for a BPEL + HumanTask application.
• For example if you have total 100 db connections, for a BPEL + HumanTask application, you can use upto 50 db connections for ODE engine and leave the rest of the db connections for HumanTask operations.
• If you have only BPEL usecase, you can allocate many db connections ( see next topic) for ODE engine. 
• Also note that, even you have allocated higher number of db connections for BPS datasource, performance may not increase as excepted. One reason would be, there are no enough db sessions from database side. If that is the case, you need to increase number of db session from database side.  

How ?

• Configure BPS data source using datasources.properties file.
• eg: see highlighted section. 

 ...
 synapse.datasources.bpsds.validationQuery=SELECT 1 FROM DUAL
 synapse.datasources.bpsds.dsName=bpsds
 synapse.datasources.bpsds.maxActive=100
 synapse.datasources.bpsds.maxIdle=20
 synapse.datasources.bpsds.maxWait=10000

 

ODE Scheduler threads

When ?

•  When your application requires high throughput  

Why ?

• In ODE engine, every scheduler thread is associated with a db connection. So the rule of thumb is, number of ODE scheduler threads should be less than or equal to number of db connections allocated for ODE engine. Otherwise some threads may not work properly, because they can't acquire a db connections to work. 
• For example In BPEL + HumanTask scenario, if you have total 100 db connections, your can allocate 50 threads for ODE scheduler. This will grantee that at a given time, only 50 db connections are acquired by ODE engine.    

How ?

• Configure this via bps.xml.
• eg: 

    <tns:odeschedulerthreadpoolsize>50</tns:odeschedulerthreadpoolsize>

HTTP connections

When ?

• When your have lot of service invocations.(external or internal) 

Why ?

• When your BPEL processes do service invocations, they use http connections. By default this http connections are limited. Because of this, thread have to waits for http connections. 
• To avoid this, you can increase this value using Multithreaded Http Connection Manager Configuration. 
• If your processes do lot of service invocation to localhost ( or particular host), then it is required to increase maxConnectionsPerHost configuration as well.

How ?

•  enable this configuration using bps.xml

    <tns:MultithreadedHttpConnectionManagerConfig>
        <tns:maxconnectionsperhost value="350">
        <tns:maxtotalconnections value="400">
    </tns:maxtotalconnections>

 

TimeOuts 

When ?

•  When partner services take more time (slow) to response.

Why ?

• When partner services are slow or take more time to response, callee BPEL process's invoke activity fails due to message exchange timeout. By increasing time will avoid these kind of failures. 
• Also note that, slow partner services will slow entire BPEL process. This will cause to timeout the client application. ( callee of the BPEL process.). Thus it is required increase timeout interval for client application.      

How ?

• Via bps.xml and axis2.xml

Read for more information.
http://nandikajayawardana.blogspot.com/2012/10/how-to-increase-external-invocation.html

 

HumanTask Caching 

When ?

• When you have to deal with large user store.

Why ?

• HumanTasks are tightly coupled with users and user roles/groups. Because of this, BPS does lot of user store lookups for HumanTask operations. These user store calls can take considerable amount of time, if user store is large or located remotely. This causes to degrade performance of the entire HumanTask engine. Caching user and role lookup data at BPS side will reduce those remote user store calls and improve overall HumanTask engine's performance.  

How ?

• Enable HumanTask caching in humantask.xml
• eg: 

    <cacheconfiguration>
        <enablecaching>true</enablecaching>
    </cacheconfiguration>

 

Number of HumanTask Scheduler threads.

When ?

• When you are not using humantask deadline/escalation.

Why ?

• HumanTask deadline and escalation are scheduled tasks, which are executed by HumanTask scheduler. By default 50 threads are allocated for HumanTask scheduler. If you are not using deadline/escalations, you can configure this value to lower value such as 5. This will utilize idle threads in BPS server.
• Note that, you can't set this to 0, because humantask engine has several internal scheduled tasks to run.

How ?

• Configure this value in humantask.xml,
• eg:

    <schedulerconfig>
        <maxthreadpoolsize>5</maxthreadpoolsize>
    </schedulerconfig>

Recovering BPEL Activity Failures - WSO2 BPS

Read more about ODE activity failure and recovery from.

http://ode.apache.org/extensions/activity-failure-and-recovery.html

 

Method 1: Via WSO2 BPS Management Console 

In WSO2 BPS, BPEL failed activity recovery can be done using WSO2 BPS Management console.

To do this, it is required to enable ODE activityLifecycle events for a BPEL process. To do that modify process-event configuration in deploy.xml as follow.
(refer http://ode.apache.org/ode-execution-events.html for to see how you can enable ODE events for a BPEL process.)

Users can view activity failures for a BPEL process instance in the instance view page. 

1) Goto Instances -> click on of the instance ID to open the instance view for that instance.

 2) In the instance view, you can find failed activity/activities under activity informations. (See image). Also you can retry/cancel (ignore a failed activity) a failed activity using two buttons listed under Action column.

Method 2 - Via InstanceManagementService admin API

Also users can recover failed activities by using BPS InstanceManagementService. Unfortunately there is no UI functionality for this when ode events are disabled. (BPS 3.2.0 & older)


These are the steps, to retry activities using InstanceManagementService admin service.

1) Execute following SQL query on BPS database.

This will return the failed activities with corresponding BPEL process instance id. You will require following information to retry a failed activity.

• INSTANCE_ID
• ACTIVITY_ID

2) Set HideAdminServiceWSDLs configuration to false in /repository/conf/carbon.xml file.

eg:

3) Then start the BPS server.

4) Now create a SOAP-UI project using https://localhost:9443/services/InstanceManagementService?wsdl

5) Create a new request under recoverActivity operation. A sample request will be like this.


6) Then Authenticate soap-ui request by configuring authentication and security related settings.
For Basic Auth select Authorization type as preemptive, and give admin user name and password.

7) Then for each failed activity (results in step 1), send a recoverActivity request. Use "retry" action to retry activity, and use "cancel" action to cancel the activity retry and continue instance execution.

Working with SOAP Headers in BPEL - WSO2 BPS / Apache ODE

Most of the web services use soap headers to pass various kinds of information and it is required to manipulate those headers within a BPEL process when we are creating a complex business logic. Sometimes we have to deal with soap headers which aren't declared in the WSDL abstract message. These kind of headers are called Dynamic headers and both Apache ODE and WSO2 BPS can handle these type of soap headers.

For more information about header handling in Apache ODE, follow this article.

This post will show you how to handle soap headers, covering following scenarios,

1. Reading a soap header in request message.
2. Create a new soap header in a variable and assign a value to it.
3. Copying soap header from one variable to another.  

Sample BPEL Process

To demonstrate above scenarios let's consider this simple BPEL process. These are process's default request and response messages.


1. Reading SOAP Header in Request Message.

Let's read "echo" header from the input message and set its value into the process output message (to result element). To do this, add another copy into the Assign activity like this. Note that we are using "header" attribute to refer a soap header. (Resultant process's response is shown in response.xml)


2. Create a new soap Header in a variable and assign a value to it

Let's add new soap header called "echo2" in the output variable and assign request message text (input) value as new header value. First copy will create the echo2 header and second copy will do the value assigning. (Resultant response is shown in response.xml)

3. Copying soap header from one variable to another.  

Let's copy request message's echo header to output message. In the Assign activity define a copy as follow. (Resultant response is shown in response.xml)

BPEL - Extensions

Introduction

WS-BPEL 2.0 supports custom variable assignment mechanisms (Extensible Assign Operations) and user-defined activities (Extension Activities). To use these features, WS-BPEL provides two explicit extension constructs <extensionAssignOperation> and <extensionActivity>.

In order to use BPEL extensions, Extensions must be declared in the BPEL process model. It tells to the BPEL engine which extensions must be available and which are optional. Extension declaration can be done by adding an <extension …> element to the BPEL process model as follows.

<bpel:process...>

…

            <bpel:extensions>

            <bpel:extension namespace="#extension-namespace#"

                        mustUnderstand="#yes|no#"/>

<bpel:extension namespace="#another-extension-namespace#"

                        mustUnderstand="#yes|no#"/>     

            </bpel:extensions>

 ...

</bpel:process>

Extensible Assign Operations

Extensible Assign Operation allows including extensible data manipulation operations defined as extension elements under namespaces different from the WS-BPEL namespace. If the element contained within the extensionAssignOperation element is not recognized by the BPEL engine and is not subject to a mustUnderstand="yes" requirement from an extension declaration then the extensionAssignOperation operation MUST be ignored.

It is structured as follows.

<bpel:process...>

…

            <bpel:sequence>

...

<assign validate="yes|no"? standard-attributes>

            standard-elements

            <extensionAssignOperation>

                        assign-element-of-other-namespace

            </extensionAssignOperation>

</assign>

…

</bpel:sequence>

 ...

</bpel:process>

E4X expressions can be used in Extensible Assign Operations. Following code snippet will show you how to define an ExtensionAssignOperation using E4X expressions..

<bpel:assign name="AssignE4X">

<bpel:extensionAssignOperation>

<js:snippet xmlns:js="http://ode.apache.org/extensions/e4x">

E4X-expressions

</js:snippet>

</bpel:extensionAssignOperation>

</bpel:assign>

The snippet element declares the given extension namespace and it contains the E4X expressions.

Extension Activity

extensionActivity is a mechanism defined in WS-BPEL 2.0, that allows to define new activities, which are not defined by WS-BPEL 2.0 specification.  You can define new activity by placing them inside the <extensionActivity> element.

According to the Specification <extensionActivity> should have a single element, which is qualified with a namespace different from WS-BPEL namespace.  If the element contained within the <extensionActivity> element is not recognized by the WS-BPEL processor and is not subject to a mustUnderstand="yes" requirement from an extension declaration then the unknown activity MUST be treated as if it were an <empty> activity that has the standard-attributes and standard-elements of the unrecognized element; all its other attributes and child elements are ignored.  

(Read full BPEL specification about ExtensionActivity)

ExtenisionActivity structured as follows,

<bpel:process...>

…

            <bpel:sequence>

...

<extensionActivity>

<anyElementQName standard-attributes>

standard-elements

</anyElementQName>

</extensionActivity>

…

</bpel:sequence>

 ...

</bpel:process>

Remote debugging problem (Tomcat): "Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options"

 Hi all,

Today I tried to remotely debug the Apache ODE source using Apache Tomcat 7 and Intellij IDEA. If you are interested in remotely debug,  follow this tutorial http://isharapremadasa.blogspot.com/2011/09/how-to-debug-apache-ode-with-apache.html.

Problem:

I tried it in windows 7. But i was unable to halt the Tomcat's the catalina script at ODE deployment. So i tried to set following windows environment variables (given by IDEA, and modified as suspend=y) for JAVA_OPTS using, 

set JAVA_OPTS=%JAVA_OPTS% -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000

and then tried to run catalina script by running,

catalina.bat jpda run

Then I got this;

ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
Error occurred during initialization of VM
agent library failed to init: jdwp

Why ? and Solution

Then I googled about this problem and found the error: when i am going to define both JPDA and environment variables at ones, it cause to generate two instance of debugger and that is not possible. By removing one of them will solve the problem.

So I tried it again removing jpda parameter, and finally I was able to halt the catalina script without ODE deployment.


Notes:


JPDA stands for The Java Platform Debugger Architecture. which is a collection of APIs to debug Java code. (see http://en.wikipedia.org/wiki/JPDA )