About Connecting to On-Premises Applications with the Connectivity Agent

You can configure access to resources residing in an on-premises network in Oracle Integration.

About Creating Hybrid Integrations Using Oracle Integration

Many business use cases require integration between applications hosted on public cloud and resources residing in an on-premises network or private cloud. For example, consider a business case where a quote or sales order configured through an Oracle Configure Price Quote (CPQ) application must be sent to an Oracle E-Business Suite application, hosted in an on-premises network, for creation and fulfillment of the sales order. To facilitate such hybrid integrations, Oracle Integration provides the necessary infrastructure and architecture patterns.

This type of hybrid integration enables you to have flows hosted on Oracle Integration that:

  • Access SOAP/REST endpoints exposed by applications such as Oracle E-Business Suite, Siebel, and JD Edwards, and any on-premises home grown SOAP/REST APIs

  • Access non-HTTP-based endpoints such as databases, JMS, AQ, local file systems, SAP, and others

These capabilities enable you to implement use cases such as the following:
  • Send requests from a cloud application (for example, send a create service order request from an Oracle Service Cloud application) to an on-premises E-Business Suite application

  • Synchronize bulk data extracts of a product from a product data hub in Oracle ERP Cloud with an on-premises Oracle database or an Oracle Database Cloud Service instance

  • Synchronize customers that are added/updated in an on-premises SAP application with SaaS applications such as Oracle CX Sales and B2B Service Adapter, Oracle CPQ, Oracle Service Cloud, and Salesforce.com

Oracle Integration provides a component called the connectivity agent to facilitate hybrid integrations. See About the Connectivity Agent.

For different connection patterns you can use to create hybrid integrations, see Connection Patterns for Hybrid Integrations.

About the Connectivity Agent

Using the connectivity agent, you can create hybrid integrations and exchange messages between applications in private or on-premises networks and Oracle Integration. The connectivity agent framework extends reach of Oracle Integration to non-internet accessible systems. The connectivity agent also provides multithreading support, which allows for multiple executors to perform downstream message processing.

For supported connectivity agent message payload sizes, see Service Limits in Provisioning and Administering Oracle Integration 3.



Connectivity Agent Components

The connectivity agent consists of the following components:

  • Cloud agent: This agent is installed and runs in Oracle Integration and supports communication with on-premises applications.

  • On-premises agent: This agent is installed and runs in an on-premises environment on the same network as internal systems such as Oracle E-Business Suite, Oracle Siebel, Oracle Database, and others. You download the on-premises agent installer from the Agents page in Oracle Integration to your on-premises environment for installation. A connectivity agent can support multiple target systems. An Oracle Integration instance can support multiple agent groups, each with up to two agents, in a cloud/on premises topology. The on-premises connectivity agent establishes connections with the cloud agent for message processing.

Connectivity Agent Functionality

The connectivity agent provides the following functionality:

Note:

While multiple connectivity agents can run on a single host, this is not the recommended practice. If you follow this practice, you must ensure that the physical host has enough resources to run multiple connectivity agents.
  • The connectivity agent opens no ports on the on-premises system for communication.

  • All communication is secured using TLS.

  • The on-premises connectivity agent registers with Oracle Integration over TLS using OAuth with the connectivity agent-specific authentication generated by Oracle Integration.

  • The on-premises connectivity agent checks for work by making outbound requests through the firewall.

  • The on-premises connectivity agent can use a proxy to access the internet (the same proxy as other internal applications and browsers use). Authentication support for outbound proxy access is provided.

  • The on-premises connectivity agent connections are configured by the agent retrieving the configuration details from Oracle Integration.

  • The on-premises connectivity agent processes requests by pulling messages from Oracle Integration across TLS.

  • The on-premises connectivity agent posts responses by pushing messages to Oracle Integration across TLS.

  • All communication is initiated by the on-premises connectivity agent.

  • The on-premises connectivity agent does not support trigger/polling for REST/SOAP endpoints.

  • Adapters such as the Oracle E-Business Suite Adapter, Oracle JD Edwards EnterpriseOne Adapter, Oracle Utilities Adapter, and Oracle Siebel Adapter even when enabled with the connectivity agent invoke Oracle Integration for direct message processing when invoking integrations.
  • No existing J2EE container is required to deploy the on-premises connectivity agent.

  • No data is persisted in the on-premises agent.

