Consider a scenario where you want to expose an existing SOAP service where requests from API consumers are forwarded, as-is, to that SOAP service. This pattern of API/service interaction is depicted in Figure 5.4:

Figure 5.4 – API proxy/SOAP service interaction

We will now explore this pattern in detail by creating a simple SOAP API proxy that will expose a SOAP-based target service (Calculator service). To complete the rest of this section, ensure that you have read the Technical requirements section of this chapter. We will be using a service definition that is completely defined in a single file.

Creating a SOAP proxy

By now, you should already have become comfortable with starting your LTE environment, opening the API Designer, connecting to your workspace, and finally, connecting your API Designer to your running LTE server. We will hence start with the process of creating a new API:

1. In the Develop APIs and products tile of API Designer, click Add then select API.
2. In the Select API type view, select From existing WSDL service (SOAP Proxy). Review the diagram displayed to the side of the Select API type view. Click Next.
3. In the File upload view, upload the Calculator service definition that was downloaded and saved by you as part of the technical requirements. The system should validate the service definition and display a success message. Click Next.
4. In the Select Service view, the Calculator service should be auto-selected for you as that is the only service defined in the service definition file. Click Next.
5. In the Info section, review all the details that are populated by APIC. You can change Base path in this section. For now, accept the default values and click Next.
6. In the Secure section, unselect CORS (more about this in Chapter 7, Securing APIs) and select Activate API. The effect of the Activate API option is that APIC will automatically create a draft Product, add this API to that Product, and publish the Product to the sandbox Catalog so that the API is available for testing. Click Next. This should create your API definition.
7. On the Summary page, you should see important information about your API proxy. Make a note of the Client ID and Client secret values. You will be using them shortly to test your API proxy and if for some reason you forget to make a note of these values, we will explore a way to recover them from the API definition.

Before we go about testing our SOAP API proxy, let’s review all the considerable work that was done behind the scenes by APIC to expose the provided SOAP service as an API.

Review SOAP Proxy configuration

To fully appreciate the work done by APIC in mapping the WSDL definition to an OpenAPI-based definition, it is imperative that you review the various mappings. In brief, the mappings are done so that each WSDL portType is mapped to API Path, each path has a POST Operation, and each Operation contains Parameters that are mapped to Input message type, and Response that are mapped to Output message type. You will now review the calculator API’s configuration. This will give you an in-depth understanding of the APIC’s API generation process:

1. APIC creates a set of API Operations based on the portType section in the WSDL document. For each operation in the WSDL portType, the API definition creates a matching API operation. The API Paths correspond to the names of the operations. You can review this mapping of WSDL portType to API Paths in Figure 5.5:

Figure 5.5 – Mapping of WSDL operations to API Paths

The HTTP method is always set to POST (SOAP services do not use HTTP methods of GET, PUT, or DELETE). Go ahead and click on one of the Paths and review the Operations section of Edit Path view. You will notice an operation with the name POST. Click on Operation POST.

APIC has done tremendous work in the background. For each API operation, it has mapped WSDL input and output types to request and response messages. Navigate to the Calculator API | Design | Paths (in the left menu) | /Add path | Operations | POST | Path Parameters type AddInput and Response schema AddOutput (Figure 5.6). Path Parameters are related to API requests and Responses are related to API responses. You will review the schema definitions for AddInput and AddOutput objects in the next step.

Figure 5.6 – Mapping WSDL Message Types to API Parameters/Responses

2. Navigate to the calculator API | Design | Definitions (in the left menu). Review the AddInput and AddOutput schemas, as shown in Figure 5.7.

Figure 5.7 – Path Parameters/Responses Definitions

These steps should have helped you develop a good understanding of the behind-the-scenes work done by APIC in exposing your SOAP-based target service as a SOAP API proxy. Before we proceed to test the API, we should review two more important items. These are the Gateway tab and Endpoint tab of our API proxy.

Go ahead and click on the Gateway tab. You should see nothing but a single Invoke policy. This is because we are exposing our SOAP target service as a SOAP API proxy. There is no translation of data required. Requests from the API consumer are passed as-is to the backend service and the responses from the backend service are sent to the API consumer, again without any translations. All this work can be carried out by a single Invoke policy. You will soon see the difference (in the next section) in the Gateway tab of a REST API proxy that proxies a SOAP backend service.

Lastly, you should look at the Endpoint tab. Earlier in this section, we mentioned that Client ID and Client secret values can be retrieved from the API definition. You can retrieve these values from the Endpoint tab.

Having now built your SOAP API proxy and reviewed the configuration generated behind the scenes, it is time to test this API proxy.