In the previous chapter we learnt how to configure SoapUI to test the services functionally, in this chapter we will cover the following topics in detail
- Service orchestration and testing it using SoapUI
- Assertions
- Configuring SoapUI for JMS Services using Hermes JMS
- Real time example of testing a service orchestration
When services act in a manner that serves a business purpose which results in a business process being completed, it's known as service orchestration. It directly addresses the implementation of business process implementation. It actually binds business logic and data exchange between applications together so that the desired flow is met.
From another point of view, it can also be said that service orchestration arranges services so that they look like a single service meant to complete a single flow.
To achieve service orchestration, every service involved in orchestration shares data among themselves where sometimes an output of one service acts as an input to the other.
But it should be noted that individual services are not designed to communicate with each other, messages should be exchanged based on certain business rules and execution sequence. To provide communication between all applications in SOA we have the concept of Enterprise Application Integration (EAI). It's more like a framework which utilizes software and systems together to achieve data and business process communication.
It should also be noted that EAI defines a set of principles for integration of multiple systems for communication architectures, such as message-oriented middleware and so on.
To understand more, let's take an example of service orchestration in a telecom application:
A user needs a new sim card for voice calling and data so he submits his details to the agent.
Now let's see what happens behind the UI layer:
- The agent logs in to the UI and submits user information.
- A defaulters check is made on the user details to check for previously disputed records with the telecom service provider. If the response of the service is yes, then the process stops and the user is notified.
- A serviceability check is made on the user's address by a service to make sure that the services requested are available. If the response of the service is no, the process stops and the agent is notified else we move forward.
- A call is made to the product service, which in turns calls the product catalogue to get the product to price mapping, and comes up with the price list for the services asked.
- Finally, the order is submitted to the provisioning service and once provisioned, the services are activated with the defined SLA.
In the preceding example we see how the orchestrated services talk to each other, pass data to each other, process it, and finally complete the journey of a new order.
As the preceding example illustrates, service orchestration is a fundamental aspect of successfully implementing SOA. In a truly service-oriented architecture, new applications are created by new orchestrations of existing services - not by writing new code.
We have now seen that service orchestration is complex and it requires exchange of data and information among several services, databases, and third-party systems to achieve the desired functional behavior.
So how do we go about testing it?
Before we learn how to test service orchestration scenarios in SoapUI let's see some of the functionalities of SoapUI which would help us in testing service orchestration and also help us in automating service orchestration flows.
In several instances, we would need to pass dynamic data each time we enter data in a request, for example, every time we register a customer there needs to be a unique phone number, maybe with a specified format. If you are automating your test you need a technique to generate it each time without any manual intervention.
For this we can use the functionality of groovy scripts in SoapUI. Now let's see how to add a groovy script in SoapUI:
- Go to Test Steps. Right-click on it and verify that the following screen is shown:
- Select Add Step from the screen and verify the following options are shown:
- Select Groovy Script and verify that a popup to name the groovy step appears:
- Rename the step to a more relevant name or leave it as it is, click OK and verify that a step is added.
- Double-click on the Groovy Script and the following script console will be displayed:
Now we have seen how to add a groovy test step in SoapUI, let's now see how to create dynamic data using groovy script:
Following is the script which will create unique data for you to be used each time the test is executed:
def PhoneNumber1=(Math.round(Math.random()*9977777770)+0000000010); def ProductId =(Math.round(Math.random()*99999999990000)+10000000010); testRunner.testCase.setPropertyValue("PhoneNumber",PhoneNumber1.toString ()); testRunner.testCase.setPropertyValue("ProductID",ProductId.toString ());
This script creates unique data to be used by a request each time you run it. This script saves the data in the properties at the test case level. See the screenshot that follows:
Then from any request you can call this data. The properties can be called from any request in the project/test suite:
The important thing to note here is that we can save the data at each level based on our requirements, for instance at the test suite level, test case level, and project level there are options to save custom properties.