setTitle functionality in 10g and 11g

For debugging purposes and more easily tracing issues on the middleware you may want to give your instances a name, or a title. This is possible by putting some code in BPEL to produce a title in the BPEL Console (10g) or the Fusion Middleware Control (11g), even for the SCA composites in 11g.

10g
In 10g (10.1.3.3.0) the following code with the setTitle function will work to produce a Name for the instances in the BPEL Console, resulting in the text "EMPLID" followed by the client:input value, which in this example would be the employee ID:

    <bpelx:exec name="Assign_Title" language="java" version="1.3">
<![CDATA[java.lang.String titleValue=null;                        
oracle.xml.parser.v2.XMLElement titleValueElement= (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable", "payload" , "/client:TesterProcessRequest/client:input");            
titleValue=titleValueElement.getText();        
setTitle("EMPLID " + titleValue);  
addAuditTrailEntry("EMPLID " + titleValue);]]>
</bpelx:exec>

11g
In 11g there is a comparable functionality with the function ora:setCompositeInstanceTitle("Hello World"); which can be used in for example an assign activity in the From statement and for the To variable a dummy could be used.


Other info
You can also do a direct update on the database level in the OraBPEL schema on the column "Title" in the CUBE_INSTANCE table (ORABPEL.CUBE_INSTANCE.TITLE). This works on 10g, I have not tried it on 11g. It's of course not recommended by Oracle.

Also note the following bug on Oracle support:
Bug 9953763 - SETTITLE FUNCTIONALITY IS MISSING IN INSTANCEHANDLE OF JAVA API

And I found this article to be rather interesting: http://technology.amis.nl/blog/2387/embedding-java-in-bpel-process

New features SOA Suite 11g

* Composite Applications
With a functional design on a logical level an application is one component. When building the application functionality is split up over multiple technical components, for example BPEL, Java, database or file adapters, business rules and human workflow. So complexity goes up and maintenance, build, test, etc goes up as well. By the way which SOA Suite 11g approaches composite applications using the SCA assembly model, complexity will not get out of hand, while retaining possibilities to easily reuse (previously created or out of the box supplied) assets.
* OER
Oracle Enterprise Repository will be getting more integrated as 11g matures.
* AIA PIPs
More PIPs will be created by Oracle or in conjuction with clients or third parties (like Capgemini).
* JCA
A JCA-based connectivity infrastructure will provide an embedded policy manager for security.
* Business rules
Business rules take a more important role in 11g. The 'Decide' activity is even replaced by the business rule activity. In the next release there will also be a webbased GUI for (business analysts) users to modify the business rules directly at runtime.
* SOA Fabric
In the coming releases a more integrated SOA Fabric will be introduced.

Dynamic endpoints in BPEL

On the Oracle website there is a good document that describes how you can make your BPEL projects to use Dynamic endpoints.

http://www.oracle.com/technology/pub/articles/bpel_cookbook/carey.html

It lacks a few things. One is a link to the WS-Addressing xsd, which you can of course find on http://schemas.xmlsoap.org/ws/2004/08/addressing/addressing.xsd

Also in this example cookbook it is hardcoded, which actually is the way not to do it since that is the whole point of making endpoints dynamic: so that on deployment to another environment your sourcecode does not need to be changed/recompiled. I am using a db adapter now myself with a response time of 69ms. As long as there is a low volume of transactions this should be fine.


Related version: 10.1.3.4.0

LOG files

There are multiple locations where you can find log files. See at the bottom of this post how to increase logging.

On the server there is a main directory under which most of the configuration, faultpolicy directory and log files are stored. For a Windows 2003 Server this could be:
c:\product\10.1.3.4\OracleAS\bpel\domains\default\
C:\product\10.1.3.1\OracleAS\bpel\system

Other logs are available here:

Webserver (apache) log:
C:\product\10.1.3.4\OracleAS\Apache\Apache\logs

OC4J log (java container):
C:\product\10.1.3.4\OracleAS\j2ee\oc4j_soa\log\oc4j_soa_default_group_1\oc4j

OPMN log:
C:\product\10.1.3.4\OracleAS\opmn\logs


To increase the logging some options in the BPELConsole can be modified:
Go to the BPELConsole - Configuration - Logging.
Standard almost all logging levels are set to INFO and some are on DEBUG.
DEBUG is the lowest level and produces the most logging information.

PLEASE NOTE Do not put everything on Debug!
If you set all options to DEBUG level you will risk crashing the server because of an extreme amount of logging data.

The most interesting options on which you can(should consider to) increase logging are the following 3:

default.collaxa.cube.activation = incoming queue/fileadapter logging
default.collaxa.cube.ws = outgoing messages when invoking adapters
default.collaxa.cube.xml = pickup messages and convert to xml data

Related version: 10.1.3.4.0

WSDL errors, Cannot figure out operation name. Bad SOAPAction or wsa:Action

If you get error messages like Cannot figure out operation name. Bad SOAPAction or wsa:Action or other strange things after you've changed something related to the WSDL then this might be a solution.
One of the possible error messages:

<env:Fault xmlns="http://xmlns.oracle.com/LeaveBalancePSProvABCSImpl">
  <faultcode xmlns="">null:LeaveBalancePSProvABCSImpl</faultcode>
  <faultstring xmlns="">Cannot figure out operation name. Bad SOAPAction or wsa:Action.</faultstring>
  <faultactor xmlns="">process</faultactor>
</env:Fault>

In our case we had modified the webservice LeaveBalancePSProvABCSImpl, which had 2 operations after a "get" was added next to the "process" operation and then we removed the process operation so we changed it back to only 1 operation (the "get"). The wsdl then is still cached somehow and even cleaning the cache through the BPELConsole does not fully work.

So, go to your DOMAIN directory on the Application Server (standard that is the 'default' domain), for example:
c:\product\10.1.3.4\OracleAS\bpel\domains\default and then under the \tmp\ directory, delete both references to your webservice.
You will need to stop all activities before deleting these temp files is possible (Oracle_AS\opmn\bin\opmnctl\opmnctl stopall)

Related version: 10.1.3.4.0

Available xpath functions

If you want to know the signature of a function, you can take a look at the xpath-functions.xml
This file can be found where your Application Server is installed. This has a list of all available functions and under which namespace each is registered.

For example on an MS Windows 2003 Server it could be C:\product\10.1.3.1\OracleAS\bpel\domains\default\ or under C:\product\10.1.3.4\OracleAS2\bpel\system\config

Change the title of the instances in the BPELConsole

To show a custom title in the BPELConsole it is possible to include in every .bpel process a piece of code.

Example:

<bpelx:exec name="Assign_Title" language="java" version="1.3">
  <![CDATA[java.lang.String titleValue=null;
oracle.xml.parser.v2.XMLElement titleValueElement= (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable", "payload" , "/client:TesterProcessRequest/client:input");
  titleValue=titleValueElement.getText();
  setTitle("Employee " + titleValue);
  addAuditTrailEntry("Employee " + titleValue);]]>
</bpelx:exec>

This code will result in a title starting with the text Employee followed by (concatenate) the value from the inputVariable, element input. In my case this will be the employee id.

Modifying the setTitle will improve tracebility. By doing a search on the text Employee and the id of the employee you want to find the performed data updates for, will result in a list of all instances with that title. A very useful change that I would advise to include in all BPEL processes as a Best Practice.