“fiux2″ Week 7 – Build Your Own SAP Fiori App

(See first post in this series — “fiux2″ – The openSAP Fiori Course – 2016 Edition — for links to the other posts).

We’re into week 7, the final week of this openSAP course “Build Your Own SAP Fiori App in the Cloud – 2016 Edition”. As we’re in the midst of building our app for the Develop Challenge, this final week is deliberately short, with only two units.

Unit 1 “End-to-End Development Scenario”. If you’ve seen a demo of the SAP Web IDE before, in particular for generating and subsequently editing an app from a template, you’ll be already familiar with a lot of the content of this unit. I’m all for repeating information and demos for learning and for strengthening the neurons, but I honestly didn’t find anything significantly new here. I think perhaps the intention is to show a final end-to-end scenario, where each course participant should now be comfortable with the details and nuances for each part along the way.

There was one part which touched on some of the features of the git functionality in the Web IDE, along with a brief view of how that then is exposed in the SAP HANA Cloud Platform, but I’d like to have seen this in the context of a non-master branch.

Unit 2 “End-to-End Administration Scenario”. In many ways, this is the other side of the coin to the development of UI5-powered apps for Fiori scenarios. While Unit 1 covers this development, this unit briefly covers what’s possible in the context of the setting for these apps – the SAP Fiori Launchpad. Specifically, this is for the cloud-based Launchpad, as provided by the SAP HANA Cloud Portal services of the HANA Cloud Platform .

It’s a shame that the content of this unit is out of date, at least visually.

Screen Shot 2016-04-10 at 13.28.42

The SAP Fiori configuration cockpit changed a while ago, and looks nothing like what’s shown in this unit. There was a brief disclaimer message during the video, but that doesn’t really help that much. That said, the actual functionality has not changed much, and with the availability of the cloud-based Launchpad in the HCP trial accounts, it’s quite easy for you to explore it yourself.

In fact, because there are some complex relationships possible between the building blocks such as tiles, groups, catalogues and role, it’s better anyway to have a play around and try to get something working that makes sense to you. This is a great example of where theory is not everything – getting the mechanisms under your fingernails and the ideas embedded into your understanding is key here.

One feature that was highlighted was the “dynamic” tile type. This is close to my heart, especially in the light of our upcoming lunchtime webinar on 26 Apr:

The SAP Fiori Launchpad as a Human-Centric Dashboard

where we explore the possibilities that are presented to us by the SAP Fiori Launchpad and its features such as the different tile types.

Finally, there was a nice touch after the instructor added the details for the dynamic tile – specifically the Number Unit value “Notebooks”:

Screen Shot 2016-04-10 at 14.23.34

“Wait!” I hear you say. “That’s static text – what about consuming this in different languages?”.

And the openSAP course folks must have pre-empted that thought. Directly following this was a short section on the Translations service within the configuration cockpit. In a similar way to how you handle internationalisation (i18n) resources for a Fiori app using the UI5 detection and resourcing mechanisms, so you also can manage property files of name/value pairs for text elements.

Here’s a screenshot of what this looks like, slightly beyond where this unit’s video ended:

Screen Shot 2016-04-10 at 14.25.15

Here, I’ve added and activated a German locale for my Launchpad, which means I’d see the translated texts when consuming the Launchpad site in German, say, by adding the sap-language=de parameter in the URL.

Anyway, as I mentioned earlier – the best way for you to learn more is to get going on your trial account and play around. Have fun!



“fiux2″ Week 6 – Extend SAP Fiori Apps

(See first post in this series — “fiux2″ – The openSAP Fiori Course – 2016 Edition — for links to the other posts).

Well we’re on to the penultimate week of learnings, in the midst of the Design Challenge Peer Review due in at the end of this week, and at the start of the Develop Challenge. Phew! Let’s take a look at the units this week.

Unit 1 “Introduction to SAP Fiori Extensibility with SAPUI5″. This was quite a good overview of the different extension capabilities with SAP Fiori. It’s an introduction, so I didn’t expect to get a deep dive, but in fact the presentation of the extension concept, within the time and slide contents constraints, was a good one. It explained the way that an extension project starts out lean, a “delta” with the parent (or “original”) application, and then builds, as extensions are added. The slideware was good too – a clear and meaningful build up of the Component.js file.

While the extension concept of the SAPUI5 toolkit supports the core extension capabilities at the developer level, it was also interesting to see the Runtime Adaptation classed, along with general user-level customising possibilities, within the general extension umbrella. And rightly so. The Runtime Adaptation is quite an achievement; while still a relatively young concept and section of the SAPUI5 toolkit, it’s definitely worth having a look. You could almost see it as “Personas for Fiori”. Now how does *that* mess with your current pigeon-holing of tactical and strategic UX technologies? :-)

There were a couple of things that I wanted to draw your attention to with the extension concept, lest misunderstanding were to take hold:

  • You can extend views with replacements (if there were no appropriate extension points for you to use), extensions (using the available extension points) and modifications. In this latter category, the slides say you can “modify certain properties like visibility”. Actually, right now, you can modify *only* the visible property, no others.
  • You can also extend controllers, where the slide says that you can “override standard controller functions such as lifecycle methods”. There’s an important distinction between the word “override” (replace) and “merge” – a word that the instructor actually used but wasn’t on the slide. With the lifecycle methods, your custom “replacement” method doesn’t actually override the equivalent lifecycle method, it is merged, and either runs before or runs after, depending on the method. This is actually what you want, but it’s not “override”.

Caveat developer!

Unit 2 “Extensibility with SAP Web IDE – SAP Fiori Cloud Example”. This unit is definitely worthwhile and a very quick walkthrough of what you can do yourself too. Last year at SAP TechEd EMEA, I was lucky enough to co-present a number of SAP Fiori related workshops (see “Speaking at SAP TechEd EMEA 2015“). One of them was to have the participants walk through extending an app in the Fiori Cloud Edition, just like the instructor did in this unit. You can do it yourself too now – just visit the SAP Fiori Demo Cloud Edition home and follow your nose. There’s also an exercise following this unit which will take you through something similar.

