1. What is a Web Service?
A Web Service is any software code that is available over the internet and is used to transfer XML messages or data using Web Protocols like HTTP. For example., the client sends a request to the server over the network and a specific port where Web Service is hosted and waits for a response. Once the response is received, communication got completed.
1.1. Features of Web Service:
- It uses XML for message communication.
- It is platform-independent.
- It can be available over the Internet or private network.
- It can also process complex documents and not just messages.
1.2. Types of Web Services:
There are three types of Web Services that are used for client-server communication:
- SOAP Web Service (Simple Object Access Protocol)
- REST Web Service (Representational State Transfer)
- WSDL (Web Service Description Language)
Table of Contents
1. What is a Web Service?
1.1. Features of Web Service
1.2. Types of Web Services
2. What is SOAP Protocol?
2.1. SOAP Protocol Features
2.2. SOAP Message Format
2.3. SOAP Message Structure Example
3. What is SOAPUI?
3.1. Types of Testing SOAPUI can perform
3.2. Protocols & Technologies SOAPUI Supports
3.3. Installing SOAPUI
3.3.1. Installing on Linux
3.3.2. Installing on Windows/MAC
4. Working with SOAPUI Interface
4.1. Main Window
4.2. Create Your First SOAP Project
4.3. What is a WSDL?
4.4. SOAPUI Test Case, Test Step, Test Suite, Logs Pane, and Assertions
4.5. SOAPUI Properties
2. What is SOAP Protocol?
Simple Object Access Protocol API, is a protocol used for exchanging structured information in web services. It defines a set of rules and formats for creating messages, exchanging data, and invoking methods across different platforms and programming languages.
To provide an example of a SOAP API, let's consider a hypothetical scenario where you have a weather forecasting service that exposes a SOAP API. The API allows users to retrieve weather information for a specific location.
Here's an example of how a SOAP API request and response may look like:
SOAP API Request:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://www.example.com/weather-api">
<SOAP-ENV:Body>
<ns1:GetWeatherRequest>
<ns1:Location>London</ns1:Location>
</ns1:GetWeatherRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
In this example, the request is wrapped within a SOAP envelope. The <ns1:GetWeatherRequest>
element specifies the operation to be performed, which is retrieving the weather information for a specific location.
SOAP API Response:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://www.example.com/weather-api">
<SOAP-ENV:Body>
<ns1:GetWeatherResponse>
<ns1:Temperature>25°C</ns1:Temperature>
<ns1:WeatherCondition>Sunny</ns1:WeatherCondition>
</ns1:GetWeatherResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
In the response, the weather information for the requested location is returned. The <ns1:GetWeatherResponse>
element contains the temperature and weather condition.
In this example, the SOAP API uses XML as the message format, and the request and response are wrapped within the SOAP envelope. The API defines specific elements and namespaces to represent the operations and data being exchanged.
SOAP APIs often rely on a WSDL (Web Services Description Language) file that provides a detailed description of the API, including the supported operations, data types, and message formats. The WSDL acts as a contract between the API provider and consumers, ensuring that both parties understand how to interact with the API.
2.1. SOAP Protocol Features
The SOAP (Simple Object Access Protocol) protocol is a messaging protocol used for exchanging structured information in web services. It offers several key features that make it a powerful tool for communication between applications. Some of the key features of the SOAP protocol are:
1. Extensibility: SOAP allows for the use of additional protocols and technologies by supporting various message exchange patterns, such as request-response, one-way, and notification-style messaging. This extensibility makes it adaptable to different communication scenarios.
2. Platform and Language Independence: SOAP is designed to be platform and language-independent, allowing applications written in different programming languages and running on different platforms to communicate with each other seamlessly. This makes it a highly interoperable protocol.
3. Message Structure: SOAP messages have a well-defined structure consisting of an envelope, header, and body. The envelope provides the overall structure of the message, the header contains additional information about the message, and the body carries the actual data being transmitted. This structure ensures consistency and standardization in the message exchange.
4. Data Encoding: SOAP supports multiple data encoding formats, including XML (Extensible Markup Language), which is the most commonly used format. XML provides a flexible and human-readable way to represent data, making it easy to understand and process.
5. Protocol Independence: SOAP can be used over different protocols, such as HTTP, SMTP, and more. It utilizes the underlying protocol for message transmission, allowing it to work seamlessly over various network protocols and infrastructures.
6. Error Handling: SOAP provides a standardized mechanism for handling errors and exceptions. It defines a SOAP fault message structure that allows for the reporting of errors and exceptions that occur during message processing. This helps in troubleshooting and identifying issues in communication between applications.
7. Security: SOAP supports various security mechanisms to ensure the confidentiality, integrity, and authenticity of exchanged messages. It can be integrated with security protocols like HTTPS, WS-Security, and others to provide secure communication over the network.
8. Standards-Based: SOAP is based on open standards and is defined by the World Wide Web Consortium (W3C). This ensures that SOAP-based web services can be implemented using standardized specifications, promoting interoperability and consistency.
2.2. SOAP Message Format
A SOAP message can be an XML document that contains the following elements:
- Envelope - It defines the beginning and end of the message.
- Header - It is an optional part of the SOAP message and is used in processing the message at an intermediary point or at the endpoint.
- Body - It is the actual XML message and a mandatory element.
- Fault - It is the optional element that contains the faults or errors information that occurred during the processing of the message. There are some sub-elements present for the fault:
- <faultcode>
- <faultstring>
- <faultactor>
- <detail>
Please note that all these specifications can be changed or modified with new SOAP Protocol versions. For updated specifications on SOAP Message format please refer following links:
2.3 SOAP Message Structure Example
<?xml version="1.0"?>
<SOAP:Envelope
xmlns:SOAP="http://www.w3.org/2003/05/SOAP-envelope/"
SOAP:encodingStyle="http://www.w3.org/2003/05/SOAP-encoding">
<SOAP:Header>
...
</SOAP:Header>
<SOAP:Body>
...
<SOAP:Fault>
...
</SOAP:Fault>
</SOAP:Body>
</SOAP:Envelope>
3. What is SOAPUI?
SOAPUI is an open-source tool for testing Web Services. These services can be SOAP Web Services, RESTFUL Services, or HTTP-based services. SOAPUI is a very popular tool and has more than 3 million downloads. A lot of community support and knowledge is available online for this tool. There is also a commercial version available for this tool with extra functionality called READYAPI.
3.1. Types of Testing SOAPUI can perform:
- Functional Testing
- Load Testing
- Security Testing
- Regression Testing
You can create a functional test and run it as a load test in SOAPUI.
3.2. Protocols & Technologies SOAPUI Supports:
- SOAP – Simple Object Access Protocol
- WSDL – Web Service Definition Language
- REST – Representational State Transfer
- HTTP – Hyper Text Transmission Protocol
- HTTPS – Hyper Text Transmission Protocol Secured
- AMF – Action Message Format
- JDBC – Java Database Connectivity
- JMS – Java Messaging Service
3.3. Installing SOAPUI
SoapUI is cross-platform and is written in JAVA, so it runs on most operating systems, It supports several Windows Versions, Mac, and multiple Linux platforms. SoapUI requires a 1.6+ version of the JRE (Java Runtime Environment), at least 1 GB of memory is recommended, and about 100 MB of disk space.
3.3.1. Installing on Linux
- Download the Linux binary from http://www.soapui.org/
- Unzip it in a directory of your choice
- And run $ bin/soapui.sh
3.3.2. Installing on Windows/MAC
- Download the installer from download for Windows.
- Installation is pretty straightforward, start it by just double-clicking on the installer.
- It will ask you to select the destination folder, select and continue.
- The next step asks you to select the components you want to install, go with the default selections.
- On the next screen, it asks you to install SOAPUI tutorials, you can add or skip it.
- Few more basic options will come and that's it. Finished!
4. Working with SOAPUI Interface
4.1. Main Window
- Main Toolbar
- Icons Toolbar
- Navigator Pane - Expandable tree display of workspace content.
- Properties Pane - Predefined workspace properties.
- Log Inspectors
4.2 Create Your First SOAP Project
- Click on 'New SOAP Project' to create a new project.
2. Enter a name for your project.
3. Enter the WSDL file path -
4. And click OK.
5. SOAPUI will create the project from the WSDL provided in the navigator bar.
6. Expand the NumberToDollars and then double-click on Request 1. It will display the following XML file on the right side:
7. Now you have to replace the '?' in <web:dNum>?</web:dNum> field with a number let's say 2 and press the green 'execute' arrow on the top left of the XML view.
8. And a response will be returned for this request, in the response you would see that 2 would be converted to 'two dollars' (you can select any of the two modes like xml or raw for the request and response):
Great! You just have done your first test of a SOAP Web Service using WSDL.
Similarly, you can test the remaining web service 'NumberToWords' by replacing the '?' with the corresponding value and executing it, and checking the response.
4.3 What is a WSDL?
WSDL, or Web Service Description Language, is an XML-based definition language. It’s used for describing the functionality of a SOAP-based web service.
WSDL files are the core of testing SOAP-based services. SoapUI uses WSDL files to generate test requests, assertions, and mock services. WSDL files define various aspects of SOAP messages:
- Any element or attribute is allowed multiple times
- The required elements and attributes
- Optional elements and attributes
- The specific order of elements or attributes
WSDL file can be seen as a contract between the provider and the consumer of the service. SoapUI supports the 1.1 version of the WSDL specification and corresponding bindings for SOAP versions 1.1 and 1.2.
We have already created a project from the WSDL file in section 4.2 of this article.
4.4 SOAPUI Test Case, Test Step, Test Suite, Logs Pane, and Assertions
Let me explain each of these elements of SOAPUI in more detail:
1. Test Case:
A test case is a container that holds one or more test steps. It allows you to define a set of tests that will be executed together. Each test case has a name, description, and configuration options, including settings for timeouts, authentication, and headers. You can create multiple test cases to cover different scenarios and variations of your web service.
2. Test Step:
A test step is an individual action that is performed as part of a test case. There are several types of test steps in SOAPUI, including:
i. REST Request: A REST request sends an HTTP request to a web service and receives a response.
ii. SOAP Request: A SOAP request sends an XML-based SOAP message to a web service and receives a SOAP response.
iii. JDBC Request: A JDBC request sends a SQL query to a database and receives a response.
iv. Groovy Script: A Groovy script step allows you to write custom code to manipulate test data, perform complex calculations, or customize test behavior.
v. Delay: A delay step pauses the test execution for a specified time period.
Each test step has its own configuration options, such as endpoint URL, HTTP method, request headers, request body, and assertions.
3. Test Suite:
A test suite is a collection of related test cases. It allows you to organize your tests and run them together. You can create multiple test suites to cover different aspects of your web service, such as functional testing, performance testing, or security testing. Test suites have their own configuration options, such as test case order, parallel execution, etc.
4. Logs Pane:
The Logs pane provides a detailed view of the test execution process. It shows the request and response messages, as well as any errors or warnings that occur during the test. The logs can be helpful in debugging issues or identifying areas for improvement in your tests.
The Logs pane can be filtered by severity level, such as errors, warnings, or information messages. This allows you to focus on specific areas of interest during the testing process.
5. Assertions:
Assertions are used to validate the results of a test step. They allow you to specify expected values and compare them to the actual values returned by the service.
4.5 SOAPUI Properties
SOAPUI, properties are used to store data that can be shared between different parts of a test case or between different test cases. They are essentially variables that can be used to store values that may change during the execution of a test.
Here are some key points about properties in SOAPUI:
1. Defining Properties: Properties can be defined at various levels, including the project level, the test suite level, the test case level, and the test step level. This allows you to define properties that are specific to a particular test or that can be shared across multiple tests.
2. Setting Property Values: Property values can be set in a variety of ways. For example, you can set the value of a property manually in the SOAPUI user interface, or you can use a script to set the value programmatically. You can also set property values dynamically based on the results of a previous test step or based on input data from a file.
3. Using Properties in Test Steps: Properties can be used in test steps to substitute variable values in requests, headers, or other elements. This can be useful when testing services that require dynamic input values, such as timestamps or user IDs.
4. Reading Property Values: You can also read the value of a property at any point in a test using a script. This allows you to check the value of a property and take action based on its value.
5. Property Expansion: SOAPUI supports property expansion, which allows you to use a property reference in a request or script and have the value of the property automatically substituted at runtime.
Conclusion
In summary, properties in SOAPUI are a powerful tool for managing data and making tests more flexible and reusable. They allow you to store and manipulate data at various levels of a test, and they can be used to create dynamic test scenarios that can adapt to changing input values.
Author
Vaneesh Behl
Passionately writing and working in Tech Space for more than a decade.
Comments
Post a Comment