OIC - Lessons Learned & Improvements in OIC Integrations

📘 Use Case

During various OIC projects, we identified recurring issues that impacted logging, error tracking, retry handling, and monitoring through tools like DataDog. Here’s a list of key observations and the solutions we applied.

---

1. Suppressed Error Details

• Observation:
  OIC sends only a generic error message to DataDog or external logs, hiding the actual root cause.

• Solution:
  Capture the actual faultMessage in error handlers and send it to DataDog along with other details for better troubleshooting.

---

2. No Retry for Temporary Errors

• Observation:
  Transient connectivity or network issues fail immediately without any retry attempt.

• Solution:
  Add retry logic using fault handlers or scopes for specific error types (like connection timeouts or 5xx errors).

---

3. Missing Correlation ID for Fusion Failures

• Observation:
  When a Fusion ESS job fails, the logs don’t include any identifier like the ESS Job ID or request ID, making it hard to trace.

• Solution:
  Extract and log the ESS request ID or other correlation IDs from Fusion and include them in your custom logs.

---

4. Payload Not Validated

• Observation:
  OIC flows sometimes try to process empty or null payloads, which leads to schema errors or misleading messages.

• Solution:
  Add condition checks early in the flow to verify if payloads contain data before proceeding to mappings or invokes.

---

5. Only Errors Logged, Not Success

• Observation:
  DataDog or similar tools receive only error logs, and successful integrations are not tracked, affecting KPI reporting.

• Solution:
  Log success cases as well, including important business identifiers like invoice number, PO number, or employee ID for better tracking.

6. Integration Timeout Not Handled

Observation:

Some long-running integrations fail due to timeout, especially when calling external systems that take time to respond.

Solution:

Adjust the timeout settings in the connection properties. Also, wrap such calls in a scope with timeout handling logic to provide custom error messages or fallback.

7. Overuse of Hardcoded Values

Observation:

Many integrations had hardcoded values for endpoints, credentials, or lookup keys, making them hard to migrate or scale.

Solution:

Use Lookups, Global Variables, and Connections smartly to externalize values. Parameterize as much as possible.

8. No Archival or Logging of Request Payloads

Observation:

When issues occurred, there was no record of what payload was received—making RCA difficult.

Solution:

Log incoming request payloads (masked if sensitive) to file server, UCM, or external logging systems before processing.

9. Overloaded Error Handlers Catching Everything

Observation:

A single generic error handler catches all faults, masking the actual error and causing confusion.

Solution:

Use specific fault handlers (like for Timeout, AuthenticationFailure, ServiceError) instead of one "catch-all" block. Customize messages accordingly.

10. Lack of Version Control or Documentation

Observation:

Integration flows were updated without tracking changes or maintaining documentation, making it difficult for others to manage.

Solution:

Maintain version notes or release logs.

Use naming conventions for integration versions.

Document integration logic, mappings, and lookups in a central repo or Confluence page.

11. Poor Use of Data Stitching (Unnecessary Variables)

Observation:

Multiple unnecessary variables and assignments are used where direct mapping or transformation would work.

Solution:

Optimize mappings and data handling. Use fewer intermediate variables and go for direct expressions or XSLT if needed.

12. Integration Not Idempotent

Observation:

Some integrations post the same data multiple times if retried, causing duplicates in target systems.

Solution:

Implement idempotency checks—use message IDs, reference numbers, or flags in the target system to avoid re-processing.

---

🎯 Outcome

Implementing these improvements helped us:

• Get full visibility into success and failure cases
• Reduce debugging time
• Improve monitoring accuracy in tools like DataDog
• Increase reliability of integrations with retry logic