C1000-010 practice question 4 of 15

A company wants to use ODM rules for a graphical user interface (GUI) validation. They want to use rules to validate forms filled out by customers. The rules would validate user input and answers to the questions. The users must have the ability to navigate the website while waiting for the ODM response. What implementation should they use?

Full set: 61 questions
Answer options
A: Implement a REST rule service in the XML format.
B: Implement a HTDS rule session to handle the request and response web service call.
C: Use an EJB rule session to handle changing the state of objects in working memory.
D: Use an asynchronous ruleset execution and an observer to end the execution or catch an exception on failure. Correct answer
Correct Answer:
D. Use an asynchronous ruleset execution and an observer to end the execution or catch an exception on failure.
Explanation

The core requirement is that the user interface (UI) must remain responsive, allowing the user to navigate while the rule execution is in progress. This necessitates a non-blocking, asynchronous call to the rule engine. Asynchronous ruleset execution is specifically designed for this purpose. The client application initiates the execution and can continue with other tasks. An observer (or callback mechanism) is then used to receive the results or handle any exceptions once the execution is complete, without freezing the GUI.

Why Incorrect

A. A REST service is a valid way to expose rules, but a standard REST call is synchronous (request-response). The data format (XML vs. JSON) is irrelevant to the synchronous/asynchronous nature of the interaction.
B. Hosted Transparent Decision Service (HTDS) exposes rulesets as standard, synchronous web services. A call to HTDS would block the client application until a response is received, which contradicts the requirement.
C. Enterprise JavaBeans (EJB) rule sessions are a server-side invocation method. Like HTDS, a standard call to an EJB session is synchronous and would block the calling thread, making the UI unresponsive.

References

1. IBM Operational Decision Manager 8.10.5 Documentation, "Asynchronous ruleset execution": This section explicitly details the solution. It states, "Asynchronous execution is useful when a client application cannot afford to be blocked while waiting for the ruleset execution to be completed." It further explains the use of an observer: "You can attach an observer to the execution to be notified when the execution is completed or when an exception is raised." This directly supports option D.

Source: IBM Knowledge Center, IBM Operational Decision Manager > Developing > Developing rule-based solutions > Developing for Rule Execution Server > Executing rules with Rule Execution Server > Asynchronous ruleset execution.

2. IBM Operational Decision Manager 8.10.5 Documentation, "Calling a ruleset from a Java SE client": This page describes the different execution modes. It contrasts synchronous execution (IlrStatelessSession.execute) with asynchronous execution (IlrAsynchronousRulesetExecutor.execute), reinforcing that the asynchronous pattern is the correct choice for non-blocking scenarios.

Source: IBM Knowledge Center, IBM Operational Decision Manager > Developing > Developing rule-based solutions > Developing for Rule Execution Server > Tutorials > Calling a ruleset from a Java SE client.

3. IBM Operational Decision Manager 8.10.5 Documentation, "Hosted transparent decision services": This documentation describes HTDS as a mechanism to generate web services (SOAP/WSDL or REST/OpenAPI). The interaction model described is a standard synchronous request-response, which validates why option B is incorrect for this scenario.

Source: IBM Knowledge Center, IBM Operational Decision Manager > Decision Server Rules > Reference > Hosted transparent decision services.

Scroll to Top