Monthly Archives: March 2015

This Week in Fiori (2015-13)

Well, another week has gone by, which means it must be time for This Week in Fiori! The Fiori juggernaut continues to rumble on, and this week was no exception. Let’s get to it!

Build Your Own SAP Fiori App in the Cloud by openSAP
This week saw the start of the new free course at openSAP, which, according to the description, is all about “building your own SAP Fiori app that’s just as delightful and user-friendly as any of the hundreds SAP has built directly”.

This is great news, especially for those of us who had signed up to the earlier course “Introduction to SAP Fiori UX” but had been rather disappointed that it had had nothing much to do with Fiori UX, and more to do with deployment and setup. I wrote about this in TWIF episode 2014-40. A number of us did have a dialogue with the openSAP folks at the time, and I’m delighted to see our comments were taken on board – this new course looks to be what we have been waiting for.

So we’re into Week 1 of this new nine week course, and already in the last unit of Week 1 — Unit 5, Introduction to SAPUI5 and OData — we’re seeing JSON and XML on the slides, HTTP headers, and even a small glimpse at the superb UI5 toolkit, including a tiny controller and an XML View definition. This is more like it! Technical details on the slides.

Don’t get too excited, however. I spotted some errors in this unit that aren’t trivial. I’ve built courses before and I know how hard it is to get things consistent, but one thing you must do is be accurate. Here are some of the things I spotted:

“OData … is using SOAP and REST to communicate between systems”
OK, so first, REST isn’t a protocol, it’s an architectural style, so it is difficult to use a style to communicate between systems. But that is sort of forgivable, in that perhaps more accurately one could say that the OData protocol has RESTful tendencies. But SOAP? No. OData has nothing to do with SOAP, in fact, one could say that the OData protocol is orthogonal to SOAP.

“One of the most important libraries we have today is sap.ui.m”
I’m guessing that’s just a typo that found its way up through the layers to the actual presentation script. Because while there are libraries with the sap.ui prefix, there is no sap.ui.m. What the instructor is referring to is sap.m. The m originally stood for “mobile”, but now stands for “main”. The sap.m library is one of the main collections of responsive controls which are used to build Fiori apps. For more info, you might want to read “M is for ‘responsive’“.

“We have a library [sap.ui.table] for table, and that provides me with the ability to create a table that is very rich in data but also responsive”
For responsive tables, you probably want to look at the sap.m.Table control, rather than the sap.ui.table library, as the former is designed from the ground up to be responsive, whereas the latter is more for desktop apps.

MVC – View <-> Model data binding
In slide 13, there’s a classic MVC style diagram, but the data binding relationship between the view and the model seems to be shown as one way only:

Screenshot 2015-03-28 at 14.12.27

One of the many features of the powerful model mechanism and the data binding therein is that you can have two way binding. So I’d have drawn that arrow pointing both ways.

XML View definition
Being a stickler for accuracy (perhaps to the point of pedantry, of which I’m proud, not apologetic :-), this XML View definition on slide 14 is not quite accurate:

Screenshot 2015-03-28 at 14.15.27

The View is within the sap.ui.core.mvc namespace, not the sap.ui.core namespace, so the root element here should reflect that, like this:

<mvc:View xmlns:mvc=”sap.ui.core.mvc” …

Router? Bueller?
So if I’m going all out, I might as well mention that one thing that I think slide 16 could have benefitted from is mention of the Router in the architecture overview diagram. I do appreciate that these slides may have come from a time before the Router concept was properly established, but the Router is an incredibly important part of any Fiori app, so it would have really helped to see it here.

Screenshot 2015-03-28 at 14.21.38

That said, now you know, you can go and find out more about it! :-)

Don’t get me wrong, I’m very excited about this course, and these issues can be ironed out now they’ve been surfaced. I’m looking forward very much to Week 2.

