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: 
MattHarding
Active Contributor

Decisions, decisions...

If you're starting out in SAP Enterprise UI5/Gateway development, you are going to find there are more than a thousand different ways of achieving the outcome. There's editors, there's repositories, there's web content hosting, different types of views, binding techniques, etc; but in just a very quick post, I thought I would highlight just a couple of techniques that I think work well, and this is coming from one of the few Web UI developers still working on a Windows laptop in this space it seems - who would have thought :neutral: (For reference, I also note IE is the most buggy browser for UI5 releases now days which is a shift for SAP)

Web Server

If you are developing UI5, and not sitting next to a big HANA data centre hosting the SDK; or are regularly on planes without WiFi (like we do in Australia), you'll want to deploy Apache Tomcat or similar on your workstation.  You can deploy OpenUI5 libraries against an IIS instance but you don't get everything working if you do this, so I suggest a local install of Tomcat, and hosting your UI5 there. But I actually don't recommend Tomcat for testing your initial development. Why? Well speed of hitting f5 to refresh your app and test actually.

See for me, unless you are a JavaScript legend who has a JS interpreter in their head running continuously over your code understanding all the intricacies of the libraries you've included; making lots of changes in JavaScript within UI5 before doing a test leads to - "it's broken, now what the hell did I do?". Trust me, "Check for 'file not found' or parse errors." will be the most annoying error message you come across when doing UI5 development.  And that's when you need to go over every last change you did in the last 15 minutes to see where you broke the code. Performing more agile techniques of developing a small piece of functionality, then testing it; leads to a more sane development experience; and the ability to wrap up for the day on a win rather than not even wanting to check it in to GitHub as a stable version/backup (since I'm told you shouldn't check-in to Github unless it's a tested working change).

So the fastest way of testing I've come across on Windows, is just to point a virtual directory on IIS at my GitHub cloned repository, make change - test.  IIS instantly feeds up the new content without any delays. There's some cool features in the UI5 Grunt server implementation you'll read about on SCN (quickly typing this post so haven't looked it up sorry) but I found the automatic 1 or 2 second delay in refresh was enough to annoy me, but this may work better for many.

One aspect to consider is setting up cache control appropriately for your source code and libraries. e.g. You want to make sure your ui5 libraries are cached in your browser, but also want to make sure that your code is not cached. You can turn off caching in developer tools, but that slows you down a lot also.

Testing against Gateway using Localhost

I'd love to be able to tell you to leverage the new mock framework in UI5 rather than be dependent on the Gateway server, but until someone posts a guide on how to do this for a production like Gateway service model that may not exist in development yet and responds with a level of logic - I'm forced to tell you how I leverage Gateway. So...

Quick and easy way to run UI5 on localhost and call Gateway (without CORS issues due to localhost and your Gateway hostname being different and Gateway not configured to say it's fine to consume its services on localhost) is to run Chrome in unsafe mode (find your Chrome.exe file and add --disable-web-security ensuring Chrome is not running anywhere) - But that's kind of annoying since I use Chrome for email and everything else and don't trust the web to run in unsafe mode; so rather than do that, let's create a reverse proxy so that everything from /localhost/sap/* goes to our Gateway server for processing. 

This can be a little confusing, but if you follow this post about it, it's not too hard:

http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-applica...

Try to not overthink it like I did, checking boxes I shouldn't have, and it should be straight forward. You may need to play around with header variables and the like if someone has tuned your Gateway and you are using full paths contained with the Gateway responses (in other words, you may need to rewrite the contents of your Gateway calls to point at "localhost/sap" but for typical UI5 deployments, simply getting localhost/sap pointing at Gateway should do the trick.

e.g. If you modify your web.config file in c:\inetpub\wwwroot with the following; after install ARR and activating the proxy; you should be up and running:


<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
                 <rules>
                                <rule name="Reverse Proxy to Gateway" stopProcessing="true">
                                                <match url="^sap/(.*)" />
                                                <action type="Rewrite" url="http://<GatewayServer>:<Port>/sap/{R:1}" />
                                </rule>
                </rules>
        </rewrite>
    </system.webServer>
</configuration>


Editor

Sublime seems to be the editor of choice for UI5 (at least on Windows since Atom runs atrociously slow on Windows but may catch up soon) and hopefully you'll find the information from John Patterson and Tobias Hoffman already to get you set-up correctly. I kind of wondered why everyone loved it since it was a great text editor (fast, easy on the eyes, lots of cool editor options like "find all" followed by editing all found locations at once simply by typing, but not a great development tool; but after looking into JS Linters that run while you type on Sublime Text 3, and Prettify to make all my XML, HTML and JS look fantastic (Thanks John and Tobias for highlighting this); I absolutely can recommend Sublime Text 3. Hopefully some of us are paying licenses for this as the developer(s) deserve making a lot from this editor (it's kind of free but with an annoying prompt if you don't buy it).  Note - Anyone come across a good real-time XML linter for ST3?

If you're wondering what Linter is all about - well just wikipedia it, but in short it's effectively looking for compilation or proper usage errors in your code.

Eclipse - Meh...

The HANA RDE for UI5 has hope, especially offering XML View intellisense, but was just too slow for me in Australia to be usable.

GitHub - Code Repository

I run GitHub Windows on my desktop as I'm not a power "Command line Git user" just yet and haven't figured out what Sublime is capable of doing here, but it's very cool for submitting the changes, and seeing the differences in your code.  To get a private repository for enterprise development is only US$7 a month; but if you don't feel like paying that for privacy, make sure you accidentally let us in on your GitHub account so we can all learn from each other...

Now something I probably do incorrectly, but whatever, is I tend to backup versions of my code regularly while refactoring my code. The reasoning behind this is that GitHub makes it so easy to look at what you changed, and can help debug refactoring regression issues.  Plus, if I had a developer who only checked in once a week, I'd be worried they weren't backing up their code anywhere. Supposedly working off branches is discouraged now days, but for me, the team is working on independent developments, so it isn't an issue for now.


Deployment

John and Tobias start to get into this in Tobias's Grunt blog and looks like John has a good #saptd session coming up about this that I plan to attend; but all I can say is; when it comes to deploying in production; standard development code can be significantly improved for performance.  Maybe on your initial release, deploy as is to allow debugging of problems; but effort (not insignificant) is required to get everything caching, minimalised, grouped, etc.


That's all folks!

That's it for now as I'm just quickly getting my thoughts down plus wondering how much more I don't know that some of the readers may be able to help us with. For those new to UI5 development, I hope this is of help and gives you ideas, especially if you're stuck (happily) on Windows.

34 Comments
Labels in this area