Triggers Properties and Sample Code

In the triggers sections of the adapter definition document, you define the actions or events that can start an integration.

Overview

A trigger is the action or event that starts an integration. For example, a state change or an event occurrence in an application can kick off an integration.

An integration developer configures the trigger for an integration when creating a connection. The trigger sends requests from the application you're developing an adapter for to Oracle Integration.

The adapter definition document must define all the actions or events that can be triggers. The source or event producer applications calls the registered webhook endpoints. These webhook endpoints are the triggers modeled by the integration developers.

The Rapid Adapter Builder platform supports HTTP protocol to receive events. The definition of a trigger allows the adapter developer to design:

Inbound message structure
Security scheme for message ingress and validation
Mechanism to create and delete a subscription of the external application

Properties

For each trigger, you must specify the required information, such as the element to use for the request and response and how to process the data. The element to use for the request could be a business object, operation, or another element. The following information is required:

Property	Description
`displayName`	Name of the trigger that appears on the user interface when a integration developer configures the endpoint in Oracle Integration.
`description`	Tooltip for the trigger that appears on the user interface when a integration developer configures the endpoint in Oracle Integration.
`type`	Type of trigger. Notification signifies that the external source notifies Oracle Integration of the message but does not require a response. RequestResponse is a cause where the external source expects a response from the request.
`group`	Name of the group that is defined in the groups section of the adapter definition document.
`execute`	Uniform resource name (URN) that references the flow that implements the trigger. The flows are defined in the flows section of the adapter definition document.
`httpMethod`	Methodology to receive a message from the external source. For example, webhooks use a POST method with a body.
`request`	The schema for an incoming message of this trigger. The request contains `schemaType` and `schema` information. The `schemaType` defines the type of the schema, and supports only the type `application/json`. The `schema` defines the structure of the incoming message, and the structure exposed to the integration for downstream mapping. It can be an inline schema, or a reference to a schema definition in the `schemas` section of the adapter definition document. The request can refer a flow in the `flows` section. The flow implements return of the whole structure that includes both `schemaType` and `schema`. Example code: `"request": { "schemaType": "application/json", "schema": { "$ref": "#/schemas/staticInput" } }, "request": "flow:inputSchemaFlow"`
`webhook`	Third party notification message structure and includies headers, parameters,and body.
`headers`	Set of HTTP header parameters that are defined by name and type.
`parameters`	Set of query parameters defined by name and type, and models the parameters from the webhook request to trigger.
`body`	HTTP body including schema type and schema. This is similar to the request section.
`subscription`	Models the ability of the trigger to programmatically subscribe to an event if the external source supports an API that support subscription. The activation section models the subscription during activation and the delete of a subscription during the deactivation of an integration. This section consists of filter, register and deregister properties.
`filter`	Enables event filtering at server through registration, or at the client through condition. This property can also filter ping events, and specify response status for client and response filters.
`register`	References a flow that executes an API call on the external service to programmatically register to an event.
`deregister`	References a flow that executes an API call on the external service to programmatically deregister to an event.
`validationRequests`	Identifies validation requests and allows override response behavior for such requests. Validation requests cannot execute integration flows. This property consists of condition, skipAuthentication and response.condition, jq expression on an incoming request object. It returns either true or false. If true, the validation request is ignored. The output must be a JSON object that represents response status, headers and body.
`configuration`	Models the configuration option required to configure the trigger. Some triggers may require additional information that users must provide to allow runtime to function. The configuration properties are modeled as user interface widgets with data that is statically defined and fed by flows.

Sample Code

"triggers": {
   "notificationTypeTrigger": {
     "displayName": "Notification Type Trigger",
     "description": "This trigger detects when an event has been raised.",
     "group": "simpleTrigger",
     "type": "webhook",
     "httpMethod": "POST",
     "request": {
       "schemaType": "application/json",
       "schema": {
         "$ref": "#/schemas/staticInput"
       }
     },
     "webhook": {
       "headers": [
         {
           "name": "http-header-1",
           "type": "string"
         }
       ],
       "parameters": [
         {
           "name": "query-parameter-1",
           "type": "string"
         }
       ],
       "body": {
         "schemaType": "application/json",
         "schema": {
           "$ref": "#/schemas/staticInput"
         }
       }
     }
}