Introduction to Flow Definitions

The flows section of the adapter definition document defines the runtime and design-time activities that an adapter is capable of.

The following examples show how your adapter might use flows:

Design-time examples

  • When an integration developer is configuring a connection based on your adapter, flows can pull data from an external application and display the data in the user interface.
  • When an integration developer selects a custom object in the Integration Designer, flows can drive the dynamic schema.

Runtime examples

  • Invoke APIs.
  • Start preprocessing activities, like transforming a JSON payload to an avro string.
  • Perform post processing, like transforming the avro-encoded data to a JSON key value.

Capabilities of flow definitions

Flow definitions support the following capabilities:

  • Cloud Native Computing Foundation (CNCF) Serverless Workflow specification as DSL

    CNCF Serverless Workflows provide open-source, vendor-neutral DSL to define workflows.

  • Expressions and additional custom functions, per Serverless Workflows guidelines
  • Logging and outbound calls through custom Serverless Workflow functions
  • jq expression language
  • Custom jq functions to simplify preprocessing and postprocessing
  • Accessing input and output context using dot (.) notation
  • Multiple states, state transitions, and filtering

Note:

The adapter definition document supports only a subset of the available serverless workflow constructs. The Rapid Adapter Builder platform ensures that the flow definitions are compliant with the adapter definition document specification.

In the adapter definition document, you can use flow definitions in:

  • Test connection

    Use flows to express test behavior for connections. The flow must return true or false in the output. For example, the flow can return true if the test connection is a success.

  • Actions

    • Execute: Process actions during integration runtime execution.

    • Input: Build input schema for actions in design time.

    • Output: Build output schema for actions in design time.

    • Configuration: Fetch dynamic values for configuration properties in design time.

  • Triggers

    • Request schema: Define the schema of a request for Oracle Integration in design time.

    • Webhook schema: Define the schema of a webhook request in design time.

    • Configuration: Fetch dynamic values for configuration properties in design time.

    • Subscription
      • Register a webhook with a target application.

      • Unregister a webhook from a target application.

    • Validation requests
      • Identify a validation request.

      • Build a response/out-of-band acknowledgment for a validation request.

    • Inbound authentication signature policies, such as HMAC_SIGNATURE_VALIDATION, RSA_SIGNATURE_VALIDATION, and JWT_VALIDATION

Flow definitions for execution scenario

As the adapter developer, you can access requests, orchestration inputs, action/trigger configurations, and connection properties as context items using the dot (.) notation in the flow definitions. Additionally, you can add temporary context variables. After you define the output in the flow definition, Oracle Integration can consume and interpret the output.