With extensions, we have many questions to answer. Why, how, what and where, for starters. The “why” is simple – because you want to have the app meet your specific business needs and nuances. The “how” is what this unit covers at a high level: the extension concept in general, along with the great support in the SAP Web IDE.

But it’s the “what” and “where” that will most likely cause the new SAP Fiori developer to scratch their head. What can I extend, and where do I find it? Well this is partially answered in the details section of each SAP Fiori app in the Fiori Apps Library. But knowing how an app is generally structured, and knowing specifically how your particular app is structured, is a level of detail and understanding much deeper than that.

And what, I hear you say, is the meaning of the S2, S3 and S4 view names? These are artifacts of the original SAP Fiori development approach within SAP, with S2 being the master view of a Master-Detail application, S3 being the detail, and so on. Getting inside the mind and the development context of the developer(s) that wrote the code you’re trying to modify (whether that’s SAP Fiori or something completely different) is something you should try to do as it will make a big difference.

Screen Shot 2016-04-04 at 07.57.57Oh yes, one more thing – the instructor added an event for the camera button he added to the S4 view. The event he chose from the list was “tap”, which was right next to “press” in the list. Unfortunately the Button control’s “tap” event has been deprecated since 1.20 (in favour of the “press” event), but as (a) the SAP Web IDE didn’t highlight this (yet!) and (b) the clock on the instructor’s screen showed just after 5 o’clock in the morning, we can overlook this ;-)

Unit 3 “Introduction to Enabling SAP Fiori for Mobile”. There’s a ton of stuff that SAP (and Sybase) have developed in the area of mobile app creation, deployment and management. I’m sure I’m not the only one somewhat dazzled by the oncoming headlights of so much traffic in this area. So if for no other reason than to summarise where SAP stands today with respect to their direction and strategy in this area, this unit serves us well.

In a conversation last month, I was rather surprised to hear that there were some people who had not heard of the term “hybrid” in the context of mobile apps. This unit clears that up for folks, and explains what hybrid means. This word for me will forever have one of its original meanings from its Greek roots (ὕβρις) – where it was used to describe the mythical Chimaera, made up of three different species of animal – and was an insult (think “hubris”) to each one. I wonder if SAP considered this in the Hybris context?

Anyway, the unit actually covers a lot of ground, at a high level, contextualising SAP Mobile Services (SAPms), Apache Cordova (nee PhoneGap), Kapsel, the SAP Fiori Client and much more besides. This is the sort of unit where you’ll want to review the slides again later to make sure you’ve built the right set of pigeonholes in your brain to store the flood of information that you know is going to come your way.

One concept that was mentioned but never really expanded upon was the offline OData feature. That alone perhaps could have taken up a whole unit, a whole week, or (in depth) a whole course, but it would have been good for the participants to learn, even at a high level, what was possible.

Unit 4 “Extending an SAP Fiori App for Mobile – Use Case”. Enough theory, how about some practical demonstration? And this unit delivers that. It continues the app from Unit 2 earlier in the week, and adds code to the event handler created then. It’s sometimes difficult to keep up with dry material, so to see something in action is a nice diversion. It also shows that not everything is always perfect – even the happy path that the demonstration was following was marred slightly by some network issues (it looked like the mobile device momentarily dropped off the wifi network).

It would have been nice to dig a little deeper into the background behind the Hybrid Application Toolkit (HAT) settings, especially the connection between the workstation-local resources and the configuration in these settings (see screenshot).

Screen Shot 2016-04-05 at 07.09.29

I’m thinking, however, that this is covered in the companion course “Developing Mobile Apps with SAP HANA Cloud Platform”.

Unit 5 “Cloud Extensions with SAP SuccessFactors”. If there ever was a unit that was full to bursting with a demo that makes you want to know more about absolutely everything, this unit comes close. Even at the longer length of 25 mins, this unit’s video only managed to scratch the surface of extending SAP SuccessFactors with an embedded UI5 app.

Looking past the clear signs of multiple SAP teams working on different parts of SAP’s cloud strategy as a whole, I can’t help but marvel at where they’ve got to. Yes, a pedant like me can spot some inconsistencies and things that don’t look right to the eye. There are also many questions relating to how things really connect and are authenticated, but on the whole, it was a good illustration of some of the core building blocks of the PaaS that HCP is.

I’m really glad that the example the instructor chose was consuming an OData service, via the Destinations facility of HCP. The backend exposing this OData service was marked as “odata_gen” – just like you’d mark any non-SAP (AS ABAP stack) OData service like Northwind.

Screen Shot 2016-04-05 at 17.36.12

I did wonder somewhat about the use of the URL in the Widget specification – it was supposed to be the URL of the app on HCP, but instead was another one with “demo2″ in the first part. Ah well, let’s put that down to slightly disjointed end-to-end demos.

Of course, like before, this packed unit was really just a taster for a full blown openSAP course. This time it’s “Extending SAP Products with SAP HANA Cloud Platform“.

Finally, did you notice the use of OpenSocial? Here’s another example of SAP adopting open protocols and standards, like HTTP and OData. OpenSocial defines a component hosting environment and a set of APIs, and SAP use it to enable the mashup of different components (such as extensions) to run within the same document object model (web page). This continues to give me confidence and encourages me to invest time and effort learning about the technologies and uses thereof in this space, as I know I’m less likely to be going down a path that leads nowhere.

Well, that’s the last main unit of this week. There was, as usual, the video blog update for this week, which I enjoyed. What struck me was the necessity to lead the course participants through architectural structures such as the one described in this diagram:

Screen Shot 2016-04-05 at 17.58.27

The cloud, with SaaS, PaaS and more, does mean that the on-premise landscape is simplified, but doesn’t mean that the architectures in general are simplified. Far from it. With tenants, accounts, trial and production platforms in the cloud, and connections to on-premise systems and even other cloud systems, it’s only going to get more complex.

And the final word goes to Bob, in the video update: “make sure you continue using Google Chrome“. What a refreshing change to SAP’s requirement from the bad old days, when it explicitly required you to use that disaster of a “web browser”, Internet Explorer. Onwards and upwards!