Fiori Breakfast Event by Brenton O’Callaghan, Lindsay Stanger and me
On Tuesdsay morning this week in London, Brenton, Lindsay and I, along with other great Bluefin folks, ran a breakfast event all about Fiori. It was a really successful gathering, with business and technical attendees from SAP customer companies who were already, or were about to, or were just interested in embarking upon their Fiori journey. We had a special guest from one of our clients too, and to be honest, she stole the show :-)

It was clear from the event that people are realising that Fiori is not only here, it’s here to stay, and it’s a journey that is not just about new apps, but about a new SAP. If you’re reading this TWIF column, you already know that. It’s a genuinely exciting time for us as customers, partners and consultants, not only because of the UX aspect, but also because the present and future that is Fiori is based upon open technology standards that are right. SAP has grasped the nettle of user experience, and embraced the right tools and technologies. Good work!

Well that was rather a longer post than usual, so in the interests of keeping this to something you can read in a coffee break, I’ll leave it here, and wish you well. Until next time!

 

 

This Week in Fiori (2015-12)

Greetings! Last week saw the return of the This Week in Fiori series, with a video from me and Brenton. More on that video shortly. Before last week, the previous episode had been in October last year. So much has happened in the Fiori world that it would be crazy to try and cover it all. Instead, over the next week or two, I’ll pick out some items that stand out.

So let’s get started with some picks for this week.

Filtering Fiori Apps by Release by Gregor Brett
In last week’s video, we looked at the Fiori Apps Library app and found that it wasn’t easy to identify the latest apps. I mentioned that while the Fiori Apps Library app itself didn’t expose the information in that way, the data was actually available, and laid down a challenge for anyone to make the app do just that.

Screen Shot 2015-03-20 at 16.03.06Just a few days later the first response appeared – Gregor Brett came up with a nice solution, which was to patch the running Fiori Apps Library app, adding a new View Settings Filter Item to the filterItems aggregation of the actual View Settings Dialog used in the app. The items within that new View Settings Filter Item were bound to a data collection that was already being exposed by the backend in the OData service, namely the Releases_EV collection, which gave information on Fiori Wave numbers and dates.

Bingo! Nice work Gregor.

 

The Fiori Community by the SAP Community Network
Since the last episode of TWIF last year in October, SAP have created a new community within the SAP Community Network for Fiori. There’s already a community for SAPUI5, but now there’s a specific community for Fiori. I spoke about this in my keynote at Mastering SAP Technologies last month, and it’s an interesting and important distinction that SAP are making.

If you think about it, Fiori as an umbrella term is gigantic. It could be seen as a lot of things to a lot of people. Separating out the technical underpinnings (UI5) from other aspects (Fiori application configuration, extension and maintenance, UX design, deployment and platform subjects, and more) was only going to be a matter of time, if only to make the subjects more manageable.

But also remember that future Fiori offerings from SAP may not be powered by UI5. Of course, all of the Fiori offerings now and in the near future are, including all the S/4HANA applications such as the SFIN set, but when you consider SAP’s purchases – Ariba, Concur and SuccessFactors to name but three – a unified UX strategy is not going to happen from re-engineering the whole UI/UX layer of those (previously) third party products.

Visit the new SAP Fiori community and have a look around. It looks like it’s here to stay :-)

Planning the Fiori ABAP Frontend Server (FES) – Architecture Questions by Jochen Saterdag
Getting your Fiori apps served to the frontend involves making the following things available: the OData services, the Fiori Launchpad, the Fiori app code (views, controller logic, and so on) and of course the UI5 runtime. SAP has been slowly but surely socialising the term “frontend server” to refer to a system that fulfils this role. I first heard the term from SAP Labs folks in Israel back in 2013 (see “An Amazing 36 Hours at SAP Labs Israel“), and it’s becoming more pervasive these days. In modern parlance, perhaps, it’s now properly “become a thing”.

Of course, there are always considerations when planning such a server, and Jochen does a good job with this overview blog post. He answers some important questions, including whether you should use an existing PI system as the base for such a frontend server … the answer, clearly, is “no”.

