Cloud Application Integration (CAI) Implementation
Domain overview
The CAI Implementation domain tests whether you can turn a business integration requirement into a deployable Informatica Cloud Application Integration asset: the right asset type, scoped data, connector configuration, fault paths, and runtime/deployment settings. Expect questions on process design, service exposure, human tasks, subprocess reuse, error handling, and Secure Agent connectivity.
Core rules and concepts
- Choose the asset by contract: a Service exposes an API/endpoint; a Process orchestrates steps; a Guide drives interactive user steps; a Subprocess is reusable logic invoked by a parent.
- Separate connections from service connectors. An App Connection holds endpoint, credential, and security configuration; a Service Connector selects the operation and maps its input/output.
- Define process objects and variables before building shapes. Process objects model business documents; variables hold runtime state. Map inputs at Start and outputs at End or in the Service response.
- Attach the runtime to a Secure Agent group when on-premises or private-network access is required. Publish and activate the correct version before testing an endpoint.
- Build explicit fault paths. A fault handler catches connector/process errors, logs correlation data, and returns a controlled response rather than leaking stack traces.
Worked example
Requirement: accept an order via REST, create it in Salesforce, then post it to an on-prem ERP. Model a Service with JSON input, a validation subprocess, a Salesforce create step, and an ERP service connector. Put the ERP call in a subprocess so retry logic is reusable; pass an orderId/correlationId. On ERP timeout, catch the fault, write a failed-status record, and return HTTP 202 with a tracking ID rather than a generic 500. Reasoning: the Service owns the public contract, the subprocess isolates retryable logic, and explicit fault output preserves idempotency and supportability.
Traps that cost marks
- Confusing Service endpoints with Process orchestration.
- Hard-coding credentials instead of using App Connections.
- Omitting fault paths and output mapping.
- Assuming a published process is active for the endpoint.
- Forgetting Secure Agent selection for private ERP access.