Skip to Content
Author's profile photo Florian Pfeffer

Using Grunt to test your UI5 app locally against SAP Gateway OData Services


Testing locally a UI5 app with mock data is useful for the most cases. But for specific cases and end to end tests it is useful to be able to access the real OData Service running on SAP Gateway without deploying the app to the server which is time consuming. If Eclipse is used as development environment, this can be done using a Proxy Servlet ( But because Eclipse is not really a JavaScript IDE (also not with the new Neon release), another IDE is used in most cases for UI5 development (in case the SAP Web IDE is not available).

Testing locally against a real SAP Gateway OData service (without deploying the app to the server) can be reached by using Grunt ( Grunt provides different plugins for starting a local web server with additional features to redirect requests to specific resources avoiding Same-Origin-Policy problems.

In the following steps the details are described. It has to be considered that because of simplicity reasons the Grunt file is not split up in task based files like it is normally done in real life projects. And of course the following described things a just a specific part out of a larger “Grunt Universe” task list used for a UI5 project.

The Gruntfile.js file

The Gruntfile.js file which has to be placed in the root folder of your UI5 project has just a few lines of code to fulfill the requirement. First all used Grunt plugins are loaded (here using jit-grunt, instead of using grunt.loadNpmTasks for each single plugin). Afterwards the necessary tasks are configured and registered. The details are described below.



To be able to use Grunt, a few pre-conditions have to be fulfilled.

  • Node.js including the Node Package Manager (npm) has to be installed. Follow the instructions on for that. If you are in a corporate network please consider to set the proxy settings for npm (
  • The Grunt Command Line Interface is necessary. It can be installed executing command “npm install -g grunt-cli” in a terminal window. This installs the Grunt Command Line interface globally on your system.
  • Following Grunt plugins and the jit-grunt package have to be installed locally via a terminal window pointing to the root folder of your UI5 project. The plugins/packages are:
    • grunt
    • grunt-contrib-connect
    • grunt-contrib-watch
    • grunt-connect-proxy
    • jit-grunt
  • The packages can be installed via command “npm install grunt grunt-contrib-connect grunt-contrib-watch grunt-connect-proxy jit-grunt”. Adding the option “–save-dev” would add the packages as development dependencies to a “package.json” file if one is defined (for real-life projects a “package.json” file should be used, but for simplicity reasons it is not discussed here).

Detailed look on the Grunt file content

Let’s have a detailed look to the different parts of the Grunt file.

Settings properties

To avoid duplicate definitions of the same host/port information in the grunt configuration tasks, properties are defined which can be reused.

  • contains the host information for the local web server started by the connect task
  • settings.connect.port contains the port information for the local web server started by the connect task
  • contains the host of the SAP Gateway server
  • settings.proxy.port contains the port of the SAP Gateway server


Connect and proxy task configuration

The connect and proxy task configuration are the main configuration steps for the goal to be reached. In the general “options” property of the “connect” task configuration general information like the hostname and the port of the local web server are defined. Also a port for the “livereload” option is defined. The livereload steers in combination with the later defined watch task that the open browser window is refreshed in case a file of the UI5 project is changed. As additional middleware the “proxyRequest” middleware is added. This allows the usage of the proxy definitions which do the redirection of requests to a defined target. Within the “connectWebapp” configuration it is defined that the webapp” folder of the UI5 application is the root for the local web server. The “open” option set to true steers that if the task is started, the default browser starts automatically pointing to the local web server.

Within the “proxies” configuration two proxies are defined. The first one defines that all requests starting with “/resources” are redirected to the SAP Gateway system. In addition a rewrite rule is defined which does a re-routing of “/resources” to “/sap/public/bc/ui5_ui5/resources”. So with this proxy configuration the UI5 resources available on the SAP Gateway system is used. Of course this step is optional, you can use SAPUI5 via CDN or via other resources, but it shows nicely how easy it is to do URL-rewriting. The second proxy then steers that all requests to “/sap/opu/odata” (so all OData requests) are redirected to the SAP Gateway system.

The “https” option is set for all proxy definitions to false, in case the https port is used it needs to be set to true. If between http/https it is switched it makes sense to define the value for the “https” option also in the above described settings property.


Watch task configuration

The watch task checks if changes are done in the “webapp” folder. Due to the “livereload” option any changes trigger a refresh of the open browser window to reflect the changes. So an easy testing is possible without doing several similar steps to refresh the browser window manually.


Register Grunt tasks

As last steps in the Grunt file the tasks are registered. A “serve” task starts the local web server and the watch task. As usual also a “default” task is registered, which does in that simple example nothing else than starting the serve task.


Test it

A simple app which uses the GWSAMPLE_BASIC OData service (/sap/opu/odata/iwbep/GWSAMPLE_BASIC) available on newer SAP Gateway systems is used. The app displays some product information.

The app files are stored in the “webapp” folder, containing also an “index.html”.


Executing command “grunt serve” (or just “grunt” due to the default task configuration) opens a browser window which points to the address of the local web server (in that example http://localhost:9555). Due to the available “index.html” file, the app is loaded automatically. All requests against “/resources” or “/sap/opu/odata” are redirected to “/sap/public/bc/ui5_ui5/resources” and “/sap/opu/odata” on the SAP Gateway system. The first time the system is accessed the user name and pwd has to be entered for the logon. After that the running app is displayed and consumes the OData service from SAP Gateway (and also the UI5 resources).


With that it is possible to access SAP Gateway OData services locally without deploying the app to the server. Any changes in the “webapp” folder will trigger a refresh of the running app due to the used “livereload” option.


The above described Grunt file and the test app can be found at

If you have a SAP Gateway system with the GWSAMPLE_BASIC OData service available you can clone the repository, execute “npm install” in the root folder of the project, adjust the host and port information for the SAP Gateway system in the file “Gruntfile.js” and execute command “grunt serve” to test it by yourself. “npm install” installs all required packages defined in the “package.json” file. If you do not have installed the Grunt Command Line interface, this has to be done too (check the pre-conditions above).

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Augustin Braslasu
      Augustin Braslasu

      Hi Florian,

      The above works quite well. I’ve tried it with GWSAMPLE_BASIC via the public ES6 system (

      The issue I have right now is accessing backends over SAProuter, as it introduces the need for a secondary proxy.

      Have you ever encountered this challenge/need?

      UPDATE: In case someone finds it useful, this proxy module worked for me. Note the CSRF issues with POST calls that could only be fixed by having an HTTPS local web server.