This two-part article will discuss details we need to know about the GraphQL implementation in SAP ABAP. How it was born, what it offers, and how to use it. As this is my first blog post ever and I am not an expert in either ABAP or GraphQL, the article may contain few mistakes. Also, this article is not designed to be a comparison of REST or OData vs GraphQL.
For those wants to skip to Technical details can go to part 2.
As I was looking for better ways to expose existing data in SAP through APIs which helps development and maintenance times low. I have tried a few ways to produce APIs out of SAP.
Earlier being ICF Services exposing data using ABAP to JSON converter utility (custom) classes. Which were bare minimum implementations of APIs that can be exposed out of SAP using SICF. Which is equivalent of Express Server in NodeJS world.
Although ICF services are quite powerful and provide total control over what can be sent over responses, I continued looking further for better options.
GraphQL
As I also work with NodeJS to develop Web Applications and Server-Side APIs, I have been following GraphQL from its earlier stages since Facebook has made it public and I am very much fascinated by the way GraphQL standardizes the access of our backend Relational Data.
Although this article is not in any way the introduction to GraphQL, I would like to just talk about a few features it brings to the table.
The quote from https://graphql.org, Describe your data, Ask for what you want and Get predictable results provides all there is to know about GraphQL in a nutshell.
One of the advantages I love about GraphQL is the ability to traverse through the relationships of our Data model. Which provides superpowers to the clients requesting data and puts totally in charge. This makes sense in the multi-platform world that A mobile App can choose to fetch fewer data from the same API endpoint as opposed to a Web Application which has more screen area.
Request and Response to GraphQL Server (image from https://www.howtographql.com)
Another advantage of GraphQL which simplifies API development and maintenance is that we can get rid of versioning APIs and maintaining several endpoints and flavors of the same domain data. As GraphQL provides Queries (Read), Mutations (Create, Update and Delete) and Subscriptions (Real-time Updates) all under single endpoint, scaling and maintaining is much simpler. Instead of versioning API, GraphQL has the functionality to flag fields for Depreciation along with the reason. Adding new fields will not be affecting existing API unless clients request for it.
The GraphQL Type System will provide the Documentation by default so that the consumers are well aware of what to request and expect back from the Server.
As the popularity of GraphQL increases, so are the Tools and Libraries around it. The GraphQL community is really awesome and can find a lot of resources online for learning about it.
- The GraphiQL tool is one used to interact with GraphQL server and has several flavors to improve usability. GraphiQL provides auto-completion of queries and shows the documentation from Server.
- Apollo and Relay libraries provide easy to integrate GraphQL into the development workflow
SAP
I would like to mention about SAP CRM module as well here, as my end goal is to expose CRM customer data as APIs. CRM has divided the functionality into Business Partners and One Order, which is already exposed to CRM UI with the help of BOL(Business Object Layer)/GenIL(Generic Interaction Layer). My Idea is to leverage what has been working for several years and extend to expose as a GraphQL API.
If we look closely, BOL/GenIL has several similarities with GraphQL.
- BOL defines Advanced Search Entities which can be related to Query Types in GraphQL
- Query Parameters can be converted as Arguments
- Root Entities/ Result Entities can be related to Custom Types
- Each attribute of the Entity can be exposed as Type fields
- Each consequent relation can be considered as Related/Sub Types and can be resolved with getRelatedEntitie(s) function calls of GenIL
- Data Element values or Value Tables for each BOL field can be converted as Enum
- Last but not least, GenIL Create Entity, Update Entity and Delete Entities can be mapped to Mutations
This view of mapping from BOL/GenIL to GraphQL compelled me to invest more time in building the GraphQL server to expose as a unified interface into SAP CRM.
Initially, I have started to implement GraphQL in NodeJS and call custom REST endpoints into SAP. Even though this approach allowed me to build an initial Proof of concept. I am not convinced that simply calling REST endpoints behind GraphQL NodeJS implementation and applying filters outside SAP, is a huge task and we can not fully leverage features BOL/GenIL. I feel that it's just a hack to expose data from SAP.
I have started looking into GraphQL implementation in ABAP and failed to find one at the time I started building one myself (around Jan 2018). I took the code of Java implementation as a reference in building GraphQL server within ABAP. There has to be a lot of adjustments and sacrifices in porting the Java code to ABAP, as ABAP OOPs is slightly different and I need to strip out Threading as our SAP ICM(Internet Communication Manager) will manage this for us at the request level in my understanding. Also changed the implementation to work with the idea of loading config from tables instead of Schema files as in other languages.
Once the GraphQL server is built and ready in ABAP, It was easy to expose BOL/GenIL to the server as reading from Config tables already available in SAP CRM.
Enough of the story, we shall now dive into technical stuff in this second part of the Article.
Other sources to track this topic.
Part 1
Part 2
- SAP Managed Tags:
2 Comments