10 tips to get you started on your Fiori development journey by me
Well, what’s the point of having your own blog post series if you can’t talk about your own content now and again? ;-) As I mentioned earlier, I spoke at the great Mastering SAP Technologies Conference in Feb this year. I wrote up my keynote into two blog posts, the second of which was a “top ten” style list. I’m sure there are many of you looking to embark upon this journey, so I thought I’d put together tips on what worked for me. If you’re interested in the first of the two posts, it’s “Can I build a Fiori app? Yes you can!“.

Well that’s about it for this week. See you next time!

The Maker’s Schedule, Restraint and Flow

A few years ago Paul Graham published a short essay “Maker’s Schedule, Manager’s Schedule“. It described succinctly how, and perhaps more importantly why calendar entry driven task scheduling, and in particular meetings, cause issues for makers. And I include myself and many of my colleagues within that “makers” general collective term.

Both the manager’s schedule and the maker’s schedule are important, but resonate differently and don’t mix. When making, building, creating things, solving problems, interruptions are disastrous, for all the reasons that Paul explains.

On the other side, time management, the proper organisation of tasks and working out what work to do, and how, doesn’t come for free. Managers and makers alike need skills in these areas. In order to build these skills, each one of us needs to understand that the areas actually exist, first of all. Email, phone calls, interruptions, the almost endless todo list and prioritisation issues are all things that we need to manage. And I recognise that I need to manage those things better. I use the Pomodoro Technique on occasion, but that’s just one tool. I also need to learn restraint. I need to resist the temptation to say “yes”, and to allow myself to be interrupted. If I get it right, I will find myself in flow more often. And that’s the mode that makers – developers, in our context – work.

Since that original article on the Maker’s Schedule, I’ve come across many other great articles and videos, and I wanted to share a few of them with you here, as you may find them useful too.

Remember – saying “no”, creating situations where you’re less able to be interrupted, using task and time management techniques that work for you, that let you produce more (or less, but that’s the subject for another post), is what we *should* be doing. Don’t fall into the trap of thinking that just because your project manager thinks and works in 1 hour chunks of time, you need to do as well. Of course, real life has a habit of getting in the way, but don’t let that stop us trying to be our best.

Further viewing & reading:

Scott Hanselman: It’s Not What You Read, It’s What You Ignore

Johnny Wu: Developer Productivity – The Art Of Saying “No”

Inbox Pause (great as an idea as well as this implementation)

The Pomodoro Technique

This Week In Fiori (2015-11)

Well hello again and welcome to TWIF readers old and new alike.

Last year I started the “This Week In Fiori” (TWIF) series looking at news, events and articles in the Fiori world. The last post (2014-43) was in October 2014, written by Brenton O’Callaghan.

The Fiori world is growing and spinning even faster, and Brenton and I decided it was time to pick up where we left off. To get the ball rolling, we recorded a half-hour session at the end of this week, looking at some news in the Fiori world. This time we took a more technical flavour, remembering that Fiori is UX, but built ultimately built with UI (see “Can I Build A Fiori App? Yes You Can!” for more on Fiori UX vs UI) – there are always two sides to any single coin.

If you have any news, or any suggestions for future TWIF episode topics, just let us know!

Here’s this week’s episode. Thanks Brenton!

Share & enjoy!

Why I’m Staying Close to UI5

I recently came across an article by Greg Donaldson – “Why We Are Staying Clear of SAPUI5“. Everyone is entitled to their opinions, and I do like challenges to assumptions and the status quo, so I enjoyed the article. I thought it would be worth responding with a similar piece, albeit with a slightly different title :-)

It would be an odd situation indeed for a unified consensus on any software, let alone software in this particular context – HTML5 development toolkits and frameworks, where, if you don’t have an opinion, you’re looked upon as an outsider. So I wanted to state before I start that there is no single correct answer, or even a single toolkit to rule them all, and Greg makes some important points.

I thought I’d look at the individual points that Greg made.

“Proprietary framework, no thanks.” 

