Cloud WebIDE - Grunt

So I merrily built an application in WebIDE, and could test using the Application-Test function... but when trying to deploy, I get “Unable to find local grunt” and “npm ERR! code EINTERGITY” errors.

So the whole point of Grunt is to “minify” the code, which makes it more efficient for the computer / phone to use, simultaneously making the code horrific to read and maintain.

Reversing the “Add Grunt” steps (WebIDE was doing these automatically) in

https://developers.sap.com/uk/tutorials/webide-grunt-basic.html

by removing the Gruntfile.js and package.json files from the app 

means that deployment is done without minification, and deploys in like 2 seconds.

Cloud... really?

So I go to log on WebIDE this morning and get the following : 

Seriously, what am I meant to do about this? With on-prem, you've got a BASIS team that you can go and bother, a manager to bother if they're getting slow, and your PM / SDM can go and bang some heads together to get things done...

Now, I'm at the mercy of some behemoth organisation, who may or may not have my back in prioritising fixing this. 

One of the selling points of Cloud was that the infrastructure is handled by someone else, but it's hard to swallow that, when I get the above!

Which leads me to another thing... your business doesn't get a say in downtime. I guess with fail-overs etc, your cloud provider can do a good job of maintenance on one box, whilst you're being served by another, so you'd never have any downtime. In the case where this is unavoidable, the BASIS guys would talk to the Business and find an agreeable time to do it. With Cloud, the Business has no say? Doesn't sound that great!

Anyway, fortunately I've got some backend oData services to build, so I can wait for Cloud to be ready, but otherwise, I'm in the position of saying "Sorry Business, I can't work on it today" and there's nothing we can do about it!?

FIORI Security gotcha : Protocol cannot be switched to HTTPS: HTTPS is not configured / active

Working on a FIORI development recently, I got flummoxed by the following error, observed when running the Gateway transaction /UI2/FLP to access the launchpad : 

This was aiming for URL :

http://<gateway box>:8000/sap/bc/ui2/flp?sap-client=001&sap-language=EN

However, other users were aiming for the following, which worked:

http://<gateway box>:8000/sap/bc/ui5_ui5/ui2/ushell/shells/abap/Fiorilaunchpad.html?sap-client=001&sap-language=EN#Shell-home

Without much explanation... but this is your workaround!

TechEd Barcelona 2018 Review

   So I attended TechEd last week – there was a lot of good stuff to learn, and you’ll be unsurprised to read that it all had a somewhat “Cloud”-y focus, with a twist of HANA / S4 in there too…

I tended to categorise what I saw into 2 blocks  :

1 : Newer ways of doing essentially the same job, but adapting to SAP’s new development mechanisms…

Including :

• Developing using Eclipse rather than SE80
• Developing using WebIDE
• CDS views on the HANA Database
• More interaction between Development, Functional and End-User as an app is developed, using tools like BUILD. (This one’s an interesting one, as it might mean we need to change the way we consult a little, as we’ve traditionally not embarked on much work till we’ve got a proper spec)

2: Cool things that you can do with Cloud Services…

Including :

• Training a ChatBot using recast.ai
• Using AI to recognise images
• Connecting IoT devices to SAP

I’m highly conscious that there’s a degree of scepticism as to whether it’s worth learning any of this stuff if our customers don’t adopt it, or SAP suddenly come out with another new product/methodology that supercedes what we’ve just learnt. I’m less concerned about this now, as SAP haven’t changed their tune on Cloud/HANA for a while now, and it’s starting to stick, as we get more and more customers using S4 and Fiori, I think it’s only a matter of time before we see Cloud adoption.

I’m also aware that, as with any training, it’s done in a very hygienic environment. A demonstration of developing in the Cloud had a step where you “select the backend system from a dropdown”. The reality would be more like “Required system not in dropdown…. Go and bother BASIS team… Set up Cloud Connector… have arguments with people about what can/can’t be exposed to the internet… need upgrade/patching to get backend to the point it can connect… then select system from a dropdown”.

All that said, I'm looking forward to trying a lot of this stuff out, and will drop some links / tuts here as I make them.

