Introduction to Trigger Definitions

When designing your adapter, you specify the trigger models that the adapter supports. Provide this information in the triggers section of the adapter definition document. An adapter developer must specify this information when creating a trigger.

Overview of Designing a Trigger

Most business scenarios require the external applications to be able to trigger integrations in Oracle Integrations. To achieve this purpose, the Rapid Adapter Builder platform supports the webhook design pattern that allows communication between two APIs, thus enabling the adapters to receive events from external applications.

For more information about webhooks, see What is a webhook.

To support receiving events, the Rapid Adapter Builder platform provides the following functional capabilities:

  • Define the user facing identity and description of the trigger as presented on the user interface.
  • Define the design time experience required to configure a trigger by selecting fields and dependencies.
  • Define the security policy or the logic required to validate the inbound message.
  • Define the inbound contract and inbound message structure to structure and present the information to the integration developer.
  • Support for post-processing hooks to customize and transform the message before exposing to the integration.
  • Support for subscription logic that uses activation and deactivation to automatically register and deregister a webhook.

Components of a Trigger

The adapter definition document allows the adapter developer to design a trigger object that can receive events sent by external applications and services. A trigger object includes the following design time related components:

  • Identity

    Description of the identity of the adapter and is defined by properties.

  • Trigger contracts

    The contracts for the trigger that models both the webhook HTTP request and the request exposed in the mapper for the integration developer.

  • Subscription registration

    A subscription object that allows the registration and deregistration of the webhook.

    For more information about registering a subscription, see Register and Deregister a Subscription.

  • Security

    Allows the adapter developer to define the logic for authentication schemes. This custom logic can validate whether incoming requests are received from the correct sender and according to the security policy defined in the connection.

  • Configuration

    Configuration models that are driven by user selections or integration developers.

For more information about trigger properties, see Triggers Properties and Sample Code.

For more information about how to categorize triggers, see Update Category Definitions.

Runtime Implementation of a Trigger

The trigger can also reference the logic required for the execution of the trigger. Runtime implementation is primarily used to transform the incoming data if it is not in a human-readable format. For more information about runtime implementation of triggers, see Runtime Implementation of Triggers.

Tools to Build a Trigger

The adapter developer can author the code for a trigger in the following ways:
  • Use the Rapid Adapter Builder extension on Visual Studio Code to convert a postman collection to the adapter definition document, and subsequently modify the triggers section according to the requirements.
  • Manually author the JSON code from scratch for the trigger object in the adapter definition document.