SAP Business ByDesign and HTML5
Update, Dec. 29th, 2015: Please see a sneak preview of the HTML5 UI: http://scn.sap.com/community/business-bydesign/blog/2015/12/23/sneak-preview-of-sap-business-bydesign-html5-ui
In a recent Blog post ( http://blogs.windows.com/msedgedev/2015/07/02/moving-to-html5-premium-media/ ) , Microsoft summarized their position regarding HMTL5 and Silverlight.
As discussed in the media, Microsoft recommends to software vendors and the media industry to embrace HTML5, while giving a Silverlight support commitment.
We have been in contact with Microsoft on the topic for at least the last two years. With SAP’s UI5 strategy the move to HTML5 has started already. As this is an overall SAP technology policy, it obviously also applies for SAP Business ByDesign.
The ByDesign development ogranization has established an additional dedicated development team to re-implement today’s Silverlight based controls in HTML5. We waited until now, to ensure the re-use of investment made by SAP’s architecture and technology teams in the respective libraries. Also insight from our colleagues in Cloud for Customer and Cloud for Travel is reflected.
Still a large amount of work is waiting for us to re-implement thousands of controls. This ranges from very small ones to super large ones like the GANT-Chart used in project management.
We are in the midst of specifying out the delivery plan for this transition. We intend to provide a sneak-preview with feature pack 15.11. The transition will happen based on the criteria, how often a work center is used and grouped by applications. In short: Frequently used work centers will come earlier than complex key user scenarios.
First mobile applications, leveraging HTML5 have already been delivered with 15.05 (Project Cockpit and Approval Application). As you may have seen, these comprise of a surrounding ‘invisible’ container application (enabling access to device specific capabilities like GPS, camera, email, phone, calendar). The actual content rendered within the container is HTML5.
The project will run through all of 2016 and carry into 2017.
Based on the guidance from the ByDesign user groups, the user interaction design will remain unchanged. No need to re-educate any users. In addition, all partner / customer add-ons built via the development infrastructure using the UI designer will work as before.
For customers, who intend to transition to Windows 10, we follow Microsoft’s recommendation to use Internet Explorer 11. For customers, who use Google Chrome, we suggest to either move to Internet Explorer 11 or to work with a Google Chrome Browser version that supports Silverlight until the transition is done. We will keep you informed about which workcenters and work center views will be available with which feature pack. Many occasional users will be able to leverage the HTML5 based UI already in 2016.
For the ByDesign management team, this project in combination with the work to fully leverage HANA capabilities is key, as it secures the underlying technology platform for the next decade.
The till now unconverted Work Center on HTML5 look very promising. I am very excited about the official Preview.
Thanks for the statement, it provides much needed clarity on this subject.
While clearly the magnitude of this project is very large, it is still disappointing to find out it will take 18+ months for the transition to be completed.
It should be noted that "work with a Google Chrome Browser version that supports Silverlight until the transition is done" is not really practical given Chrome's auto-update behavior.
The statement also fails to address the needs of Mac-based users (can Safari be expected to support Silverlight until 2017?). Firefox, another frequently used browser, has also announced support for NPAPI (and hence Silverlight) will be deprecated and removed. IE11 clearly is not an option on Macs.
I know of the situation of our customers with a Mac and Chromebooks. This always was part of our motivation to move to HTML5.
To get you the first HTML5 UIs fast and cover as many users as possible, we went through the statistics, how ofter workcenter and views are used. Therefore, during the course of 2016, you should be able to provide ByD to a larger number of users. As said: Those with heavy key user scenarios will come later.
Hello dear Rainer,
Thank you for this official information as more and more customers are worrying about this matter. A message from you has always a better impact.
I am looking forward to see the full HTML5 version in production. The new Fiori client is looking very promising also.
Thank you for your attention.
thanks for your response. For the moment, we do not yet transition to a full blown FIORI look&feel. Key reason is twofold: 1. We don't want to make it too complicated and change in parallel the underlying UI technology and the interaction design. 2. FIORI is 'evoluting' very fast, also in the direction of a pattern based approach similar to ByD.
With 15.11, you will see, that we introduce a new UI stylesheet which picks up the FIORI colors.
What does it mean for developers? From the perspektive of an abap developer, i'm still confused about the technologies and the tools / skills needed in the future.
What does the change to HTML5 mean, will the development in ByD be in the .Net framework? Will the devlopment utilities and language become the same as in S4?
Will byd custom developments be supported?
Thank you for your reply and the clear statement about byd and html5.
I'm specialy thinking about this, since the huge change in technologie in the SAP Mobile Platform solutions from 2.0 to 3.0.
thanks for your question. For developers the transition to HTML5 shall be fully transparent, which means: No additional effort.
In ByDesign you use the so called UI Designer to create your user intefaces, based on the available ByD patterns. As SAP upgrades these patterns from Silverlight controls to HTML5 controls, you should not even see it.
Overall, the ByD extensibility topic does not change. for the years to come. You can continue to use the Cloud Application Studio (which is built on top of Microsoft's Visual Studio isolated shell) with all of the built-in capabilities (like the C# similar programming language ABSL, the object modelling language BODL, UI Designer, ...) or you could also use HCP if you have a JAVA preference.
One side remark: We are NOT using the SAP mobile platform, as it would be too demanding for the typical ByD customer.
How does this rewrite fit in with the general SAP UX strategy that appears to be pushing Fiori? I understand that Fiori is essentially HTML5, but most other SAP materials when it comes to UX explicitly mention Fiori.
Please ignore my question Rainer, I missed your answer to Jacques earlier post
we had extensive discussions with the ByD user groups about this topic. The clear feed back was: Keep you fingers off of the ByD UI, you will only break it 🙂 . Customers want more freedom regarding browsers and devices. Therefore HTML5 is the way to go. The foundation of the ByD UI are the so called patterns (search, list, quick activity, object instance floor plan, guided activity, ...). Once you know a pattern, you can operate every application for which you understand the business background.
FIORI is introducing similar concepts right now.
At the moment, it is key for our customers to get HTML5 without re-training their users and for the partners there is no need to adjust any add-ons. But the UI journey will continue and FIORI will be a key to it in the future. As you can see in 15.08, we have introduced a fiori-like style sheet already.
can you say something about other performances related improvement to be given to BYD ?
1/ I am thinking about REX which was supposed to disappear in order to give better speed to provide even better user experience
Is this still on the roadmap ?
2/ in BYD, we do not have access to the real HANA performance ... since our HANA is shared among customers tenants.
Is there a way to open the datasources as it is done with HCI ?
Other small tricks that could benefit to the user as a matter of responsiveness of the application ?
Thank you in advance
thanks for your questions.
1. In 2009 we introduced SAP's in memory search engine TREX into the ByDesign stack. Simple speaking, we route all selects into the search engine. By coincidence, I got performance data yesterday on 'display GL account data' for 117.000 line items: We spent 293 msec in the database, 380 msec in the web application server (total backend 673msec). This data is roughly the same on a MaxDB/TREX tenant AND on a HANA based tenant. Therefore, for SAP business suite, HANA is the same boost, that we introduced in ByD 2010. If I look across all backend dialog steps, we spend about 830 msec on average in the backend. The remaining elements are network latency and UI redering time in the browser (especially, if we talk about large amount of data to be transferred to the front end)
2. As mentioned above, ByD customers irrespective of their existing infrastructure, enjoy HANA speed already. But you are right: The HANA DB is shared amongst multiple tenants. We try to isolate the load as good as possible, but there may be spill over effects. Never the less, the response time experience is predominantly driven by the application server and here we have a lot of techniques to isolate.
Therefore: even in a single tenancy environment with a non-shared infrastructure, you would see about the same performance patterns. And 830 msec is a really good number.
We do not intend to open up the underlying HANA tables to user access. The reasons are: 1. The tables are part of the multi tenancy architecture and 2. in most cases, the access rights of the user are often dynamic and a function of the organizational model, which can't be represented with access methods on the DB level.
For these reasons, the best we can do is to provide the rich public solution model for accessing capabilities and e.g. (beyond many other methods) oData access to analytical information.
In 2016 we will publish monitors, so that customers and partners can analyze 'their' performance situation. I had some escalations over the last years, where either
a) we had to improve the access routines or the logic
b) the partner implemented an add-on in a sub optimal way
c) the latency on the customer's network was beyond 300 msec (to the SAP data center)
d) the front end machines were so low on clock speed, that the pictures took way too long to be rendered (maybe because of too extreme power saving options)
e) all of the network bandwidth was consumed by user users listening to youtube as background radio
We will post more about this topic in SCN in the future.
I like this discussion.
Html5 can support various devices.At the same time various devices can operate same functions as desktop. Then we will think about the role of mobile app. When we use browser, byd should give us all operations. For Persons who want simple function, we could develop various specific mobile app. Concerning to which specific mobile app is excellent, it might be a lot of fun to leave market principles at this moment(soon it might converge). I think the important factor is that byd should not limit the functions whether mobile app can access or not at the server side. If mobile app have an authorization, it would be nice to be able to access all functions. That whether the app access something function or not should depend on the mobile app design, should not depend on server design. I think it is not simple that we select 'desktop', 'mobile only' or 'desktop and tablet' when we develop server side.Regarding standard functions…
This architecture will not remain in the html5?
In my forecast, Fiori would realize a concept like adaptable responsive UI(Switches of 'desktop', 'mobile only' or 'desktop and tablet' would be migrated to adaptation layer). Cloud application would be able to get one virtual environment on android, ios, windows and so on.