Lately, I've been messing about quite a lot with SAPUI5, NetWeaver Gateway and the SAP Fiori Suite. I haven't had much time to write any of it down, seeing as I've recently taken up a new role and I'm not yet used to all aspects. But as I'm waiting for a customer's BW system to finish a couple of loads, I find myself with some free time on my hands to note down some of my findings.

Fiori Perception

Part of my new role includes presales. I spend quite some time with customers explaining the new UI strategy of SAP. Internally, I also do a little bit of coaching and knowledge sharing. There as well, a lot of colleagues have questions about Fiori and what it can mean to them. Both functionally and technically. One of the remarks that keeps coming back is: "Which applications are available? Oh, but those don't fit all our needs."

Often times, customers have quite some WebDynpro Applications, SAPGui screens and custom workflows in their system. Obviously, SAP is not going to foresee Fiori applications to replace your own custom code. So many customers and colleagues think that Fiori is not the right fit for them.

It's not just a suite

Fiori is the name for the SAP Standard suite, which includes the launchpage. But all the technologies used are at your disposal to make something out of it. There are tons of funky stuff you can do.

• Copy a standard Fiori application and change it to your needs (beware, no updates)
• Enhance an existing/standard Fiori application for minor changes
• Create your own custom Fiori application (it sounds more daunting than it is)
• Add new tiles to the launchpage which refer to
  • (custom) Fiori applications
  • WebDynpro screens
  • Screen-persona's (webgui url)
  • the web version of the business client
  • Internet pages

It's an opportunity

When talking about creating your own launchpages, you actually have a great opportunity to rethink the roles you're assigning to people. The standard Fiori Launchpage requires a role, in which the first level contains an authorization to a certain Tile Catalog, which in turn contains the applications for that catalog.

So the role refers to one, or more catalogs (important, the catalog entry must be on the root level of the role, not in a subfolder). The catalog contains one or multiple groups. Every group can contain one, or multiple Tiles. 1 tile maps to one URL, or Application.

In the very same role you can also include the authorization objects required on SAP side for the functional execution. (PO Creation, Company code authorization etc..)

Clearly, this is a very different way of creating roles, as opposed to transactions.

Your own tiles

So you may want to create your own tiles, which you can include on custom Launchpages. The first thing to do is launch your Fiori URL, and replace the "Home.html" by "admin/admin.html". There, you can create new catalogs, groups and tiles.

Every tile requires a URL, or an object based navigation towards its application. No-one ever claimed that it has to be a Fiori applicaiton. It could just as well be a WebDynpro, a third party web-app, a WebGui url, a BSP page...

(PS: all Fiori apps are stored on the backend as BSP applications.)

(PPS: I'm hoping that the next version of Abap In Eclipse will have support to edit BSP views and mimes directly, So  don't have to up and download all the time)

When you've gone through the entire process, you'll end up with some extra tiles on your home screen. In this example, I've added a tile towards my own custom Fiori application, called "myHome" (an app for Real Estate):

Custom Fiori apps

Lots of customers will look at the standard Fiori apps and say: "Well, we can't use that, because we do it differently"

Have no fear. The standard apps in the Fiori suite are the basic versions. They'll do what they promise, but nothing is stopping you from enhancing and extending it to suit your exact needs.

You can even go as far as to create a fully functioning custom Fiori application. They can even be quite extensive.

Theming

SAP is quite proud of their Theme Designer, but to this date, I haven't actually succeeded in adapting a theme properly, and publishing it back to our ERP backend. I find it much easier to foresee my own CSS file (small) which overrides some of the standard theme settings, and refer to that CSS file from the index.html.

There's a nice little trick in CSS. If you add the notion !important to a line in CSS, it will have priority over all other possible settings. Comes in handy.

Aww, I notice the BW system has finally finished loading, so I'll keep it at this for now and maybe next time, I'll let you have a look under the hood.