Get in touch: info@samuelfair.com

Testing the SOAP Proxy- Digital Transformation with IBM API Connect

There are multiple ways to test your API. You can either use the SoapUI tool or the test tool built into API Designer/API Manager. You will be using the SoapUI tool for this test. Through this test, you will explore how the API’s base path and path values are mapped to the actual URL. You will also be able to make a comparison between the API URL and the service URL. This test is divided into two parts. Part one will test the SOAP service by directly calling the service URL. This will ensure that there is required connectivity to the backend SOAP service and give us a glimpse of the response (to make a later comparison) returned by the SOAP service. Part two will test your SOAP API proxy. The highlight of your API proxy test will be to compare the responses produced by the two test cases and to see the Client ID and Client Secret security in action.

Testing the SOAP service

Open your SoapUI tool and create a new SOAP project. You can give this project any name. The initial WSDL value will be http://www.dneonline.com/calculator.asmx?wsdl. SoapUI should create a project based on this service.

Run a quick test by invoking the SOAP service directly. Refer to Figure 5.1. You should be able to get a valid response from the Add operation.

Testing the SOAP API Proxy

Using the same SoapUI project, change your testing endpoint URL.

Your URL consists of the following parts:

  • API base url: https://localhost:9444/localtest/sandbox/ (provided to you when you started your LTE environment).
  • API base path: /calculator (available in the Design|General|Base Path section).
  • API path: /Add (available in the Design|Paths section).
  • Complete URL: You can construct the complete API URL as API base URL + API base path + API path, that is, https://localhost:9444/localtest/sandbox/calculator/Add.

Add this new endpoint to your SoapUI project as shown in Figure 5.8. But before you can send a request to this APIC endpoint, you have to do a couple of things.

  1. First, add Client ID security to your SoapUI request. This can be done by adding a new header, X-IBM-Client-Id (it’s worth mentioning that the Client ID is mapped to parameter name X-IBM-Client-Id in the Security Schemes section of your API. You can give any header name, but it is recommended to use X-IBM-Client-Id for the sake of standardization). The value for this header is available in the Endpoint tab of your API.
  2. To enable rapid testing, APIC auto-publishes your Product to a Target Product (Calculator auto product) and a Test application (Sandbox Test App). Refer to Figure 5.8.

Figure 5.8 – Auto-publishing Preference

3. Now you are ready to test your API. Send a request to this new endpoint. You should see a response, as shown in Figure 5.9.

Figure 5.9 – SOAP API proxy test

4. You should take time to test other operations as well. Make sure that you change the API URL as you test other service operations. With this test you should now be able to identify the key elements of an API URL, a simple method to enforce security on your API, and an API proxy that sits in front of a SOAP service.

This section covered in detail the facilities available in APIC to expose an existing SOAP-based service as a SOAP API proxy. This ability to expose an existing service as an API, without much effort, can help you on your modernization journey. Many of your API consumers who continue to use SOAP services will be able to consume your APIs with ease. But as their modernization efforts continue and they move from SOAP services to REST services, so will you have to evolve your API endpoints. To accommodate these consumers, you will need to expose your SOAP services as REST API proxies. This is exactly what we will cover in the next section.

Create a REST proxy that invokes a SOAP service

In the previous section, we looked at the method of exposing an existing SOAP service as a SOAP API proxy. That method works for our consumers who are still using SOAP services. But we should also cater to the demands of our more modern or evolving consumers who have shifted to REST services. Continuing our journey, let’s now explore the methods in APIC to make available a sample SOAP service as a REST proxy API and satisfy our more modern consumers. APIC provides simple methods to expose an existing SOAP service as a REST API. Let’s dive into learning these methods.


Leave a Reply

Your email address will not be published. Required fields are marked *