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.

Description of connectivity_agent.png follows

Description of the illustration connectivity_agent.png

Connectivity Agent Components

The connectivity agent consists of the following components.

Component	Description
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.

Component

Description

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.

Feature	More information
Network	The connectivity agent opens no ports on the on-premises system for communication. 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.
Communications security	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 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.
Access to the connectivity agent	Depending on your setup, either the Service Gateway or a NAT Gateway provides access to Oracle Integration and other resources. This setup is different from Oracle Integration Generation 2 and is a requirement of OAuth 2.0. The Service Gateway on the Oracle VCN provides access to Oracle Integration, Oracle Identity Cloud Service, and identity domains in the same region as the connectivity agent. See Access to Oracle Services: Service Gateway. A NAT Gateway provides access to Oracle Integration, Oracle Identity Cloud Service, and identity domains in a different region than the connectivity agent. See NAT Gateway.
Requests	The on-premises connectivity agent checks for work by making outbound requests through the firewall. All communication is initiated by the on-premises connectivity agent. Every interaction that the connectivity agent has with Oracle Integration follows a prescribed paradigm in which the connectivity agent pulls information from your Oracle Integration instance.
Connection details	The on-premises connectivity agent connections are configured by the agent retrieving the configuration details from Oracle Integration.
Adapter support	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.
Data security	No data is persisted in the on-premises agent.
Additional details	The on-premises connectivity agent does not support trigger/polling for REST/SOAP endpoints. No existing J2EE container is required to deploy the on-premises connectivity 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 Notification Service (SNS) Adapter
- Amazon Simple Queue Service (SQS) Adapter
- Amazon Simple Storage Service (S3) Adapter
- Apache Kafka Adapter
- Using the ArcGIS (ESRI) Adapter with Oracle Integration 3
- Azure Active Directory Adapter
- Azure Event Grid Adapter
- Azure Service Bus Adapter
- Azure Storage Adapter
- Confluent Adapter
- File Adapter
- FTP Adapter
- GCP Pub Sub Adapter
- GCP Storage Adapter
- GraphQL Adapter
- IBM DB2 Adapter
- IBM MQ Series JMS Adapter
- Microsoft SQL Server Adapter
- MLLP 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 Primavera P6 EPPM 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
- Snowflake 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

Differences from Oracle Integration Generation 2

If you upgraded from Oracle Integration Generation 2 to Oracle Integration 3, be aware of how the connectivity agent has changed.

Area	More information
OAuth 2.0 token based authentication, not basic authentication	Oracle Integration Generation 2 supported basic authentication for the connectivity agent. Oracle Integration 3 does not support basic authentication for the connectivity agent. Instead, Oracle Integration 3 supports only OAuth 2.0 token-based authentication, which is more secure than basic authentication. OAuth 2.0 requires a service gateway or NAT gateway to provide access to certain resources. See Network Requirements.
Simpler configuration	The configuration of the connectivity agent is simpler in Oracle Integration 3 than in Oracle Integration Generation 2.

Area

More information

OAuth 2.0 token based authentication, not basic authentication

Oracle Integration Generation 2 supported basic authentication for the connectivity agent. Oracle Integration 3 does not support basic authentication for the connectivity agent.

Instead, Oracle Integration 3 supports only OAuth 2.0 token-based authentication, which is more secure than basic authentication.

OAuth 2.0 requires a service gateway or NAT gateway to provide access to certain resources. See Network Requirements.

Simpler configuration

The configuration of the connectivity agent is simpler in Oracle Integration 3 than in Oracle Integration Generation 2.