Once started, a Web Service Provider (WSP) object detects incoming requests and can process them based on the additional configurations you make with other objects. For example, a consumer could request and obtain information about a specific purchase order in your database.
This object currently supports the REST method.
Web Service Providers and the API Endpoint (in Cockpit)
API Provider Endpoints are auto-generated in the CIC Cockpit when Web Service (WS) Provider objects are created in CIC Studio and deployed to the Integration Server. Multiple WS Provider objects referencing the same host and vault alias value are combined into a single API Endpoint, which can be viewed from the Jobs page. See API Provider Endpoint for more information.
How to create a Web Service Provider (REST)
A wizard assists with creating this object. Upon saving the Web Service Provider (REST) object, the following automatically takes place:
- both the HTTP and HTTPS versions of the URL (Location of service) are constructed, which can then be provided to consumers
- a Business Process is generated
When creating a Web Consumer (REST) object, you define different options and settings. This includes the URL location of the service, as well as the HTTP methods to be used. Once saved the Web Service Consumer object can be called as a task in a Business Process.
Create a Web Service Consumer to create and configure the objects that are used to request and process information or activity from a provider through the use of request messages.
- Select File | New | Web Service Provider from the main menu.
- Select a type - currently, the only choice is REST. Click Next to proceed.
- Select Source folder, Package, and Name.
Note: Since the name you select here will also be the name of the service to be provided, it is good practice to include descriptive naming (while following recommended Naming Conventions).
- Click Finish. An editor appears.
How to define a Web Service Provider (REST)
Defining this object identifies the active service made available by a provider using the REST protocol, and allows you to configure settings on how the service is to be consumed.
- Under the Settings section, enter the name of the service.
If you are connecting to a secure (HTTPS) URL you may need to import its certificate in the CIC Studio Keystore prior to connecting.
- Business Process. This should be pre-populated, as the Studio automatically creates a corresponding package containing a Business Process, which is preconfigured with the Web Service Provider object just defined in this task. The Business Process contains two tasks: SendRestReply, which sends the response message to a consumer, and SetExitStatus, which sets the Business Process’s Exit Status to true. All task parameters are pre-populated.
Additional configuration is required.
Any additional tasks will need to be added and defined to the Business Process. For example, some additional tasks might include determining the requested purchase order number (using GetProperty), gathering the data, and generating an e-mail (SendEmail).
- Configure HTTP Basic Authentication Validation for this Web Service Provider. Select OAuth2_Client_Credentials (the only option available currently) from the Authorization Type drop-down and contact your Account Manager or Cleo Support for assistance completing this configuration.
Note: It is also possible to configure No Auth or Basic Auth for your Web Service Provider. Please contact your Account Manager or Cleo Support for assistance completing authentication configuration, whether for OAuth2, No Auth, or Basic Auth.
- Under the Default Response HTTP Headers section, include any additional Header information required as part of the consumer request.
HTTP header fields are components of the message header of requests and responses used in HTTP. They define additional information about the request to and response from the service provider. This additional information may be sent with the status codes. This may include required authentication info, such as user name and password, or just additional information about the requester. They can be used to override common headers, or create custom ones. Examples of common header fields include cookie, ETag, Location, HTTP referer, DNT, and X-Forwarded-For.