Siebel Outbound Service to Open Integration

This topic describes how to use the OpenIntegration Outbound Service business service to enable synchronous communication from Siebel CRM to the Open Integration microservice by using Perimeter authentication or OAuth User Assertion authentication.

Use the OpenIntegration Outbound Service business service for synchronous communication from Siebel to the Open Integration microservice. This business service supports communication by using Perimeter authentication or OAuth authentication with the UserAssertion grant type.

Outbound Business Service Arguments

The OpenIntegration Outbound Service accepts the following arguments for communication with Open Integration:

• integrationname:api: Name of the integration deployed in the Open Integration microservice to invoke.
• username:security: User name to use for Perimeter or UserAssertion.
• authtype:security: Authentication type. Supported values are Perimeter and OAuth.
• granttype:security: Grant type supported in the OAuth model. Currently, only UserAssertion is supported.
• preauthheader:security: Header name to use for Perimeter authentication.
• accesstokenurl:security: Access token URL to use for OAuth authentication requests.
• scope:security: Scope to use for access token generation.
• clientid:security: Client ID to use for IDCS access token generation.
• clientsecret:security: Client secret to use for IDCS access token generation.
• audience:security: Audience for which the access token is requested.
• subsystem:security: Parameterized option to override the subsystem configured for the Business Service.
• refreshfrequency:security: Time interval at which the access token must be invalidated.

Subsystem

The OpenIntegration Outbound Service business service uses OpenIntegrationSubsys as the default named subsystem. You must configure the subsystem containerURL with the load balancer URL of the OpenIntegration microservice. The target microservice URL is computed as containerURL + “/v1.0/integration/” integrationname.

Config Agent Tomcat Configuration

When authtype:security is set to OAuth, configure the following properties in configagent.properties for Config Agent Tomcat. These properties are required to form the JWT token used in UserAssertion.

• ClientCertKeyAlias: IDP key ID, or kid value. This is the alias or key ID registered in Identity Provider (IDP) for the signing certificate and sent as the JWT header key ID, kid. It tells IDP which registered certificate to use for signature verification.
• PrivateKeyAlias: Alias of the private key used to sign the JWT token.

Input and Output

Any argument passed to this business service that is not a business service argument is considered input.

You must define the required input and output in the Open Integration DSL. Requests made through this business service are mapped to the DSL input and output.

The business service generates the following output structure:

• body.RespBody: Response body for the request.
• header.RespHeader: Response headers set in the Open Integration flow.
• status.HTTPStatusCode: Status set by the Open Integration flow.

Sample DSL Mapping

The following sample maps the Open Integration DSL input and output to the SWIOrderIO integration object.

{
  "input": {
    "type": "object",
    "required": ["SiebelMessage"],
    "properties": {
      "SiebelMessage": {
        "type": "IntegrationObject",
        "IntegrationObject": "SWIOrderIO"
      }
    }
  },
  "output": {
    "type": "object",
    "properties": {
      "SiebelMessage": {
        "type": "IntegrationObject",
        "IntegrationObject": "SWIOrderIO"
      }
    }
  }
}

In Siebel Workflow, map the output to the required properties as needed.

JWT Generation

For the OAuth authentication flow with UserAssertion, the Siebel Server communicates with Config Agent Tomcat to invoke the JWT Builder Service (JBS) service. The JBS service returns the JWT token used for the rest of the process.

Update the JAVA64 subsystem containerURL with the corresponding Config Agent server JBS URL.

Caching and Refresh

The Siebel server caches the access token and refresh token generated from IDCS and reuses them in subsequent requests until expiry. The access token is regenerated if it exceeds the expiry or refreshfrequency duration. If a refresh token exists, it is used to regenerate the access token.

Note: Refresh tokens older than one day are invalidated by the server.