Adapter Connections that Work with the Connectivity Agent

Any callbacks using REST/SOAP do not go through agent, but go directly to Oracle Integration. The on-premises connectivity agent works with the following adapter connections.

  • Outbound (invoke) adapters: The following adapters can be configured as invoke connections in an integration to support communication with endpoint applications:

    • Amazon Simple Queue Service (SQS) Adapter

    • Amazon Simple Storage Service (S3) Adapter

    • Apache Kafka Adapter

    • Azure Active Directory Adapter

    • Azure Event Grid Adapter

    • Azure Service Bus Adapter

    • Azure Storage Adapter

    • Confluent Adapter

    • File Adapter

    • FTP Adapter

    • GraphQL Adapter

    • IBM DB2 Adapter

    • IBM MQ Series JMS Adapter

    • Microsoft SQL Server Adapter

    • MySQL Adapter

    • Netezza Adapter
    • OData Adapter
    • Oracle Advanced Queuing (AQ) Adapter
    • Oracle Autonomous Data Warehouse Adapter
    • Oracle Autonomous Transaction Processing Adapter
    • Oracle Database Adapter

    • Oracle Database Cloud Service Adapter
    • Oracle E-Business Suite Adapter

    • Oracle JD Edwards EnterpriseOne Adapter
    • Oracle Siebel Adapter

    • Oracle SOA Suite Adapter
    • Oracle Utilities Adapter

    • Oracle WebLogic JMS Adapter

    • PostgreSQL Adapter
    • REST Adapter

    • SAP Adapter

    • SAP ASE (Sybase) Adapter
    • SOAP Adapter

  • Inbound (trigger) adapters: The following adapters can be configured as trigger connections in an integration. Trigger adapter use with the connectivity agent is accomplished with polling or direct message processing:

    • Polling:
      • Apache Kafka Adapter

      • Azure Active Directory Adapter

      • Azure Service Bus Adapter

      • Confluent Adapter

      • File Adapter

      • IBM DB2 Adapter

      • IBM MQ Series JMS Adapter

      • Microsoft SQL Server Adapter

      • MySQL Adapter

      • Netezza Adapter
      • Oracle Advanced Queuing (AQ) Adapter
      • Oracle Autonomous Data Warehouse Adapter
      • Oracle Autonomous Transaction Processing Adapter
      • Oracle Database Adapter

      • Oracle Database Cloud Service Adapter
      • Oracle WebLogic JMS Adapter

      • PostgreSQL Adapter
      • SAP Adapter

      • SAP ASE (Sybase) Adapter
    • Direct message processing:
      • Oracle E-Business Suite Adapter

      • Oracle JD Edwards EnterpriseOne Adapter
      • Oracle Siebel Adapter

      • Oracle Utilities Adapter

Connection Patterns for Hybrid Integrations

Use the connectivity agent in any of the following patterns to set up a connection between an application on your private (or on-premises) network and Oracle Integration.

Note:

You are responsible for configuring your own network routing rules. If you don't know how to configure these rules, contact your network team for assistance.

You can set up a connection over the public internet or select to configure an exclusive connection using FastConnect, which provides a faster, more reliable networking experience compared to the internet. You'll use the connectivity agent to communicate with Oracle Integration irrespective of the connection pattern you select; employing FastConnect only ensures that the traffic between your private (on-premises) network and Oracle Integration doesn't go over the public internet and remains private.

The patterns you can use are listed here:

Public Internet Pattern

Install the connectivity agent on your private (on-premises) network. The inbound and outbound traffic to Oracle Integration goes over the public internet. For the outbound traffic from Oracle Integration, the connectivity agent initiates a secure connection to Oracle Integration, retrieves the request, and then invokes the required API in the on-premises application.

When you employ the connectivity agent, you don't have to open firewalls to access applications on your private network. In addition, all messages between the private network and Oracle Integration are encrypted.

To install and configure the connectivity agent, see Manage the Agent Group and the On-Premises Connectivity Agent.

Description of connectivity_agent_internet.png follows
Description of the illustration connectivity_agent_internet.png

Oracle Cloud Infrastructure Only - Virtual Cloud Network Pattern

