Skip to Content

Custom data validation and error messaging in Olingo V2 OData services

I recently discovered a nifty feature in Olingo V2’s JPA APIs. There are cases in web services programming where you’ll need to return a custom error message, a specific HTTP error status code, or both. Olingo V2 now provides an easy to use exception class to support this.

Olingo V2 version 2.0.6 introduces a new exception class, ODataRuntimeApplicationException. This exception can be invoked to generate a specific HTTP error on demand.

A common case where you’d want to employ this would be to validate property values of an object before allowing it to be saved in the database. If you are using Olingo’s JPA API, you probably want to take care where you’d perform these checks. Since these checks are associated with Olingo/JPA web service calls, we probably want to restrict the check(s) to code that would only be executed in an Olingo context. That’s a convoluted way of saying that this sort of integrity check should not be done in the POJO “setter” methods — those functions will be called in places that will have nothing to do with the Olingo web service.

I’ll start by creating a separate method to perform all required validations.

private void validateFieldsBeforeSave() throws ODataRuntimeApplicationException {
// reject null or empty Name field
if (supplierName == null || supplierName.length() == 0) {
 throw new ODataRuntimeApplicationException(
               "Invalid value for supplier name field",

As you can see, you as the developer have control over the HTTP status code returned and also can supply a custom error status message.

I choose to call this validation code in the JPA object’s @PrePersist and @PreUpdate methods. Those methods are associated with object creation and object updates — what a great place to do such checks.

  private void persist() throws ODataRuntimeApplicationException {

I have added an example putting all of this together in my version of the SAP ESPM example web service. The source code can be found on github: GitHub – SAP/sap_mobile_platform_espm_olingo_services: A version of SAP's ESPM web services built using Apache O…  Take a look at the class definition.

Data validation in your Olingo V2 JPA projects is now easy to control with this new feature. The only requirement is to use version 2.0.6 or later of the Olingo V2 libraries.

You must be Logged on to comment or reply to a post.
  • Hi Riley,

    Is it really a good idea to mix JPA coding with Olingo? What if you want to build some other connectivity later? jax-rs maybe?

    I think a better solution is to catch the exception in the Olingo processor and convert it to Olingo there.

    Good luck ­čÖé


    • Hi Tudor,

      Thanks for your remarks.

      Olingo V2 includes an extension API specifically for using JPA with Olingo -- so, I'm thinking at least in that case the answer would be "yes, use JPA with Olingo" (see Apache Olingo Library tutorials)

      There's other examples of where leveraging JPA features to enable or enhance certain Olingo features proves useful (see my article titled Build an Optimized Hybrid Mobile Application using the HANA Cloud Platform as an example).

      If you are suggesting that there are many more valid use cases that probably have nothing to do with JPA, I complete agree (and error control there is much easier and directly dealt with ...)



      • I'm afraid you misunderstood me ­čÖé

        JPA is a good solution for implementing persistence, no discussion. What I actually meant is that Olingo can use JPA (because JPA is just a specification, you can easily switch the implementation), but JPA should not use Olingo class. The later would create a tight coupling between the two different "layers", in the wrong direction. That's what I wanted to point out.

        I had the same problem pushing up the error message, especially if validator classes are used.. If nobody else gets to a better solution, I will post mine soon enough.



        • Tudor,

          Well, the Olingo JPA extensions pretty tightly intertwine these two component layers.  That said, I agree simpler is almost always better. I look forward to any approaches you might share.




          Hello Tudor ,

          I am also looking for an option to push the JPA validation error message to OData level. Could you please share your solution ?




  • Hi┬áRiley,

    Nice Blog!

    could you please help us with raising exceptions from servlet class?

    We tried the data validation through POJO class, but we are looking for data validation based on business logic in servlet.

    Please help us asap!!




    • Hi Madhavi,

      The Olingo V2 JPA class framework described in this article provides you fixed, prebuilt servlet logic.  There's not an easy, maintainable path to extending it.

      You might consider using the standard (non-JPA) Olingo framework. And doing so would expand your OData protocol support to your choice of V2 or V4.  There is much more to code to map each interaction to your ORM but this would get you away from filtering/authorization code in the POJO. Unfortunately, I'm not aware of a code example that marries business logic and those libraries.



  • Hi,

    We have a usecase to send the target in the OData Error Response.

    The value for the target name/value pair is the target of the particular error (for example, the name of the property in error).

    Looks like there is no option to send that information through any OData Exception.

    Can you help me here?.