Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
pfefferf
Active Contributor


Intro


At the moment of writing this post in the UI5 projects I am involved there is always the discussion which IDE should be used. SAP Web IDE would be of course the best choice in most cases, but many customers are still somehow reserved regarding web based tools in the Cloud and storing the sources not on own servers. There are solutions for such problems, but they are still some kind of a workaround. Another gap of SAP Web IDE are the missing Continuous Integration and Continuous Delivery options at the moment (this gap will be closed in the next few month according to SAP). Beside SAP Web IDE the next choice we have for UI5 development is Eclipse with the UI development toolkit for HTML5. But hopefully everyone agrees, Eclipse is not really an IDE for JavaScript development (not fast, code completion slow and buggy, ...). The advantages of Eclipse are the SAPUI5 ABAP Repository Team provider which comes with the UI5 plugin and to work with an on-premise Git repository. Due to the described reservations of customers and behaviors of the IDEs (especially Eclipse) in many cases the projects decide to use another JavaScript IDE (for instance WebStorm or Visual Studio Code) to implement their openUI5 and SAPUI5 apps. But there is still a gap in the process. The chosen IDE does not support the deployment of the UI5 sources to the NetWeaver ABAP system if the apps should be executed on such a system. Neither directly from the IDE nor from a CI server. To close that gap, the closest solution was to create a Grunt plugin which does the job. Nearly each project uses Grunt (or Gulp which can also call Grunt tasks via a special plugin), so that the integration of the additional task is very easy (either directly in the IDE or in a project of a CI server).

Grunt Plugin "grunt-nwabap-ui5uploader"


The Grunt plugin which does the upload job is called "grunt-nwabap-ui5uploader". The plugin does following things:

  • Create BSP container if not already available.

  • Synchronize folders between local project and the BSP container (create new folders, delete removed folders).

  • Synchronize files between local project and the BSP container (create new files, delete removed files, update changed files).


The sources and documentation are available at https://github.com/pfefferf/ui5-nwabap-deployer/tree/master/packages/grunt-nwabap-ui5uploader. As usual for a grunt plugin it is available as NPM package for easy installation and usage (https://www.npmjs.com/package/grunt-nwabap-ui5uploader).

The pre-conditions for the usage are:

  • Node.js must be installed (>= 8.5).

  • Grunt's command line interface must be installed globally (npm install -g grunt-cli).

  • Grunt must be installed for the project (npm install grunt --save-dev).

  • On the NetWeaver ABAP system the ABAP Development Tool services must be activated (transaction SICF, path /sap/bc/adt) and the user must have the necessary rights to use the tools and to create/modify BSP containers which acts as UI5 repositories.The plugin was tested with NW 7.40 and NW 7.5x systems.


To install the plugin just follow the steps described on Github. When the plugin is installed the configuration and registration of the upload task can be implemented in the "Gruntfile.js" of your project.

Here is a little sample project containing a UI5 app (based on UI5 1.28, so no manifest.json) to illustrate the setup. All UI5 app relevant objects are contained in folder "webapp".



In the following Grunt file there is just a task "nwabap_ui5uploader" defined which describes that all files in the "webapp" folder should be uploaded to a BSP container "ZZ_UI5_DEMO_AP1" in package "ZZ_UI5_UP_DEMO". For simplicity reasons in that example the whole content of the "webapp" folder is uploaded. In real life projects several "build steps" would create an optimized version of the coding stored in a separate folder, for instance "build". In that case of course the optimized coding has to be uploaded.

Because the changes are tracked, a transport number is also defined. It is also possible to upload the sources as "local objects" into the "$TMP" package without transport number. To avoid that the user name and password for the NetWeaver server are stored in the file, they are passed as command line arguments which are fetched using grunt.option().

This is a very simplified Grunt file to set the focus only on that specific plugin, but in real life scenarios there are of course some additional tasks for linting, UI5 preload component creation, test and many more. For a detailed list of all options available for the upload plugin (e.g. strictSSL, object language, ...), please have a look to the documentation on GitHub.


Usage scenarios


After the upload task in the Grunt file is defined it is ready to use. Following two sample scenarios shows how it can be used.

Direct upload to NW ABAP


This first example is for developers who do "single man" projects or who wanna test their implementation directly on the NetWeaver server in for instance a BSP container assigned to the "$TMP" package.

In a console for the project folder the developer just have to run the following command.
grunt --user=myuser --pwd=mypassword


Before the execution the target package is empty.



The console display which actions are done for which folders and files. In that example only "create" operations are done, but if you later change or delete files or folders the corresponding actions are displayed also in the log.



Afterwards the BSP container and the UI5 sources are available in the package.



Testing the app via calling "index.html" file shows that the upload worked.


Integration into Continuous Integration/Continuous Delivery environment


The scenario to integrate the upload/deployment step for an UI5 app in a CI/CD environment is the most interesting for me. In a CI/CD project there are several build steps defined (e.g. static code checks, execution of tests). If all steps are processed successfully the sources should be uploaded to the NetWeaver ABAP server by calling the defined Grunt task.

For demo purposes I created for the above described UI5 project a Jenkins project pointing to the Git repository of the UI5 project. The configuration executes an "npm update" step to install/update the Node.js plugins necessary for the node related steps. Afterwards the grunt nwabap_ui5uploader step is executed which triggers the deployment of the sources to the NetWeaver ABAP server. To avoid to directly enter the password in the console step I used the "Masked Passwords" plugin. With that plugin a variable NWABAP_PWD is defined with the masked password. This variable is then addressed with "%NWABAP_PWD%" to provide the password for the grunt task execution.



If the build is successful, in the Jenkins build log also the action steps of the upload task can be found. To see a difference to the example before I deleted the folder "test" containing file "test.txt" in the "controller" folder. The started build was successful and in the console output of the Jenkins build the following information can be found.



And of course the BSP container is updated, that means the file and the folder removed from the Git repository were deleted on the NetWeaver ABAP server too.


Conclusion


With that plugin it is a lot easier for me to setup my development environment for UI5 projects regarding the choice of the IDE and the integration into a Continuous Integration and Continuous Delivery infrastructure. There are so many other Grunt plugins which can be combined in such an environment to help to improve the quality of the source code and to the improve the efficiency of a developer. In case you try out the plugin and find some bugs, please report it via GitHub.

10 Comments
Labels in this area