A Web Service Consumer (WSC) object requests and processes information or activity from a service provider using request messages. The provider defines how those messages must be structured.
CIC supports both SOAP/WSDL and REST. A REST WSC references a single Service.
To expose a service rather than consume one, use a Web Service Provider object.
Relationship to API Consumer Endpoints (CIC Cockpit)
When you create WS Consumer objects in CIC Studio and deploy them to the Integration Server, CIC Cockpit auto-generates API Consumer Endpoints. Multiple WS Consumers that reference the same host and vault alias are combined into a single endpoint, which you can view on the Jobs page. See API Consumer Endpoint for details.
Creating a Web Service Consumer
- Select File | New | Web Service Consumer.
- Choose the consumer type: REST or SOAP/WSDL.
- For SOAP, you must supply and validate the provider’s WSDL. It specifies the service’s IP address and port, the available operations, and the XML Schemas for incoming and outgoing messages (and WS-Security, if used). Use these schemas to build your request and interpret the response.
- Continue with the steps for your type below. At the end of either flow, you select a Source folder, Package, and Name. The name also becomes the name of the service, so use a descriptive name that follows your recommended naming conventions.
- Click Finish. An editor opens for further configuration.
Defining a REST Consumer
This identifies the active REST service and configures how it is used.
Settings
| Field | Purpose |
|---|---|
| URL | Location of the service. May include a substitution variable (see below). |
| HTTP Method | REST operation to perform: GET, POST, PUT, or DELETE. |
| Timeout | When a connection attempt to the provider is terminated if no response is received. |
| Retry Count | Number of reconnection attempts. |
| Retry Delay | Seconds between retry attempts. |
| Transfer Type | Chunked: payload is split into smaller units sent one at a time. Content-Length: the entire payload is sent at once. |
| Vault Entry Alias | Alias of the vault entry this object should use. See Secure Authorization of Web Service Requests using the Server Vault. |
Secure URLs: For HTTPS URLs, you may need to import the target’s certificate into the CIC Studio Keystore before connecting.
Substitution variables: You can use a placeholder for all or part of the URL, with the actual value supplied at runtime by a Business Process. For example, in https://api.bestbuy.com/v1/products/${productId}.json, ${productId} is replaced with a real product ID at runtime.
Default Request HTTP Headers (optional): In this section, click Add to define headers sent to the remote server each time the consumer runs. These are default values; a Business Process can override them at runtime.
Once saved, the object is available as a task in a Business Process.
Defining a SOAP Consumer
This sets up the resources needed to consume a SOAP service. The wizard proceeds as follows:
- WSDL location: Choose a URL or filesystem location (browse a workspace or elsewhere). Click Next.
- Validate: Click Validate WSDL Location. An invalid location blocks you from proceeding. Click Next.
- Save resources (optional): Select Save WSDL and XSDs to workspace to retain them, mainly for version control. Click Next.
- Select operation(s): Each WSDL service exposes operations with optional request and response formats. Select at least one. Click Next.
- Select types (if applicable): Choose Base Types and their inherited Derived Types for the selected operation. The Base Type is the type the selected operation directly inherits from, and a Derived Type inherits further from the Base Type. Operations without base types skip this panel.
- Name the object: Provide the Source folder, Package, and Name, then click Finish.
What gets generated
A new Package is created in the Workspace, along with companion objects:
- XML Schema for the request message
- XML Schema for the optional response message
If the WSDL contains WS-Security policies, the editor references the security policy at the bottom of the screen, and authentication can occur via the displayed username/password requirements.
Advanced Configuration
API Proxy for API Consumers
CIC often needs to reach a customer’s internal APIs that aren’t exposed outside their network. API Proxy support (REST and SOAP) routes these calls through an Access Point. Setting an Access Point is optional and the field can be left blank. It requires CIC Studio v5.2.13 or above.
- In CIC Cockpit > Network > Access Point, create an Access Point if one doesn’t already exist.
- In CIC Studio, open the API Consumer that needs the proxy.
- In the AccessPoint section of the editor, select the new or an existing Access Point.
- Save and close the editor.
- Deploy the API Consumer.
Result: When the consumer is invoked, CIC uses the Access Point to connect to the internal endpoint.
WS-Security Authentication for SOAP Consumers
Complete these steps before the step that invokes the consumer:
- Create a manual auth vault of Basic type.
- In the BPS file, add a new step and select Process Environment - Set Value.
- Create a variable for Environment Variable Name with the initial value
addWSSecurityHeader. - Create a variable for Environment Variable Value with the initial value
true.
Comments
0 comments
Please sign in to leave a comment.