SAP Graph – an explorer perspective

ianbunker · ‎12-13-2022

This blog is written from the perspective of a complete novice of SAP Graph and its capabilities and covers the learnings and observations while following some of the excellent training and reference material available ^[1,3,4]. Including building and testing a free tier SAP Graph instance.

SAP Graph is an enabler for businesses and business users to build applications primarily accessing SAP information from multiple line of business (LOB) systems for example SAP S/4HANA Cloud, SAP Success Factors, SAP S/4HANA ^[15]. SAP Graph is configured (by an Administrator) to connect to these systems and after a ‘collection run’ provides API paths to interrogate the data and help rapidly build business applications, for example, through low code/no code techniques such as SAP AppGyver^[8].

SAP Graph – how to set it up?

The initial setup of an SAP Graph instance is relatively straight forward and if already using SAP BTP (who isn’t!) will be very familiar – search for the service and select the plan that matches requirements. Initially, there is a free tier plan available to trial out and become familiar; however, I did find that there is a requirement on the SAP BTP Account itself – needs global administrator access (not trial account), as when creating the SAP Graph instance, a new subaccount is provisioned. Under the hood you can see numerous technology elements are provisioned such as Cloud Foundry, Kyma, Kubernetes (K8s).

Also, note the region which SAP Graph is deployed in, for example, if connecting to existing subaccounts. At the time of these investigations the Europe region was the only one available, but more regions will/have subsequently become available such as CF-US10 (US-East).

Once up and running there are several administrator level tasks that need to take place. This is around the area of connecting to the LOB systems that are the data sources. In the referenced training material, there are good examples of the steps to follow and include template accelerators for prefilling in a lot of the fields. The templates are available for download from GitHub. Without the templates, determining the right input values will be a “difficult” task.

*Note cxsales namespace has been renamed to c4c since May 2022

In the training material followed,^[1] there are examples for connecting to SAP sandbox systems and this was a straightforward task, mainly due to access and security considerations being relaxed. In a real-world example, how the data is to be accessed is a critical consideration. The process for determining the appropriate access setup is shown in the training demonstrations through a flow chart, for example whether to use email authentication or configure service accounts.

SAP Graph does not manage users themselves or directly authenticate with the connecting client. Business user authorization is in the responsibility of the source system. The advantage of this is existing user authorizations are maintained even in the usage of the technical user, the data that the technical user can access is maintained and controlled within the source system itself. The ability for SAP Graph to perform updates ^[12] to data is a relatively recent innovation and this builds further on ensuring the access setup is appropriate.

Overview of the access process

SAP Graph uses token-based authentication, based on OAuth 2.0. To interact securely with SAP Graph, a client application must present an access token (A), as shown below. The token represents the authorization of the client process to access data.

*Multiple data sources shown, can be single source

SAP Graph communicates securely with data sources in the landscape on behalf of the client (B); as per the destinations configured in SAP Graph.

You need users in the system(s) for a scenario to work. SAP Graph does not manage user identities and it cannot directly authenticate clients. Instead, it relies on the XSUAA, SAP Authorization and Trust Management Service to do that. By setting a trust relationship to XSUAA, SAP Graph accepts the identities verified by XSUAA and passed to it in the form of bearer tokens. It supports token-based authentication

Once the connectivity is in place, the next step is to interrogate the source systems and build the data model. This is done though a command line interface graphctl similar to many cloud cli’s. the high-level process is to logon to the appropriate account through the cli and use the command to generate the model file and then run another command to activate and actually create the model. This 2-step approach gives you the opportunity to edit the model file if desired, remove/rename entities etc.

The activation time obviously depends on how many LOBs or instances are being connected and the amount of data. One thing to note, the model when built will only find data it has access to, if it can’t see it, it’s not in the model. Initially, this means the connections setup will likely have very high and widespread authorizations – once configured this should be closed down as appropriate.

SAP Graph – accessing the data

Once SAP Graph is up and running graphctl can be used to check status and run commands for normal administration functionality. The data model is also available to interrogate and access through tools such as Postman or if more code orientated through SAP Business Application Studio. In both cases there are easy to follow examples in the training material showing ability to see the different LOB data and selectively access data – e.g., selectively picking personnel number or returning the top 3 jobs etc. The ability to construct more complex queries is an evolving aspect of SAP Graph cf. GraphQL supported.

Building Business applications

Once the data sources are available, the final step is to create the presentation layer (UX) in the case of end users. SAP Graph when initially configuring destinations to source systems has options to include SAP AppGyver etc. as enabled properties of the destination.

When building a project in SAP AppGyver the destinations will then be available as datasources. E.g., entries would exist for each destination HCM (SAP Success Factors), SAP S/4HANA Cloud etc and then built upon and included in the project to create the final application.

SAP AppGyver projects can then be imported into SAP Business Application Studio and published as normal ^[8]. There are examples in the training material, as well as code sources to copy, that demonstrate building an application directly through SAP Business Application Studio – also showing access and authorisation considerations.

If the build examples are followed ^[1] it is very easy to see the power and versatility inherent in SAP Graph as a single source of data which can be quickly made available for business users (or systems) to access and interrogate. Once the source destinations are in place and the Model available further applications can be rapidly created and made available as use cases arise.

SAP Graph – what to build?

The ultimate question and target for SAP Graph, this is where the business knowledge and unique customer needs are matched. The entire trial, tests and setup of SAP Graph was very straight forward and easily completed within a day. Admittedly, in the real world there are a few more considerations but the core setup can be run up (or torn down) rapidly and rudimentary apps distributed and available securely for use through for example SAP BTP e.g., using SAP AppGyver/SAP Business Application Studio and SAP Cloud Identity Services.

The illustration below shows three archetypical ways of creating client applications that use SAP Graph. Each archetype represents differing coding considerations, security requirements, and best practice ^[13].

The ability for a business to easily access and combine disparate data sources in a single place with a unified API layer is the core deliverable in SAP Graph. Noting SAP Graph can’t access data from multiple systems from a single query i.e., representing a union statement. The sources are primarily SAP LOBs but there is also the ability to include ‘custom’ sources to further broaden business scopes (with caveats).

Example scenarios for SAP Graph^13,14

Call Centre business users using SAP Sales Cloud but need access to Business Partner details (available in SAP S/4HANA). A custom app or embedded tile could be created in the business user’s UI to bring the data from both systems together and made readily accessible.

A large company with multiple SAP landscapes (multi-national?) would like to compare and display data between separate S/4HANA instances in a single application. This scenario could also include multiple SAP Graph instances, for example if security or geolocation considerations are present.

The power of SAP Graph comes from presenting data from separate SAP sources at a central point, however, a single source is also a valid scenario. SAP Graph can quickly be configured to grant access to business users to any information in the data model for example in the extension archetype showing when an employee works excessive periods matched with a business rule.

Conclusion

Following the example SAP Graph builds and configuration training is excellent exposure to understanding the power and ease of implementation of SAP Graph. The high-level steps to implementation can be broken down and followed by a person unfamiliar with SAP Graph in a logical fashion to quickly yield access to business data. The structure of the data is then visible and can be interrogated and then built upon to match diverse data needs of business users and processes.

References and further information