Weblogic Server provides runtime MBeans which provide information about the runtime state of its resources. The entry point for these MBeans are the MBeanServer Services. There are two Runtime MBeans, the DomainRuntimeServiceMBean, which is only available at the Administration Server and the RuntimeServiceMBean which is the entry point for WLS runtime MBeans for the current server. WLS runtime MBeans can provide information about the runtime state of WebLogic Server resources. An overview of the available Runtime MBeans can be found in the Weblogic Server MBean Reference. Sometimes it can be useful to retrieve data from these Runtime MBeans in a BPEL process. For example the name of the Weblogic domain, the machine or the managed server whereon the BPEL process is running.

Here is an example how you can retrieve the Weblogic Domain Name, Machine Name and Server Name whereon the BPEL instance is running.

Tweet
Read More...

Although FMW 11g is around for some time, there are still organizations running on SOA Suite 10g. So maybe this tip is still useful for some of you. When testing my not-yet-quite-finished BPEL processes on my local BPEL server i am not interested in the manage view when selecting a BPEL instance. What i need is the audit view of my BPEL process. Since most of the BPEL Console is based on JSP, you just have to find the right jsp-file in the container...

Tweet Read More...

When searching for an efficient way to de-duplicate elements in a BPEL process, i found several blogs and communities on the web showing examples how to use the XSL key and generate-id functions to extract unique elements. Only none of them explained the science behind the magic. Here a more elaborate explanation how the extraction of unique elements, based on a chosen combination of key elements, from a XML message works.

Tweet Read More...

In my current project the BPEL development team, wherein i participate, maintains and develops BPEL processes on 10g. The complexity of these processes are not the processes itself but merely the applied transformations in these processes which also contain custom XSL functions. Testing of the XSL transformations within the IDE (JDeveloper) therefore is in many cases not an option. Alternatively the whole service has to be deployed to a local installed BPEL server and tested by instantiating the service. The main disadvantage here is that BPEL keeps it XSL files in cache, even the XSL files which were re-deployed. So when testing a re-deployed service with modified XSL files, the results of the transformations are unchanged, simply because the 'old' version of the XSL files are still in memory. To load the modified XSL files in memory the BPEL server has to be re-started after each deployment. When having to go though multiple iterations of testing and therefore time-consuming restarts of the local BPEL server can be quite annoying.

Tweet Read More...

The fullWSAddressing partnerlink property is available in Oracle BPEL since 10.1.3.3. When set to true this property enables you to set the WSA addressing properties From, Action, To, and FaultTo, through the deployment descriptor parameters. After enabling the partnerlink property i have not been able to find any change in the deployment descriptors or web.xml to utilize the WSA headers and had to search for an alternative solution. The Web Services Adressing 1.0 recommendation also describes the ReplyTo, MessageID, RelatesTo, RelatesTo/@RelationshipType messaging addressing properties in addition to the previously mentioned headers, which are not made available through the fullWSAddressing partnerlink property. You can however make use of all WS Addressing properties when calling external webservices through a BPEL Partner Link. I will explain in a few steps how to build a BPEL process making use of WS Addressing without usage of the fullWSAddressing partnerlink property.

Tweet Read More...