Skip to Content

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",
               Locale.ROOT,
               HttpStatusCodes.BAD_REQUEST
           );
      }
  }

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.



@PrePersist
 @PreUpdate
  private void persist() throws ODataRuntimeApplicationException {
      validateFieldsBeforeSave();
  }

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 Supplier.java 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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Tudor Riscutia

    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 🙂

    Tudor

    (0) 
    1. Riley Rainey Post author

      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 …)

      Cheers,

      Riley

      (0) 
      1. Tudor Riscutia

        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.

        Thanks,

        Tudor

        (0) 
        1. Riley Rainey Post author

          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.

          Cheers,

          Riley

          (0) 
        2. Roopa M S

           

          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 ?

           

          Thanks&Regards,

          Roopa

          (0) 
  2. Madhavi Khaladkar

    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!!

    Thanks

    Madhavi

     

    (0) 
    1. Riley Rainey Post author

      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.

      Regards,

      Riley

      (0) 

Leave a Reply