Getting and Setting JMS Header Properties - SOA 11G

Hi Guys,

Sometimes there is requirement where you are required to set some JMS header values and then send the jms message to the client or consumer may interact with you via jms queue and sends some user defined properties in the JMS header.In BPEL 11G, we can easily set or retreive these values.

Setting JMS Header Values

Step1: Click on the invoke activity inside your BPEL process that is calling your JMS adapter for publishing messages in the jms queue.Then click on the source tab of BPEL.

Step2: Inside the invoke activity code add this property <bpelx:inputProperty name="jca.jms.JMSProperty.propertyname" variable="variablename"/>
where propertyname: name of the property you want to set and variablename: variable from which you are passing value to this property.For instance,in out usecase I am setting following properties:

      <bpelx:inputProperty name="jca.jms.JMSProperty.MSG_ID" variable="TransID"/>
      <bpelx:inputProperty name="jca.jms.JMSProperty.FROM_SYSTEM" variable="FROM_SYSTEM"/>   
      <bpelx:inputProperty name="jca.jms.JMSProperty.ServiceName" variable="ServiceName"/>
Make sure you populate all these properties before calling invoke activity,otherwise these properties will contain null/blank values.

Step3: Deploy and test your code.Verify that these values are getting set by looking into the flow trace of your composite.

Step4: Also,you can verify the message in jms queue as well and see if the properties are properly set or not.

Getting JMS Header Values

Step5:Inside your BPEL process,click on the receive activity that is receiving input from the jms adapter and click on source.

Step6: Add this property inside your receive activity: <bpelx:outputProperty name="jca.jms.JMSProperty.propertyname" variable="variablename"/>. It is same as we did for setting the property except the outputProperty tag.In my example, I am retreiving the value of jms header that I set previously.

      <bpelx:outputProperty name="jca.jms.JMSProperty.MSG_ID" variable="TransID"/>
      <bpelx:outputProperty name="jca.jms.JMSProperty.FROM_SYSTEM" variable="FROM_SYSTEM"/>   
      <bpelx:outputProperty name="jca.jms.JMSProperty.ServiceName" variable="ServiceName"/>
     
Create the variables that will store the values of these properties.

Step7: Deploy your code and test your composite.Inside flow trace verify you are able to retreive the jms properties headers value from the JMS message.

In this way you guys can set and get the header properties of any JMS message in SOA 11G.Apart from accessing these values from BPEL,you can also access these values from Mediator.In mediator, they are accessed in the assign step using:

Inbound: $in.property.jca.jms.JMSProperty.<propertyname>
Outbound: $out.property.jca.jms.JMSProperty.<propertyname>

Hope this post of some help to you.

Happy Learning,
Cheers !!!

Difference between BPEL 1.1 and BPEL 2.0

Hi Guys,

In my project there was a requirement to work with BPEL 2.0.I had experience of working with BPEL 1.1 only so it was something new for me.There are some minor differences in both the two.I will explain the basic differences between them

• FlowN activity in BPEL 1.1 is replaced by <forEach> activity which can be invoked both serially and parallel.
• RepeatUntil activity is added. Use this activity if the body of an activity must be performed at least once. The XPath expression condition in the repeatUntil activity is evaluated after the body of the activity completes. The condition is evaluated repeatedly (and the body of the activity processed) until the provided boolean condition is true.(Same as do while in programming languages).
• The switch activity in BPEL 1.1 is replaced by <if> <elseif <else> activity in BPEL 2.0.
• Terminate activity is chqanged to Exit Activity.
• CompensateScope activity added - This activity enables you to start compensation on a specified inner scope that has already completed successfully. This activity must only be used from within a fault handler, another compensation handler, or a termination handler.   
• A new activity Rethrow has been added to fault handlers.This activity enables you to rethrow a fault originally captured by the immediately enclosing fault handler.

XPath expressions are simplified by using the ‘$’ notation for variable access in BPEL 2.0, for example, $inputVariable.payload/ns1:firstname.

