12c SOA - Composites - Unit Test suites creation and run the test cases from console.

Topics covered:

• Create, deploy, and run test cases that automate the testing of SOA composite applications.

Why Test Suites:

Test cases enable you to simulate the interaction between a SOA composite application and its web service partners before deployment in a production environment. This helps to ensure that a process interacts with web service partners as expected when it is ready for deployment to a production environment.

In this type of testing, wires, service binding components, service components (such as BPEL processes and Oracle Mediator service components), and reference binding components are tested.

Overview of Test Suites

Test suites consist of a logical collection of one or more test cases. Each test case contains a set of commands to perform as the test instance is executed. The execution of a test suite is known as a test run. 

Before starting let me explain you two basic terms that will be used while creating test cases. These are 

Assertions : You perform assertions to verify variable data or process flow. Assertions enable you to validate test data in an entire XML document as a process is executed. This is done by extracting a value and comparing it to an expected value.

Emulations: These are used to simulate the message data that your SOA composite application receives from web service partners.

Usecase:

I have created a sample SOA application having BPEL service exposed as web service and wired with DB adapter which is used to call a table that I have created.The input for this interface is a string variable and its value would be passed to the table as an input parameter by our BPEL process.In response it will return response based upon the input passed. Visit my previous blog for the steps 12c-soa-db-adapter-perform-select.

Below is the list of input and output that would be returned:

Input: EmpId

Output: EmpId EmpFName EmpFName DeptId DeptName EmpType

Test cases tested with the implementation:

• Case1 -Tested with initiate Message + Assert Input to BPEL + Assert Input and output DB Adapter. Result: It will fetch the data from the DB table based on the assigned Input in the test case and validate with the assert output data. if they are matched, then it is passed with success. otherwise it is failed.
• Case2 - Tested with initiate Message +  Assert Input to DB Adapter. Result: It will fetch the data from the DB table based on the assigned Input in the test case.
• Case3 - Tested with initiate Message + Assert Input to BPEL + Emulate Output to DB Adapter. Result: It will fetch the data from the DB table based on the assigned Input in the test case. if Input is dummy or invalid, then it will send the emulate data as a output to the user.

Implementation:

In project explorer⇾navigate to "testsuites" then right click and click on "Create Test Suite".

 Give the test suite name and click ok.

 Another window will open up prompting for test case name.Give the test case name and click OK.

 Next

Input  Initiate Message - Generate Sample

 Provide the data.

 Test Output part - Generate Sample

 Provide the output data

 So the Test case is ready.

Deploy and run Test case 1 :

Now use only Initiate Input and Assert Input to the Adapter

 Deploy and run Test case 2 :

Now use Initiate Message + Assert Input to Adapter + Emulate Output from the adapter.

 Deploy and run Test case 3 :

In this way we can add any number of test cases to our SOA composite application and before deploying them to production we can test our composites functionality whether they are behaving in expecting manner or not.

12c SOA - DB Adapter - Perform select operation on a table

Here I will do:

• Create a table Employee and insert some employee rows.
• Create a DB Adapter and fetch the employee data based on employee id.
• Create a synchronous BPEL service and call the DB adapter

Create a table:

create table employee

(

emp_id number(10) not null,

emp_fname varchar2(50),

emp_lname varchar2(50),

dept_id varchar2(50),

dept_name varchar2(50),

emp_type varchar2(50),

CONSTRAINT customers_pk PRIMARY KEY(emp_id)

)

Insert Data:
insert into employee values (1,'Sri','Das','123','OSP','P')

insert into employee values (2,'Dip','Cha','123','OSP','S')

 Create a SOA project

 Right click on the External References lane ⇾Insert⇾Databse

 Provide the adapter name

 Create the DB connection

 Provide the JNDI Name and if you don't have any JNDI then create it in admin console.

 Select Perform an Operation on a table

 Import Tables

 Give the table name in the filter and select it.

 Next

 Next

 Add a parameter

 Name the Parameter.

 Click Edit

 Add

 Select Parameter

 Select created EmpId as parameter

 Next

 Next

 Next

 DB Adapter created.
Now Right click on components and insert BPEL Process

 Select Synchronous service

 Modify the XSD

 Wire the BPEL with the adapter

 Drag and drop an invoke activity and call the adapter partnerlink

 create the invoke input and output

 Assign the Input

 Assign the output

 Deploy and test

12c SOA - set custom jms header property in Mediator and BPEL components and message selector syntax for jms consume

By Default a JMS message includes a number of header fields that contain information used to identify and route messages. The supported headers for an incoming message are:
JMSCorrelationID
JMSDeliveryMode
JMSExpiration
JMSMessageID
JMSPriority
JMSRedelivered
JMSTimestamp
JMSType

But we can also set Custom properties.

Mediator: To set custom JMS header property in Mediator follows below steps.

Open .mplan file and click on assign activity. Here we are defining new custom header property (city).
To set city custom header property choose “jca.jms.JMSProperty” and append “.city” to it. You can assign any expression or hard-code this property value.

BPEL: To set custom JMS header property in BPEL follows below steps.
Go to *.bpel file, check the invoke code and add a new property called jca.jms.JMSProperty.Profession, for instance:

<invoke name="InvokeJMS" inputVariable="InvokeJMS_Produce_InputVariable"

                partnerLink="JMSProduce" portType="ns1:Produce_Message_ptt"

                operation="Produce_Message" bpelx:invokeAsDetail="no">

                 <bpelx:inputProperty name="jca.jms.JMSProperty.Profession" variable="profVar"/>

</invoke>

Currently this property is equal to profVar but you can also use expression to assign value to city property.
 <bpelx:inputProperty name="jca.jms.JMSProperty.Profession" expression="2"/>

Remember you will not find this property in header tab, you need to manually set this property in *.bpel file for specific invoke.

When you will run the composite, you will see custom JMS header property at admin console for that queue.

Deploy and Test:

 In JMS queue weblogic console

 Consume message using message selector