Skip to Content

Hello friends,

One of my favorite ways to speed up my SAP Gateway coding is to have my own code templates for each of OData operations. I have been able to significantly increase my productivity using these templates.

I have been collecting them in a Git repository from last 3 years. Using this blog, I want to share it with the community so that everyone can make use of these templates. Each of these templates is documented inside.

I am open to contributions. So please feel free to send a pull request if you have a better or new template. Also if you need a template for a specific frequently occurring scenario, let me know. I will try to add.

Here is the GitHub link.

https://github.com/krisho007/gatewaycodepatterns

 

To report this post you need to login first.

10 Comments

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

  1. Timothy Muchena

    Thanks Krishna

    Thanks for the excellent template.

    I have questions regarding use of changeset_process and expand.

    On changeset_process when processing data from multiple entities with multiple items. Which approach would you recommend between using changeset_process (cv_defer_mode = abap_true) and letting the gateway do its thing and and call create methods multiple times and storing data in a global internal table for processing in changeset_end.

    On expand, do you always recommend redefining get_expanded_* methods or there are times when generic expand is a better option?

    Kind regards

    (0) 
    1. Krishna Kishor Kammaje Post author

      Hi Timothy,

      ChangsetEnd is ideally used only for Commits. I collect all changes within ChangesetProcess, and perform an update at the end of the method itself.

      On Expand, I have rarely used generic expand in a production code. Usually, you can write an efficient logic by implementing the method explicitly.

      Regards

      Krishna

      (2) 
  2. Bilen Cekic

    cool idea. Still i prefer single service based approach with POST(CREATE_ENTITY) and GET(GET_ENTITY) approach.  Application become more rest-like and easy for data transfer. data to JSON and JSON to DATA conversion is done on ABAP layer and everything is much more easy. No function import, no deep insert , no association.

    (0) 
    1. Krishna Kishor Kammaje Post author

      Hi Belin, Interesting. Can you explain a little more? What do you mean by no deep insert? How do you achieve creating parent and children together? And what about handling changesets?

      (0) 
      1. Bilen Cekic

         

        Above is my service structure. 6 months ago i created it and no one visit SEGW after that 🙂

        Our data is moving inside the CONTEXT column in a JSON structure. So whatever comes and go is inside CONTExt. Parenth-child is very easy, just prepare structure in ui5 later, lets say a nested array and send to ABAP layer via create method. in ABAP it will be converted to internal table. (you need to have corresponding ITAB structure of course). now you can do what you want with this nested internal table.

        Above logic makes everything very easy. Any structure changes or you need to add any field, table you just need to append existing work area thats all. Everying will be output as JSON .

        I will write a blog for it.

        (0) 
        1. Krishna Kishor Kammaje Post author

          I see that you are not using OData, rather using Json model for UI5 binding in that case. In that case, you can just use a generic SICF service with a handler class, you do not even require SEGW. Would love to know your experiences with your approach.

          I would miss two-way binding of OData model, which greatly reduces my UI5 code.

          (0) 
          1. Bilen Cekic

            simplicity on UI5 layer brings too much complexity on ABAP layer, i really don’t udnerstant the need of deep insert or read with expand option which should be done very very easy.
            oData is okay for very simple data communucation but when dealing with more “serious” applications, you could spend a lot of time just trying to make data communication “just” work properly. Advantage of using SEGW comparing to a custom SICF class, building error handling, authorization, media type etc…

            But still complex application should go plain rest-like. Initially i really get excited too much when i start UI5 first but when application needs become more serious you feel that server dependent oData communication not really working well. Lets say you have 10K rows, 120 col and user want aggreagation of all rows on top of each column and make it dynamic whenever there is filter. In this case oData lazy loading will make things not to work because you will always load lets say 200 rows in one call or whatever.

            Anything goes complicated on Ui5 will be pornographically expensive on gateway layer. SAP is not really understand how modern web application are evolving, still they need to have full control of how design and data communication should be.
            Anyway i will write a blog soon 😀 thanks

             

             

            (2) 

Leave a Reply