• In BPEL 2.0, if you are working with synchronus BPEL process and in the BPEL code you have not used reply activity to send bcak the response.You will get below error where as, in BPEL 1.1 no error occurs.

 

These are the main differences in terms of process flow and new/modified activities. For more information you guys can refer below links:

• BPEL Activites 1.1 and 2.0
• BPEL 2.0 Features

Hope this helps you.Guys please do share your comments as well,if you find any of my post useful.

Happy Learning.
Cheers !!!

Composite Sensors in SOA Suite 11G

Hi Guys,

Its been long since I last wrote blog because of some workload.Eventually took out some time to continue sharing my knowledge.Without wasting any time, Ill start and explain you guys about Composite levels , what are they used for and how to use them.

Composite sensors provide a method for implementing trackable fields on messages. Composite sensors enable you to perform the following tasks:

•     Monitor incoming and outgoing messages.
•     Specify composite sensor details in the search utility of the Instances page of a SOA composite application in Oracle Enterprise Manager Fusion Middleware Control. This action enables you to locate a particular instance.
•     Publish JMS data computed from incoming and outgoing messages.
•     Track composite instances initiated through business event subscriptions.

You define composite sensors on service and reference binding components or on service components that have business event subscriptions in Oracle JDeveloper. This functionality is similar to variable sensors in BPEL processes. During runtime, composite sensor data is persisted in the database.

In our use case I have created a One Way BPEL process exposed as web service using below schema:

<?xml version="1.0" encoding="windows-1252" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

            xmlns="http://www.example.org/Employee"

            targetNamespace="http://www.example.org/Employee"

            elementFormDefault="qualified">

<xsd:element name="employee" type="personinfo"/>

<xsd:complexType name="personinfo">

  <xsd:sequence>

  <xsd:element name="EmpID" type="xsd:string"/>

    <xsd:element name="firstname" type="xsd:string"/>

    <xsd:element name="lastname" type="xsd:string"/>

  </xsd:sequence>

</xsd:complexType>

</xsd:schema>

Inside the BPEL process  we only have receive activity.Our BPEL process will accept the fields defined in schema and thats all we require for this post. 

Step1: To create sensors ,Click the Composite Sensor icon above the SOA Composite Editor

Step2: Composite sensors window will pop up.Click on "+" icon to create composite sensor.

 
Step3: In the next window, give the name to sensor and define expression to assing value to this sensor.

Step4: You will see the input payload only in our usecase as our BPEL process is one way only.Drill down to Employee ID and click OK.

Step5: Now under sensor actions you will see two options Enterprise Manager and JMS Queue. 

• Enterprise Manager

Select to make runtime sensor data searchable in the Instances tab of a SOA composite application in Oracle Enterprise Manager Fusion Middleware Control.

• JMS Queue

Select to store composite sensor data (XML payload) in a JMS queue. You must specify the JMS connection factory and queue name.In our case we will use Enterprise Manager

Step6:Our Composite sensor EmployeeID is created .Click OK.

Step7: Under your projects on left hand side you can see two new files getting created sensor.xml and sensorActiuon.xml. These files contains list of all the sensors configured for particular composite and along with their actions.

Step8: Compile and deploy your code to EM and test the Sensors composite.Pass the values in employeeid,Fname and Lname.

Step9: Now Open up flow trace for the request you triggered.Expand the sensors tab just below Flow Trace.You will see EmployeeID as sensor and its value that we passed in the input.

Step10: Go back to your Composite in EM and go to Instances tab.Just next to Search,Reset Buttons you will see a new button :AddFields. Click on that and select EmployeeID.

Step11: New search field "EmployeeID" will be added in the Search box along with all other existing search criterias.In this way you can search your instances by passing employeeID field value.

Composite sensors are very important from support and operations point of view as we can set custom search fields using which we can search for our composite instances.
For more imformation you can refer this LINK.

Hope you guys enjoyed the blog.

Happy Learning,
Cheers