Skip to Content

We in ABAP world used to have everything handy. Access some information in any table, SELECT and done. Update? Done. Use some global class, done. It’s not even necessary any “require” or “include” command. It’s there. Just use it!

However, in my very first days working with SAPUI5 I saw that the life is not so easy outside of ABAP stack. Thinking in how I could make the UI5 developer easy, I started to working in the ABAP Active Record project. It’s a open source project project shared in Github to replicate the Active Record that I know from Ruby on Rails. The objective of this project is to provide a way to UI5 devs access SAP tables at ABAP stack in a very easy way.

This blog is to give an ABAP perspective to community. You can find more information on my blog at SAPUI5 community. Please check there how to use and how it works in SAPUI5.

Note: It’s already in my future road map to use ABAPGit.

SAP Gateway

It’s only necessary to create one generic service at SAP Gateway that will respond all requests for any table!

There are two entity types: request and result, with their entity sets.

  • request is responsible to receive all information about database operation, like table name, fields to be selected and filter conditions.
  • result is responsible to process all information entered using resquest calls and execute desired operation.


The whole transation is executed using batch processing.var oFlightsTable = oARModel.aarGetEntitySet('SFLIGHT', ["CARRID", "CONNID", "FLDATE", "PRICE"], {carrid: "LH", connid: "2402"});For example, for the aarGetEntitySet method call above, it’s necessary follow requests:

  • first request (POST method) call to pass operation and SAP Table name;
  • 4 request (PUT method) calls to pass all 4 fields to be retrieved;
  • 2 request (PUT method) calls to pass 2 filter conditions and
  • last result (GET method) call to retrieve all information from database selection.

It’s necessary 8 requests in total for this example called in the same transaction (batch).

Here is the return of result entity set method:

<model>SFLIGHT</model>

<field>CARRID</field>

<value>LH</value>

<model>SFLIGHT</model>

<field>CONNID</field>

<value>2402</value>

<model>SFLIGHT</model>

<field>FLDATE</field>

<value>08/21/1997</value>

...

ABAP

In ABAP side, I implement proper methods for very dynamic Open SQL calls. For more information, you check the ABAP methods implementation.

Here is the list of methods implemented in ABAP in order to process database retrieval:

  • REQUESTSET_CREATE_ENTITY

Called in the begginig of all transactions. It’s responsible to define the table name and operation.

  • REQUESTSET_UPDATE_ENTITY

Receive all parameters to build dynamic database operation.

  • RESULTSET_CREATE_ENTITY

Used in aarCreate method (PUT) and execute INSERT SQL command.

  • RESULTSET_DELETE_ENTITY

Used in aarDelete method (DELETE) and execute DELETE SQL command.

  • RESULTSET_GET_ENTITY

Used in aarGetSingleValue method (GET) and execute SELECT SINGLE SQL command.

  • RESULTSET_GET_ENTITYSET

Used in aarGetEntitySet method (GET) and execute SELECT SQL command.

  • RESULTSET_UPDATE_ENTITY

Used in aarUpdate method (PUT) and execute UPDATE SQL command.

Sequence Calls

Just as an example, here is the sequence of calls necessary to retrieve a set of records for SFLIGHT table:var oFlightsTable = oARModel.aarGetEntitySet('SFLIGHT', ["CARRID", "CONNID", "FLDATE", "PRICE"], {carrid: "LH", connid: "2402"});All calls bellow are result of a batch request from SAPUI5.

  1. Call REQUESTSET_CREATE_ENTITY to start the processing and define some parameters.
  2. For each field in the list (i.e. ["CARRID", "CONNID", "FLDATE", "PRICE"]) callsREQUESTSET_UPDATE_ENTITY and store all values in an internal table.
  3. For each property in the object (i.e. {carrid: "LH", connid: "2402"}) callsREQUESTSET_UPDATE_ENTITY and store all filters to be used in WHERE clause in an internal table.
  4. At the end of processing, call RESULTSET_GET_ENTITYSET to execute the dynamic SELECT command and return the entityset with a list of all fields.

Here is the list on parameters internal table for the method call above:

Filter Internal Table

Based on that parameters dynamic select is called like bellow:

* --- all dynamic retrieve

TRY.

  SELECT (it_fields) INTO TABLE <dyn_table> FROM (me->ddic_table) WHERE (it_where).

CATCH cx_root.

  RAISE EXCEPTION TYPE /iwbep/cx_mgw_tech_exception.

ENDTRY.

Feedback

I started this project to share my idea and the initial proof of concept. I’m not consider ready to be used in production and improvements are needed. However, in the pure open source spirit, I decided to share my idea and receive feedback from the community.

To report this post you need to login first.

6 Comments

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

  1. Shai Sinai

    Interesting piece of work.

    Maybe it’s just my (wrong?) impression, but isn’t one of the concepts behind SAPUI5 is you shouldn’t have direct access to DB tables, but use business entities instead?

    (0) 
    1. Flavio Furlan Post author

      Hi Shai,

      I agree with you and I though about that before publish it. However, the original objective is to be used for “incidental” table access, may be just during Proof of Concept phase?

      (0) 
  2. Lucas Tétreault

    8 requests to do a simple query? Seems unnecessarily chatty…

    I would also say that it’s pretty dangerous to expose a service that will execute arbitrary sql statements without any cleansing of the inputs.

    (0) 
    1. Flavio Furlan Post author

      Hi Lucas,

      Those 8 requests are within the same batch request. From HTTP perspective, it’s just one request. So far, I didn’t find any other way to provide all flexibility I want for the project.

      Edit: I forgot to mention, I changed the way I made the requests. Instead one request for each parameters of SQL (fields and where clause), I concatenate all of them in one string to be parsed in ABAP stack. So, I minimize the numbers os requests inside the batch request.

      Talking about the danger to expose SAP Tables with such flexibility, the user can avoid all update operations not implementing respective methods. BTW, I’m planning to add authority check verification and possible other configurations, like some operations for some defined namespaces etc.

      Thanks for your comment! It’s my main goal at this moment, gather community feedback.

      (0) 

Leave a Reply