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