HANA Core Data Services

I've been getting to grips recently with the Core Data Services and the ABAP Development Toolkit in Eclipse. I do like dropping into Eclipse from time to time, and it's a nice environment to use once it's been loaded, which can take a while. 

There's two things I've learned today... one is that the filters in Data Preview sometimes need the leading zeroes dropping in : I've spent ages getting rubbish data against Material 123456789 when I really needed 00000123456789. Kicked myself so hard when that one happened.

One of my problems with CDS in ADT is that I'm used to SE80 jumping into SE11 when I double click on an object.

Not here in ADT! I'm forced to go and find the thing.

Whether this is intentional, and will force devs to be all organised in the way they store their definitions, I don't know. There's a lot to like about the way Eclipse integrates with SAP, and time will tell whether it gets adopted by the community, but this feels like a step backwards.

SAP Web IDE Full Stack

This is part opinion piece, part news... I just went in to 

https://webide-sMYSNUMBERNOIMNOTTELLINGYOUWHATITIStrial.dispatcher.hanatrial.ondemand.com/

and was presented with a whole bunch of "WebIDE full stack has not been enabled" messages, which prompted me to investigate what this new and exciting bit of tech could do for me, and why would I want to use it?

This got me thinking... one of the selling points of doing stuff (in my case... development) in the cloud is that 'you always have access to the latest and greatest' and for the first time, it occurred to me that this may not always be a good thing! Yes, FullStack (or whatever the latest development is) could well be the best thing since sliced bread. Or the last version of WebIDE. To be honest, I don't really care. I get that my tool that I'm used to using could be improved upon, but if I'm busy getting code cut, do I have to also start factoring in the potential overhead of getting to grips with a development environment that's changed.

With Eclipse, at least I've been able to be in charge of when I upgrade - like, when I've got time to do it, get to grips with the new interface, process flow, hoops to jump through etc.

I've also got the facility to go back to the previous version.

I'm not Cloud-sceptic - I love the idea of all the benefits it could confer, not least the idea of developing and testing solely in a web-browser, meaning I could use a whole bunch of other devices to do my development. A raspberry pi perhaps... 

BUT

if they keep on messing about with it, then I'm not going to like it, because I've generally got enough on my plate on-boarding client requirements and esoterics, without having to get to grips with a new development environment every other month!

Function module to remove special characters : ES_REMOVE_SPECIAL_CHARACTER

Maybe I need to just have a single "Useful FMs" page... that'll prevent clutter... hmmm...

Table Maintenance Generator

You can do more than just the vanilla...

You can edit the screens that get generated in :Environment -> Modification ->Maintenance Screens - from there you can manipulate the screen field contents, in the same way for a screen you'd built yourself.

2/  Environment -> Modification -> Events. Events numbered 01-05 get hit by the processing of the screen, allowing you to do cool stuff like data validation, kick off workflows, errr... other stuff.

Three Reasons for Test Scripts

Just got asked by an end-user whether they needed to put screenshots into their test scripts... Now test-scripts are only partially for the benefit of the developer; they also serve the end-users and maybe audit, depending on the organisation. This was a pretty simple application (no spec, just a few conversations) for an end-user with whom I've got a good relationship. I'd done a bit of to-ing and fro-ing, had a few sit-down sessions where we point at the screen and talk about adjustments and how to use the app, along with it's supporting reports etc, but not got to the stage where we'd formally tested.

As far as I'm concerned, people do test-documents with a mixture of 3 attitudes:

1 I just want it done, get it into PRD as soon as possible

In which case, you’re shooting for the bare minimum that the CAB board will accept to put it into PRD. You probably don’t need screenshots, you could get away with a text description, replacing “Screenshot of” with “We tested and saw”. 

2 I want a resilient, well tested application that suits my requirements and what I asked for.

In which case, you describe the end-to-end process (new joiners, new users, updates to policy documents, mailing users to prompt them for un-acknowledged policies, facility to review who has/has not acknowledged etc) with expectations of results at each stage. You then run through the entire process, and highlight where the program’s behaviour differs from your expectations.

