With the success of the initial version of GraphQL ABAP implementation and usage analysis over several APIs, though the APIs can be built and used with ease, I felt an urge to improve the efficiency of developing APIs with an easier and standardized way. I have started working in my free time on the next version of the GraphQL ABAP implementation, which I will try to present first hand in this Blog Post, in hope of suggestions and comments. Thoughts and Improvements: ◉ GraphQL Schema ◉ But where is the Graph? ◉ How can we visualize the Data Model it exposes? ◉ Schema Development ◉ Defining schema using ABAP code takes significant efforts and error-prone ◉ How can we standardize the Schema Definition process ◉ How can we decrease the efforts of managing the Schemas available across systems ◉ How can we reuse existing Business logic efficiently with minimal efforts ◉ How can we quickly go from Schema to API Out of these above thoughts, I have started designing a GraphQL Admin (Web Application) with features like: ◉ Maintain all Schemas available in the system with a simple and refreshing interface ◉ List the schemas ◉ Create/Edit/Delete the schemas ◉ Use the Schema Definition Language (SDL) of GraphQL ◉ Instead of creating the schema using repetitive ABAP code scattered across Classes, provide an in-place editor for the whole schema ◉ Instead of resolving only by ID ◉ Provide more context to the Resolvers to be able to improve efficiency by Schema awareness ◉ Resolve the ABAP executable code like Function Modules and Classes ◉ Defining the Mapping between GraphQL and ABAP using Directives Let us dive deep into the features of the Web Application with few Screenshots instead of my boring theory. ◉ Dashboard (is now left empty) ◉ can be used to show statistics like the number of schemas available, the number of requests per schema, active calls per hour and critical messages and so on… ◉ Schemas Menu Option: for CRUD operations on Schemas ◉ Creating a New Schema ◉ takes unique Schema ID, description and SICF path of the schema in SAP ◉ Creating related SICF node in SAP with just ZGQLCL_API_SERVICE_BASE as the superclas ◉ List of Schemas ◉ the operations for each tile contains Edit Schema Header, Delete and Visual Editor in sequence ◉ New Schema created will be stored into SAP tables ◉ Fun Fact: The API for this Application is also running on GraphQL ABAP Implementation and maintained using this Web APP and can be seen in the above screenshot as GQL_ADMIN tile ◉ Visualizing/Updating the Schema using GraphQL Editor ◉ Adding new functionality into new Schema using GraphQL Editor ◉ Note: Thanks to the GraphQL Editor Open Source library, which is used to edit the Schema generated from GraphQL ABAP Implementation ◉ SAP will generate the SDL required for GraphQL Editor ◉ WebAPP will pull this SDL from SAP and render using GraphQL Editor library ◉ Once the Editing is done in WebAPP, Saving will convert the updated SDL to config tables of SAP ◉ Please head over to the GraphQL Editor site to check out how cool the idea of editing the Graph online is ◉ The Left side Icon Menu comes with GraphQL Editor library standard Operations for searching within Schema ◉ with additional custom Save icon at the bottom for saving the updated Schema into SAP ◉ The top bar is to navigate between ◉ GraphQL Editor ◉ Dashboard with Schema List ◉ Creating a New Schema ◉ Importing ABAP DDIC objects ◉ Editor pane on the left is the SDL Syntax highlighted text editor which will render the SDL generated by ABAP Server ◉ The right panel is the Visual representation of the Graph for given SDL which also allows ◉ Adding, Deleting, Updating of the Nodes in the Graph visually ◉ Scrolling, Panning and Zooming into the Graph ◉ Finally, GraphQL Playground tool used to execute/test the GraphQL queries against ABAP server showing the initial schema created Note: URLs of the Web Application and GraphQL Playground are showing “http://localhost” since these are running proxy servers locally to connect to local SAP Netweaver 7.52 instance distributed free for developers, huge Thanks to SAP for the same ◉ Directives ◉ Here is another idea I have admired from PostGraphile library showing efficient usage of Directives to bridge the Operations between Data model and GraphQL language ◉ I have tried to implement the same for the GraphQL ABAP implementation to integrate and invoke existing executable business logic available in SAP ◉ I see the Directives as a way to provide additional information either at Design time or Execution time for different elements of the Schema ex. Fields, Types, ENUMs ◉ Following basic Directives are defined as standard into the GraphQL ABAP implementation @abapName for mapping GraphQL name to SAP name @abapValue for mapping GraphQL Enum value to SAP Domain value @resolver to support legacy RESOLVER by ID functionality ◉ Additional Directives can be defined and added to the Schema generator using a simple implementation of Interface ZGQLIF_CUSTOM_DIRECTIVE @functionModule to execute the ABAP function module using GraphQL data @class to execute ABAP Class and Method using GraphQL data ◉ Import functionality can be used to generate base SDL for these directives to be added to Editor and adjusted to the needs ◉ Working with Schema Editor to define GraphQL Schema ◉ Adding operations into Schema using simple Import Function Modules ◉ Function or Class imports will be generating simple SDL for the main operation and supporting SDL types, Inputs based on ABAP Imports and Exports. ◉ This allows us to define or customize as desired, rather framework deciding all on its own, which will mostly not be sufficient for ever-changing API contracts ◉ Imports support Basic Data Types, Structures and Table Types ◉ FM with Type Ref To is not supported, as we can’t send references through API ◉ bellow we can see an operation zgqlfmTestStringRes has been added to Query type ◉ with @functionModule directive and attribute “name” with FM name for resolver execution ◉ executing the above query after saving the Schema ◉ We can modify the names of the generated schema fields from “zgqlfmTestStringRes” to “fetchStringResource”, which will have no effect on the execution of the Function ◉ But in order to change the field names generated, we need to use the @abapName directive to map to original SAP parameter names, ex “evStr” export parameter is renamed to “sampleString” ◉ Here is the actual Function Module from SAP looks like ◉ Let us try to change the logic to return dynamic values from EV_STR with Time Stamp ◉ Import also supports Class Methods import as well with few limitations ◉ Class Constructor with Required parameters are not supported ◉ Static and Public Instance methods are only exported as GraphQL operations ◉ Sample Import of a Class results SDL as ◉ Above the Importer provides the Static and Public Instance methods of the bellow sample class ◉ Operations in Schema ◉ bellow we can see 3 operations getSeed1, staticMethod and testMulitExport have been added to Query ◉ getSeed1 has @class->name as Class name and @class->method as Class Method name for resolving ◉ Execution of Class Methods is same as calling operations Building Sample Demo GraphQL API using SFLIGHT BAPIs ◉ Search for Flights – FM – BAPI_FLIGHT_GETLIST ◉ SDL with “searchFlights” operation, includes all the Import and Export parameters from FM ◉ Executing BAPI from GraphQL ◉ Now we need Details of the Flights we fetched, we can use FM – BAPI_FLIGHT_GETDETAIL ◉ we will define the details operation both as ◉ dependent on Search – when we want sub information at the time of search within the single API call ◉ root operation – when we know all required information on the flight (without performing Search) ◉ The difference above is to remove Required parameters when including under Search operation as the values from Search results will be automatically passed down to Details operation when the input parameter of the child operation is the same as Output field of the parent. Ex. “airlineid”, “connectionid”, “flightdate” ◉ Executing Flight Details operation ◉ as Root operation when Flight details are known ◉ as Search dependent operation to pull the details along with Search Advantages & Conclusions: ◉ Using the SDL for managing the Schema is a great way to improve the Developer experience in building the APIs ◉ SDLs can be managed in Source Controls like GitHub or Bitbucket at a central location for review and tracking the changes across Teams ◉ This is a faster way of building the APIs and will need less technical knowledge of the internal logic of the server itself ◉ As this does not rely on any functionality of the SAP Modules and is purely implemented in ABAP, this could be used across all SAP Systems ◉ Using the Directive Resolvers will reduce the amount of SAP code to build Schema significantly ◉ GraphQL Admin Web App can be used as a gateway to maintaining GraphQL Schemas across different SAP systems with minimal changes and can be integrated with Source Control systems for version management on SDL ◉ The new system is designed to provide more context to the Resolvers and better Error handling ◉ This mainly reduces/eliminate the code we need to write for Schema development itself, which will shift the focus on API development and design instead Although this is nowhere near to finish, I see it has a lot of potential and scope to reduce Development costs and increase the efficiency of building APIs. The source is not exported as of now for this implementation, as it is under constant changes. Once this is finalized will probably share the code here. Anyone wants to see this in action, reach out to me for a discussion on what I have built so far.