“fiux2″ Week 5 – Enhance an SAP Fiori Master Detail App

(See first post in this series — “fiux2″ – The openSAP Fiori Course – 2016 Edition — for links to the other posts).

So week 5 came and went rather quickly – perhaps it was the Bank Holiday weekend! This week sees the introduction of the Develop Challenge, as well as the main content of this week – looking at more advanced features of the SAP Web IDE. Let’s review the units.

Unit 1 “Enhancing Your SAP Fiori App with the Layout Editor”. This was a good introduction to the Layout Editor – an alternative way to edit Fiori app views. The Layout Editor is an accomplished piece of software, especially when you consider it’s running in the browser. I wouldn’t say it is my first choice for editing view definitions, but for the occasional user, it might be just the right thing. (There’s an argument that says occasional users shouldn’t be messing around with the innards of Fiori apps, but I’ll leave that for another day).

It’s interesting to remember that one of the reasons why such a thing as the Layout Editor is possible (and indeed the view part of the extension concept). Views in UI5 can be defined imperatively, in JavaScript, or they can be defined declaratively in JSON, HTML or XML. All three of these declarative formats are much easier to parse and manipulate programmatically – which is what the Layout Editor is doing.

The format of choice for Fiori apps is XML – I wrote an introduction to XML views, contrasting them to their (then-more-popular) JavaScript equivalents, in a post as part of a series (Mobile Dev Course W3U3 Rewrite) on the SAP Community Network back in 2013: Mobile Dev Course W3U3 Rewrite – XML Views – An Intro. If you’re still trying to decide what format to use, XML should be where you start – simple as that.

Anyway, take a look at this unit to find out more about the Layout Editor. Moreover, if you haven’t used it yourself, there’s a related exercise which goes into great detail – including data binding. The 34-page exercise document is called “Enhance Your SAP Fiori App with the Layout Editor” and it sits between this unit and the next.

Unit 2 “Develop Challenge: Build Your Own App with Peer Review”. Can you say “meta-course”? This unit merely covered the details of the Design Challenge. That said, “merely” doesn’t really do justice to this unit, or the information imparted.

There’s a lot packed into this course, including two major hands-on activities – the Design Challenge and the Develop Challenge, with their respective peer review activities to boot. I’m struggling a little to keep up with what’s required, especially as I’m dipping in and out of the course material when I have time.

So while this unit helps, I’m still a bit confused – particularly about when the peer review for the Design Challenge is to start. That confusion was increased by the deadline extension given for this challenge (that I mentioned last week). But perhaps I’m just getting old. I checked my Study submitted via Build / Splash, but have had no peer feedback yet. Nor have I had any prompting to start the peer review (we all get 5 submissions to review).

Update – I did some digging around, and you can now get to the peer review section within the Design Challenge section, as shown here:

Screen Shot 2016-03-31 at 08.43.06

So don’t wait for any prompts or emails – just go there and start!

Unit 3 “Other Considerations in Building an SAP Fiori App”. Well this was certainly a challenging unit! Challenging for the audience (it was a sudden slip off the relaxing poolside into the deep water), for the presenter (squeezing that much content into a 15 minute video was clearly a struggle) and challenging for the course as a whole, because while extremely important, it didn’t really fit into the flow of where this course has come from.

As a small example, one of the slides showed a snippet of a key artifact in any Fiori app – the Component.js file (unfortunately written on the slide as Components.js). To understand the context, the audience would have to have some non-trivial knowledge of UI5 development. This is coming (in a course starting in April, hurray!) but we’re not there yet.

It was like a whirlwind tour of lots of small performance and security related topics, which if done properly, could be expanded into a 3 or 4 day course :-) So in that sense, it was useful to impart. But I wonder how much of that information was really understood?

This unit talked about OData Choreography – a phrase I like – but it also had a couple of questionable pieces of advice, at least in my view. If you want only three properties of an entity rather than the three hundred it normally sports, you were advised to create another OData service. That’s not what I’d do – rather, I’d use the power of the OData protocol and use the query string option “$select” to return just the properties I needed.

I also do baulk somewhat at the recommendation to use $batch. In a TLS (ie HTTPS) context, URI security is fine, and while increasing performance (by batching up multiple requests), batching makes the application mechanics more opaque and difficult to support and debug. The approach also flies in the face of the architectural style that has informed the OData protocol as a whole – REpresentational State Transfer (REST). Don’t mask resource identifiers (URIs) and hide them where they don’t belong!

Finally, it would have been nice to hear a more compelling explanation of the reasonings behind the “one app / one service” rule. But perhaps that’s coming later.

All in all this unit was a useful, if slightly inconguent, poke in the ribs for the attendees to let them know it’s not just point-and-click in the Web IDE Layout Editor. I guess my comment about occasional users earlier in this post is relevant here too :-)

Unit 4 “Creating an SAP Fiori App with a Smart Template”. The combination of OData, annotations, and Smart Templates is a powerful one. We had a brief introduction to Smart Templates in week 3 so I need not dwell on them too much again here.

Suffice it to say that this unit showed a pretty impressive demo – a happy path demo, but a good one nevertheless. One of the things that stood out from the slide notes, and brought up by the presenter, was that with Smart Templates, there are “NO modifications”. I’ve yet to find out what that really implies; read-only code sometimes goes hand-in hand with auto-generation, but I’m pretty certain that what we’re going to end up with is something workable. The UI5 toolkit itself does a lot of the heavy lifting here, so it’s not as if there’s a ton of code that’s being emitted.

It’s definitely an extremely interesting area, and one to watch and learn more about.

Unit 5 “Introduction to SAP Fiori Overview Page”. Pretty much a continuation of the previous unit, here we move on to another concrete artifact from the “smart” stable – the Overview Page, or OVP.

Screen Shot 2016-03-30 at 18.02.54

You can’t help but be impressed by and attracted to this lovely combination of practical and visually appealing functionality. It’s a cross between the Fiori Launchpad and functions and features of Fiori apps, all on a single page.

