Using WebIDE Personal Edition in a corporate environment

Long time lurker, first time blogger…

Introduction

While many developers are happily using WebIDE in the cloud platform for Fiori development, it is not always easy for some to get access due to the nature of their company’s business and security policies/concerns. Developing code in the cloud is still somewhat unorthodox and requires a bit more understanding with a magnifying glass. In this blog I’d like to discuss how we started using WebIDE Personal Edition in our organisation for production Fiori development. To get this to work, we had to use a number of non-SAP tools, including GIT, TeamCity, and open source modules such as Grunt, openui5-preload and, nwabap-uploader.

Security and network – burn burn burn

In order to get WebIDE in SCP working, the initial setup process is a small project in its own right and requires many parties involved. Installing/setting up the cloud connector, white listing the SCP URL in our corporate B2B proxy, getting security endorsement for this new development approach, establishing funding model in on-going support and maintenance etc — all these do not happen overnight. Lots of grilling questions will be asked by different teams who don’t know much about SAP –

• How secure is this approach going to be?
• Once the connection is established, what data flows back and forth between the outside world and our internal systems?
• What happens to the IP to our source code – now that it’s left the organisation, will others be able to see it?
• Will the outside world be able to initiate a call to our development environment, and connect to our prod environments etc.?

Whilst these are all excellent questions, it requires a bit of investigation to answer appropriately. It’s not as simple as install and forget about it. Of course the answer is Yes Yes Yes, and YES — it’s all good and safe and SAP will do all they can to ensure everything is good and nothing is going to happen, while I hand over the terms and condition from SCP. In short, getting WebIDE in SCP set up is not a walk in the park. We are still working through this but it’s a long journey.

How we used to develop Fiori applications

We started our Fiori journey around 4-5 years ago, and back then using Eclipse (Juno) was the only IDE available. For those around long enough, we had to use an Eclipse plugin called “Fiori extension toolkit”. SAP Fiori was only available in the Netweaver stack, and like many others we extended standard SAP Fiori applications for our own use.

This is a typical development process for us:

1. Our developers would use the “ABAP Developer tools plugin – Team provider” to download the BSP application source code (where Fiori is stored) from development box into Eclipse.
2. After the development is complete, we then use Eclipse to call an open source plugins – (grunt + openui5_preload) to minify and generate component-preload file for our Fiori source code. (Preloading/bundling is basically a concept of bundling all your HTML resources into one single file so that your browser does not make hundreds of requests to get all the files to your webapp – thus reduces network traffic and loads a bit faster).
3. Finally the developer would push the source code back to our development box using the Team Provider plugin and test our changes in DEV.
4. Unit test, and release transport.

While this is all great, we do face a number of challenges with this approach:

• We could not run and test the code on developers laptop easily – our Fiori apps had a bit of dependency to the backend configuration and cannot easily run locally. Using a Mock Server to fake oDATA response and config wasn’t not entirely practical for us. Especially when we were extending SAP Fiori apps, that were in it’s infancy back then difficult to run locally.
• As we could not run locally we have to unit our changes in the development system, which means our development system is always volatile whilst change is in flight. This is no different to normal ABAP development I guess.
• Locking – If two developers are working on the same object, they could lock each other out – Just standard ABAP limitation.
• Fear of developers forgetting to generate component-preload.js file their code before uploading
• Rely on ABAP code version management – not easy when you have heaps of files.
• Automating unit testing was not easy

WebIDE Personal Edition (PE)

A bit over a year ago, WebIDE Personal Edition (PE) was made available by SAP to customers for productive use. You still require a WebIDE SCP licence to use it. It’s more palatable as it’s on-premise, and I no longer have all the headaches mentioned above. One might consider WebIDE PE as little brother of the cloud version. It has way less features (no plugins), much less templates, updated infrequently by SAP.  This is by no means like for like, but we consider this a big jump from Eclipse. Use it at your own discretion. There’s an excellent blog by Florian Henninger covering how to install WebIDE Personal edition so that I won’t cover it again here. Maybe I’d like to add some tips and tricks maybe someone will find it useful in the next blog.

(In fact there are quite a few different versions of WebIDE available now, how confusing. You might want to read this awesome blog)

How our build pipeline works now….

We installed WebIDE PE in all our developers’ machines (see Florian’s blog). We could have gone with a more centralised approach, but we lose flexibility for the developer. We need better version control – our current only means was was to rely on version control in SE80.

Make GIT the central repository for Fiori

The beauty is that WebIDE works with with GIT out of the box. We have a enterprise GIT environment available to us, so we decided to make that the central repository for all of our Fiori source code, no longer SAP ABAP repository. (You can either use Github or Bitbucket, both works). We then copied the code from BSP repository to uploaded it to GIT manually using tools like Git extensions. (We have one GIT repository per BSP application).

In short, the idea is that the developer would do the following:

1. Create a new branch and clone the GIT repository to their local WebIDE PE environment,
2. Build and test locally, and commit and push code back to GIT when they have completed development.
3. The code will be code peer-reviewed, pull request will then be approved approved, and allowed to be merged back into the master branch.

Now we have a problem. How do we sync the source code back into SAP, which is the source of truth that matters? Where should we build component-preload for our Fiori projects (previously we do this Eclipse)? and WebIDE PE has no such capabilities (no plugins etc).

We use TeamCity to solve this problem…..

Note, WebIDE PE allows you to push your code directly back into SAP using the “Deploy to SAPUI ABAP Repository” function. However we noticed the following:

• Every file in the BSP application is replaced (not just delta) – losing all change history.
• Our GIT will become out of sync, which defeats the purpose of the whole exercise.

TeamCity

Continuing from above, the developer has finished developing his code, tested locally and has merged it into the master branch of GIT. Now the final code sits inside GIT, but we really need that code back in SAP development environment and use SAP transport management system to transport the code to our test environments.

We use TeamCity to plug this gap, but there are many ways to skin this cat. We used TeamCity because it is readily available to us.

So we wan to code to go from: WebIDE > GIT > TeamCity > SAP DEV

In brief, we have TeamCity listen to a branch merge event to master branch of the GIT repository. Team City will:

1. Download the source from the master branch into it’s agent’s artefact.
2. Determine transport to use – we have some powershell scripts written in Team ity to call SAP DEV to determine which transport to use. We developed some simple logic in SAP (in a HTTP handler) that will determine whether we can use an existing transport, or create a new one. Luckily, this logic is already delivered by SAP because the Team Provider/ADT modules uses them. Our code just has to call it (see ‘/sap/bc/adt/cts/transportchecks’) to get an existing transport number, and if it can’t find one, we will create one. We will always return a transport number.
3. Call Grunt script which that will trigger “OpenUI5_Preload” node module to create component-preload file
4. Call Grunt script which that trigger “nwabap_ui5uploader” to send the code back to SAP DEV with the correct transport.
5. An email notification is then sent to the developer with the transport number.

Summary

Voila, Fiori source code goes back to SAP, and the developer has to manually reassign the transport back to themselves and release it. Of course this is not the only way you can do this. There are many ways to skin a cat, and I’m sure there are better ways. We’ve been doing this for about a year now and so far so good. As with anything with IT, there are probably way better ways that superseded this already.

Leave some comments below to let us know what we can do better.