Tuesday, November 1, 2016

Qualities of SAP Fior Apps

Few months ago, SAP published document "Qualities of SAP Fiori Apps (July 2016)". This document is aimed at customers and partners and defines the qualities to be met by a SAP Fiori app. It covers design, implementation and technical criteria to be met beyond the SAP product standards. Thus a handy resource to utilize for reference and guidance. However, as result of SAP's recent changes on SCN, the link became a deadlink and can current not be successful viewed via SAP locations. As I downloaded the document before, I make it available here in awaiting for SAP to structural recover their document link on SCN and/or HANA EA Explorer.

Qualities of SAP Fiori Apps

Friday, September 30, 2016

Why is Fiori adoption lagging behind?

Yesterday I attended a meeting of the Dutch SAP User Group (VNSG) on the topic ‘Customer Fiori Experiences’. As usual, the audience was mostly consultants/developers of SAP consultancies, and only a few actual end-customer attending. After interesting sessions on the state of Fiori (a.o. on SAP Fiori Cloud Edition), the meeting ended with a roundtable to share experiences. And in particular to discuss and answer on the topic how-to increase Fiori adoption in the market. According to latest numbers, (only) 10% of SAP customers world-wide are active with Fiori, and significant subset of them merely with 1 or 2 first Fiori Apps. Note, in The Netherlands the number is higher, as we’re very technology-savvy and typically run ahead of the rest of the world on adoption of new technologies.

There was large consensus in the group that the minimal actual Fiori implementations is for a major part still due unfamiliarity. Not so much by business and end-users, but by majority of SAP developers for which the step to Fiori / UI5 is [too] big, and they prefer to just stick within their comfort zone. Although there might be truth in this, I personally think the more important causes are others.

The most important is that for SAP customers there must be a tangible business case to switch to Fiori. It is not sufficient, even irrelevant for SAP organizations to switch to new technology and products just because SAP is now delivering it (and promoting it as the next great thing). Even though standard Fiori Apps do not have a license cost (anymore), there is still investment costs involved to transition from current application formats (e.g. GUI transactions, Portal application, WebDynpro) to Fiori as new UI and interaction concept. The investment costs are within preparing the IT landscape infra (introduce NetWeaver Gateway, and Fiori Front-End Server), deploying Fiori Apps plus the required underlying Gateway OData services in the SAP landscape, align with and convince Enterprise Architecture plus (IT) security that Fiori is a future-proof and secure/safe approach, educating end-users. And typically the standard Fiori Apps are not addressing the core of the specific organization, and custom Fiori Apps + Gateway OData services must be developed. And there is again the business case: if there is an existing application that still does the job, even with outdated, stone-aged layout and user-experience, there is little business motivation to invest in improving that for the internal employees. So what is needed then? In my experience and opinion, the precondition to introduce + land Fiori usage within any organization is that there is a concrete trigger – business or IT (savings). This can be that an existing SAP application (standard or custom) no longer suffices and requires to be redesigned and rebuild – and thereby introduces the opportunity to take new UI and mobility requirements into account. Or because there is a new business demand, and again in the current days with ‘mobility-first’ this must be included from beginning of. A third trigger is Application Lifecycle Management, which forces organizations to upgrade their landscape to recent NetWeaver version. Also this can be good moment to reconsider for (some) applications to migrate them into a modern UI experience.

Note, what does not help the market growth of Fiori is the SAP image: stable and robust functional platform, that you do not have to (should even) touch much. SAP could therefore also take a rewarding approach: make it tangible benificial for SAP customers to introduce Fiori => introduce new functional capabilities only via/as Fiori. Actual SAP is following this approach, with 'Fiori-tizing' S/4 HANA.

Wednesday, September 21, 2016

Resources for considering Fiori Launchpad deployment options

With the introduction in March this year of SAP Fiori Cloud Edition, SAP now supports upto 5 different deployment options for Fiori Launchpad:

ABAP Front-end Server
SAP Enterprise Portal, as of NW 7.31 SP12 and NW 7.4 SP7
HANA Cloud Platform (HCP)
SAP Fiori Cloud Edition
SAP HANA Server

Which of these options is a/the best fit for an organization is largely influenced by the situation and roadmap of that specific organization. Some useful resources to aid in this deployment decision-making:

Use them at your own convenience...

Friday, June 3, 2016

SAP Web IDE cloud connectivity issues

This blog is earlier published on SAP Community Network Blogs

SAP Web IDE cloud connectivity requires project folder direct below the root node “Workspace”

In the HANA Cloud Platform cockpit I’ve setup a connection to the demo Gateway system. Next, in SAP Web IDE I’ve created a new App folder. As I prefer a manageable overview of all Apps (to be) developed in Web IDE, I created that App Folder in a subfolder beneath the Workplace folder:

This decision however gives problems within Web IDE wrt setting up the cloud connectivity.

Issue 1: neo-app.json generation is not available

Pragmatic workaround for this was to generate it via a test-App folder directly beneath Workplace, and copy + paste that file in MyApp folder. Problem resolved.

