REST Service Integration in SAP BW
Integration is one of the most important keywords in today’s Information Technology systems. The ability to connect outside of its boundaries and collect data that would be otherwise effortful or not possible to create is one of the utmost important features to an application, with a great number of implications. As web applications gain popularity, so is the need for their integration. REpresentational State Transfer, also known as REST, is a wide-spread Architectural Standard for the creation of Web Services (also encountered as Web APIs). From Social Media to Banking, most web applications/sites we use in our personal and work life rely on Web Services. REST Services, in particular, are employed by the products of a number of today’s software giants. We, the BI consulting company - DAHLBEER, strongly believe in the benefits of automating those user actions that machines can perform better/faster as well as decreasing the number of applications & screens the users are exposed to – two of the numerous use cases for a REST service interface. In today’s article we’ll take a closer look on REST Services and how can we communicate with them using SAP BW.
Web Service Basics
Web services are a way for a web application to interact with the outside world and send and receive data. Let’s imagine the following case: A Company needs to calculate the amount of labor spent by its employees on different production processes for the sake of a price planning application in its SAP BW system. The Company has already invested in a third-party time tracking web application for the needs of its HR department and the tool has a built-in Service that can provide data to external applications when requested. The BW system can Call the Service and Request the total time spent on a particular activity (parameter I) for a given period of time (parameter II). The Service in its place would provide a Response to the caller. This approach is much more efficient than building mirror time tracking solution and asking the users to submit their timesheets in two different systems.
Rest Specifics
REST is a particular way of building a web service. RESTful services are considered easier to operate with, they are based on Hypertext Transfer Protocol (HTTP) and have similar constructs and same status codes. REST is language independent, meaning that any language that can execute HTTP requests can be used.
The most important elements of the request are:
URI ( Universal Uniform Identificator = URL + URN): Shows the location and name of the service
Method: Shows what action should be accomplished with the data. Most widely used are POST and GET methods. Use POST if the use case is to send data to the service and GET to receive data from the service
Headers: Fields that help in establishing communication between the parties. Passed in “Key” : “Value” format. Example: “Accept: application/json”
Parameters: Values that show the service details about the requested data or help to determine what internal function needs to be executed.
Authorization Elements (optional): Contain a form of user authentication. Different types exist, but the most basic form is just supplying username and password.
Body: Has no meaning for a GET request, however, in case of POST should contain the data to be sent.
Each request is followed by a response that has headers and body of its own, as well as status, In case of a GET request, the requested data would be found in the Body of the response. Example: “Accept: application/json”
{ "ActivityCode": "11", "EmployeeCode": "203192", "DepartmentCode": "M14", "TimeSpent": "15d", }
Calling a REST Service from within BW
Let’s review the two most common ways to call service via HTTP in BW. One of them is Class-Based and the second one is Functional Module Based. The latter employs standard modules “HTTP_GET” & “HTTP_POST” the import and export parameters of which contain the basic elements of the request. Complex calls, however, would require the use of the built-in http classes & interfaces in BW. Here are the basic steps that have to be followed:
Declare URI object referencing interface if_http_client – Will be used to building up the URI & Authorization Elements
Declare Request & Response objects referencing interface if_rest_entity – Will be used to building up the request
Declare Call Object referencing class cl_rest_http_client - Will be used to executing the request
Call Method cl_http_client=>create_by_url to Create the URI object
Call Method lo_http_client->request->set_version to Set HTTP Version for URI Object
Call Method lo_http_client->authenticate to Authenticate URI Object (optional)
Call Method cl_http_utility=>set_request_uri to set URI in URI Object
Create Call Object by using CREATE OBJECT statement & exporting the URI Object
Create Request object for Call Object using [Request Obj.] = [Call Obj.] ->if_rest_client~create_request_entity( )
Set Header fields for Request Object using [Request Obj.] ->set_header_field( iv_name = 'Accept' iv_value = 'application/json' )
Set Body for Request Object using [Request Obj.]->set_string_data( lv_body_string) (optional)
Execute HTTP Method: [Call Obj.] ->if_rest_resource~get( Request obj. )
Collect Response. [Response obj.] = [Call Obj.] ->if_rest_client~get_response_entity( )
Architecture & Automation
In a productive application, service calls would be rather frequent and they would need a proper mechanism to in order to connect to the application landscape. Among many architecture possibilities, here we show a couple that represents a simple, and a complex planning scenario.
In the first one, the sole goal of the REST service interface is to supply plan data to a subsequent planning step inside a web application via scheduled data pushes.
Data originates from a real-time InfoCube and is loaded in a write-optimized DSO (with the relevant transformations), which has the same granularity as the target on the Web application side. A program reads the DSO into an internal table and then proceeds to execute an HTTP POST to the desired service. A process chain that includes both the data load to the DSO and the program is needed for automation.
In the second approach, data is selected from the Cube via a custom planning function and transformations are executed via ABAP Code. Afterwards, a dedicated helper class takes care of calling the REST Service. Due to the use of a planning function, the reverse action is also possible: User executes a planning sequence in order to get real-time data from a remote system. In essence, this architecture allows both data push and data pull from BW perspective.
Creating a Native BW REST service
In order to enable initiation of a Push/Pull on the remote side as well, BW has a Web Service Creation as well as Web Request Handling Capabilities Integrated, which make it possible to implement a REST service straight in BW. This way, the system would be open for calls from external web applications requesting data on the fly. This would enable web applications which cannot store large sets to still display relevant user selected data or even do planning. Transaction SICF is responsible for the creation of the Service entity. A custom ABAP class, however, has to be created to read the call and extract/write data from respective InfoProviders. Among other exciting use cases, such an implementation would make planning and reporting easily possible from mobile devices.
In Conclusion, the wide adoption of Rest APIs in combination with matching BW features provides us with an easy gateway option to most modern web applications in order to gather and distribute information, outsource complex calculations, derive pictures and link planning applications to various web services providing valuable input.
Comments