Catching Expected And Unexpected Faults In BPEL

In BPELs in WebSphere Integration Developer we can catch exceptions – faults from a BPEL, like during an invoke for example.


What happens when we want to catch an exception that is not necessarily a fault and could stem from the underlying  system or the application behind the invoke(in the diagram it is InvokeSomeOperation)?

As you can see in the above excerpt of a BPEL, we have a known Fault called MyApplicationFault in the catch and then in the Catch All we deal with any unknown faults that are not MyApplicationFault and just exceptions that are not BPEL faults at all.

So if we have a NumberFormatException for example it will pass the MyApplicationFault catch and go the Catch All.

Now if we want to transform any exception that comes through in a BPEL exception that will be like a fault we can use an anonymous class in a snippet:


new BpelException(){


public String getFaultName() {

return “MyFaultName”;



public String getMessage() {

return caughtException.getMessage();




This way we can handle the exception elsewhere in the BPEL Process using: bpelexception =


logger.debug(“Fault Name” +


bpelexception.printStackTrace( System.out);

Throwable rootCause = bpelexception.getRootCause();


So the Catch All can accept normal java exceptions as well as BPEL faults Smile

Securing a BPEL in WebSphere Integration Developer 7 difference over WebSphere Integration 6


Hi, another day in the windy city Smile Today we look at how to add a role-based security to secure a BPEL.

In WebSphere Integration Developer(WID) 6 there was no direct way to add a role to a BPEL at assembly level.

In WID 7 we can assign a role to the whole BPEL this could not be done in WID 6. It makes security much easier.

All you have to do is open your assembly diagram as in our example project below:




Click anywhere on the assembly diagram. Then click Properties on the BPEL and then click All Qualifiers.

Expand ExtractionProcess. As you can see above the is Security Identity. Here you can place a security role:



There you have it the entire Process is secured. On deployment make sure that role is allocated to a user that should have access to the BPEL application:


That’s all there is to it! Enjoy Smile

LTPA Tokens For JAX-RPC and JAX-WS in IBM WebSphere Server Version 7. Client and Provider communication.


HAPPY NEW YEAR!!!! To all the followers of this blog. I changed jobs in the later half of last year 2011 and as a result neglected my blog. I hope to turn things around this year Smile

Today we are going to look at JAX-RPC and JAX-WS communication in IBM WebSphere Server 7.  We will look at communication using LTPA tokens and passing LTPA version 1 and LTPA version 2 tokens for authentication.

We will show how to setup the client bindings and provider bindings to enable this communication. This will be of particular importance when legacy applications for WebSphere 6 and earlier need to communicate with Websphere 7 clients.

This will revolve around Provider Policy Set Bindings and Client Policy Set Bindings .

In this article we assume that we have two applications the first is a legacy provider application from IBM WebSphere Server 6 that uses JAX-RPC, (we will call this application LegacyProviderApp1) and we have a new client application from IBM WebSphere Server 7 that uses JAX-WS.

Now LTPA tokens version 1 are compatible with JAX-RPC so here we will show how to setup a client binding that uses LTPA version 1 tokens as seen below:



Go to Services> Policy Sets> General client policy bindings> New:



From Add select WS-Security.  Under WS-Security we have various options:


We are interest in Authentication and protection. Note you will add the necessary information for Keys and certificates, Message expiration and Custom Properties according to your design specifications.

After clicking Authentication and protection we look at Authentication tokens:


Here we have created two Authentication tokens: gen_signltpaproptoken and gen_signltpatoken

gen_signltpatoken is configured as follows:


The Namespace URI ending with 5.0.2 is LTPA version 1 which is compatible with JAX-RPC.

Now if you want to ensure that only LTPA version 2 tokens are supported and accepted then select Token type>LTPA Token v2.0


The gen_signltpaproptoken is configured as follows:


We can actually setup multiple client bindings. So we can have two. One for LTPA version1 tokens and another for LTPA version 2 tokens.

Now we look at the setup of the provider.

Go to General provider policy set bindings>New and create a new binding:


Name it to LegacyProviderApp1Provider and then Add> WS-Security. Once again we are interest in Authentication and protection. Note you will add the necessary information for Keys and certificates, Caller, Message expiration and Custom Properties according to your design specifications.


Now click on Authentication and protection. Again we are interested only in Authentication tokens :



Click on con_ltpatoken (this means consumer Smile)


If you select LTPA Token v2.0 but you do not check Enforce token version. Then this provider will be able to generate tokens that are LTPA version 1 and LTPA version 2 compatible. This will also aid in JAX-RPC communication for applications designed under WebSphere 6 and below.

The details for con_ltpaproptoken are as follows:



There you have it we have setup Provider Bindings and Client Bindings that will enable communication using LTPA version 1 and version2  tokens. Smile