The SAP Data Intelligence Graph, the seventh SAP API Development method introduced in Jerry’s previous article, is actually a manifestation of Low Code Development.

Through a specific example, this paper introduces how to combine various standard operators released by SAP in the graphical interface of SAP Data Intelligence Modeler in a way similar to children playing with building blocks, and then obtain an API that supports addition, deletion, modification and checking through a small amount of coding.

Open the Operators TAB of Modeler and see that there are more than 300 Operators under different Categories.

Each Operator can perform a function for a certain domain, such as connecting to the ABAP system and reading data, generating random data, writing data to a persistent store, calling apis, and so on. We end up with an end-to-end scenario by combining these Operators.

Let’s try out some of the simplest operators before we use them to build apis. Drag and drop a Data Generator with the Terran radar station icon from StarCraft into the edit page.

This Operator defines an Output Port of type String, which means that it generates a random number of type String that is passed to other operators through this Output Port.

The Output Port of the Data Generator in the figure above points to the Input Port of another Terminal Operator, which represents the direction of the Data flow from the Data Generator to the Terminal.

These nodes, Operators, and directed lines that connect nodes together form the Graph in SAP Data Intelligence.

The SAP Data Intelligence website mentions one of its “embrace of open technology” qualities:

For example, the Kafka Consumer and Producer Operator provided by SAP Data Intelligence can easily implement producer-consumer scenarios without programming by maintaining a Kafka Broker address:

Now back to the requirements for adding, deleting, and reviewing the API mentioned at the beginning of this article. The API allows consumers to invoke it over HTTP, and the operation objects that are added, deleted, modified, and checked via the API are only maintained in the Graph runtime’s memory, which are essentially key/value pairs of objects that JavaScript simply implements, with persistence omitted for simplicity.

The API implemented by Graph finally consists of six operators, one HTTP Server, four JavaScript operators, and one Multiplexer, as shown in the figure below.

According to the help document, the HTTP Server Operator encapsulates the functions of the simplest HTTP Server and can receive HTTP requests at user-specified endpoints.

How do I configure Operator? Right-click on the menu and choose “Open Configuration”, click the “Routes” edit icon:

According to the SAP help document, the HTTP Server Operator is only responsible for receiving HTTP requests, but not for business processing after receiving these requests. Instead, it is sent to other operators downstream of Graph through the Output Port. Route configuration information is clear. After receiving HTTP request with parameter ID on path/Objects, the request is forwarded to other Operators through three Output ports of GET, POST and DELETE according to HTTP request type.

Next we implement the response logic for the HTTP GET operation. Drag a JavaScript Operator from the Operators TAB to the edit page, rename it GET Handler, create an Input Port named Request, and connect it to the HTTP Server’s GET Output Port.

Right-click GET Handler and select the Open Script menu item:

Expect the HTTP Server to have some generic logic to handle when receiving GET, POST, and DELET requests, such as parsing the object ID parameter values passed in by consumers from the URL and handing them to downstream operators for further processing. So the design here is that these three handlers, upon receiving the request, simply construct a command object that contains the operation type of the key-value pair of the JavaScript object in memory corresponding to the HTTP request (GET request corresponds to SELECT, POST request corresponds to insert, DELETE request corresponds to DELETE) and the passed parameter ID value:





It can be seen from the figure above that the implementation codes of these three handlers have no other differences except the operation types (objectStore.command) transmitted to the downstream nodes through the command Output port.

After an HTTP request is received by the HTTP Server, only one of these three handlers is triggered. The three types of handlers produce three possible Output operations, which are passed to the triplex marked trident in the figure above through an Output Port named Command. This multiplexer ensures that the last JavaScript Handler handles all three of these possibilities simultaneously, executing the corresponding key-value pair operation and passing the result of the processing through the data stream indicated by the orange dotted line above to the HTTP Server’s Input Port.

Inside the JavaScript Handler named Object Store, the variable Objects defines an empty JavaScript Object as the storage entity for key-value pairs. For select, INSERT, and delete operations, this object is used to add, delete, change, and search respectively.

In this way, the Graph forms a complete closed loop from receiving the HTTP request to writing the result into the Input Port named Response of the HTTP Server after processing the request.

Once Graph is developed, click the Run button, and when it is running, it can be consumed using tools like Postman or programming languages. Copy the Runtime Handle from the console:

First test the API reading function and try to read an instance with ID 1:

https:///app/pipeline-modeler/service/v1/graphs//operator/httpserver1/objects/1

The message “no obect with ID” is our hard-coded error handling in the Object Store JavaScript Handler.

We then call HTTP Post to insert a JavaScript object with key 1:

Then use HTTP GET to read, this time successfully:

DELETE the object with ID 1 using the HTTP DELETE request:

I hope this article can help you to have a most intuitive understanding of the low code development approach in SAP Data Intelligence. Thank you for reading.

Read more

  • SAP OData programming guide
  • 30 minutes To develop a Fiori application with Restful ABAP Programming model to support add, delete, change, and query
  • Advice from a 13-year ABAP veteran: Knowing the basics will never hurt ABAP development
  • Deploy and run Docker applications on SAP cloud platform
  • How to use API to consume SAP Commerce Cloud order service
  • From ABAP Netweaver’s SICF to SAP Kyma’s Lambda Function
  • Zhou Botong’s Kongming Fist, Minos’ Stardust Puppet line, SAP Kyma’s Serverless
  • From SAP Leonardo to SAP Data Intelligence

  • SAP API development methods

For more of Jerry’s original articles, please follow the public account “Wang Zixi “: