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?

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.

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

• Design submission
• Develop submission

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.

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

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

Exploring scenarios for upgrade of SAP Portal based application

In our company we’ve set up multiple end-user business applications on the same physical SAP Enterprise Portal landscape. Due diverse reasons, our Portal landscape is still on version 7.01 and getting outdated. From Application Life Management responsibility we’re now looking into upgrade of our Portal landscape. However, as everyone involved in SAP architecture and usability is very much aware, SAP has not stood still the last years, and as result the landscape to select from has been severely broadened. We can upgrade our SAP Portal landscape to the newest version 7.5. Or we can decide to introduce Fiori Launchpad as new entry point for our logical applications. Another solution option is the NetWeaver Business Client. Or the HANA Cloud Portal. And then there are all kinds of mixture scenarios thinkable. Amongst the decision criteria for the diverse scenarios are off course money and effort/time. But the most important is the usability of the new solution. And another is to careful watch what direction SAP is heading, to avoid that we go into a direction that SAP will not be committed to in [a] near future.

Current I’m defining the architecture plan for the new solution. In this plan I outline the diverse scenarios, and weight each of them on pros and cons for our situation. To form more feeling by what SAP is doing, we attended 2 workshops: one arranged by SAP specific for our company, and another setup by VNSG (the Dutch SAP User Group) for multiple invited companies. Especially in the last it was clear that we’re not alone in/on our quest: multiple organizations (among remarkable a lot of Universities) are struggling on what step(s) to take next on [SAP] portal area.

In the coming months I will regular post updates on first our decision path, followed by the progress of the eventual implementation(s).

Aspects and challenges encountered mobilizing a SAP business process

This blog is earlier published on SAP Community Network Blogs

Last year I was the integration/solution architect to expose a custom SAP business process as mobile App. In this posting I want to enumerate the major aspects and challenges we encountered. And with success, the App is in productive use, and the end-result recently won the SAP Quality Award 2015.

Aspects and challenges

SAP business system is a closed system
This actually encompasses 2 different aspects. For one, the functionality of the SAP system is locked internal in the SAP system with SAP proprietary technology and data formats, not exposed nor fit for alternative UI channels. And second, the SAP system is isolated from the evil outside in the company-internal infra.

Users demand a pleasant ‘form-factor’
Users are fed up with the arcane UI, and want a user-experience that feels good. This means it must look good, and moreover that it must have a pleasant behavior that supports the user in doing the work effective and efficient.

The mobile ‘form-factor’ must enable multiple devices and screens
Most noticable is that users expect an App to be usable from tablets and smartphones. And second is that for tablets, but in particular for smartphones, multiple different device formats and OS platforms are in use.

Unknown makes unloved
Since decades the SAP business systems are the stable base on which the organizations rely. Any change to this status quo inhibits the risk of disruption. And then also all that mobile technology and aspects introduces new knowledge. It is human response to be very careful, perhaps even scared, to all that new stuff.

The unknown outside is evil
IT security is not an easy, or even thankful job. They are held responsible in case of issues, and taken for granted otherwise.
When functionality is exposed via additional channels, also the security vulnerability increases. It is only rightful that security is very cautious, and demands proofing that the changes do not result in unacceptable security and thus business risks.

Secure and reliable authentication from App into SAP
Like all business systems, SAP internal processing is permission-based. What one is allowed to do depends on authentication (who you are) and authorization (what your allowed to do). In mobilizing the business process, the authentication part is primary delegated to the App, while the authorization part remains in the business system.
Typical the App-identity is different from the SAP identity, and a credential-mapping is required (Single Sign-On).

Performance
Although performance is also an aspect of the pleasant app-experience, the importance of this topic for user acceptance on itself warrants dedicated focus. Business-users are just as intolerant against bad-performing business-apps as they are in the personal context against non-performing consumer-apps. Also note that a major motivation for mobilizing SAP business process is to facilitate shorter time to handle, and a performant ui-experience is in that sense an absolute requirement.

What if…
...in <x> time insights or business situation has changed, and the delivered App is no longer sufficient? Such uncertainty about future developments (business and technology) is often misused as excuse to halt, and make no changes. And users are withheld from improvements in operation of the daily business actions that can be delivered to them today.

