Working with OpenESB WLMSE

Overview Here we will attempt to create simple Application that demonstrate use of WLM Application. Before we begin, quick introduction to WLM is appropriate. WLM stands for Worklist Manager. It allows you to create Web Service Application that require human action/decision (one of pre-defined options) based upon some input data. So, in nutshell, the WLM application can be fed messages (predefined type) and exposes some API’s (can be used to build Web Interface) that allows assigned user’s to see the requests as list of tasks for some actions/decisions. The resulting choice of the user will be sent back as output message (again pre-defined type) to calling service. The service interface is defined using WSDL and the communication is Synchronous. WLM application can be best thought of means to incorporate human step in an automated process. For example, if you need to incorporate human approval step in you BPEL Process, you can achieve this using WLM Application. It also provide features such as Task Escalation, Notification etc. This is what we are going to do in this Helloworld Application. A WLM Application has three components: Please refer to Downloads for required components download Design Time You can use Netbeans (download page) with SOA Modules and create WLM Project type. Using worklist editor, you create task definition wherein the aspects about the task definition is specified. More on this later. Runtime The built project is deployed on Glassfish with JBI Runtime Environment. Project Open-ESB provides a Service Engine called sun-wlm-engine which provide runtime implementation for WLM Projects. Web Application The Users of the Task can log on to Web Console and...

Running Apache Camel in OpenESB – Part 2