But perhaps what’s most impressive is the way that the OVP plugin works and embeds itself seamlessly into the Web IDE. The generation of the core OVP example was impressive, but what really took my fancy was the addition, in the demo, of actual cards, via further wizards. When you consider the different teams that have been involved, it’s a great example of the tip of a complex iceberg, both technically and organisationally at SAP. Nice work, teams!

By the way – if this sort of UI presentation appeals to you, you may be interested in a free 1-hour webinar I’m involved in on 26 Apr. For more information, see the event’s homepage:

The SAP Fiori Launchpad as a Human-Centric Dashboard

and maybe I’ll see you there!

Unit 6 “Deploying Your App”. This was the last main unit of this week’s course content, and covered, at a high level, what you do next after building your Fiori app. Basically there are a couple of main options – a deployment to a Fiori Launchpad site on the HCP cloud portal, or a deployment to an ABAP stack backend SAP system. There was another option shown in the slide and in the demo, to “clone *to* a git repository”. I can only think there was a little bit of confusion here – git clone goes the other way – creating (pulling) a copy of an existing repository, not instantiating (pushing) a new repository.

But we’ll gloss over that for now, especially as the key git parts of the workflow – when deploying to HCP – were actually shown. There are some gotchas with the git workflow when it comes to using different branches (which you should be doing during development). You may be interesting in this screencast I recorded showing you the challenge, and the solution: “SAP HCP, git, and Feature Branches“.

It was good to see the relationship between the app itself, the portal FLP site, HCP along with the roles, even though it was a very quick high level overview. Almost directly after the video was recorded (mid Dec 2015) some improvements have been made to this area, notably, with SAP Web IDE release 1.19, the ability to specify *which* FLP site you want to deploy the app to. You can have multiple FLP sites in your HCP portal account, and the ability to specify the right target site is key. See “Registering Applications to SAP Fiori Launchpad” documentation for more details.

One thing that struck me as a little odd was the tile definition demo. After the Tile Configuration part of the wizard was complete, we looked at the tile in the FLP, but it had different text (title and subtitle) to what had been defined. I can only think that this might have been the product of a video splice … and serves as a reminder of how hard it is to create even one tutorial video, let alone multiple series! (I speak from first hand here). So my hat goes off to the teams that turn out such great content for all these openSAP courses.

For some of the audience, it might have been worth just spending a bit of time explaining the BSP Application connection, when the deployment to an ABAP repository was shown. Of course, there isn’t a connection – you’re not travelling back in time to the Business Server Pages technology arena; rather, it’s just that the storage container for a BSP Application was deemed “good enough” to contain all the artifacts of a Fiori app – it being a web app after all.

On the subject of deployment, this time to the FLP, it would have also been nice to mention the difference between the “webapp” folder and the “dist” folder created in such circumstances. But perhaps that will come up in another course.

Despite these gaps, it was a good overview unit that completed the picture.

Post Script: one of the self-test questions for this unit rather unfortunately suffered from perhaps being set by someone other than the person who wrote or presented the unit video content; there isn’t a single “correct process for deploying an SAP Fiori app to the cloud Launchpad”, and the officially correct answer doesn’t reflect the procedure that was shown in the video. Ah well, it’s only a self-test :-)

That’s about it for this week – see you next time!


Quick HCP title hack with the Navigation Manager

One of the great things about the new SAP is that it has embraced open standards and protocols, and is building the UX and UI present and future on HTML5. A by-product of that is the ability to see how they’re building things and make, or suggest, changes.

At SAP Inside Track Sheffield last year, one of the sessions I gave was “Fixing up a nicer HCP Destinations table”, where I showed the power of UI5 introspection and the Chrome Developer Tools that enabled us to modify the surface upon which we were standing, to improve things. I re-recorded my session as a video here, in case you’re interested:

Fixing the HCP cockpit titles

Anyway, there’s something else that’s been niggling me a bit while using the HANA Cloud Platform (HCP) cockpit. And that’s the inability to see which tabs in my Chrome browser are open at what particular areas of the cockpit. Due to the way each location’s title text is structured, all the tabs look the same – at least at the start. It’s only when you hover over them you see what a given tab contains.

Here’s an example:

Screen Shot 2016-03-28 at 11.42.06

It’s only when hovering over the first tab that I see that it’s showing the HTML5 Applications part of the cockpit. If I’m looking to switch to that tab, the search for the correct one is painful.

So I wanted to take a quick look to see where this title was being set, and when. I used the Chrome Developer Tools’ DOM breakpoints feature to halt when the <title> element was changed:

Screen Shot 2016-03-28 at 11.46.08

This led me to a section of the HCP cockpit code that inside the Navigation Manager (cockpit.core.navigation.NavigationManager), in a function called “navigate”. This is what the code that sets the title looks like (I took the liberty of formatting it a little bit better for readability):

Screen Shot 2016-03-28 at 11.49.41

You can see how the title string is constructed – with the most significant part (current.navigationEntry.getTitle()) buried deep within it.

A small change to this code, so it looks like this:

Screen Shot 2016-03-28 at 11.49.54

brings the most significant part to the front, meaning that now I can see what tab contains what HCP cockpit feature – at a glance:

Screen Shot 2016-03-28 at 11.30.28

I think that’s a nice improvement. Personally, I’d love to see this make it into a future release. What do you think?



“fiux2″ Week 4 – Create Your First SAP Fiori App

(See first post in this series — “fiux2″ – The openSAP Fiori Course – 2016 Edition — for links to the other posts).

Well we’re pretty much at the half-way point in this course, and it’s going well. This week sees the end of the deadline extension for the Design Challenge that I wrote about in Week 3, but mainly is about introducing the course attendee to some basic hands on with the SAP Web IDE. Let’s have a look at how this unit went.

Unit 1 “Introduction to SAP Web IDE”. I’m guessing that the majority of this course’s attendees may well have some familiarity with SAP’s now-flagship interactive development environment (IDE). It had an interesting genesis, growing from an initial offering called App Designer, which, remained a young product but seemed like it might be aiming to become, for UI5, what the Microsoft tools were for Visual Basic. There was also App Builder, which one might say was a competing product, from the Sybase stable. And how can we forget the tools and accelerators for various workstation versions of Eclipse.

