Thursday, February 6, 2020

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.

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.
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.
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.

 Add a parameter
 Name the Parameter.
 Click Edit
 Select Parameter
 Select created EmpId as parameter

 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

Wednesday, February 5, 2020

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:

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"/>

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 

Featured Post

11g to 12c OSB projects migration points

1. Export 11g OSB code and import in 12c Jdeveloper. Steps to import OSB project in Jdeveloper:   File⇾Import⇾Service Bus Resources⇾ Se...