Skip to Content

OData enablement is a subject of significance, especially, considering pressing needs of requirement by frameworks that facilitate state-of-the-art user interfaces. It also becomes important by another high-demand requirement that is multichannel access to services and solutions.

It is evident that OData is endorsed in SAP world. In fact, the ABAP stack has a pretty mature Out-Of-the-Box availability of OData enablement.

The blog – What’s new in Process Orchestration 7.31 SP09/7.4 SP04 , provides introduction of BPM OData services. It’s not only pleasing to realize the availability of OData service for BPM, but reflects importance of ‘OData exposure for technologies’.

In the light of realization of the significance of OData enablement, there are a few use cases which still stand devoid of OData enablement – a situation that we recently came across in our team. They were :

  • Need for exposure of not only BPM but CAF (Composite Application Framework) services as well in form of OData services.
    • Existing CAF based solutions with WebDynpro and VC as front end might want to move to UI5 based state-of-the-art solutions, to be also able to have multiple device access enablement. The wish here would be that this should be possible with minimal effort. We should be able to draw advantage of the layered architecture. Thus utilizing most of the existing solution.

/wp-content/uploads/2014/04/1_431571.png

  • Exposure of BPM for PO versions before 7.31 SP 09, with minimal effort for achieving OData enablement.

/wp-content/uploads/2014/04/2_431572.png

Ahead, in the article I will present  the approach used to enable OData enablement from point of view of components involved (and step-wise description, perhaps later, if needed).

The OData enablement is done for two scenarios :

  1. Exposing CAF service as an OData Endpoint. (CAF services then, may or may not, initiate a BPM process)
  2. Exposing BPM as an OData endpoint

Prerequisite:

  • We used odata4j library as dependency for OData capabilities. The odata4j library download information may be accessed at this link.
  • For creation of OData request we used :
    • ¨ datajs library
    • ¨ SAP UI5
    • ¨ odata4j consumer library for JAVA based request creation.
    • ¨ other JS frameworks come with the same capability and also of almost same ease (download information available at this link).

So, here is a synopsis of the steps we followed :

Exposing CAF service as OData Endpoint

/wp-content/uploads/2014/04/5_431590.png

    1. Create and fire an OData request, from OData consumer (may or may not be a web module for composing the OData request to act as an OData consumer)
    2. Façade DC invokes CAF Service – Query parameters are extracted from OData request and used to invoke CAF services through JNDI invocation.

Few points about this Façade Development Component :

      1. Request is received at one of the exposed end-points ( from within a web module, separately deployable as an enterprise DC).
      2. This web module performs an ejb invocation to CAF operation (which can then invoke BPM service).
      3. The web module has dependencies on a DC created as type of ‘External Library’ which consists of jar files from odata4j library. Also, the web module has created namespace for OData request and registered resource, as well.
      4. Query parameters are extracted from the request payload.
      5. Make the actual ejb invocation for CAF service from the creatEntity endpoint, to initiate a BPM process.

  3.  The BPM service is invoked from within a CAF service, through a web service.

  4.  BPM Process Instance ID is returned.

  5.  BPM Process instance id is further returned to OData producer.

  6.  OData response entity is created and returned to the OData Consumer

Exposing BPM as an OData endpoint

Depending on the NW version you have, you will be faced which of the solutions below to follow :

For versions 7.31 SP9 and above :

These versions come with default OData enablement of BPM and so they may be directly consumed.

For versions 7.31 SP8 and below :

For these versions there is no default OData support available and so we will do façade creation as follows:

/wp-content/uploads/2014/04/4_431589.png

  1. Create and fire an OData request, from OData consumer (may or may not be a web module for composing the OData request to act as OData consumer)
  2. Façade DC initiates BPM – Query  parameters are extracted from OData request and used to initiate BPM process.

Few points about this Façade Development Component :

    1. Request is received at one of the exposed end-points (from within a web module, separately deployable as an enterprise DC).
    2. The web module has dependencies on the DC created as type of ‘External Library’, which consists of jar files from odata4j libarary. Also, the web module has created a namespace for OData request and also registered resource.
    3. Query parameters are extracted from the request payload.
    4. This web module initiates the BPM process, with help of BPM JAVA APIs.

   3.  The response is sent to OData producer.

   4.  OData response entity is created and returned to the OData Consumer.

Some additional points to be taken care of while making the solution work, could be with respect to cross origin request handling and authentication.

Conclusion :

Having performed the above steps creates a short, quick and yet a proper (hopefully!) solution to give OData enablement to your PO stack’s BPM & CAF, which then gives you the capability to consume services by any technology like javaScript, JAVA, dotNet etc.

To report this post you need to login first.

2 Comments

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

  1. Vincenzo Turco

    Great blog, very interesting.

    How about using Olingo Java library? I think right now it’s a prominent Java OData client/server API, possibly more than OData4J

    What’s your take on it?

    Thanks, regards

    Vincenzo

    (0) 
    1. Utsav Chobe Post author

      Hi Vincenzo,

      Thanks!

      Even I have tried to answer the same question at my end, for projects in my organisation.

      In one line: I believe Olingo is the better way to implement the facade layer to integrate with backend (CAF or otherwise).

      Reasons why I believe (and a brief comparison) are as follows:

      1. OData4J does not have any support or strong community to help you out. You have to invest a bit more on learning OData4J. Olingo is Apache’s library and has got support of SAP as well. It also seems to have a good community. With time, this should grow for Olingo and there are no signs of such support with OData4J.

      2. If I am not wrong to quote(and if I remember correctly), OData4J will not have support for OData version 4, which will be supported by Olingo (clearly mentioned on the home page of Olingo). This brings to a stage where one will HAVE TO adopt Olingo sooner or later. So why not sooner!

      These two are compelling advantages in favor of Apache Olingo, as they ensure support.

      The only good thing, I personally like about OData4J is the way it registers classes for exposing as OData entities. One can use backend (CAF / Beans) classes to register when exposing as OData entities. Whereas, in Olingo, each variable of a class needs to be added as a property. This requires mirroring of the whole backend class in the facade layer (when using Olingo). Having said this, there is a easy way to bypass it by creating a little bit of a utitlity class (using Java Reflections) to do that manual work for us.

      Hence, overall, I totally agree with you that Olingo should be used as the facade provider.

      (0) 

Leave a Reply