What came out of that cloud of dust is what is becoming a very fine product indeed – the SAP Web IDE. Technically based upon Eclipse, but Orion – meaning the offering can be cloud-based, which it is. That said, there are the occasional releases of personal versions to run on one’s workstation, but of course these are still web-based – you’re just running Orion locally.

This is not a new concept. While today no-one bats an eyelid when we talk of running web servers locally on our laptops, it was a big “aha” moment for me and many others back in the 1990’s when one of my all time heroes Jon Udell wrote about the concept in Byte magazine a long long time ago now. There’s an online version of the article here: Distributed HTTP.

Anyway, I won’t go into all the features of the Web IDE here – find out for yourself in this unit. You’re not attending the course? Get that sorted now!

Unit 2 “SAP Web IDE App Development Basics”. This unit covered the basics in terms of what features the Web IDE has to support the end-to-end process described in Unit 1 – Prototype – Develop – Test – Package & Deploy – Extend.

One of the challenges when developing UI5 and Fiori apps is the data. Where is it, what does the structure look like, and is it actually available at all yet? The mock data services within the Web IDE go a long way towards smoothing over the answers to these questions. Often you’ll be developing an app before a backend OData service is even available. Perhaps that’s your modus operandi anyway. And even if the OData service is built, there may be no actual data to test with. With the mock data services you can mock your backend very nicely. See the last unit of this week (towards the end of this post) for more content on mock data services.

And with the Web IDE you have many of the facilities you’d expect in other IDEs – code completion, the ability to lint and beautify, integration with source code control (in the form of git, of course) and more.

As a (very) long time vim user, I have to say that an IDE (rather than “just” an editor), and one in the cloud, is a concept that doesn’t come naturally to me. But what the Web IDE offers is too good to ignore, so it’s become my companion working environment of choice. And I recommend it to clients and colleagues alike if they’re wanting to start on their Fiori journey.

Unit 3 “Creating Your First SAP Fiori App with SAP Web IDE Templates”. One of the reasons why the Web IDE is my companion working environment is covered in this unit: App starter templates and reference apps. I built my own starter templates a good while ago for my own development workflow, but I don’t maintain them, and there’s only a couple of them. With the templates available in the Web IDE, you can hit the ground running and have a working basic app in a matter of minutes.

And the templates are maintained too; this means that as the best practices improve, and the maturing of UI5 continues, there are differences in approach that you want to make sure you capture. With the plugin based architecture of the Web IDE, you can even build your own templates. As an experiment, a good while ago now when this was quite new, I created a custom template that allowed you to get started quickly with test data from a Google spreadsheet: SAP Fiori Rapid Prototyping: SAP Web IDE and Google Docs.

An equally good reason to look at what the Web IDE has to offer are the reference apps. These are full blown apps that are a great source of wonderment – audited source code that covers myriad functions and mechanisms in real Fiori apps. You either enjoy reading source code or you don’t. If you do, you’re in for a treat. If you don’t, grasp the nettle and at least have a go. I’ve always maintained that reading other people’s source code is educational (sometimes to see how *not* to do something!). And here’s no exception. The world of SAP development is changing – use these resources to give yourself a leg up. And SAP – more of this please!

Unit 4 “Enhancing Your SAP Fiori App with SAP Web IDE”. This was a fairly straightforward unit, where the instructor takes us through a couple of examples of enhancing existing SAP Fiori apps. Rather than use the visual editor, we are shown the regular editor where the view is modified by adding XML elements as shown in the screenshot from the video below. This is fine, and my preferred modus operandi.

Screen Shot 2016-03-24 at 07.30.11

But I do wonder if attendees are thinking: “how would I *know* that I could or should place an <attributes> element there, and within that element, an <ObjectAttribute>. And what about the capitalisation? Well, for those who can’t wait for the coming weeks, where I suspect, or hope, that this is covered in a little bit more detail, here are a couple of pointers:

1. If an XML element starts with a capital letter, it represents a control. For example, we see on line 6 in the screenshot, an <ObjectHeader>.

2. If you look at the reference for this Object Header control in the excellent Explored app within the UI5 SDK – sap.m.ObjectHeader – you’ll see in the Aggregations tab a list of aggregations. And there you’ll find the “attributes” aggregation, which contains entities of type “ObjectAttribute”. And these are the children that can be placed inside the “attributes” aggregation.

3. So yes, you guessed it – whereas controls are represented as XML elements with capitalised names, aggregations are represented by XML elements starting with lowercase letters. So <attributes> here in line 9 is the start of the list of Object Attributes within the “attributes” aggregation belonging to the Object Header control.

Screen Shot 2016-03-24 at 07.39.34

I’m sure that this sort of information will be covered in much more detail in the upcoming openSAP course on SAPUI5 – watch this space! :-)

Unit 4 “Testing an App with Mock Data”. Ahh, a pain point in every developer’s workflow – “Where do I get the data to test?” “When will the backend service be ready?” “Can I start development sooner?”.  Well with the mock data service things are a lot smoother than you might imagine.

It’s definitely worth studying the Web IDE features explained in this unit. While the OData Model Editor is still something I’d like to see improved (adding some visual aspects to the *editing* process, rather than still having to edit at the rather verbose EDMX level), it’s still a great first step, especially with the visual display of the entities and their relationships:

Screen Shot 2016-03-24 at 07.50.59

It’s a shame that this wasn’t shown in this unit.

What was shown is the the Mock Data Editor is definitely easy to use and a great boost to your testing workflow. If you’re going to invest some time on this week’s content, this unit is where you should focus your efforts.

And with that, week 5 is just about to start. See you next time!



“fiux2″ Week 3 – Get Ready to Create Your First App

(See first post in this series — “fiux2″ – The openSAP Fiori Course – 2016 Edition — for links to the other posts).

It’s around this time of the week that the changeover between each week’s worth of content happens. Week 3 of the Build Your Own SAP Fiori App in the Cloud – 2016 Edition course has just come to a close, so it’s time for me to write down my thoughts.

