Workflow to Implement a Trigger

Complete the Prerequisite Tasks

Before you start authoring a trigger definition, complete the following prerequisite tasks.

Understand the requirements of the adapter you plan to build.
Understand the type of integration tasks that the adapter should support.

That is, understand the actions that the adapter must support, including the contract that needs to be exposed to the integration developer in the mapper.
Model and test the authentication through the connection definition.
Understand and be able to test the external application's API.

You may require a test-development account with the external application or service.

Design the Trigger

As a first step, you must:

Determine the behavior of the trigger.
Determine the event that triggers the runtime execution.

For example, an external application may send an order-create event as a webhook. Determine if this event should be a trigger in your adapter.

Test an Event with a Request Bucket

After you identify the required event, test it using various request buckets, such as mockable.io, request.bin, or webhook.site. These sites expose an endpoint that the external application can send an event for testing. The request buckets show the event body and the various headers that are part of the event.

Create a Basic Trigger

Using the VS Code extension for Rapid Adapter Builder, create the skeletal trigger code from a template and modify it to map to the event you have tested.

The creation of the input schema is important. Using the payload of the event (which can be obtained from the request bucket), you can convert the JSON content into a JSON schema for the purpose of designing the webhook.

Note:

To quickly 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 an integration flow to use the trigger and verify if it is working as expected. Using the same steps that you used 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 limitations:

Manual registration of subscription on the external application's administrative user interface.
No message validation or authentication.
A static-event message structure according to the modeled event, received in the request-bin test.

Enhance the Functionality of a Trigger

The basic implementation of a trigger supports only 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.

However, for real-world business scenarios, you may need to enhance the functionality of the trigger. For example, an action that can create a customer object in Oracle ERP may require the integration developer to enter or select custom attributes that have been modeled by the ERP administrator. These custom attributes vary based on the ERP system instance.

To handle such complicated functionalities, refer the following topics: