All posts · OIC Integrations

OIC Connectivity Agent: Connecting On-Premise Systems

The Connectivity Agent bridges the gap between OIC and systems that live behind your firewall — here's how to install, configure, and maintain it reliably.

Anurag Jangra · February 20, 2026 · 6 min read · ... views

What the Connectivity Agent is

The OIC Connectivity Agent is a lightweight Java process you run on a server inside your network. It creates an outbound tunnel to OIC, allowing integrations to reach on-premise databases, file shares, JMS queues, and legacy APIs — without opening inbound firewall ports.

Prerequisites

  • A server (physical or VM) with Java 8 or later, inside the network that hosts your on-premise systems
  • Outbound HTTPS access to OIC (port 443)
  • At least 2 vCPUs and 4GB RAM recommended
  • Network access to the systems you want OIC to reach

Installation steps

  1. In the OIC console: Settings → Connectivity Agents → Download Agent
  2. Extract the archive to your server: unzip oic-agent.zip -d /opt/oic-agent
  3. Edit conf/Config.properties: set your OIC URL and the agent group name
  4. Authenticate: ./agent.sh configure — enter your OIC credentials
  5. Start: ./agent.sh start
  6. Verify in OIC console: the agent should appear as Active within 60 seconds

Making the agent a system service

Don’t run the agent manually — it’ll stop when you log out. Create a systemd service:

[Unit]
Description=OIC Connectivity Agent
After=network.target

[Service]
ExecStart=/opt/oic-agent/agent.sh start
ExecStop=/opt/oic-agent/agent.sh stop
Restart=on-failure
User=oicagent

[Install]
WantedBy=multi-user.target

High availability

Run two agent instances in the same agent group for redundancy. OIC load-balances across all active agents in a group. Both agents need identical configurations pointing to the same on-premise systems.

Common issues

Agent shows Inactive in console: usually a network or credential issue. Check outbound connectivity to OIC URL and verify credentials haven’t expired.

Slow integration performance: the agent introduces latency. Minimize round trips — batch requests where possible.

Agent crashes under load: increase JVM heap in agent.sh by editing JAVA_OPTS=-Xmx2g.

Maintenance

Update the agent whenever OIC has a major version upgrade. Download the new agent binary and redeploy — agent group configurations persist in OIC. Always test in a non-production agent group first.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp