Workflow to Implement a Trigger

Prerequisites to Author the Code for a Trigger

The adapter developer:

Understands the requirements of an adapter.
Understands the type of integration tasks that an adapter supports.

Knows the actions that the adapter must support. The adapter developer must evaluate and understand the contracts that need to be exposed to the integration developer in the mapper.
Implements the authentication through the connection definition and execute a test connection.
Understands the external application's API and knows how to test the API.

This step may require a test development account with the external application or service.

Implement a Trigger

The following topics provide an overview of how to design a trigger.

Design the Trigger

Before you start to author the code for a trigger, the adapter developer must:

Determine the behavior of the trigger.
Determine the event required for runtime execution.

For example, the external application or service sends an event that is a webhook to create an order. The adapter developer must determine which event can act as a trigger in the adapter.

Not all events qualify based on whether the event makes sense within an automation context.

Test an Event with a Request Bucket

Once required event is identified, the adapter developer tests it using various request buckets such as mockable.io, request.bin, or webhook.site. These sites expose an endpoint to the external application or service so that the event is received for testing. The resultant request buckets show the event body and the various headers that are part of the event.

Create a Basic Trigger

The adapter developer now uses the Rapid Adapter Developer extension to create the skeletal trigger code from a Postman Collection template. Subsequently, the adapter developer modifies the generated trigger code to:

Map to the required event.
Create the input schema.

Using the payload of the event obtained from the request response, the adapter developer can use various online tools to convert the JSON content into a JSON schema for the purpose of designing the webhook.

Note:

To quickly ensure and test the delivery of an event and its usage in an integration, send the event without any security policy.

Test the Trigger

To test the trigger using Oracle Integration in runtime, design a flow that executes the trigger. Verify whether the behavior of the trigger is according to the requirement. Using the same steps to trigger the event for the request bin, kick off an event and ensure that the integration is working.

This basic trigger implementation may have the following requirements:

Manual registration of subscription on the external application's administrative user interface.
Message is not validated and authenticated.
Implements a static event message structure according to the modeled event received in the request bin test.

Enhance the Functionality of a Trigger

The bare minimum implementation of a trigger includes supporting a specific event and the event schema is defined by the request bin test. It also requires the user to manually register and deregister the trigger.

The following business scenarios provide an idea of how to enhance the functionality of a trigger:

Query Microsoft Outlook Mail for emails that match a specific search string.
This implementation may require selection of a folder and the action may require the internal identifier for the folder.
An action that can create a customer object in Oracle ERP.
The integration developer may need to enter or select custom attributes that are provided by the ERP administrator. These custom attributes vary based on the ERP system instance.

To handle such complicated functionalities, refer Use Postman Conversion of Flows to Design Configuration Fields and Use Postman Conversion of Flows to Model Dynamic Schema.

Configure the Trigger

Some business scenarios may require the integration developer to configure the trigger. As part of configuration activities, the integration developer can select values from a list of options or enter information on the user interface in Oracle Integration.

For example, the external application or service may provide a generic mechanism to receive an event from any object such as a creation event. However, the configuration of the trigger requires the user to select the type of object to monitor. In this scenario, the integration developer must select the object.

When an action requires configuration, the Rapid Adapter Builder platform provides an adapter page where the integration developer can configure by selecting values, entering text, or enter data in complex multi-values table. These user provided values can be used for schema generation for the integration mapper or for runtime execution.

On the configuration page, the Rapid Adapter Builder platform supports design of multiple user interface components like dropdown selection, text input, etc. For more information, refer Design User Interface Components of an Adapter and Design of Configuration Fields.