1Z0-1042-25 practice question 11 of 15

You have a use case requiring the design of a synchronous Oracle Integration Cloud (OIC) integration flow that returns a custom business fault message to the client if processing fails due to an external runtime fault encountered during the integration instance execution. Which implementation strategy best satisfies this requirement?

Full set: 99 questions
Answer options
A: Implement a scope fault handler to catch the runtime fault, and then use the Fault Return action providing mapped data for the custom fault. Correct answer
B: Implement a scope fault handler to catch the runtime fault, then allow the global fault handler to automatically send the runtime fault to the error hospital.
C: Create a custom scope fault handler to catch the runtime fault, and then use the ReThrow Fault action to send the fault to the Error Hospital.
D: Implement the Global Fault handler to catch the runtime fault, and then use the Rethrow Fault action to send the custom fault to the client.
Correct Answer:
A. Implement a scope fault handler to catch the runtime fault, and then use the Fault Return action providing mapped data for the custom fault.
Explanation

In a synchronous Oracle Integration Cloud (OIC) process, the client application waits for an immediate response. The requirement is to return a custom business fault, not the original system fault. The Fault Return action is specifically designed for this purpose within synchronous integrations. By placing a Scope action around the potential point of failure (e.g., an external service call), its fault handler can catch any runtime exceptions. Inside this handler, you can map the details of the caught fault into a predefined custom fault structure and then use the Fault Return action to send this structured, user-friendly fault message back to the calling client, fulfilling the requirement.

Why Incorrect

B: Sending a fault to the error hospital is characteristic of asynchronous processing. A synchronous client would time out or receive a generic error, not the intended custom fault. C: The ReThrow Fault action passes the fault to a higher-level handler (the global handler), it does not send a response to the client or directly to the Error Hospital. D: The Rethrow Fault action does not send a fault message to the client. The correct action for returning a fault to a synchronous caller is Fault Return.

References

1. Oracle Official Documentation - Using Oracle Integration Generation 2:

Document: Using Oracle Integration Generation 2

Section: Manage Errors in Integrations > Add a Fault Return Action

Content: "The Fault Return action enables you to return a fault to the caller of a synchronous integration. This action is only available in the fault handler of a scope in a synchronous integration." This directly supports option A as the correct implementation for returning a fault to a synchronous client.

2. Oracle Official Documentation - Using Oracle Integration Generation 2:

Document: Using Oracle Integration Generation 2

Section: Manage Errors in Integrations > Add a Re-throw Fault Action

Content: "The Re-throw Fault action enables you to re-throw a fault that has been caught by a fault handler. The fault is re-thrown to the next level fault handler (either the outer scope's fault handler or the global fault handler)." This explains why options C and D

which use Rethrow Fault to communicate with the client

are incorrect.

3. Oracle Official Documentation - Using Oracle Integration Generation 2:

Document: Using Oracle Integration Generation 2

Section: Manage Errors in Integrations > Add a Scope Action to an Integration

Content: "A scope is an action that groups one or more actions into a unit of work... Each scope can have its own set of fault handlers to catch and manage faults that occur within the scope." This establishes the best practice of using a scope to isolate potential failures and apply specific fault handling logic

as described in option A.

Scroll to Top