This week’s content was shorter than usual. Deliberately so, to give the attendees a better chance at completing the Design Challenge, which started in Unit 7 of Week 2 (see my comments for that unit in the previous post in this series). There were only three units, so let’s have a look at those first, and then finish with a few observations on the Design Challenge.

Unit 1 “Anatomy of SAP Fiori Apps”. I enjoyed this unit very much, as it really started to explain well how the rubber hits the road. At some stage, UX needs to turn into UI and become real. Using a combination of the excellent SAP Fiori Design Guidelines and the actual controls in the UI5 toolkit itself (see the Explored app for a great showcase of many of them) – advice and building blocks in harmony – is a great way to get started on your Fiori app development journey.

Understanding the anatomy of a Fiori app – from small controls such as Buttons to larger concepts such as the floorplans, and everything in between, can make the difference between creating a Fiori app, and a Fiori-like app. Here, I refer to Fiori-like as using the building blocks, but not in the right way.

Unit 2 “Introduction to SAPUI5 and OData”. At less than 10 mins long, this unit was very short indeed, only providing a very high level introduction to two of the most important topics in Fiori – UI5 and OData. One of the aspects of the openSAP courses I’ve become used to was the way the instructors often squeezed as much out of each slide’s content as possible. In this unit, I felt a lot of the detail was skipped.

That said, if it hadn’t have been skipped, I could imagine the unit being four times as long or more. There is more on OData coming later in this course, so let’s hope that they dig in a little more. OData is a fascinating topic, not least because it’s REST-informed, based on an architectural style that I worked hard in the past trying to convince SAP of its merits :-)

An old post on SCN from 2004 – “Real Web Services with REST and ICF” – where I expounded on the virtues of the REpresentational State Transfer (REST) based approach to data services … and was slightly disowned by SAP ;-)

Unit 3 “Introduction to Annotations and Smart Templates”. This was a very interesting unit, not least because of the implications and the reasoning behind augmenting the metadata with extra semantics. I’ve written about semantic information before (see Semantic Pages, a post in the 30 Days of UI5 series). This time it’s about adding extra information to the OData metadata to enable a more rapid construction – in some cases automatic – of UI5 based application components. A control, or set of controls, that can understand the data that is bound to it, is capable of more than acting passively.

There’s a lot driving the concept of annotations and their use in smart controls and templates, not least SAP’s need to produce yet more SAP Fiori apps, more quickly and more reliably. Finding a way for apps, or parts of apps, to write themselves, is going to help that process.

One thing that made me smile was the lovely conflict between Unit 2’s statement “OData model is based on … JSON” and Unit 3’s statement “OData is based on XML“.

Of course, we all know that it’s based on both. JSON and XML just happen to be used to provide the format for the payload – there are different formats that the OData standard describes. But OData is also a protocol. Don’t let this confusion confuse you – OData is about more than representing data, it’s about describing operations upon that data too. The XML representation originates from the Atom Syndication Format (RFC4287) – this informs the “format” part of OData. The operations originate from the Atom Publishing Protocol (RFC5023) – this informs the “protocol” part of OData.

Design Challenge

And what of the Design Challenge? First, the deadline has just been extended by a week due to some system problems that were encountered. I think that’s a pretty generous extension, well done again openSAP folks for reacting in the right way. I’m on holiday this week and got some earache from M for working some late night and early morning hours to get the submission in before today. Oh well :-)

As the deadline has been extended, I have to be careful not to give anything away here. But I can certainly make a few observations of my own. I’d say, all told, with putting together each of the deliverables for the challenge, doing the screen mockups and then using the online tools to create a prototype and then a study, it took a good few hours, not counting the idle time mulling over what problem I wanted to solve and persona for whom I wanted to address the needs.

I think it was because I’m not actually that used to the formal process, so things weren’t as smooth as they might be next time. This is part of the point, I guess – getting us used to the Design Thinking methodology and learning about the process by being persuaded to address each step in turn. Although I think it was a valuable exercise, there is something in me that is ready to admit that I already had the design of the app in my head, and extrapolated backwards a little bit into the discover and design. But who said it was a linear flow? :-)


“fiux2″ Week 2 – Design Your First SAP Fiori App

(See first post in this series — “fiux2″ – The openSAP Fiori Course – 2016 Edition — for links to the other posts).

Well, the weeks certainly come around fast in these openSAP courses, and so we find ourselves on Week 2 of the Build Your Own SAP Fiori App in the Cloud – 2016 Edition. Here’s a quick run down of what was covered, with some thoughts from me.

Unit 1 “SAP Fiori 2.0 Overview”.  This first unit gave a nice overview and introduction to the SAP Fiori 2.0 concepts. Yes, Fiori 2.0 is still conceptual in parts, but we’re already seeing practical output, in the form of the very real Overview Page mechanism, for example. There are plenty of new concepts for Fiori in the 2.0 design, such as the Viewport, the Control Space and the Copilot.

Some of these concepts are not new, but they don’t have to be; in fact one of the key tenets of Design Thinking, introduced in Unit 2, is “Build on the ideas of others”. I rather think that some of the ideas have been taken from the Dashboard concept that Nat Friedman built a good while ago – I wrote a few posts on Dashboard back in 2003 and then later that decade.

Unit 2 “Introduction to Design Thinking”. This content isn’t new, in fact the openSAP folks stated that it’s the same content as last year’s course. Nevertheless it was worth a brief re-introduction to set the scene for the design principles that are to come in Unit 3. The thing with Design Thinking, at least for me, is that it’s all pretty obvious in theory, but putting it into practice requires effort.

I think the concepts around the pre-build phases of app delivery still need to be successfully and firmly landed in some organisations. Further, there’s a fine balance to be had between not letting technology (and developers) drive solutions, and designing something that would require a great deal of effort to implement. We have the tools (and the design principles) and know how to use them, so we should use that knowledge to inform the process.

Unit 3 “The SAP Fiori Design Guidelines”. Anyone who’s looked into SAP Fiori UX is likely to be at least lightly acquainted with these, either at 30000 feet – with the 5 principles (Role-Based, Responsive, Simple, Coherent and Delightful) – or at ground level with the practical implementation advice in the online documentation. But as this course is soon to introduce the first hands-on element (designing an app), it’s valid to re-introduce them at this stage, if not to set a level knowledge playing field for all participants.

