OIC Performance Tuning: Making Integrations Faster

How to find the bottleneck first

Before changing anything, use OIC monitoring to find where time is being spent. Open a failed or slow integration instance and expand the activity stream. Each activity shows its start time — the gaps between activities reveal where the integration is waiting.

Common findings:

• 80% of time in a single REST invoke → the downstream API is slow
• Time accumulating in a loop → too many iterations or large payloads per iteration
• Time in the mapper → oversized payload transformation

Reduce payload size

The most impactful change is almost always reducing how much data OIC processes per call. If you’re fetching 1,000 records when you only need 50, fixing the query is faster than any other optimisation.

For Fusion REST APIs, always:

• Use fields parameter to specify only required fields: ?fields=PersonNumber,Name,Email
• Use q for server-side filtering instead of fetching all and filtering in OIC
• Set a reasonable limit and implement proper pagination

Avoid N+1 REST calls in loops

A loop that makes one REST call per record is the single most common OIC performance problem. If you’re calling /orders/{id} inside a loop of order IDs, replace it with:

• A bulk endpoint if available: POST /bulkorders with an array of IDs
• A database query that returns all records in one call
• A parallel scope with branches (for small, fixed-size sets)

Choose the right message tracking level

OIC’s activity stream and payload tracking consume resources. For high-throughput integrations, set tracking level to Business Identifiers only, not All Payload. This alone can improve throughput by 20-30% for message-intensive integrations.

Increase batch size for scheduled integrations

If processing 10,000 records one at a time, switch to processing 200 at a time using chunking. Each chunk runs as one OIC instance, reducing overhead significantly.

Connection pooling

OIC manages adapter connection pools internally. For DB Adapter connections with high concurrency, verify the connection pool size in the adapter configuration matches your expected parallel instance count.

Caching reference data

If the same lookup table or reference data is fetched on every integration run (e.g. currency mappings, BU names), consider moving it to OIC Lookup Tables rather than a live REST call. Lookups are in-memory — effectively zero latency.