OAuth2 in SAP CPI and Informatica CAI: Real Flow, Runtime Behavior, and Failure Handling

OAuth2 in SAP CPI and Informatica CAI: Real Flow, Runtime Behavior, and Failure Handling

In integration platforms, OAuth2 is not just configuration.

It directly affects:

• whether API calls succeed
• whether flows complete
• whether production jobs fail

This post focuses on real runtime behavior in:

• SAP Integration Suite (CPI)
• Informatica Cloud Application Integration (CAI)

---

🧠 Real System Scenario

Example landscape:

• SAP S/4HANA → Source
• SAP CPI / Informatica CAI → Middleware
• External API (Salesforce / Stripe)
• Auth Server (Auth0 / Azure AD)

---

🔷 SAP CPI — Actual Flow

🔄 End-to-End Flow

flowchart LR
    S4[S/4HANA] --> CPI[iFlow]
    CPI --> Adapter[HTTP Receiver Adapter]
    Adapter --> Cred[Credential Alias]
    Cred --> Token[Token Request]
    Token --> Auth[Auth Server]
    Auth --> CPI
    CPI --> API[External API]

---

🔁 Runtime Sequence

sequenceDiagram
    participant CPI
    participant Auth
    participant API

    CPI->>Auth: Request Token
    Auth-->>CPI: Access Token

    CPI->>API: API Call (Bearer)
    API-->>CPI: Response

    Note over CPI: Token cached internally

---

⚙️ CPI Behavior

• OAuth configured via Security Material
• Adapter uses Credential Alias
• Token fetched automatically
• Token cached internally

---

⚠️ CPI Observed Issues

• incorrect credential alias
• wrong token endpoint
• scope mismatch
• token expiry during long execution

---

🔶 Informatica CAI — Actual Flow

🔄 End-to-End Flow

flowchart LR
    Source --> Process
    Process --> OAuthService
    OAuthService --> Auth
    Auth --> OAuthService
    OAuthService --> TokenStore[(Token DB - userId)]
    Process --> API

---

🔁 Runtime Sequence

sequenceDiagram
    participant Proc
    participant OAuth
    participant Auth
    participant API

    Proc->>OAuth: Request / Validate Token
    OAuth->>Auth: Authenticate (if needed)
    Auth-->>OAuth: Access Token

    OAuth-->>Proc: Token
    Proc->>API: API Call
    API-->>Proc: Response

---

⚙️ CAI Behavior (Actual)

Token reuse is not purely automatic.

Even if stored, process must:

• check if token exists
• validate expiry
• fetch new token if needed

---

🔄 Token Lifecycle Logic

flowchart LR
    A[Start] --> B{Token Exists?}
    B -- No --> C[Request Token]
    B -- Yes --> D{Expired?}
    D -- Yes --> C
    D -- No --> E[Use Token]

    C --> F[Store Token]
    F --> E
    E --> G[Call API]

---

⚠️ Error Handling

401 Unauthorized

• cause: expired token
• action: refresh token + retry

---

403 Forbidden

• cause: scope/permission issue
• action: fix config (no retry)

---

5xx Errors

• cause: server issue
• action: retry with delay

---

🔁 Retry Flow

sequenceDiagram
    participant Proc
    participant API

    Proc->>API: Call
    API-->>Proc: 401

    Proc->>Proc: Refresh Token
    Proc->>API: Retry
    API-->>Proc: Success

---

💥 Failure Chain

flowchart LR
    A[Token Expired] --> B[API Call]
    B --> C[401 Error]
    C --> D[No Retry]
    D --> E[Failure]

---

⚖️ CPI vs CAI

Area	CPI	CAI
Token handling	Adapter-managed	Process-controlled
Token storage	Internal	userId / DB
Visibility	Low	Medium
Control	Low	Higher

---

🧭 Final Mental Model

Token → Validate → Use → Expire → Refresh → Retry → Continue

---

🧠 Final Takeaway

OAuth2 in integration systems is not about getting a token.

It is about managing the token lifecycle:

• when to use it
• when to refresh it
• and how to recover when it fails

Platforms may abstract this differently, but the responsibility remains in your system design.

---

🔗 Related Reading

• OAuth2 Explained Clearly
• OAuth2 vs OIDC