The debugging mindset
Debugging without a method wastes hours. The method: isolate the smallest failing unit, reproduce consistently, understand the error fully, then fix. Resist the urge to randomly change things and hope the problem disappears.
OIC integration debugging
Step 1: Read the monitoring detail carefully. Open the failed instance in OIC monitoring. Expand the activity stream. Find the last successful step and the first failed step — the problem is between them.
Step 2: Check the fault payload. OIC captures the fault message in the instance detail. “HTTP 400 Bad Request” means the payload was malformed. “401 Unauthorized” means an authentication issue, not a data issue.
Step 3: Check the request payload at the failing step. In OIC monitoring, you can view the request payload sent to the failing invoke. Copy it into Postman and replay manually against the API — this separates OIC routing issues from API issues.
Step 4: Check connection health. Test the connection from OIC connections menu. A healthy connection that still fails on invocation usually means a permissions or endpoint-specific issue, not a connectivity issue.
VBCS debugging
Browser DevTools Network tab: the most important tool. Filter to XHR requests. Find the failing service connection call. Check: request payload (is OIC receiving the right data?), response payload (what did OIC return?), HTTP status code.
VBCS audit log: in the browser console, VBCS logs action chain execution. Enable verbose logging: vbDiag.enableLogging('all') in the browser console.
Test service connections in isolation: before blaming the action chain, use VBCS’s built-in service connection tester (the play button on a connection) to verify the endpoint responds correctly with test parameters.
Isolating intermittent failures
Intermittent failures are the hardest to debug. Add structured logging to your integrations — log the input parameters, the response from each invoke, and a timestamp. When the intermittent failure occurs, the log tells you exactly what was different about that run versus the ones that succeeded.
The “works in dev, fails in prod” problem
This almost always comes down to: environment-specific data (a customer ID that exists in dev but not prod), environment-specific configuration (a lookup value set differently in prod), or scale (prod data is 100x larger and triggers a timeout that dev never hits).
Always compare: connection configurations, lookup table values, and test with production-scale data volumes.