SAP Frontend Choices

It is interesting when SAP keeps touting new features for the Portal, for instance in Netweaever 7.3, when it is now that broad end user community is coming to terms with basic Portal functionality like surfacing roles for ESS, MSS or SRM. Surely, the smooth Single Sign On to various SAP apps helps end user experience as well though.
SAP continues to tout features like Workspaces, Wikis and Forums, Mashups, Web Page Composer from various versions through 7.3 – when what is really getting used is role based navigation, KB based document management, and the fact that you get a consolidated view into the backend systems using SAP Portal.
Most of the enterprises either use default SAP Portal Interface with two rows of navigation on the top and detailed navigation on the left calling in SAP transactions in the middle. Or they take a higher route, engaging some kind of user interface experts to totally revamp the look and feel, basing it on some creative use of pages created out of HTML, and stored in KM.
However SAP keeps convincing developers to use Web Page Composer, for instance to nicely design the pages. Yes, WYSIWYG is a good way to author content on Joomla (an open source Content Management System), but I doubt if anyone is looking to do that for an SAP Portal Home Page, when you have Enterprise IT resources and System Integrators available with either none, or sometimes creative strategies. None of them even looking at something as trivial as Web Page Composer.

Mashups: It will be interesting to note how many companies are using a page with Supplier, Materials and the page going into Material Details and then showing the Supplier location page that also displays a Google Maps – as an example of external service integration – all instances of what SAP calls Mashups. Its time these examples need to come out of SAP’s demo instances and Teched Workshops, into the real world, i.e. if there are any takers.

Sure SAP keeps coming out with improvements for administrators and developers like File Extension and Size filter in KM or Transports of KM, or various APIs for third party integration – all is fine, but any substantial improvement in the end user interface seems still off radar. Yes, AJAX based interface makes things slick, but real improvement is required at how, for example, is the experience of a supplier in the supplier Portal. Is an Office Admin at a Supplier partner able to easily maintain the user profile, and look at Product Categories? This is an age of Facebook and Google where user interfaces don’t let there be any click more than necessary. Unless SAP can bring forth easier and simplified navigation to what an end user has to do, any amount of progress in SAP Portal features will essentially go nowhere.

NetWeaver Business Client (NWBC) is a rich client that can access all of SAP’s business applications. It runs not only new Web Dynpro or Visual Composer applications but also classical Dynpros (standard SAPGUI screens), BSP pages, analytic dashboards, iViews, portal pages, etc.

Too much detail on this is not forthcoming – other than an interview explaining the approach by Vishal Sikka, CTO of SAP and this whitepaper USING THE SAP NETWEAVER ENTERPRISE PORTAL AND NETWEAVER BUSINESS CLIENT. A few months back, the time line on this was another 18 months or so. SAP may be giving access to specific clients/partners for beta testing.
Some documentation has started referencing NWBC so probably its on the horizon.
NWBC will essentially enable users to switch between a Web-style UI and a desktop-style UI.

An important missing piece of the Netweaver puzzle has been an Identity Management piece. Identity Management in old R/3 world was easy but very limited and siloed – create users and their attributes in SAP directly (or via an HR process) for most part, and let them diffuse to other SAP systems in the landscape and set a degree of automation in managing the security attributes via CUA. But enterprise have challenges with users having a number of IDs and passwords that they have to remember and the whole management around these IDs. For this and in an attempt to make SAP tie in better with other pieces of enterprise IT systems, SAP’s new java line products started to connect to an LDAP as the main user store. And techniques connecting the ABAP system to the LDAP also started showing up. However, as the importance of LDAP increased, more conspicuous its absense from SAP’s own product suite became. Virsa acquisition added the slick GRC tools, but with MaXware acquisition, the shape seems to be rounding off. SAP just made available “SAP NetWeaver Identity Management 7.0”.

Now SAP has its own product that can connect to a heterogeneous IT landscape effectively – it has a self service interface and together with better integration with GRC Access Control tools should bring down the cost of ownership and compliance audit. The focus can be on integrated Business Processes which mostly already fed by the SAP applications. There is also the promise of seamless SOA support and above all, MaXware has already been a respected name in Identity Management space and SAP’s re-branding will only help further.

This is going to create a positive pressure from SAP side on an IT Organization. Hitherto, for example SAP Portal user and role assignments could connect to an iPlanet or Active Directory LDAP which is not typically part of SAP footprint. While the MaxWare connectivity would continue to be open and SPML based (letting competitors compete at a level playfield(?)), now there is a powerful product in SAP’s own inventory that fits the bill and in due course would integrate better and easier. Expect new implementations or organizations will look very seriously at SAP Netweaver Identity Management (in addition to existing MaXware clients).

More details on SAP User Access solutions are here.икони

With new Business Intelligence version 7, SAP has moved it BEx Web Analyzer to a pure Java framework. This necessitates that there be usage type BI Java, the prerequisite of which is usage type EP. Which means every BI 7 upgrade or installation needs a Netweaver Portal together with KM and Collaboration installed. This has been an interesting way how the landscape has been laid out.
Now it does not really mean that BI Java has to be set up on your primary portal instance. Instead what it means for all practical purposes is that it will almost necessitate setting a separate portal instance. While users will not necessarily know (and should not know) that there is another portal, this additional portal will be real for portal administrators and BI team to manage. The framework for this new portal can (and should) be kept dormant (hidden). The real use of this portal instance should be limited to the use of its underlying J2EE engine to run the BI Query runtime and BEx web analyzer. And probably to use the KM that comes with it for information broadcasting functionality.
In BI 7, The AS ABAP usage type continues to have the BW 3.5 Web Runtime together with IGS for graphics, and is topped off with BI Content Add-on. Which is inclusive of all that is required for web based BEx reporting as people have seen coming out of BW 3.5. Whats new is really the BI Java Usage type that brings all the new added functionality (the IT Scenarios like Enterprise Reporting, Query, and
Analysis) to the fore for the users. For example Analysis Item, Formatted Reporting, Web Printing, PDF Export, etc. Its also required for rendering Webdynpro for Java apps for BI Integrated Planning.
So while technically one could do a “technical” upgrade to BI 7 without the Java engine, any new functionality will need Java (and hance the dormant EP instance).
How is the BI Portal different from the user facing primary portal instance?
Even if your company did not foresee a need for a federated portal, looks like there is no escape from it since in this new architecture, the BI Portal becomes a producer portal and the main portal the consumer portal. Content from the BI producer portal surfaces inside the consumer portal as url iViews, remote role assignment is possible, etc.