3 I want to make sure the Customer hasn’t got anything to bash my backside with in the future.

A testing document set up by the customer/apps consultant allows us to confirm that the application has passed any test that was agreed upon, and that any future amendments to the application(s) are either bugs that weren’t picked up in testing, or changes that have subsequently arisen.

In this case, owing to the good relationship, I'm not worried about 3, and the simplicity of the app means I'm not worried about 2, so that left me with 1...

I can't force users to test stuff before pushing to Production, but if I don't, I have to be prepared for the potential of a bunch of re-work!

WebIDE vs Eclipse

The first time I developed UI5 applications, I did so using Eclipse, because that was what the tutorials told me to do. Eclipse has served me well for UI5, but also for Android and HTML5 development. 

The nice thing about Eclipse is that it's on my desktop, and once the HANA/UI5 setup has been done, I know full well that if my desktop can see the SAP system, then Eclipse can too. I don't need to negotiate any firewalls, install anything on the target system, or jump through any additional security hoops. I like that it's free (who doesn't!) and I know WebIDE has a free component, but when you've got a cloud solution, those guys could start charging any minute. (This happened to me recently with BKool online bike-training, who withdrew their free offering, making it a purely premium service...not happy!)

For those reasons, I've enjoyed using Eclipse. A co-worker, who started her UI5 journey with WebIDE decries the difficulty of getting Eclipse set up in the first place, that it's slow, and doesn't offer particularly good syntax checking or intellisense code completion.

She's right on both counts - getting Eclipse going for UI5 development isn't a straight "Download the UI5 Eclipse Version" - JDKs, System settings, JREs and adding software are all gotchas that can impair your progress. 
Additionally, it requires updating every now and then, and if you're using Eclipse for a number of different purposes (say one day you're building an Android App, the next a WebPage) the libraries can all add up and start slowing Eclipse to a crawl - I solved this by having an install for each purpose, which takes up disk space, but at least keeps everything nicely siloed.

The verbal sparring we've had over the merits and drawbacks of each have made the long winter evenings just fly by, as you can imagine.

Bearing in mind that in our role as developers, we often have to just crack on and do the job, we don't get abundant time to try new things and compare the merits;  Not wanting to knock something until I'd given it a fair chance, I've been dabbling with WebIDE recently.

The first few times I tried, it just seemed like someone had WebSkinned Eclipse, and it was slower and more unresponsive than my desktop. Why would I bother!? Here's a shootout for Developers:

Speed:WebIDE
The WebIDE is now faster... wasn't always the case, but Eclipse takes a long time to load. Once it's loaded, it's fine, but WebIDE has the win here:

Connection to backend:Eclipse
Using the HANA Cloud Connector, it's also possible to transmit your code to your on-premise solution relatively easily : There's a good blog about it here:

https://blogs.sap.com/2015/07/13/cloud-connector-a-brief-guide-for-beginners/

I don't think it's quite as straightforward as Eclipse's "Team->Share" option, but once set up is neat enough.

Getting Set Up:Contentious, but WebIDE
Sometimes you can have a really nice Eclipse setup experience, sometimes it takes forever. This seems to be a combination of laptop system settings, what JREs/JDKs you've already got on your computer, and whether HANA libraries and Eclipse releases are in sync at the moment. 
The WebIDE should be a standard "set up an account on a website and you're in" experience... which could be sand-bagged by SAP.com's annoying habit of asking you for a password every page you go to.

Documentation: Eclipse
It's been around longer, so I'm expecting WebIDE to edge this in a year or so. The in-editor documentation on WebIDE is really good though.

Features: WebIDE
Intellisense code completion, documentation, object-method suggestion etc. WebIDE blows Eclipse out of the water on this one, and is the main reason I'm going to try and get some development work done there rather than in ol' faithful(Eclipse) in the next couple of months.

Once you know what you're doing, it'll be the connection to backend that makes the difference - and that'll depend on how amenable your sys-admins are to opening up their SAP system to a cloud solution... but I'm looking forward to using WebIDE a whole lot more.