OCI App Integration Pro (1Z0-1042-25) cheat sheet

Oracle Cloud Application Integration (OIC) is a cloud-native iPaaS: a runtime cluster executes integrations, a design-time web console authors them, and an embedded metadata repository stores artifacts.

Core runtime services: the integration engine (orchestration), the connectivity layer (adapters and agents), the mapping/XSLT engine, the scheduler for app-driven and scheduled triggers, and the monitoring/tracing service.

Integration styles: app-driven (event/trigger-based, real time), scheduled (orchestrated batch), and the newer asynchronous callback pattern where a long-running process returns via a callback URL.

A connection is a reusable endpoint configuration (adapter + URL + security); an integration references connections; a trigger is the first activity that starts an instance.

Instances are the unit of execution: each trigger firing creates one instance with its own state, variables, and audit trail. Instance states include ACTIVATED, RUNNING, COMPLETED, FAILED, ABORTED, and WAITING.

Projects (formerly packages) group integrations for lifecycle operations and role-based access; a project is the unit of export/import between environments.

Lookups (local or REST-backed) hold reference data such as code cross-references; local lookups are versioned with the integration and cached at runtime.

The OIC instance is region-scoped and identity-domain-scoped; service instances in different regions cannot share connections or lookups directly and must be exported/imported.

Design-time vs runtime separation: activating an integration promotes a draft to an active version; only one version per integration is active at a time unless versioning rules allow parallel activation.

Adapter categories: application adapters (Oracle ERP/HCM, Salesforce, NetSuite, SAP), technology adapters (REST, SOAP, FTP, File, Database, JMS, Kafka, MQ), and trigger-only adapters.

REST adapter supports both trigger (expose an endpoint) and invoke roles; SOAP adapter uses WSDL; both require a security policy (Basic, OAuth 2.0, or none) and a connection URL.

File/FTP adapter requires an agent for on-premises file systems; cloud file targets can be reached directly. The agent tunnels traffic outbound over HTTPS; no inbound firewall rule is required.

Connectivity agent runs on a host inside the private network, registers with the OIC instance using an agent group identifier, and proxies adapter calls to on-premises endpoints.

Agent group is the logical name used in a connection; multiple agents can join one group for high availability and load distribution.

Database adapter supports CRUD, stored procedure, and SQL query operations; polling strategies include timestamp-based, sequence-based, and delete-based (logical delete).

Oracle ERP Cloud adapter uses the ERP integration service catalog (business events and service objects); HCM adapter similarly uses HCM business objects and events.

Connection testing validates URL, credentials, and agent reachability; a failed test usually indicates wrong credentials, wrong agent group, or unreachable endpoint.

For Salesforce, use the Salesforce adapter for object/event operations and OAuth 2.0 or Basic security; bulk operations use the REST/Bulk API variants exposed by the adapter.

Trigger types: REST (exposed endpoint), SOAP, app-driven (business event from ERP/HCM/Salesforce etc.), scheduled (recurring), file/FTP (polling), database (polling), JMS/Kafka (message consumption), and callback.

App-driven trigger flow: the source app fires a business event, OIC receives the event payload, and the integration runs asynchronously; the event name and business object are configured on the trigger connection.

Scheduled trigger uses an iCal-style recurrence expression (e.g., FREQ=DAILY;INTERVAL=1) plus a timezone; the schedule fires one instance per recurrence.

Orchestration activities: assign, switch, while, for-each, scope, call (invoke integration), notification, and the adapter invoke activities.

Scope activity groups steps, defines local fault handlers, and supports transaction boundaries; for-each iterates over arrays and can be sequential or parallel.

Callback pattern: an integration exposes a callback endpoint, calls an asynchronous external service, and resumes when the service posts to the callback URL; the instance stays in WAITING state meanwhile.

Global fault handler catches unhandled faults for the whole integration; scope fault handlers catch faults within that scope; fault handlers are not themselves fault-handled.

Asynchronous vs synchronous: app-driven and scheduled triggers are asynchronous; REST trigger can be synchronous (returning a response) or asynchronous (returning 202 with a tracking URL).

Resubmission and recovery: failed instances can be resubmitted from monitoring; scheduled integrations can be recovered for missed schedules within a configured window.

Mappings use XSLT 1.0/2.0 (OIC generates XSLT from the visual mapper); the mapper supports source-to-target drag, functions, and conditional expressions.

Common mapper functions: concat, substring, translate, normalize-space, if/then/else (choose), for-each, sequence, lookupValue, and the xp20/xsl extension functions.

Lookup functions: lookupValue(lookupName, sourceColumn, sourceValue, targetColumn, defaultValue) references a local lookup; lookupTable uses a REST lookup.

