If you have a SOAP service defined in a WSDL file, you can use the WSDL file to create an API Connect SOAP proxy API
that calls that SOAP service.
About this task
You can complete this task either by using the API Designer UI application, or by using the
browser-based API Manager UI.
To complete this task,
you must be assigned a role that has the Api-Drafts:Edit
,
Settings:View
, and App:View
permissions. The pre-supplied Developer role has these permissions by default;
if you are assigned a custom role it must have these permissions.
For more information, see Creating custom
roles.
Note: By default, the SOAP proxy API that is created will have the basepath set to the WSDL service
name. You can edit the SOAP proxy API to change this basepath.
You can add a SOAP API to expose an existing SOAP service by supplying the
WSDL file that defines that existing
service in one of the following ways:
- If the WSDL file is a
stand-alone file with no external dependencies, you can load the .wsdl file
from a directory to create the SOAP API definition.
- You can provide one or more WSDL files in a single
.zip file that contains the WSDL files and any necessary
schemas.
If the WSDL file
references other WSDL files or
references XSD files containing XML schema definitions, you must create a .zip
archive of the WSDL file and its
dependent documents, and then load the .zip file from a directory to add the
SOAP API definition.
- If you are using API Designer with existing APIs that were created
from a WSDL or WSDL.zip file in Version 5 API Designer, make sure that the following requirements
are met:
- The WSDL or WSDL.zip file must be stored in the same directory as the API's YAML file.
- In the API's YAML file, the
x-ibm-configuration
-->
wsdl-definition
--> wsdl
property must point directly to the WSDL
or WSDL.zip file with no path specified (the files are located in the same directory).
The service must support Web Services Basic Profile Version 1.1 - Second Edition.
Procedure
To add a SOAP API definition by loading a WSDL file, complete the following
steps:
-
In the navigation pane, click
Develop, select the APIs tab, then click . The
Select API type screen is displayed.
- Select OpenAPI 2.0; this API type
does not support OpenAPI 3.0.
-
Select From existing WSDL service (SOAP Proxy). Click
Next.
The Create API from Existing WSDL Service (SOAP Proxy) window
opens.
-
To upload the service information from a stand-alone .wsdl file, or a
.zip file that contains a WSDL file and its dependent
documents, you can either drag and drop your file, or
browse and select the file that you want to use.
After you upload the file, the WSDL is evaluated and a message displays whether the WSDL is
valid.
If you upload a .zip file, you can include in the .zip
file an options file to specify additional directives. For details, see Using an options file when importing a WSDL service.
-
Click Next. At the Select Service panel, select a WSDL service from the
imported file.
-
Click Next. Specify the API summary in the Info
section. You can fine-tune the API after it is created.
- The Title can include special characters but should be kept short so that
it can be easily displayed in the user interface.
- The Name is entered automatically. The value in the
Name field is a single string that is used to identify the API in developer toolkit CLI commands. To view
the CLI commands to manage draft APIs, see the toolkit CLI reference documentation.
- The Version corresponds to the value of the
info.version
property of the API's OpenAPI definition. The
version.release.modification
version numbering scheme is recommended; for example
1.0.0.
- The Base path is the URL segment of the API and does not include the host
name or any additional segments for paths or operations. The base path cannot include special
characters and must begin with a
/
character even if it is otherwise empty.
- The optional Description helps to identify the API.
-
Click Next. In the Secure section, configure the
API security that you require.
- Secure using Client ID - Select this option to
require an Application to provide a Client ID (API Key). This causes the
X-IBM-Client-Id
parameter to be included in the request header for the API. If
selected, you can then select whether to limit the API calls on a per key (per Client ID) basis:
- Limit API calls on a per key basis - If selected, you must configure the
rate limit that you require. Rate limits control the maximum number of calls allowed within a time
period (hour, minute, month or day). For example, 100 calls per hour.
For information about security options in IBM® API
Connect, see Configuring API
security.
- CORS - Select this option to
enable cross-origin resource sharing (CORS) support for your API. This allows your API to be
accessed from another domain.
Note:
- CORS support is available only on the DataPower® API
Gateway.
- When CORS is enabled, the API Gateway runs the
cors
preflow policy to handle
all CORS requests that are made to the API.
- When CORS is enabled and a preflight request is received, only the following API actions are performed:
- The
cors
preflow policy configures the appropriate response headers.
- The response headers are set.
- When a preflight request is received, the
request.attributes.isCORSPreflight
flag is set to true
.
- For all preflight requests, the
security
and
client-identification
preflow policies are always skipped, whether CORS is enabled
or not enabled.
- Optional:
Select Activate
API if you
want to immediately use the API for further development and testing.
Note:
- When you select the Activate
API option, API Connect automatically completes the
following actions:
- Creates a draft Product, adds the API to the Product, and publishes the Product to the Sandbox
Catalog so that the API is available to be called. The Product has the title
api_title auto product. This Product is not visible in the
Develop view and you cannot delete it directly. However, if you delete the
API the draft Product is deleted together with the API; see Deleting an API
definition. The Product is visible in any Catalogs to which it is published. If you want to
remove the Product from a Catalog, you must do this separately; see Removing a Product
from a Catalog
- Subscribes the Sandbox test application to the Product so that you can immediately test the API
in the test environment. For information on testing an API, see Testing an API.
- You cannot use the Activate
API option if lifecycle approval
is enabled in the Sandbox Catalog for the Stage, Publish, or Replace actions. If any such lifecycle
approvals are enabled, then to be able to use the Activate
API option they must be disabled;
for information on lifecycle approval settings, see Creating and configuring Catalogs.
- To use the Activate
API option, you must be assigned a
role that has the
Product:Manage
and Subscription:Manage
permissions. The pre-supplied Developer role has these permissions by default;
if you are assigned a custom role it must have these permissions.
For more information, see Creating custom
roles.
-
Click Next to create your API definition.
The Summary panel displays messages as the definition is created, and the selected security
options and rate limits are enforced.
If you selected Activate
API,
the wizard populates an API Endpoint URL that you can use in testing. If you have also selected
Secure using Client ID, the wizard displays a Client ID and Client Secret you
can use.
-
Select one of the following options:
- To further configure your API, click Edit API. For details, see Editing an API
definition.
- If you do not want to configure your API further at this time, click the
Develop link in the breadcrumb trail to return to the welcome page; you can
then move on immediately to another task. For details on how to configure your API later, see Editing an API
definition.
Results
You created a SOAP API definition by using an existing WSDL file.
What to do next
APIs are made available to application developers by including them in a
Product, and then publishing that Product to a Catalog. For more information, see Working with Products and Working with
Catalogs.
You can also manage the Product lifecycle, and control who can see and subscribe to your Product,
by opening the Sandbox Catalog associated with your API in the
Manage page of the API
Designer UI.