Issue 2: The destination is runtime resolved to incorrect address

Testing the MyApp in Web IDE, data is not displayed in UI. Via F12 notify that the connection to connect to the demo system is not correct resolved, and returns a 503:

For a quick test I duplicated MyApp to be directly below Workplace folder, and without making any code or configuration change, ran it from here. And now the connection is resolved, and the App displays the data from Gateway demo system:

I compared the urls generated from Web IDE to the service destination in the 2 situation. The only difference is in the 'webidetesting' part. Apparently there is some "magic" in Web IDE that reserves a dispatching url in HCP for service destinations, and that 'magic' is dependent on the project folder located direct below 'workplace'.

I considered as workaround to modify the 2nd level project in manifest.json and have it use the absolute connecting url to service:

However, that setup runs into a cross-domain issue, and is thus neither working:

The only resolution for this is to comply to the 'implicit rule' of Web IDE, and place the project folder thus direct below root node "Workplace". With the drawback that you loose the option to structure and classify your projects / Apps folders, and all need to be administrated at the same level as sibling nodes. I would rather be able to make in Web IDE visual groups of project / Apps folders per customer and / or functionality, e.g. for HR, Finance, Marketing. Perhaps we will see this functionality in a next version of Web IDE?

Thursday, May 12, 2016

First thoughts on Native Enterprise Fiori iOS Apps

On May 5, SAP and Apple announced a partnership to deliver native iOS Apps that will connect into SAP business suites:

Apple & SAP Partner to Revolutionize Work on iPhone & iPad

My personal first response on this news was astonishment and non-understanding. Since 3 years SAP is full promoting SAP Fiori build through SAPUI5 (or openUI5) web-technology as THE future-proof way to build user-friendly SAP Apps. SAP applies itself in all new and updated product developments, as SAP HANA Analytics Apps, NetWeaver Business Client, SAP Enterprise Portal. SAP made and evidently applies the decision to go full-stream for web-based UI in favor of the platform-specific native product developments (of which SAP tried several variants, most notable through the Sybase Unwired Platform). And now all of a sudden, SAP appears to return on this decision and [also] to put full steam on platform-native development. Starting now with first Apple/iOS, and already communicated plans to follow later with Android.

I expressed my surprise and concerns on a SAP post in which Steve Lucas communicated on the SAP-Apple partnership. His responses gave me more insights in the why of this renewed native-attention, and the positioning towards web-based. Not to say that I in all agree.

Steve in particular replied with statement ‘There’s a big different between “semi” native and native’. On this I disagree, regarding the qualification ‘big’. I do acknowledge that for interactive consumer Apps this may still (and likely remains to) hold, as those may need the local computer power and platform-local capabilities. Games are a good example that really benefit from direct access to the local resources and computing power. But I personally doubt that platform-native capabilities add considerable extra value for business / enterprise Apps.

(Source: [Salesforce Developer] Native, HTML5, or Hybrid: Understanding Your Mobile Application Development Options)

As a true architect, I made a Pro/Contra enlistment for Fiori-native and Fiori Web-based:

Fiori-native

Pro	Ability to use device-local capabilities (e.g. geolocation, camera, local storage)
	Rich UI
	Consistent UI for the specific device-platform
	Optimal local performance (power)
	Fast graphics
	Push-notification supported
	Possible to run / continue in background
	Data-integration possible with other local Apps

Con	Need to build + support per device-platform
	Mobile-Only
	Version-upgrades must be explicit brought to each individual end-user device
	Requires SAP HCP

Fiori web-based (SAPUI5/openUI5)

Pro	One version usable on all device-platforms
	Mobile-First / Mobile + non-Mobile
	Easy deployment: Version upgrades only on central webapplication level, transparent to end-user devices
	Via Fiori Client or Kapsel: possible to act as semi-native App, direct user-launchable from the device
	Via SAPUI5 and other frameworks (jQuery), possible to use device-local capabilities (GPS, Camera)

