Service Chain

A service chain is a configuration of Web Services that operate in a defined sequence, where the outputs from one are available for use as inputs to the next. (Such a sequence could also be called a service pipeline.)

About Service Chains

Some Web Services (like the platform's REST APIs), require a separate login step. The configuration procedure for that two step connection is described here. For Web Services that do not require login, or that allow login credentials to be supplied as part of the request, you can configure a single-step service using either the SOAP or REST process explained earlier, and configure the Basic Auth parameters, as needed. But for a login-controlled service, a two-step connection makes sense.

In addition to supplying credentials for login-controlled services, there are other scenarios in which a service chain is useful:

• Get an access key of some kind.

In a banking system, for example, a routing number and account number might be supplied to get a one-time authorization key for a single transaction.

• Get other data required by the next step in the chain.

In a commodities purchasing system, for example, one service might get the current price. That value could then be fed into a another system that gets the current exchange rate for the customer's currency. That combination of values would determine how much could be purchased for a given amount.

Note: It is possible to set up a two-step sequence in a Process Model. But it is generally wiser to define the steps in the Web Service configuration, for a number of reasons: If configured in the process model, the steps need to be repeated in every process that accesses the service. As part of the Web Service, on the other hand, the configuration is done only once. With the service configured, process modelers don't need to worry about protocol details. They can focus their attention on the business problem they are trying to solve. In addition to being available for use in a process, a two-step service can be used for an External Lookup or as an External Data Source.

Create a Service Chain

A two-step service chain consists of a pipeline service and an endpoint service. The pipeline service makes outputs available to other web services. The endpoint service, on the other hand, can use a pipeline service for one or more of its inputs.

Considerations

• The maximum number of links in the chain is two (hence the term, "two-step chain").
• The inputs to the pipeline service must be hardcoded values or expressions.
• A pipeline service can be accessed only by other Web Services. It is not available for use in other contexts.
• An endpoint service is available for use anywhere that a normal single-step service can be used--for example, in a Process, an External Lookup, or an External Data Source.

Note: In the steps that follow, the platform's REST API is used as an example. In that context, logging in sets up a valid session. The session ID is stored in a cookie, which is then included in subsequent requests for as long as the session remains valid. (It will typically timeout after a period of inactivity.) The details will vary for any particular service, but that is the general idea behind a login-controlled service.

First, set up the Web Service that will be used to log in to the remote server:

1. Give the Web Service a name (the Title).
2. Configure the header parameters.

   For a platform REST request, for example, you would enter Accept to specify the format for returned data (XML or JSON).

3. In the first configuration page, select Login Service.
4. Configure other parameters (for example, Basic Auth, if applicable).
5. Click [Next]
6. Configure inputs that are required to login.
7. Click [Next]
8. Configure outputs from the Web Service

   For the outputs that need to be included in subsequent requests, __TBD__.

   For the platform's REST login resource, for example, you would save the sessionId value.

9. Click [Save]

Next set up the Web Service that will be used to make the service request:

1. Give the Web Service a name (the Title).
2. Configure the header parameters.

   For a platform REST request, for example, you would specify Cookie,Accept, where the cookie parameter will contain the session ID, and the Accept parameter will specify the format for returned data (XML or JSON).

3. For the inputs that need to be provided by the login service, __TBD__.

   For example, to provide the session ID in the cookie format expected by the platform REST APIs, you would map the input Cookie parameter using the expression: 'JSESSIONID='+platform.login.sessionId, where platform.login.sessionId is the path to the valu provided by the login service.

4. Configure other inputs and outputs normally.
5. Click [Save]