I did like the explicit calling out of the concept of “Fiori-like” towards the end of this unit. Design is not black and white, and there’s been a long-standing question over whether non-SAP folks could call their apps “Fiori”, or whether they had to say “Fiori-like”. I’ve maintained the position that if the design guidelines were followed, then they were “Fiori”, not just “Fiori-like”. That said, with the title of the course we put together gave in the early days (three years ago!) – “Building SAP Fiori-like UIs with SAPUI5“, things weren’t so clear-cut :-)

Unit 4 “SAP Fiori Decomposition and Recomposition”. You might be forgiven for thinking that this process is a somewhat over-formalisation of what appears to be straightforward: The extraction of functionality from the “kitchen-sink” transaction-based approach of the traditional SAP experience into smaller role and task focused applications, sometimes combining functionality from previously separate transactions. Sure, that’s what it is.

But it’s more than that, I think, when seen as a complete process. The functionality being extracted is predominantly being extracted from a proprietary context, and reconstituted into a neutral, platform-independent and responsive context. We’ve been stuck too long in the world of proprietary, tethered too much to the desktop with SAP because of the Microsoft disease that has set hold in enterprises in the last couple of decades or more. So SAP targets that market and the only real experience for many has been SAPGUI for Windows, an experience that is so far from being portable it became one of the catalysts for Fiori. Recomposing functionality into the context of the one true native platform – the Web, is a great move for SAP.

Unit 5 “The Importance of Prototyping”. Like Design Thinking but perhaps less so, prototyping phases are sometimes difficult to bring about and get the most out of, especially when deadlines and budgets are tight. Organisations need to work out the value for themselves for the Discover and Design phases, rather than just focus on the Develop and Deploy phases … especially those that involve the business.

There’s a leap of faith that’s required, and we’re all responsible for helping make that happen.

On mockups and protoyping, especially in the early stages, I’m a fan of the simplest thing that could possibly work, which is pencil and paper. Low cost, discardable, and folks aren’t distracted by debating what colour a button should be.

Moving into the benefits of the later stages of prototyping, I’m reminded of one of the founding beliefs of the Internet Engineering Task Force (IETF) – one of the bodies that maintain standards that mean that we can all simply take the Internet and all its children (such as the Web) for granted. This belief is “general consensus and running code” (from the Tao of IETF). Showing a working model of something you’re trying to convey is very valuable indeed.

(I did take issue with the stated “correct” answer to one of the self-test questions on this unit: Q “How can app implementation be inexpensive?”  A: “If enough iteration, prototyping and validation is done beforehand”. That might mean the UX is right, but it doesn’t imply that making that UX happen is easy!)

Unit 6 “Prototyping 101 Using SAP Splash and Build”. Following on from my comments earlier about adoption and landing of the Discover and Design phases, this unit contained an overview of the two tools that help to support those stages – Splash and Build respectively. It’s a longer than usual unit with 25 mins of video, but worth watching if you haven’t already seen or played with these tools.

The tools themselves are already very accomplished, but I do wonder how much the studies have actually been employed thus far. It’s partially a circular situation – the tools won’t be used unless Discover and Design are more strongly adopted, and the adoption has a better chance of taking hold if tools like this deliver on their promise.

One of the things that caught me eye (that hadn’t been available in the early-access I’d had to Splash a while ago) is the Gallery of existing designs. I’m looking forward to browsing through, and seeing how they complement the Fiori Design Guidelines.

Unit 7 “Design Challenge”. The last unit of this week sees the start of the first of the two practical portions of this course. This is the design challenge, where we must put into practice what we’ve learned this week – covering the Discovery and Design phases of the end to end process, including use of Splash and Build. Giving and receiving feedback from course peers is also involved, which is a nice way to scale this, and also an opportunity for me to see feedback stats in these tools that has come from someone other than me!

This design challenge lasts two weeks, which means that although there’s an assignment to complete this week, there isn’t one next week – so that we have time to complete the first part of the challenge (submitting the design mockups) without needing to spend more time than budgeted for this course. A nice move.

There’s one more aspect of this course that I wanted to mention last time but didn’t get round to it. At the end of each week, there’s a “just in time” video blog entry which gives the course creators and instructors a chance to impart last minute information and changes. I like this aspect, and the relaxed nature of how it’s presented. Indeed, with the contents of this course being based on software-as-a-service products in the cloud, and with the changes that happen on a monthly basis, it’s a good idea.

And on this note of constant change, I’ll leave you with one thought from Martin Fowler. I was reminded of this wisdom via Sascha Wenninger’s tweet this morning: “If it hurts, do it more often” :-)

(For links to commentary for further weeks, see the first post in this series: “fiux2″ – The openSAP Fiori Course – 2016 Edition.)

“fiux2″ – The openSAP Fiori Course – 2016 Edition

Links to the rest of the series:

“fiux2″ Week 2 – Design Your First SAP Fiori App
“fiux2″ Week 3 – Get Ready to Create Your First App
“fiux2″ Week 4 – Create Your First SAP Fiori App
“fiux2″ Week 5 – Enhance an SAP Fiori App
“fiux2″ Week 6 – Extend SAP Fiori Apps
“fiux2″ Week 7 – Build Your Own SAP Fiori App

I’ve written about the openSAP Massive Open Online Courses (MOOC) system in the past. I’m a big fan, particularly for the way the folks run the ship. They are “open” in the best possible ways.

Anyway, last week saw the start of the much anticipated 2016 Edition of the course “Build Your Own SAP Fiori App in the Cloud“, aka “fiux2″. I’m enrolled and have just completed the first week, as many of my colleagues have too.

I’m a great believer in learning and re-learning subjects, especially from different sources. Even if you feel you know a good chunk of a given topic, learning with new material, and from different angles, will give you not only knowledge reinforcement but also new nuggets which are therefore also more easily digestible. If only for this reason, I’d recommend this course to you. The time commitment isn’t unreasonable, there’s hands-on, and even a competition!

