Oracle Integration Cloud: Building Integrations That Survive Production · Module 6 · Orchestration patterns
When an orchestration is too big
Lesson 67 of 175 · 2 min
The signs — thirty steps, nested loops, branches nobody has exercised — and how to split it WITHOUT HIDING THE COMPLEXITY ONE LEVEL DOWN. THE SIGNS ARE COUNTABLE, which is what makes them useful. Step count past about fifteen. Loops inside loops, which multiply both the runtime and the failure modes. Branches nobody has run — count them and ask when each was last exercised. And a flow nobody but you can explain, which is the sign that matters most and the only one that is not a number. HOW TO SPLIT IT BADLY: extract a sub-integration for each section. The diagram is now short and the system is more complicated: the same thirty steps exist, plus four artefacts, four sets of callers, and a debugging path that spans four instances. That is hiding the complexity one level down, and Lesson 6 says what it costs. HOW TO SPLIT IT…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Integration Cloud: Building Integrations That Survive Production, with a certificate on completion and a fourteen-day refund window.
In this module: Module 6 · Orchestration patterns
- 1App-driven versus scheduled
- 2Invokes, and the shape of a flow
- 3Switch, and branching honestly
- 4Loops over collections
- 5Local variables and assignment
- 6Sub-integrations and reuse
- 7Synchronous versus asynchronous
- 8Stitching in a database or file step
- 9When an orchestration is too big
- 10What breaks: three orchestration failures
- 11Lab briefing · Build a four-step flow