As a lot of folks already know, UI5 is far from proprietary. It is written and maintained by web developers that work for an enterprise software behemoth, but the key difference is that UI5 has been open sourced, as well as using many open source libraries itself. In the article there’s the contrast made between “proprietary” and “industry standard” as though they’re opposites. This is not the case. So I’m not sure whether the criticism being levelled at UI5 is about its proprietary nature (which is not the case) or about (not) being an industry standard. This latter point is debatable: A toolkit powering frontend software across the entire ERP landscape for SAP customers feels like a de facto industry standard to me. Yes, not every company has adopted Fiori, but for one that drives its business on SAP products, UI5 is a likely software component.

I’m curious about the “SAP quirks” phrase which is also mentioned in this point. I’m not sure which quirks are being referred to, but if industrial strength design, MVC, internationalisation, automatic support for RTL languages, client and server side model support and an accomplished data binding system are SAP quirks, then yes please!

Further, AngularJS is mentioned as a framework with a huge community behind it. From what I can see, that community is fracturing, due to the major upheaval in (re)design between the 1.x and 2.x versions. That’s not to say that this couldn’t happen to UI5, but it’s actually happening right now with that framework.

“SAP Backend Upgrade?”

To do UI5-based apps “properly”, or “the SAP way”, then this is true; if you don’t already have a Gateway system in your ABAP stack landscape, then you’ll need one and also the UI2 add-in with which the UI5 runtime is supplied.

In my experience, however, it’s increasingly less common for an enterprise to not have a Gateway system somewhere; and with NetWeaver 7.40 you get the components built in as standard anyway. Further, installing Gateway components is often a coffee time activity.

But not wanting to over-trivialise this important original point, I wanted to point out the alternative; an alternative that is the most likely scenario anyway for a non-UI5 deployment such as AngularJS: a separate web server. You can just as easily host and serve your UI5 based applications, along with the UI5 runtime, from a web server of your choice. Then accessing the backend becomes the same task as if you’d chosen a different (non-UI5) framework.

And on the subject of accessing the backend, the point that was made about “remote enabled functions” does intrigue me. One of the advantages of UI5 is that it supports OData, an open standard, by the way, and one of the advantages of OData in turn is that it is a server-side model.

Calling remote function modules in this day and age is certainly possible and sometimes the only choice, but you’re not going to take advantage of server-side heavy lifting when it comes to data integration with your frontend. I’ve built Web-based apps with SAP remote function calls since the 90s, so I have the scars :-) Not only that, but the data abstraction model presented by the RFC approach is somewhat orthogonal to modern web based app data mechanisms.

“Browser Support”

This is of course always an interesting issue, but as an individual developer, and as a member of a development team, I prefer a solid statement about a well defined set of modern browsers which are supported by the toolkit I use, rather than have to do that job myself and deal with the vagaries that present themselves on a daily basis. Of course, rolling your own gives more flexibility, but it’s often more work.

And at least for the clients that I work at, the fact that (a) the browser choice is usually somewhat controlled anyway, and (b) the fact that in the BYOD context people even choose (choose!) to bring Windows phones, which are supported by UI5, underlines that choice for me.

“Frontend Developers Don’t Care”

At the risk of appearing obtuse, I’m going to absolutely disagree with this statement :-) Frontend developers *do* care; they care about the quality of the software they work with, about how and whether the toolkit they use does the job without getting in the way. Of course, this caring, this obsessive compulsion to be using the right framework and doing the right thing may mean that for some developers the choice is something other than UI5.

And that would be fine. There is no one piece of software that fits all requirements or circumstances, in any context. In the past I have used jQueryUI, JQTouch, AngularJS and other frameworks. And I would never rule them out for future projects. But right now, I’m investing time and effort in UI5, because it’s open source, it’s enterprise ready, it’s been designed & built and is maintained by committed, passionate designers and developers just like you and me (well, a lot more competent than me) and it is also fully in tune with SAP’s technology directions.

Skills in UI5 are going to be useful not only for building out the current and next generation of proper outside-in apps, but also for supporting the deployments, customisations and extensions for Fiori. A nice side effect at which one should not sniff.