Infra aspects highlighted
1. Interoperability
Connectivity from App to the SAP business system
Expose the SAP proprietary data and functionality for outside consumption in the App
Data mapping of SAP proprietary data model in a standards-based, and optimized dataformat
Integration endpoints
2. Identity Management / IAM
Authentication (SSO across diverse authentication administrations)
Permission management

3. Security
Data loss ( through Device loss)
Data integrity (inspection, to prevent via encryption)
Unmanaged devices / BYOD
User and Device onboarding

4. Performance
Network throughput + latency
Scalability
Availability

5. Auditing / Audit Trails
Logging
Health monitoring

Architectural decisions

1. Deliver the App as a web-app; and rely on platform browsers to make sure the App runs on the multiple devices
2. Deploy as PhoneGap hybrid App that can directly be started from the device (relieving the user of need to retype the url in browser)
3. Expose the required functionality to outside as an API, with endpoints that are invoced via integration and data standards.
4. Use Gateway as middleware to deliver the service API: develop + runtime
5. Use SAPUI5 as html/javascript platform to deliver Responsive Design UI, and in look&feel that users are getting more familiarized with via the expanding SAP Fiori apps
6. Architect the App as loosely-connected UI-part and Processing part. This allows to exchange the UI-part for another UI-format when the situation has changed, while the processing part can be reused.
7. Architect the service API for an optimized integration surface. Avoid excessive call behavior of the App into the service API resulting in network latency, and design ‘chatty’ interface methods instead of data-minimized service methods.
8. We did NOT utilize SAP Mobile Platform, but hook into mobile platform that is already in use. Providing device onboarding, reverse proxy, transfer security.
9. Rely on proven SAP-technology of Java Authentication Server + LogonModule to convert customer-internal credential into SAP Logon Ticket (MYSAPSSO2, used in the SAP system).

Project approach

1. UI-design the ‘mobile experience’: build mock-ups together with stakeholders to quickly arrive at an App-experience that will truly help the business users.
2. Take the initial unknowledgable at the customer side on the tour to teach the new mobile concepts, and as such take away their uncertainties and anxiety that are due the unknown
3. Team up with SAP as supplier, and convince IT stakeholders at the customer on the support level of standard software (Gateway, SAPUI5). Call in on well-known SAP expertise (Andre Fischer, Holger Bruchelt) for solid advice and/or crosschecking.

Some relevant references:

• Single Sign On to SAP NetWeaver Enterprise Search 7.2 Using Integrated Windows Authentication
• SAP Fiori - Overview of SSL and SAML 2.0 Configuration
• Building SAP Fiori-like UIs with SAPUI5 in 10 Exercises
• How-to Avoid Caching of Confidential Data
• Gateway Protection against Cross-Site Request Forgery attacks

The SAP Mobile Integration playing field

SAP NetWeaver Gateway, SAP Mobile Platform, SAP API Management, Integration Gateway: the SAP Mobile Integration playing field includes multiple players. What are their roles, and can they play well together?

SAP Mobile Integration technologies and products

The role of SAP NetWeaver Gateway is exposing SAP ABAP-based Business Suites for consumption by alternative UI-channels, SAP and non-SAP. Including mobile apps, a.o. the SAP Fiori Apps.

SAP delivers also SAP Mobile Platform as a standard product. SMP 3.0 includes an internal component Integration Gateway. This is something different than NetWeaver Gateway, although it’s role is comparable: expose data and functionality for external consumption. Starting SMP 3.0 service pack 4, SAP positions SMP also as “Fiori-compatible”. Elements of this are SAP Fiori Client and Kapsel SDK within the SMP portfolio.

Early October, SAP in addition launched the new product SAP API Management. With this product, organization can manage and govern their service provisioning and usage by consuming organisations and Apps. Also this product thus has its rol in the mobile integration landscape.

How do these products play along?

SAP itself acknowledges that the pure existence of these 3 products, which seem to functionally overlap, likely will result in market confusion. To mitigate that effect, Joav Bally wrote an excellent article to clarify on higher level the difference in role positioning. Instead of repeating him, I simple refer to his post: Uniform Provisioning and Consumption of SAP (and non-SAP) Data. Another good information source is the post ‘There is a Gateway for that …’ by Mustafa Saglam.

Inspired by the insights I gained via these 2 blogs, I sketched a conceptual architecture diagram in which the 3 SAP integration products/technologies are positioned in the architecture layers.