And in case you need a little bit more convincing, I thought it might be fun and perhaps useful to write a short post each week, describing what we learned. So here goes with Week 1.

Week 1 – Get to Know SAP Fiori UX

A gentle start to the content this week, with a balance of marketing (you knew it was going to come, best to get it over with in the first week) and a 30,000 feet view of the UX strategy. If you’ve followed the SAP Fiori UX revolution at all, it should all be fairly familiar to you. We also covered the SAP HANA Cloud Platform (HCP) and the key role it plays in the extension concept generally, and in particular for Fiori apps.

Within the context of HCP and the cloud centric approach we looked at various tools that are available for different stages in the Fiori app journey, from discovery (Splash), through design (Build) to development (WebIDE). There was also mention of the Rapid Development Solution (RDS) available, and the wealth of documentation that was to be had.

We looked at SAP Fiori in the cloud, with a specific focus on Fiori-as-a-Service (FaaS) and the HANA Cloud Portal, where you can build sites including Launchpad-specific landing pages.

Finally the focus ended upon S/4HANA and how Fiori UX fits directly as the strategic way forward. Now I think it’s fair to say that the statement “SAP Fiori is the default user experience for S/4HANA”, but If I’m not mistaken, one of the lecturers gave the impression that it’s the only user experience. Yep, here, in Week 01 Unit 06:

“We provide Fiori, and Fiori is the default user experience for S/4HANA. There’s no other user experience there.We’re not using SAP GUI, we’re barely using any other user experience like NetWeaver business client.”

Now, that’s not quite true, is it? S/4HANA, architecturally, is still based upon an ABAP Stack system, which means the venerable R/3 architecture is still in play. Yes of course we have HANA underneath and Fiori on top, but in the middle we still have DISP+WORK and all the wonderful SAPGUI and ABAP goodness that we know and love. And while there are huge inroads made already in the new Simplified suite, there’s always SAPGUI.

I’ll just put that down to the lecturer’s excitement and enthusiasm :-)

Overall, it was worth the hour or three invested in watching the videos**. And the assignment at the end of this week was pretty straightforward, as long as you were prepared for translating marketing speak into specific questions.

I’ll leave you with one thought, which we may well pick up in week 2. Here’s a screenshot, from one of the slides of an S/4HANA Fiori app:

In relation to the Fiori 2.0 designs, which are being introduced in week 2, there were some comments on Twitter today about the perceived complexity of the newer apps. I think we’re already seeing complexity here, but I don’t think it’s necessarily the end of the world. Some things do require you to see more information. Not everything is as simple as approving a purchase requisition or booking leave.

**I’d recommend the openSAP mobile app (available for Android and iOS) which now works properly – i.e. it doesn’t immediately crash when you try to download content to watch offline.



Impromptu JS session at UKISUG15

We’re hearing a lot about Fiori at #UKISUG15 this year, of course. Many of you (perhaps especially those reading this) realise that Fiori is built using the power of HTML5, and specifically with the UI5 toolkit. This means, amongst other things, JavaScript.

I was talking to my friend and colleague and fellow SAP Mentor Chris Kernaghan on the evening of Day 1 about levelling up in JavaScript, and had planned to go through some JavaScript goodness with him during the conference. But then I thought it might be fun for others to come along too. So here’s the (rough) plan:

– meet at the Bluefin Solution stand on the show floor on Tue 24 Nov (last day of #UKISUG15) at 1300 (should give you time to grab a bit of lunch first) if you’re interested in coming along (that’s TODAY, folks!)

– we’ll find (or will have found) a room to use – probably Level 5 Hall 8b (the SAP Mentors Track room)

– the session will be between 30 and 45 mins max

This session will be for those already with some basic JavaScript skills, and / or those interested in using JavaScript to manipulate data inside an SAP Fiori app. Even if you have no JavaScript skills, you might find it interesting. And if you don’t, you can always just laugh at me.

The session is titled “Programming in a more functional style in JavaScript” and we’ll go through handling and manipulating data from a running Fiori app. Handling and manipulating data like this is a common use case. Becoming more familiar with doing this will help you build your skills and confidence in the future normal of SAP frontend development. Learning to do this in a functional way will give you a basis to write more solid and reliable code.

See you at the Bluefin stand at 1300 today!

Speaking at SAP TechEd EMEA 2015

Screen Shot 2015-11-03 at 09.36.37

I’m looking forward to a packed set of days next week in Barcelona, where SAP TechEd EMEA 2015 is taking place. It’s packed in many ways: so much to share, so much to learn, so many people to meet and re-meet, so many kilometres to walk in the convention centre, and so much coffee.

I’m involved in a number of activities during the event. I’m co-presenting a number of hands-on sessions relating to SAP HANA Cloud Platform (HCP) and the SAP Web IDE, Fiori, and of course the fantastic UI5 toolkit. Here’s a quick summary (in my own words):

UX260 Experience SAP Fiori on SAP HANA Cloud Platform
SAP HANA Cloud Platform (HCP) is changing the Fiori landscape in so many ways, by offering features and services all the way from development, through connectivity & deployment, to exposure to end users. This session gives you hands-on experience at the places where Fiori and HCP meet.

UX261 Extend a Fiori App with SAP Web IDE based on beautiful Fiori Reference Apps
The key to the present and future success of Fiori in your organisation is the correct adoption of best practices, both from a general development perspective and also from an extension perspective (for standard SAP delivered Fiori apps). There’s a lot to get wrong, but a ton of help for you to get it right. This session shows you what and how.

UX262 Building SAPUI5 Applications using SAP Web IDE
The SAP Web IDE is the cloud-based IDE that can. From a standing start not too long ago, it’s progressed into an impressive set of features, not least those involving the templating and plugin system. This (4hr) hands-on session, which is being given twice next week, covers these subjects and more in particular the rather exciting Runtime Adaptation (RTA) features of UI5. Oh yes!

In addition to these hands-on sessions, I’m taking part in a couple of SAP TechEd Live Studio events – I’m interviewing one of my heroes on SAP Development Tools (and in particular those available on HCP), and taking part in a live panel discussion on developer engagement. Stay tuned!