Con	Functionality limited to common denominator across the platforms
	UI is not on-par with the device-specific experience (e.g. Fiori UI differs considerable from iOS native UI)
	Push-notification is complex (and requires Fiori Client or Kapsel [Hybrid App]
	Local file storage not available (although from security perspective, this is not per se a disadvantage for business / enterprise Apps. Dependent on the business App, it may be prohibited to locally store sensitive / business-critical data)
	Not possible to run in background
	Less performant due browser javascript engine + interpreted rendering

Based on these (and more) pros/contras, individual companies/architects can decide whether to go for web-based SAP Fiori or platform-native Fiori. Noticable especially is the HCP dependency in case of Fiori-native. Implication is that companies that are no subscriber [yet] of SAP HCP, cannot go the Fiori-native path. But they can expose their on-premisse SAP Business Suite(s) via web-based/SAPUI5 Fiori Apps.

Saturday, April 30, 2016

My openSAP Fiori submission flagged as extraordinary by peer reviewer

Over the last couple of months I participated in the openSAP ‘Build Your Own SAP Fiori App in the Cloud – 2016 Edition’ on-line training. Reason to participate was to increase my practical knowledge on Fiori development, now that we intend to rebuild our business portal utilizing Fiori Launchpad and UI-technology. Although I already have practical SAP Fiori + Gateway experience in my role of solution architect for an App build for a large Dutch bank – this App even won the Bronze SAP Quality Award 2015 in the category ‘Innovation’ -, I wanted to renew my knowledge with the latest SAPUI5 technology state and also the tools that SAP now delivers. The tools encompass the full spectra, from design [SAP Splash and BUILD], to development [SAP Web IDE]

The structure of the openSAP training is first lectures explaining about the why and concepts of Fiori, Design Thinking approach applied for custom Fiori development, and how-to design and develop a custom Fiori App. A central element of the training is, as the title already states, to design and develop an own Fiori App. Applying the Design Thinking approach, and the tools that SAP provides. The first assignment was to design the App, both functional as visual specification – preferable via SAP BUILD. And the final assignment was to develop it as a real functioning Fiori App, build with SAPUI5 framework within SAP Web IDE.

The App I came up with is ‘ProcessMonitor’. Basically it serves as a headlights dashboard to watch the (non)progress of business processes that you have a stake in. Typical these are the processes that you’ve started, and await on their completion.

Design - mockups


Develop - App

A nice element of the course is mutual peer-reviewing. Each participant is requested to review at minimal the submissions of 5 of your peer participants. And it also implies that your own submitted work will be reviewed by at minimal 5 of your co—participants. I was pleasant surprised to hear that my Develop Challenge submission was flagged as extraordinary by one of my peer reviewers. Acknowledgement and recognition by your peers is one of the best there is…

And the App can be further extended on. A next useful functional addition to the App is the ability to monitor the (non)progress of projects in which you are not yourself direct involved, but still have a stake or even merely are interested in it’s completion. The idea here is that you can request a list of running processes – naturally complying to business authorization rules, you thus only can see the processes that you given your business role are allowed to see. And select from the list the process(es) that you want to ‘follow’. An example would be to 'follow' the progress of a budget approval process in your company that concerns a project you like to participate in.

Wednesday, April 27, 2016

Architectural decision path to rebuild our business portal foundation

As stated in previous post, current our business portal foundation is based on SAP Enterprise Portal 7.01. The direct trigger to consider a rebuild is that SAP has announced that support on EP 7.01 ends per end of 2017, and even no extended maintenance will be offered (source: SAP Note 1648480 - Maintenance for SAP Business Suite 7 Software). But another motivation is perhaps even more important: enable our end-users to seamless access and use the business portal foundation and the business applications exposed in/via it.

What is a business portal: Architectural Views

Business Architecture

Host of functional portals
Launchpad to access business applications
Structured collaboration with external counterparts (suppliers and customers)
“Business card” of the company’s identity and IT maturity level to internal employees and external partner organizations

IT Architecture

Presentation layer
Identity and Access Management
Reverse Proxy
Authorization / Roles Management
Single Sign-On to ASML business applications
Content + Knowledge Management
Application hosting

Ambition for renewed Portal foundation

We aim for a user-centric environment, Responsive Design, mobile-ready, seamless end-user operation, personalizable, role-based, performant, secure, company branding. And appealing to use…These are all aspects that SAP aims to address with the Fiori offering, and via SAP Fiori Launchpad as gateway entrance. But SAP is not alone in there, other portal platform vendors aim to support the same.

Portal platform (re)selection

The decision to rebuild our company portal foundation also beholds a good moment to re-evaluate the portal platform selection. It will again be a decision that lasts for years, thus justified to spend time to the portal platform and vendor selection.

The outcome of the selection traject is that we stick with SAP as vendor for our portal foundation. The main decision drivers for (re)selecting SAP as portal platform are:

This is predominantly Application Lifecycle Management, like for like
Gartner positioned SAP as a leader in it’s 2015 Magic Quadrant for Horizontal Portals – on completeness of vision for Portal and UX (via Fiori) offering
The weighing of the 6 Portal Platform Leaders on the main company priorities results in SAP qualified as Nr 1 for our portal foundation
A large set of the exposed business applications are current build as ‘Portal-Embedded’ applications: they make use of and are dependent on SAP Portal capabilities, e.g. Enterprise Portal Knowledge Management
A large set of the exposed business applications are SAP backend based. Exposing via a SAP technology-based portal results in better integration plumping: authentication, Single Sign-On, end-2-end auditing.
SAP and it’s partners (will) deliver standard SAP Fiori Apps to operate SAP Business Suites (Finance, HR, Sales, Manufacturing, Supply Chain, …). Examples applicable for Supplier context:
- WBS Element BOM
- Quality Notification
- Report Quality Issue
- Open Orders – Total Orders By Status
- Process Order
- Track Shipments

Portal foundation rebuild strategy

Application Lifecycle Management to SAP EP 7.5:
- Remain supported by SAP
- Remain in-control of the full Portal landscape
Innovation via Fiori Launchpad:
- User Experience: Prepare and enable for new UI concepts
- Functionality: Prepare and enable for new service concepts