Anatomy of an OIC IAR file — what's actually inside

An .iar is a renamed zip archive — nothing more. The whole reason teams hit ICS-20099 when they try to edit one is that Oracle stamps the archive with a mod hash on export. Strip the .iar extension to .zip and any tool can open it.

Top-level layout

MyIntegration.iar
└── icspackage/
    ├── project/
    │   └── <PROJECT_CODE>/
    │       ├── project.xml                    ← the AST (declarative)
    │       ├── ics_project_attributes.properties  ← contains the mod hash
    │       ├── processor_<id>/
    │       │   ├── processor.xml              ← step definition
    │       │   └── resourcegroup_<id>/
    │       │       ├── req_<hash>.xsl         ← request mapping
    │       │       └── res_<hash>.xsl         ← response mapping
    │       └── application_<id>/
    │           ├── connection.json            ← connection ref (no creds)
    │           └── adapter.json
    └── manifest.mf                            ← OIC version metadata

project.xml — the integration AST

This is the closest thing OIC has to a flow definition. It declares applications (sources and targets), processors (transformers, branches, fault handlers), and resourcegroups (XSL/WSDL/JSON resources attached to each step).

<icsflow>
  <application id="13" type="REST"
    connection="CORE_OIC_REST"
    binding="outbound"/>
  <application id="29" type="SOAP"
    connection="CORE_FIN_SOAP_BIPUB_REPORT"/>
  <processor type="transformer" id="24"/>
  <processor type="transformer" id="69"/>
  <orchestration>
    receive → transformer →
      invoke(SOAP) → transformer → reply
  </orchestration>
</icsflow>

Processors and resourcegroups

Each step in the integration has a processor_<id>/ directory. Transformer processors carry their XSL transforms inside resourcegroup_<id>/ as req_<hash>.xsl (request mapping) and res_<hash>.xsl (response mapping).

OIC's mapper produces XSL 2.0 even for simple field-to-field copies, which is why a 22 KB IAR can contain an 18 KB XSL. The format is verbose by design — Oracle wants the mapper UI to round-trip deterministically.

Application and connection metadata

Each application directory holds a connection.json that names the connection (e.g. CORE_OIC_REST) but never the URL or credentials — those live on the OIC instance, bound to the connection name. This is one of the few things OIC gets right: connection refs vs creds are properly separated.

manifest.mf and ics_project_attributes.properties

manifest.mf records the OIC build that produced the archive (e.g. oicVersion=26.01.0.8-EC), useful when filing support tickets. ics_project_attributes.properties carries the integrity hash:

mod=csiyL2JIDTnU8K10o63Xlw==
modified=1715632841234

The mod field is a base64-encoded 16-byte digest. We have inspected eight production IARs across two customers — see the mod hash explainer for what we know about its derivation.

Practical: parsing an IAR programmatically

Reading is easy — any zip library works. Here's a minimal Node example:

import { unzipSync } from "fflate";
import { readFileSync } from "fs";
import { XMLParser } from "fast-xml-parser";

const archive = unzipSync(readFileSync("MyIntegration.iar"));
const projectXml = new TextDecoder().decode(
  Object.entries(archive)
    .find(([k]) => k.endsWith("/project.xml"))![1] as Uint8Array,
);
const ast = new XMLParser({ ignoreAttributes: false })
  .parse(projectXml);
console.log(ast);

ERPHive uses exactly this approach in its /migrateendpoint, with additional normalisation to handle OIC's several flow-shape variants. The full migrator is open source (BSL 1.1) — you can run it against your own IARs without uploading them anywhere.