In this blog I am going to highlight my experience with the development of a business solution built on SAP HANA Cloud Portal and SAP HANA Cloud Platform.
Overview
In 2012 my department was requested to develop a Web CRM system (B2E scenario) to be used by customer service operators working at Danone’s Call Centers located in South Africa. Such a piece of software was embedded into CAD (Cisco Agent Desktop), a tool used to manage phone calls. We investigated a few options and decided to build the solution on SAP HANA Cloud Platform, a flexible, elastic, standards-based on-demand platform targeting Java solutions.
Monolithic application
We then built a monolithic application, based on SAP UI5, which offered a set of functionality through a shell controller accessing back-end functions by means of SAP NetWeaver Gateway (oData protocol) over a secure tunnel on top of SAP Cloud Connector (SCC). Initially, application’s performance was not entirely satisfactory, due to network latency: users accessed the solution from South Africa, server side components were executed in SAP’s Data Centers (located in Germany) which, in turn, accessed Danone's SAP ECC back-end systems (located in France). The implementation of a multi-channel caching approach (i.e. data was cached at any layer) ensured the achievement of performance KPIs.
Upon showcasing the solution across the organization, interest aroused and some business units requested the application be rolled out to them. The solution did not fit 100% the requirements of these Country Business Units (CBU) and, as a consequence, we had to identify and bridge all the gaps that were found.
Going Portal
The idea was to lay the foundations for the development of a template solution that could be easily flavored to meet varying CBU needs, for example in terms of branding and theming requirements, navigation patterns, etc. We then thought that a (cloud) portal would be the most appropriate response to this scenario and started to review a few products available on the market.
Upon reviewing them we chose SAP HANA Cloud Portal because of its flexibility and easy branding and customization, easy integration with SAP and non-SAP sources, out-of-the-box widgets, mobile consumption and social experience.
The original application was broken down into smaller components that were reassembled into a portal website and deployed to our first client: DWC (Danone Waters China).
The procedure we followed to transition from a monolithic solution to a portal based one, that's what we call portalisation process, will be documented in the remainder of this article.
Portalisation process
When a monolithic application is to be portalised we first need to identify what its reusable components are and then break it into them. The identified components shouldn’t be neither too large (so as not to hinder future reusability) nor too small (which could lead to communication overhead across components) and the right trade-off, based on functionality, ought to be found.
Our monolithic solution provided functionality for order taking, order retrieval (display and modify), open invoices retrieval, customer search, customer credit check and reporting capabilities.
We mapped each of them to portal pages and we started to design these pages. Since some parts of the pages were the same across the whole website we made use of the template concept. We developed a custom template made of a masthead (displaying a logo specific to the CBU and a dynamic navigation belt) along with a right panel displaying a widget to allow end users enter business parties like sold-tos, ship-tos, payers and bill-tos.
By making use of page templates we also enhanced the load of the pages (since the components that were always visible were factored into the template).
Communication across widgets was managed by means of the sap-context feature (open social API), a kind of broker implementing the pub/sub pattern which enables widgets interaction using a shared data store (the site context).
The navigation belt came as an out-of-the-box widget whose content was driven by user roles. HANA Cloud Portal’s role concept is tightly integrated with the authorization concept of HANA Cloud Platform.
In fact, roles are defined in HCP at subscription levels (e.g.: Sales Assistants, Sales Managers, Approvers, etc), groups are defined in HCP at account level or subscription level or defined by means of dynamic assertion group rules using regular expression of SAML attributes from SAP IdP.
Roles defined in the platform become Organizational Roles in the portal and have to be added to the site to have them available at page level. Roles are then assigned to groups and users to groups. Finally, based on the groups the user is assigned to, the list of roles is determined and navigation hierarchy is subsequently built.
The screenshot below provides a quick view of what the final solution looks like.
This project posed numerous challenges, particularly in the area of application's performance. Users accessed the solution from a number of locations throughout China and, since SAP does not have HANA Cloud Data Centers in China, the best performing location to deploy our application on had to be found. Upon measuring application’s response times from different locations (Europe, USA, Australia) we decided to go for the Data Center located in Sydney, which exhibited best overall performance.
Information exchanges from the client to the Data Center have been compressed (gzip) and static resources minified. Resources are downloaded from a CDN and a double caching mechanism has been implemented on the cloud. Specifically, a CacheControlFilter with a 1-day maxage has been set up to cache static resources on Shindig and a custom LRU cache mechanism has been implemented to cache dynamic proxy requests.
Benefits of portal base applications
All in all I would say that portalizing a monolithic application is pretty straightforward and numerous benefits are obtained as a consequence:
- functionality can be reused to build new sites which can easily be deployed to business lines by Content Administrators (and not developers)
- roles based access is tightly integrated with the authentication mechanism of the platform and covers most of the role-based scenarios enterprises may have
- significant set of out-of-the-box widgets to use to build sites
- powerful and easy to use branding and theming capabilities
- APIs to develop bespoke scenarios not covered by the standard.
At next d-code in Berlin, November 11-13 2014, I will be hosting a session dedicated to this subject wherein details on two interesting live scenarios will be provided.
Look forward to seeing you there!
- SAP Managed Tags:
2 Comments