In my previous post, I gave a step by step guide on running your first camel application in OpenESB. This entry is continuation to that it shows how to invoke an outbound JBI call from Camel. We will modify the same application to send message to a Glassfish’s JMS Queue instead of ActiveMQ’s queue. 1. To send a message to Glassfish’s Queue, we need a create JMS Binding WSDL Create a WSDL using the Wizard and select JMS Binding. Follow the wizard to provide a queue name, access details, etc. The WSDL should be created in CamelCompAppJBIModule1 project in default package. Choose the jbi2camel.xsd and select input element as msg:AnyMessage. Below is the types part and message part from the wsdl: <types> <xsd:schema targetNamespace="http://openesb.org/jbi2camel/CamelJBIModule1"> <xsd:import schemaLocation="jbi2camel.xsd" namespace="http://openesb.org/jbi2camel/message/CamelJBIModule1"/> </xsd:schema> </types> <message name="JMSInputMessage"> <part name="part1" element="msg:AnyMessag"/> </message> 2. Edit the jbi.xml in CamelCompAppJBIModule1 project to add the consumes element: <consumes service-name="JMSOutService" endpoint-name="jmsTestQueue_OutPort" interface-name="jms:JMSOutPortType" > </consumes> Make sure the service-name, endpoint-name, interface-name are the same ones from the newly created JMS wsdl. 3.  Edit the AppRouteBuilder.java as below:   public void configure() { String jbiJMSTestQueue = "jbi:http://j2ee.netbeans.org/wsdl/CamelJBIModule1/src/jmsTestQueue/JMSOutService/jmsTestQueue_OutPort"; //(A) String jbiURI = "jbi:http://openesb.org/jbi2camel/CamelJBIModule1/CamelJBIModule1_service/jbi2camel_endpoint"; //(B) from(jbiURI).process(new Processor() { //(C) public void process(Exchange exchng) throws Exception { Message inMessage = exchng.getIn(); String strInMsg = inMessage.getBody(String.class); System.out.println("Received in Processor : " + strInMsg); String strOutMsg = strInMsg.replace("My String", "MyReply"); exchng.getOut().setBody(strOutMsg); // (D) }}).to(jbiJMSTestQueue); //(E) } A) The variable “jbiJMSTestQueue” refers to the JMS WSDL’s endpoint. This URL is constructed by concatenating namespace, service name, port name. E). This line sends the message to the new JMS Queue. 4) Right click on Service Assembly node and “Clean” it....

Running Apache Camel in OpenESB

Introduction Apache Camel is a widely used java based integration framework. Apache camel’s strengh lies in its simple,light weight and modular approach as well as its easy-to-use implementation of Gregor Hoppe’s Enterprise Integration Patterns. It is also a very light weight framework that can also be easily embedded with other applications as a library. In Open ESB, we can utilise Camel for all its strength ranging from routing & mediation, to utilising the camel components which are missing in open esb, to integrating existing Camel applications with Open ESB. We now have a service engine called Camel SE which will act as a bridge between JBI and Camel technologies. By having a Service Engine for Apache Camel, OpenESB can utilize Apache camel by participating in message exchanges. This way we have both the technologies collaborating seamlessly. For example, HTTP BC can receive a message and can send it to Camel SE which can mediate, route, process the message, can invoke OpenESB’s JMS BC and can reply to HTTP BC. The following blog is a tutorial on how exactly we can achieve this. In this entry I will write a step by step guide on how to use the new Camel Service Engine to utilize Apache Camel in Open ESB. We will use OpenESB’s HTTP BC to receive http soap message, send it to Apache Active MQ’s queue, send it to Camel Processor and then reply to sender. You need to have both the runtime and design time modules of Camel SE to try this. Installing Runtime jar 1. Download the runtime service engine jar from here: http://hudson.openesb-dev.org:8080/hudson/job/openesb-components-git/lastSuccessfulBuild/artifact/dist/camelse.jar 2. Go to Servers...

Creating a Patient Web Service Provider

Creating a Patient Web Service Provider Written by Michael.Czapski@sun.com Updated By Mriganka Banerjee In the below document written by Michael Czapski, he demonstrates how we can write a patient webservice using OpenESB. This patient webservice will allow patient information to be upserted into a database table and will return all patient details for a patient whose Facility+Local ID are specified in the request. This service will be used to populate the patient table and to implement patient lookup portlets, discussed in other walkthroughs in this series. This is a basic Patient Service that hides the specifics of interaction with the patient data store form applications that need to interact with it, by providing a defined interface and web service-based implementation. Thus the data store may change but the service consumers need not. We use Database BC (select, insert, update, null values), SOAP/HTTP BC and BPEL SE.christmas inflatables Document link :...

“Unable to Locate Activated Endpoint” when reusing a common service

We have one EJB for sending email notifications. We did not use Email BC because we have to format the email and we did not want to do that in every BPEL. We have atleast 30 service assemblies using this EJB. Everytime we shutdown one of the service assemblies, this EJB stops working. We will not get email notifications. When we went through the logs we found that we are getting “Unable to locate activated endpoint” error. Usually this error occurs when the service is not deployed or not reachable. On Further investigation we were able to make out that when we shutdown any of the service assemblies which uses this EJB it affects all the others. We thought it is a bug with GlassFishESB. As a workaround, we had to restart all the service assemblies which uses this EJB. I wanted to fix this Bug. I wrote two service assemblies TestCA1 and TestCA2, and one CommonEJB. TestCA1 and TestCA2 will receive a http request, invoke the CommonEJB and return the string from CommonEJB. This is a plain echo service. For invoking this EJB from BPEL I need to have the WSDL of this EJB. So I used “Generate and Copy WSDL..” option to copy the WSDL into the BPEL folder. I was able to cleanly reproduce the problem. Everytime I shutdown TestBP1, TestBP2 was not working and vice versa. I turned the JBI logging to finest. And this is what I found when I shutdown TestCA1: [#|2012-02-14T19:33:41.322+0530|FINE|sun-appserver2.1|com.sun.jbi.messaging|_ThreadID=1015;_ThreadName=TestCA1-sun-http-binding;ClassName=com.sun.jbi.messaging.EndpointRegistry;MethodName=removeEndpoint;_RequestID=42f05924-ebc6-43ad-8a4d-539c8d910bf3;|Removed endpoint: http://test.logicoy.com/,CommonEJBService,CommonEJBPort|#] So it is clear that it is removing this endpoint from EndpointRegistry. But why does it remove this endpoint?...