Conditional mapping uses the 'if' function or a choose/when construct; for arrays, map inside a for-each to iterate elements.

Type conversion is implicit where possible; explicit conversion functions (e.g., xsd:integer, xsd:date, string()) avoid runtime type errors.

Global variables and local variables hold intermediate values; variables are immutable once assigned and must be re-assigned to change.

XSLT import: custom XSLT can be imported for complex transformations; the mapper then wraps it and exposes the resulting target structure.

Date/time handling uses xsd:dateTime and format-dateTime; timezone conversion must be explicit, since OIC does not auto-convert payload dates.

Namespaces matter: target elements inherit the schema namespace; mismatched namespaces are the most common cause of 'element not found' mapping errors.

Switch activity routes by condition; each branch is evaluated in order and the first true branch executes; a default branch handles the remainder.

Call activity invokes another integration synchronously or asynchronously; use it to modularize reusable logic and to isolate fault handling.

Notification activity sends email; it is a common fault-handler action to alert operators on failure.

Fault handling structure: try/scope → fault handler → rethrow or continue; the global fault handler is the last resort.

Fault types include binding faults (adapter/connection), validation faults (schema), and business faults (application errors returned by the target).

Rethrow fault re-raises the fault after logging; suppress fault lets the instance complete successfully despite the error.

Error handling best practice: wrap external calls in scopes with fault handlers, log the fault payload, and notify; use rethrow when the instance should be marked FAILED.

Retry: adapter invocations can be configured with retry counts and intervals for transient errors; scheduled integrations retry on the next schedule if not recovered.

HTTP status mapping: 2xx success, 4xx client error (mapping/validation), 5xx server error (target unavailable); monitoring classifies faults accordingly.

Security policies per adapter: Basic Authentication, OAuth 2.0 (client credentials or authorization code), SAML, and None; the policy must match what the target expects.

OAuth 2.0 client credentials flow: OIC obtains a token from the token endpoint using client ID/secret, then sends Bearer token; no user interaction.

OAuth 2.0 authorization code flow requires a user to consent once; the refresh token is stored and used to obtain new access tokens.

Credentials can be stored in the connection (username/password or OAuth client) or referenced from an OCI Vault secret; prefer Vault for production.

Connection security is separate from integration-level security: the REST trigger can require OAuth 2.0 or Basic to authenticate inbound callers.

Roles: ServiceAdministrator, ServiceDeveloper, ServiceMonitor, ServiceInvoker; least privilege means developers do not get administrator rights.

Identity propagation: OIC can propagate the caller's identity to the target via SAML or OAuth, or use a service account; choose per target requirement.

Secrets rotation: rotate client secrets and passwords in the connection or Vault, then retest the connection; old tokens expire per the token lifetime.

Data at rest and in transit: TLS for all adapter traffic; payloads can be encrypted with PGP in file/FTP adapters.

Monitoring console shows instances with status, start/end time, duration, and error message; filter by integration, status, and time range.

Instance detail shows the activity stream, payload at each step, fault details, and the tracking variables defined in the integration.

Activity stream icons: green check = success, red = fault, yellow = waiting, gray = not executed; the first red activity is the failure point.

Tracing: enable detailed tracing on the integration to capture payloads and headers; tracing increases storage and should be temporary.

Logs: the instance log holds runtime messages; adapter logs hold connectivity errors; agent logs on the agent host show tunnel and DNS issues.

Common failures: connection test failure (credentials/agent), schema mismatch (validation fault), timeout (target slow), and OAuth token error (expired secret).

Resubmit re-runs a failed instance from the start with the same payload; recovery replays missed scheduled instances.

Tracking variables are user-defined fields shown in monitoring to identify business keys (e.g., order number) without opening the payload.

Metrics: instance counts, success/failure rates, and average duration are available per integration; use them to spot regressions after deployment.

Lifecycle stages: design (draft) → activate → monitor → deactivate; only active integrations execute.

Export/import: export a project as an archive (.par) containing integrations, connections, lookups, and certificates; import into another environment.

Connection overrides: on import, map exported connections to existing target connections so environment-specific URLs and credentials are not overwritten.

Versioning: each activation creates a new version; you can roll back by activating a previous version. Deactivating stops new instances but running instances continue.

Promotion path: develop in a dev instance, test in test, deploy to production; never edit production directly.

Certificates and keystores must be exported and imported explicitly; missing certificates cause TLS handshake failures after promotion.

Scheduled integrations must be activated in the target; schedules do not carry over automatically unless included in the export.

CI/CD: use the OIC REST APIs (or the CLI) to export/import and activate integrations from a pipeline; store the .par artifact in version control.

Pre-deployment checklist: connection tests pass, lookups populated, certificates imported, schedules reviewed, and fault handlers verified.