Usually input validation is an essential part of business decision models created by OpenRules customers. They add rules that validate input decision variables for null values, empty strings, impossible values like Feb 29 during a non-leap year, and many other problem-specific input errors. These custom error reporting mechanisms usually generate lists of errors with explanations in the JSON response for RESTful decision services. However, while input errors are diagnosed by the decision service, its return code is usually 200 meaning it was a “good” request. In this post I will describe how your service may return code 400 for bad requests.

Let’s consider a simple business decision mode “PatientTherapy” described in detail here. Let’s convert this basic decision model to a RESTful decision service using OpenRues with SpringBoot. I simply copy the project PatientTherapy (included in the OpenRules installation) to another project
PatientTherapySpringBoot, and add the property

deployment=spring-boot

to its “project.properties” file. I also add SpringBoot related dependencies in the file “pom.xml” by copying them from the standard project “VacationDaysSpringBoot”. Now I can simply run “runLocaServer.bat” (also borrowed from “VacationDaySpringBoot”). It will rebuild my project and will start my local server:

Now I may test this RESTful service with POSTMAN:

As you can see, there were no errors in this JSON request and response code (highlighted) was 200.

Now, let’s add rules that check that the Patient Age and Creatinine Level cannot be undefined. Here is how I did it by adding conditions and conclusions that may generate Error Messages:

I also added the array of strings “Error Messages” to the Glossary:

I deployed and ran this service again but this time I removed the “age”, “allergies”, and “creatinineLevel” from the response. POSTMAN produced the following results:

While our RESTful service caught and reported two error messages, the response code still was 200. Usually when the server cannot process the request due to something that is perceived to be a client error, the client expects to receive back “400 Bad Request” error. How can we force our RESTful webservice to produce the code 400 instead of 200 in case when our rules create error messages?

We need to add a special error code handler that is a small Java program. OpenRules automatically generates a Java interface for handling errors. Here is an example of our error handler:

As you can see, this is a Java class that implements an automatically generated interface PatientTherapyRestControllerPostHandler – this name was created by adding “RestControllerPostHandler” to the name of our decision model “ParientTherapy” defined in the Environment table as “model.name”. We needed to implement only one method “postHandle”.

First, this method takes a JsonNode which we called “errorMessages” using the path that may be seen in the above POSTMAN response: “response – doctorVisit – erorMessages”. If this node is not empty, we will change the httpResponse by setting its status to BAD RESPONSE (400). Note that the class ErrorCodeHandler should be created in the package like “healthcare.service” formed by adding the word “service” to the package name “healthcare”.

After restarting my local server with unLocalserver.bat I received these results:

Now our RESTful webservice returns “400 Bar Request”.

You may notice that I also added our error message to the header:

httpResponse.addHeader(“X-Error-Codes”, errorMessages.toString());

So, now if you click on “Headers” in the POSTMAN response, you will all error messages:

And here is the generated header:

The entire working example could be found in the project “PatientTherapy” included in the standard installation “OpenRulesSamples“.

CONCLUSION. OpenRules Decision Manager allows users creating their own error handlers to control response codes of the deployed RESTful decision services.