ESB Testing Best Practice
ESB functional test method
As Figure 1 shows, within a service oriented architecture, service requesters and service providers communicate with each other through an ESB. The major capabilities of ESB are message transformation, protocol conversion and service routing. Based on the ESB middleware, integration routines are developed to mediate the service requesters and providers. To test those integration routines, we summarized the different types of ESB functional verification test methods as below. In this article, we take WebSphere Message Broker as the ESB middleware example to describe our testing guideline.
Figure 1. Example message and network protocols in SOA
Message flow for JMS to web service
Figure 2 displays the message flow about correlation between JMS (consumer) and the web service (provider) within the ESB. The service requester sends the request to the ESB and converts the request to the SOAP message and transfers to invoke the web service (provider). The provider sends out the SOAP response message to the ESB and transforms the message to XML and sends the message back to the requester’s response queue.
Figure 2. Message Flow 1
To test the function of the message flow, the test branches for the message flow need to be identified firstly. There are two valid branches in the Figure 2. One branch is sending the message to the requester’s request queue, and getting the response message from the requester’s response queue. The other branch is sending the message to the requester’s request queue, and getting the fault message from the requester’s response queue.
Secondly, different kinds of input messages for different branches should be designed. For example, for the first branch, kinds of input XML messages would be designed to be converted to the different kinds of SOAP message to get the different response from the service. The input boundary and the classification need to be considered when design the test input. For the second branch, invalid input XML messages would be converted to the invalid SOAP message for the service.
Test cases are designed to verify the function of the message flows. First of all, clear the requester’s request queue, and send the input message to the queue. Get the converted SOAP request message at the check point 1 of the Figure 2 and verify the SOAP message is converted to the expected Message. In the check point 2 of Figure 2, the test client gets the Response/Fault message from the request’s response queue and then checks if the message is expected.
Message flow for web service to JMS
The Correlation Message flow with a web service to JMS is showed at Figure 3. A web service (consumer) sends the SOAP request message to the ESB and converts the SOAP message to an XML message and sends the message to the Provider’s Request Queue. Service provider gets the request the message and response message to the ESB. ESB transforms the response message to SOAP message as the SOAP reply of the web service. To test the kind of flow automate, a provider simulator is implemented to send back the response message of the provider.
Figure 3. Message Flow 2
The message flow of Figure 3 could be identified as two test branches. One is SOAP request message is invalid, ESB handles the exception and sends out the Fault Result as the response. The other is web service sends out the valid SOAP request message and gets the valid SOAP response message through the ESB.
The input messages for exception branch need to be designed to cover the exception situations. And for the valid branch, the input boundary and the classification need to be considered when design the input SOAP message for the coverage.
There are two check points in the test cases for the valid flow as the Figure 3 shows. When the SOAP request is converted to the XML message, test client gets the message to verify the XML is converted successfully and the content satisfies the requirement of the service provider. And the other check point to verify the converted SOAP response message is correct. For the invalid branch, the check point 2 needs to be verified. Test client need to verify the Fault response result is generated correctly.
Message flow from MQ/JMS to MQ/JMS
The message can also be transferred from one queue to others (Local/Remote) by ESB. Figure 4 shows the one way message flow. Input message would be designed to verify the message is transferred successfully. Input message is sent to the consumer’s request queue and test client gets the message from the provider’s request queue to verify the format and the content of the message is transformed and transferred successfully.
Figure 4. Message Flow 3
As shown in figure 5 the correlation message flow in the ESB. Service consumer sends the service request by JMS and the request message transferred and transformed by ESB. Service provider gets the request message from the provider’s request queue and sent back the response message to provider’s response queue. ESB transfer the response message to the service consumer. The test case is designed to cover the flow.
Input message is designed by the contract schema. Test client verifies if the provider receives the right messages in the check point1. Test client create a simulator to send back the response message. The consumer's response message is need to be verified if the format and content is expected in the check point 2.
Figure 5. Message Flow 4
Message flow from FTP to FTP
Files can be transferred by FTP from the consumer to the provider through ESB as Figrue 6. Test client would upload the files from the dedicated source folder. ESB transfer the file to the expected destination. Test client get the files from the destination and check files are the same as the input files by byte compare. Three types of input files are designed: 0 size file, normal file, large size file to verify the transformation function.
Figure 6. Message Flow 5
Message flow from FTP to JMS
The Figure 7 shows a conversion of FTP to JMS. The ESB receives the files by FTP and converts the file to the message and sends to the provider’s queues. Test client needs to design different kinds of files (zero size, normal size, large size) to be the input. And then get the converted message from the two queues to verify the files are converted and transferred successfully.
Figure 7. Message Flow 6
ESB performance test method
Concurrent workload control
In this performance test, we will test the in-scope message flows in an extreme strict situation that all the request of the message flows will be sent to message broker just at the beginning of the test without think time. For example, message flow IRS_CRM_AccountCreationRequest has 1000 requests in the peak hour. Then all of the 1000 request messages would be sent to the input queue of the message flow without stop when the testing is started. At the same time, the request messages of other 20 plus message flows are sent to the specified destination too. So the stress of the message flows at the beginning of the test would be very high.
One-way message flow
The one way message flow usually contains one MQ input node and one MQ output node as shown in figure 8 below.
Figure 8. One-Way Message Flow
In the test script, we will record the timestamp as t0 when we start to send one request message to the request queue. We will record the timestamp as t1 when we retrieved the response message from the response queue. And the other request messages are also recorded as described. We calculate the sum of the entire message flows’ response time as ∑ (t1-t0). Suppose we send totally m messages for this flow. Then the average response time (ast) would be calculated as ast= ∑ (t1-t0)/m.
Correlation message flow
The correlation message flow usually contains 2 MQ input nodes and 2 MQ output nodes as below.
Figure 9. Correlation message flow
We have one simulator illustrated at the right side to construct a reply message with the given request message. The simulator just simply set the correlation ID of the reply message with the request message ID and then put the reply message into Provider’s Response Queue. Similarly, we will record the timestamp of t0 and t1 as 3.2 described. Moreover, we will record the total time used in the simulator to construct and reply the message as ds. Suppose we send totally m messages for this flow. Then the average response time (ast) would be calculated as ast= (∑ (t1-t0)-ds) /m.
Web service provider message flow
The web service provider message flow usually sends the SOAP request message to SOAP Input node and get the SOAP response message from SOAP Reply node like below. The MQ input node and MQ output node are used to send the transformed messages to the service consumer and get the response message from the consumer.
Figure 10. Web service provider message flow
The simulator acts as the service consumer to construct a reply messages as 3.3. The timestamp t0 is used to record when the SOAP Request message is sent out. And t1 is the timestamp we get the response time from SOAP Reply. We will record the total time used in the simulator to construct and reply the message as ds. Suppose we send totally m messages for this flow. Then the average response time (ast) would be calculated as ast= (∑ (t1-t0)-ds) /m.
Web service consumer message flow
The web service consumer message flow usually contains one MQ input node and one MQ output node as followed. The web service node consumes the MQ request messages and sends the response message to the MQ output node.
Figure 11. Web service consumer message flow
Similarly, we will record the timestamp of t0 and t1 as 3.2 described. We will record the total time used in the web services simulator to construct and reply the message as ws. Suppose we send totally m messages for this flow. Then the average response time (ast) would be calculated as ast= (∑ (t1-t0)-ws) /m.
The function test and performance test method are described in this document. The testing method could be implemented by JUnit and executed automatically. The ESB system has been deployed in the customer’s Road User Charging project and performs an import role in the project.
- The WebSphere MQ Information Center explains how to use WebSphere MQ.
- The WebSphere Message Broker Information Center explains how to use WebShpere Message Broker.
- Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.