OCI App Integration Pro (1Z0-1042-25) key terms

A reusable configuration object in Oracle Integration that stores the endpoint URL, authentication method, and credentials needed to talk to an external application. Integrations reference connections instead of hard-coding endpoint details.

The technology-specific component behind a connection that translates between Oracle Integration's internal message format and a target protocol such as REST, SOAP, FTP, database, or a packaged application API.

A lightweight Java process installed on-premises that opens outbound tunnels to Oracle Integration so integrations can reach private endpoints without inbound firewall rules. It also hosts the file and FTP adapters for on-premises file access.

A logical grouping of connectivity agents that share configuration and are addressed as a unit. Integrations target the group, so any healthy agent in the group can serve the request, giving high availability.

The connection placed on the left side of an integration that defines how the integration starts, for example an inbound REST endpoint, a scheduled run, a file arrival, or a business event subscription.

The connection placed on the right side of an integration that represents an outbound call to an external system. Each invoke activity sends a request and optionally maps the response back into the flow.

An orchestration style where a trigger event such as an incoming REST call or business event starts the integration and the flow runs immediately in response, as opposed to running on a timer.

An orchestration style where the integration starts on a defined schedule rather than in response to an external event. It is used for batch polling, reconciliation, and periodic data synchronization patterns.

A step inside an orchestration, such as an assign, switch, for-each, while, stage, notification, or callout. Activities control data flow, branching, looping, and side effects between trigger and invoke connections.

A branching activity that evaluates one or more expressions and routes the flow down the matching branch, with an optional otherwise path. It provides conditional logic inside an orchestration.

A looping activity that iterates over a repeating element in a payload and runs its child activities once per element. It is commonly used to process line items or bulk records one at a time.

A grouping activity that wraps other activities into a named block, which can be run sequentially or in parallel. Stages improve readability and support parallel processing and per-stage tracking.

The step that defines how fields in a source structure populate fields in a target structure. Mappers can apply direct assignments, functions, conditional expressions, and lookups between the two schemas.

An XML Stylesheet transformation used when source and target structures differ in shape, not just field names. It supports templates, loops, sorting, and conditional logic that simple field-to-field mapping cannot express.

A built-in or custom operation available in the mapper, such as string manipulation, date formatting, arithmetic, or conditional selection, applied to source values to produce a target value.

A stored table of key-value pairs that a mapper can query at runtime to translate codes, for example converting a country name to a numeric identifier. Lookups keep translation data out of the integration logic.

A structured definition of a message's elements, types, and cardinality, usually expressed as JSON or XML schema. Integrations use schemas to validate payloads and to drive the mapper's source and target trees.

A web service or REST call made from inside a mapper or orchestration to fetch or enrich data mid-flow, for example validating an address before writing a record. Callouts add latency and failure points.

The design of how an integration responds when an activity fails, using fault handlers, scope-level error branches, and explicit error responses so failures are reported and do not silently drop data.

A fault handling path defined at the integration level that catches errors not handled by a narrower scope. It typically logs the error, notifies an owner, and returns a meaningful failure response to the caller.

A container that groups activities so they share local variables and a dedicated fault handler. If an activity inside the scope fails, the scope's handler can recover without aborting the whole integration.

Configuration that controls how many times and how often a failed outbound call is retried before the error is raised. Retries suit transient failures such as timeouts but can duplicate side effects if not idempotent.

The property that repeating the same request produces the same result without creating duplicate records. It matters for retries and replays, and is usually enforced with a unique business key or deduplication check.

The runtime area where failed integration instances are collected for inspection and resubmission. Operators can review the payload and error, fix the cause, and replay the instance rather than rebuilding the flow.

Re-running a failed integration instance from the point of failure after the underlying problem is corrected. It avoids reprocessing already-completed steps when the runtime supports recovery from a checkpoint.

A single runtime execution of an integration, with its own state, payload, timestamps, and activity trace. Instances are the primary unit inspected during monitoring and troubleshooting.

The per-instance timeline that shows each activity's start time, duration, status, and payload. It is the main tool for locating which step failed or where latency accumulated.

A business identifier, such as an order number, that is captured during a run and indexed so instances can be searched by that value later. It links runtime monitoring back to business records.

Correlating a single request across systems using propagated identifiers and diagnostic logs. Tracing shows the full path and timing of a call chain, which is essential when an integration spans several services.

Detailed runtime log output, often enabled per integration at a chosen level, that records message processing and errors. It is more verbose than the activity stream and is used for deep troubleshooting.

An authorization framework where a client obtains a time-limited access token from an authorization server and presents it to call an API, instead of sending user credentials on every request.

An OAuth 2.0 flow where a client application authenticates with its own client ID and secret to obtain an access token, with no end user involved. It is typical for server-to-server integrations.

A short-lived credential issued by an authorization server that grants access to a protected API. Integrations attach it to outbound requests and refresh it before expiry rather than storing it permanently.

A longer-lived credential used to obtain new access tokens without repeating the full authorization flow. It lets integrations keep working after the short-lived access token expires.

The confidential value paired with a client ID that proves a client application's identity to the authorization server. It must be stored in a protected credential store, never in plain configuration or source control.

A secured repository for secrets such as passwords, API keys, and client secrets that integrations reference by alias at runtime. It keeps sensitive values out of exported artifacts and visible design metadata.

The process of moving an integration through design, activation, versioning, deactivation, and retirement, including export and import between environments such as test and production.

The action that deploys an integration version to the runtime so its trigger can receive events or its schedule can fire. Only one version of an integration is active at a time.

A numbered snapshot of an integration's design. New versions are created for changes so the active version keeps running while the new one is tested and then promoted.

Bundling an integration together with its dependencies, such as connections and lookups, into an archive for import into another environment. It is the standard way to promote work between tenants.