Activate an Integration

Once you have completed design of your integration and resolved any errors, you can activate it to the runtime environment. You can activate an integration in Oracle Integration to begin processing messages. You can also individually activate an integration in a project.

Note:

If you activate a new version of an existing integration, tracking instances or logs of the old version are not deleted. However, related artifacts are deleted and redeployment is performed on the back end. Monitoring data is also removed.

Understand Restrictions About the Number of Active Integrations

The number of active integrations per Oracle Integration instance cannot exceed 800. Active integrations are defined as currently active integrations and integrations whose activations are in progress.

• If you reach 90% of this limit, the following warning is displayed:

  You've number integrations which are either active or whose activation is in progress. 
  It is more than 90% of the allowed limit. 

• If you reach the limit of 800, the Activate or Activate & Schedule button to activate an integration is disabled and the following warning is displayed.

  You've reached the limit as there are 800 integrations which are either active 
  or whose activation is in progress. Deactivate or abort the activation of an integration 
  and try again.

  If you are nearing your limit, review and delete any older integrations that are no longer required.

Activate an Integration

1. Decide where to start:
   • Work in a project.
     1. In the navigation pane, click Projects.
     2. Select the project name.
     3. Click Integrations .
     4. In the Integrations section, find the specific integration to activate.
     5. Click Actions , and select Activate.

        The Activate integration panel opens.

   • Work outside a project.
     1. In the navigation pane, click Design, then Integrations.
     2. Find the specific integration to activate.
     3. Hover over the integration to activate, then click Activate .

        The Activate integration panel is displayed.

2. Select the level of tracing appropriate to your integration. This level describes the amount of data to capture in the activity stream. The tracing level has no impact on billing.

   WARNING:

   The Audit and Debug (Not recommended) tracing levels are not recommended for a production environment. These options may slow down your system and also present a security risk because sensitive information from the payload is logged.

   Element	Description
   Tracing	Select the level of tracing information to log to the activity stream. Production: Logs all actions with the exception of loops and invoke/logger actions inside of loops (up to 1000 iterations) to the activity stream. Data is retained in the activity stream for 32 days. Note: Oracle Integration for Healthcare data is retained for 184 days. Audit: Logs the same data to the activity stream as the Production option, along with wire payloads of triggers and invokes. Data is retained in the activity stream for eight days. Wire payloads are the payloads sent and received over the wire by Oracle Integration while communicating with third-party applications. These communications either happen through triggers (where Oracle Integration receives the initial triggering message) or invokes (where Oracle Integration sends and receives data). The data in these payloads is untranslated and in the same format understood by the external applications/services that send and receive these payloads. Debug (Not recommended): Logs the same data to the activity stream as the Production and Audit options along with all payloads and all actions inside loops (up to a 1000 iterations). Data is retained in the activity stream for 24 hours. After that time period elapses, all payload, activity stream, and business identifier data is purged and a minimal amount of instance information is retained for 32 days. Note the following: After 24 hours, Debug (Not recommended) is automatically reset to Production. This reset cannot be bypassed. Explicitly reset the tracing level to Production or Audit when debugging is complete. Do not rely on the 24-hour automatic reset. The actual reset may take longer than 24 hours if no messages are processed by a given integration. See View Minimal Details About Debug Tracing Level Instances for 32 Days. See Activity Stream Details.
   Allow to run again	This check box only appears for REST Adapter-triggered and AS2 Adapter-triggered integrations. Select this check box if you want to replay an instance of this integration during runtime. See Replay Integration Instances.
   Enable payload validation	Select to validate inbound JSON payload syntax during activation of REST Adapter trigger connection-based integrations. Validation consists of checking for duplicate keys in the payload. If you select this option, it remains selected by default. For example, if you later deactivate and reactivate,the integration, the check box remains selected. You must explicitly deselect this check box if you no longer require its use.
   Edit/Add Schedule	Select to add or edit a schedule for this integration now. This invokes the page for adding or editing an integration schedule.

3. If integration activation is unsuccessful, the status of the integration changes to Failed in the Status column. Click the Open Details icon to see the error.
   If your integration includes a function that is not completely configured, an error message is displayed in the banner. You must complete configuration of this function before you can activate the integration. Click inside the integration and note the following errors/warnings:

   • An error icon is displayed on the function call action that uses the incomplete function. The Error panel on the right side of the integration canvas provides specific details about the incomplete function.

   • A warning icon is displayed on the mapper that uses the inputs and outputs of this function. After completing function configuration, you must verify the input and output mappings before activating the integration.

     If activation is successful, the status of the integration changes to Active in the row.

4. If integration activation is successful, an Active message is displayed in the Status column.
   Additional messages can also be displayed:

   • If you selected Audit during activation, an Audit Tracing message is displayed after Active.
   • If you selected Debug (Not recommended) during activation, a Debug Tracing message is displayed after Active.
5. For REST Adapter trigger-based integrations, click Actions , then Run to display the Configure and run page to run, test, and track instances for this integration. See Test Integrations from Outside the Integration Canvas.

Behavior of Running Instances When a Minor Integration Version is Activated

When activating the minor version of an application or schedule integration (for example, 1.0.1) while the major integration version (1.0.0) is still active, all running and failed instances for major integration version 1.0.0 complete without being terminated. All new requests are then handled by integration version 1.0.1.

The following behavior occurs to ensure zero downtime:

• Integration version 1.0.0 is activated with running, in-progress instances.
• Integration version 1.0.1 is then activated.
• All new instance requests are routed to integration version 1.0.1.
• Integration version 1.0.0 remains activated, but does not receive any new requests.
• All running instances of integration version 1.0.0 complete running (no instances are terminated).

  Note:

  It is recommended that you not import, overwrite, or delete an integration until all running instances complete.
• Integration version 1.0.0 is then completely deactivated.

  Note:

  For schedule integrations, all queued instances are paused and all in-progress instances are allowed to complete. No operations other than stopping or deleting a schedule are permitted. When all instances complete, the schedule integration is deactivated.
• If any instances of integration version 1.0.0 fail, integration version 1.0.1 is used for resubmitting.

Let's view a simple use case:

1. Activate an integration (for this example, MINOR_VER_REST version 1.0.0).

   
   
   

2. Run MINOR_VER_REST version 1.0.0, which creates an in-progress instance that's visible on the Observe tab.

   
   
   

3. Activate MINOR_VER_REST 1.0.1, which automatically deactivates integration version 1.0.0.

   
   
   

4. Run MINOR_VER_REST 1.0.1, which creates an in-progress instance that's visible on the Observe tab. The version 1.0.0 instance is not terminated. Both instances are shown as in-progress.

   
   
   

5. Refresh the Observe tab and note that the version 1.0.0 instance completed successfully.

   
   
   

6. Refresh again and note that the version 1.0.1 instance also completed successfully.

Any new instance requests are handled by integration version 1.0.1.