Debugging SAP Fiori apps - the fifth "D"

12 January 2017

DJ Adams

DJ Adams

Principal Consultant & Mobile, UX and Development Centre of Excellence Lead

It's all very well designing and building a delightful Fiori app. But what about the long tail - supporting that app through its lifetime, with fixes and changes that come along? There's a fifth "D" to the SAP Fiori development mantra, and that "D" is for "Debugging".

The mantra 

In the SAP Fiori world, there's a mantra which generally goes like this: 

Discover -> Design -> Develop -> Deploy 

These four "D" words represent the progressive stages of bringing new functionality into the world, starting with Design Thinking principles, iterating on prototypes early on, building a stable first version and moving it to production. You can read more about this mantra, relating to SAP's User Experience as a Service, in Digital devolution in local authorities - Putting people first

However, there's a fifth "D" word that is crucial. That word is "Debugging", representing activities that kick in around "Develop" and live well beyond "Deploy".

Debugging is positive 

DJ-Debugging-SAP-Fiori-apps-cropped.jpgDon't get put off by the knee-jerk negative connotations that the word "debugging" might conjure up. Sure, it represents the act of diagnosing and fixing problems with code, with apps, especially those already in production. But it also represents the more positive aspects of being able to thoroughly understand an app from the inside, behind the scenes.

Not only to be able to support it and to address issues, but also to have the wherewithal to properly extend and enhance it, introducing new features in a sane and safe way, sympathetic to the existing design, architecture and codebase. 

Complex vs complicated 

SAP Fiori apps can be complex beasts. This complexity comes at different levels. While the Fiori design language demands simplicity of user experience, realising that minimal user interface is far from simple; it's not magic that causes a swan to glide effortlessly and smoothly across the water, it's a combination of muscle coordination, fluid dynamics and, well, pretty furious paddling under the surface.  

Another level of complexity is in the implementation itself. UI5, the industrial strength HTML5 toolkit with which Fiori apps are built, is commonly referred to as being "enterprise grade". What that means is that it has a set of features and facilities that are key to creating business apps that can go global: Support for the Model-View-Controller development approach, data binding, internationalisation, control hierarchies and asynchronous network requests to satisfy business data consumption are just some of the ingredients that make Fiori apps what they are today. Moreover, these ingredients make for complex scenarios under the hood.  

There's a difference between complex and complicated. By the nature of what is being achieved by building rich business apps that run in the browser and reach back into SAP systems to transact, lots of things have to be properly orchestrated. But that's different to complicated. Any fool can build something complicated - to paraphrase a famous quote that's often attributed to Mark Twain:

"I didn't have time to build a simple app, so I built a complicated one".

Building something complicated is not the same as building something that is inherently complex.

Debugging tools

With traditional ABAP-based apps that run in SAPGUI, it became second nature long ago to enter "/h" in the OK-code field and jump into debug mode. The ABAP debugger tools have improved considerably over the decades and we've come to expect not only facilities to help us wade through and find what we're looking for, but also (and perhaps more importantly) for folks in development and support teams to understand what they're looking at and to be able to find their way around behind the curtain.

So it is also with HTML5-based SAP Fiori and UI5 apps today. What facilities do we have at our disposal to help us navigate the complexities of a modern business app?  

Well, for a start we have the excellent UI5 Software Development Kit (SDK). Even from early versions it has been rich in documentation, samples and more. All debugging endeavours should start with a reference guide, the "sine qua non" that acts as a backstop, definitive documentation and final arbiter of how things work, or should be working.

Then we have built-in tools. Chrome is an incredible feat of engineering, providing near unrivalled development and debugging facilities for the creation and support of HTML5-based apps. It also has a pretty fine browser built in1! Time taken to teach oneself about features of the Chrome Developer Tools is time well spent.  

Furthermore, the UI5 runtime itself has some rather good facilities for debugging, notably the UI5 Inspector tool, which can be summoned easily in any running Fiori app.  

The knowledge

What binds the reference material with what the tools can tell you is something else, though. A knowledge and general understanding of how UI5 and Fiori apps tick. How they are loaded, form themselves into functionality in the browser, and bring data and UI to life on the screen.  

A painter doesn't pick up a brush and wield it like an axe against the canvas (well perhaps some do, but that's another story). They hone their skills and perfect their understanding of how their movements influence the brush, how the brush touches the canvas, and how the colours glide and combine.

Debugging is a conversation 

DJ-Debugging-SAP-Fiori-apps-content-1.jpg

I find that debugging a Fiori app is like having a conversation. A conversation with the control flow, a conversation with the mechanics of the runtime and often a(n imaginary) conversation with whoever was responsible for building the app. Understanding how to have that conversation is key.

So I was delighted when SAP Press gave me an opportunity to write a short guide to help us orientate ourselves with what we find under the surface of a Fiori app. That orientation is designed to show us how to use the tools available and have good debugging conversations with the runtime. It's in the form of an E-Bite, and is available now from their website: 

SAP Fiori and SAPUI5: Debugging The User Interface

 

Start now 

If you can see a Fiori app in your browser (I'm going to assume it's Chrome - if you're at all concerned with standards, security and reliability, why would you be running anything else?) then you're ready to start your debugging conversation.

Open up a separate window with the UI5 SDK, invoke the Chrome Developer Tools, and bring up the UI5 Inspector. And maybe even grab a copy of the E-Bite :-) Then you're ready to begin your debugging conversation. Start with "hello" and have a look around. You won't regret it. 

 

1 Yes, for those geeks amongst you, this is an oblique reference to the traditional description of the Emacs editor: "A fully featured operating system, lacking only a decent editor".

View comments

Comments

Blog post currently doesn't have any comments.

About the author

DJ Adams

Principal Consultant & Mobile, UX and Development Centre of Excellence Lead

DJ Adams is an enterprise architect and open source programmer, author and bread-maker. He has a degree in Latin and Greek (Classics) from the University of London and, despite having been referred to as an alpha geek, can nevertheless tie his own shoelaces and drink beer without spilling it.

He hacks primarily on SAP systems for a living, and has been doing for over 20 years, cutting his teeth modifying SAP applications in S/370 assembler, building real-time interfaces between forklift truck-mounted RF devices and SAP materials and warehouse modules in C (yes, this was pre-MM-MOB and WM-LSR!), and most recently integrating SAP, Ariba, Infor, Siebel, IXOS and PeopleSoft systems with a REST-based ERP business messaging gateway built on an SAP NetWeaver platform and processing tens of thousands of messages per day. Phew!

DJ is an SAP Mentor, and in 2003 helped get the SAP Developer Network (SDN) off the ground. He also spent a year working at SAP Walldorf in the 1990s, and is proud to still have some of his code and ideas in core SAP software.

When not building and integrating systems, he advises enterprises on architecture and integration, from SOA to REST, from pubsub (most recently with Coffeeshop) to messaging and presence, from message queues to webhooks.  DJ has written two books for O'Reilly, on Jabber (XMPP) and Google.