Suggested answer

The goal is that the user gets a sensible outcome and the support team gets enough information to act.

1. Wrap the external call in a Try-Catch Block so a failure is caught rather than propagated raw to the user.
2. In the catch path, decide the behaviour deliberately: return a degraded but usable response (cached or default data), return a clear business-level message the OmniScript can display, or mark the request for later retry — whichever the business actually wants.
3. Log enough context to diagnose: which call failed, with what inputs, and the response status. Without this, an intermittent external fault is undebuggable.
4. Do not swallow failures silently. A catch block that returns success with empty data produces the worst kind of defect — one nobody reports until the data is wrong downstream.
5. Consider a Cache Block in front of the call, so a brief outage is invisible for data that tolerates being slightly stale, and think about whether a non-blocking call is appropriate when the caller does not need the result at all.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.