Install the connectivity agent in your Virtual Cloud Network (VCN) within Oracle Cloud Infrastructure, and configure a service gateway to route the traffic from the VCN to Oracle Integration. Use this pattern if you have applications, such as Oracle E-Business Suite, running in a private subnet within Oracle Cloud Infrastructure. In this case, all traffic is routed locally and the public internet is not involved.

While not strictly required, it is highly recommended that all access from the VCN go through the service gateway. Service gateways primarily ensure that access to Oracle-hosted services is routed over the internal network. Users are not charged for service gateways. Service gateways only work within a region, and not across regions. For access across regions, traffic is still routed through a NAT gateway.

A service gateway is a common configuration for users that have implemented FastConnect or VPN/IPsec private peering to route traffic to Oracle Integration (ingress), including the connectivity agent in a private subnet.

For details on configuring a service gateway, see FastConnect and VPN with Oracle Integration Cloud (OIC).

Description of connectivity_agent_vcn.png follows
Description of the illustration connectivity_agent_vcn.png

FastConnect Public Peering Pattern

Install the connectivity agent on your private (on-premises) network, and set up an exclusive connection between your network and Oracle Integration using a FastConnect public peering link. The inbound and outbound traffic to Oracle Integration goes through the FastConnect link. This connection pattern provides a faster and more reliable networking experience compared to the public internet pattern.

Follow the steps listed here to configure this pattern:
  1. Subscribe to FastConnect with the public peering option. Currently, Oracle Integration directly supports only public peering with FastConnect. If you want to use the private peering option, you'll need to additionally use a VCN and a service gateway. See the FastConnect Private Peering Pattern.

    For detailed information on requirements and best practices for setting up an Oracle Cloud Infrastructure FastConnect, see FastConnect.

  2. Configure your private (on-premises) network to route traffic through FastConnect.

    The FastConnect link contains the public IP addresses of Oracle Integration.

  3. Finally, configure the connectivity agent to handle the outbound traffic from Oracle Integration to the on-premises application.

    The connectivity agent also acts as a client to FastConnect and uses public peering.

Note:

With FastConnect public peering, you must deploy the connectivity agent in your private or on-premises data center.

Description of fastconnect_public_peering.png follows
Description of the illustration fastconnect_public_peering.png

FastConnect Private Peering Patterns

In addition to providing fast and reliable connectivity, the FastConnect private peering patterns provide additional security to prevent traffic analysis.

Note:

The private peering patterns also apply to Virtual Private Networks (VPN) and are identical except that the FastConnect private peering link is replaced with a VPN.

The connection patterns are as follows:

Connectivity Agent Deployed in Private or On-Premises Network

Install the connectivity agent in your private (on-premises) network, and set up a private connection between your network and VCN using FastConnect private peering or VPN. In addition, configure a service gateway to route the traffic from the VCN to Oracle Integration. To use FastConnect, you must first subscribe to FastConnect with the private peering option. See FastConnect. The FastConnect link contains the private IP addresses of the VCN.

If you want to use VPN, see VPN Connect.

To configure a service gateway, see FastConnect and VPN with Oracle Integration Cloud (OIC).

Description of fastconnect_private.png follows
Description of the illustration fastconnect_private.png

Connectivity Agent Deployed in a VCN

Install the connectivity agent in your VCN within Oracle Cloud Infrastructure, and set up a private connection between your network and the connectivity agent using FastConnect private peering or VPN. In addition, configure a service gateway to route the traffic from the VCN to Oracle Integration. You can use this pattern if you have limited capacity or resource constraints on your data center.

For details on configuring a service gateway, see FastConnect and VPN with Oracle Integration Cloud (OIC).

Note:

The connectivity agent deployed in a VCN can also be used to access resources deployed in an Oracle Cloud Infrastructure VCN.

Description of fastconnect_private_vcn.png follows
Description of the illustration fastconnect_private_vcn.png

Workflow for Using the Connectivity Agent

Follow this workflow to use the on-premises connectivity agent.

Task Documentation
Create a connectivity agent group. Create an Agent Group
Download and run the on-premises connectivity agent installer on your host. During installation setup, you associate the on-premises connectivity agent with the agent group.

Download and Run the Connectivity Agent Installer

Create an adapter connection in Oracle Integration and associate the connection with the connectivity agent group.

Create Connections

Design an integration that uses this connection.

Create an Integration

Activate the integration. Activate an Integration