SAP Frontend Choices

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.икони

SAP continues with its name and package nomenclature game, and confusing the heck out of its customers and users. So the latest (since Sapphire) is that mySAP ERP 2005 is now called SAP ERP 6.0 and, in particular, that SAP NetWeaver 2004s has been renamed SAP NetWeaver 7.0.
So basically remember that it’s the same NetWeaver release behind all of these names: SAP NetWeaver 2004s, SAP NetWeaver 7.0 (2004s), as well as the new official name SAP NetWeaver 7.0.

So its no co-incidence that one of my favorite interview questions is – what is the difference between R/3 4.6C, R/3 Enterprise, mySAP ERP 2005, SAP NetWeaver 2004s, ECC 6.0, and so on. And eight out of ten experienced SAP consultants find themselves struggling. Talk about clients….

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.

At Sapphire SAP & Microsoft announced the extended roadmap for Duet 2.0 and Duet 3.0.

Microsoft and SAP will extend their Duet partnership with two more major versions aligned with the next generation of Microsoft’s Office and SAP’s Business Suite. New scenarios include sales and supply chain management beyond ESS/MSS. There also seems to be a momentum building towards extended use of Sharepoint Server for unstructured data and collaboration – though Netweaver Portal will continue to be critical to the architecture. There are also enhanced Duet tools and infrastructure interwoven with Microsoft Office SharePoint Server.

Duet 2.0, is planned for the end of 2008 and Duet 3.0 is planned to be released soon after the next generation of SAP® Business Suite applications and Microsoft Office software, including Microsoft Office SharePoint® Server.

http://www.sap.com/company/press/press.epx?pressid=7607.
Check www.duet.com and http://www.sapmendocino.com

In addition, together with HP, SAP and Microsoft also announced Duet Appliance – a pre-installed and configured Duet solution based on HP servers. You can see http://www.sap.com/company/press/press.epx?pressid=7577 for more information.

SAP started talking about composite applications, or xApps, around 2003 with its Enterprise Services Architecture Strategy. All SAP xApps composite applications combine Web services and data from multiple systems. The company has developed a composite application framework that supports model-driven application composition, a user interface layer and a collaboration framework to relate any service or object from SAP’s Netweaver to any other business object. There are xApps for Sales and Operations Planning, Lean Planning and Operations, etc. – and some of the new ones around Governance, Risk and Compliance and Mobile Business.
Now Oracle has jumped into the fray – probably it had to with its multiple app portfolio. Big question is whether Project ‘X’s approach will overshadow and perhaps be injurious to Oracle’s Fusion vision. If Oracle is smart, Project X could generate an annuity business. However with this, a JD Edwards customer could use this integration framework to access G-Log’s logistics hub, Demantra’s demand planning capabilities or Siebel’s CRM functionality without having to license the suites themselves or wait for Fusion Applications.

This seems like the hottest debate in SAP shops these days. There has been a slow and steady build up towards SAP’s move to Java based development in the last few years with Netweaver. And that seemed to be culminating in SAP’s WEBDYNPRO framework which optimizes the MVC paradigm into something most suitable for business application development. Traditional Java developers hitherto using JSPDynpPage or DynPage development for Portal development seem to be smitten by Webdynpro for Java and swear by ease of development of common business applications using Webdynpro for Java. It is apparently robust and high performance. It brings to the Java world the basic tenets of SAP’s traditional dynpro programming where the developer strictly works in a module pool framework for PBO and PAI, does simplified coding, and scaling, performance and best practices are implicit in the framework itself. So far so good.
And then, last year SAP came out with the same framework for ABAP language. Which suddenly seems like natural progression for SAP’s ABAP development community – to develop web based business applications within the familiar SE80 environment which also brings to the table all the goodies associated with the Webdynpro framework.
So as SAP development shops were gearing for significant changes in their skill mix (trying to bring on a mix of Java skills inhouse), suddenly there is a new found hope that afterall, after all the scare and uncertainity of the move towards Java, finally there was a Knight in form of Webdynpro for ABAP that can bring back the glory and stability to ABAP developers career.
But the question is how to fairly decide how to go about preferring one language to another with the Webdynpro paradigm.

Why is WEBDYNPRO good for Java development?
Relatively easy and fast application development as compared to other usual J2EE options via use of visual models/code-editors. Comparable with Java Server Faces (JSF).
Generated applications independent of different UIs – like Web, Rich-clients, Mobile devices.
Scalability, robustness and performance are handled by the framework to a large extend
Code available for reuse and modification

What is SAP’s own take on Webdynpro for Java?
SAP’s is using Webdynpro for Java as a strategic tool to produces robust and highly scalable J2EE architecture applications. SAP is in the process of rewriting Employee Self Service (ESS) and Manager Self Service (MSS) applications using Webdynpro for Java. CRM 5.0 uses this functionality. Important SAP Portal applications like User and Role management transaction, Universal Work List (UWL) use Webdynpro for Java.

What are the downsides of Webdynpro?
Framework proprietary to SAP – as opposed to any standard J2EE framework (like Java Server Faces)
Not complete freedom to design user interface elements as only specific objects and their properties can be manipulated
Not possible to include application data ‘scriplets’ into HTML markup
Cannot use Javascript, DHTML, etc. – so limited freedom to do frontend screen design (as familiar to web developers)
Custom Style-sheet integration

Training implications?
For Webdynpro for Java – there is a learning curve for Java developers, not to mention a very steep one for ABAP developers
For Webdynpro for ABAP – its other way around – easier for ABAP developers (especially if they are experts in Object Oriented (OO) ABAP). A Java developer would be wasting time learning Webdynpro for ABAP.

How about promote to Production?
Webdynpro for Java uses NWDI – which is new in SAP shops, but nevertheless nothing but a version control system. If NWDI is already setup well and working well, its not such a big deal doing sensible promote to production of Webdynpro for Java code.
Webdynpro for ABAP uses SE80 and Promote to Production is integrated with SAP’s transport management system. Which is especially good for projects and organizations which are already familiar with TMS and use it to control project and release builds. Really a big plus on the side of Webdynpro for ABAP!

Performance, scalability and robustness?
While there is no comparison to these parameters when it comes to standard ABAP based development based on Basis kernel, when it comes to handling http based applications, large scale applications are not proven on the web server of the ABAP stack. So there are bound to be issues with that. Some of these weaknesses could be manifesting themselves in SAP’s own decision to use Java application server (using Webdynpro for Java) in products like ESS, MSS, SAP Portal admin apps, CRM, etc.
So while it may be viable to use Webdynpro for ABAP as a platform for low use internal web applications in a company, for truely robust and scalable applications, perhaps Webdynpro for Java is a better choice. In the end, these apps are hosted on a standard J2EE server that is compliant with standards of the J2EE world. It is relatively easy for SAP to leverage or adapt the advancements made to the technology by the likes of companies like SUN, Oracle or IBM for the Java stack, when compared to its own investments that SAP needs to make for any improvements to the ABAP stack (especially the web side of it). And of course, there are not many people who would doubt the J2EE architecture on the parameters of scalability and robustness.

Which skill set is more expensive and how to set up the Netweaver development team?
Easy availability of Java skills is an important reason for SAP to have gone into the Java direction as such. Having said that, there are still a plenty of ABAP developers out there and they are still going to be very relevant to SAP’s development world. Leave aside a handful of the new web based applications, and the core of SAP’s revered ERP app is still based in the ABAP kernel. To elaborate ECC x.0 is still nothing but a R/3 application suite at the core of it (actually a 4.6c based). So, have no mistakes – ABAP is still going to be very very core to any SAP implementation or upgrade (remember, Web apps of any kind typically use RFCs that are still written in ABAP). The jury is out there only for the (so far) perepheral applications – but that is kind of where the actual growth is. At that end of it, its perhaps the low cost of Java skill set that will come to have a role to play at that end.
So if you have an army of ABAP developers, would you rather have them do the core ECC related work, and have a handful of them move into the Webdynpro world with some additional tooling in Webdynpro for ABAP? Or, its move prudent to start injecting in skills in Java and build a parallel but complimentary team that is expert in Webdynpro for Java? Perhaps there is no getting away from latter if ESS, MSS and Portal are in scope of your applications. Given that, it may not be a bad idea to start building the Java skills. Get them from outside or have some of the ABAPers retool themselves (which by the way, is the best place to live in if you are a developer in the SAP world). In fact re-tooling as a Webdynpro for Java developer is easier for an ABAPer than retooling into JSPDynPage or JSP.
Companies would like to dabble with webservices, especially if Duet, xApps or Adobe integration is out there on the horizon. Reality is all this new world is really based on Webservices and SAP’s bet at that point is on the J2EE enabled webservices. So perhaps there is no escape from having Java skills in your backpocket. Given that is the future direction, why take a stand against it – which means its time to be open about Java skills. And that being true, it becomes easier to give a verdict on the side of Webdynpro for Java (as a corollary).

11/29/2007 – SAP’s latest Enhancement Package 2 for ERP 6.0 has ESS 1.2 in which a handful of ESS modules, like Travel and Expense, have been rewritten in Wedynpro for ABAP. Functionality is almost same. But does speak to the direction in which SAP may possibly be going. That is use Wedynpro for ABAP for functions that are only dependent on backend SAP.

SAP has augmented SAP NetWeaver Visual Composer’s capabilities with the ability to render the resulting models into Flex. Now Adobe has come out with its next-generation client Apollo that will extend the reach and capabilities of today’s Rich Internet Applications, freeing them to run outside the browser, on desktops. Project Muse is the result – has robust “thick client” capabilities that seamlessly consume and interact with web-based “thin client” capabilities. That is, it basically replaces a browser to see web content in, and that with a very rich client interface (read Flash like).
With Muse, SAP users will still get all the functionality they have today in SAP GUI and all SAP GUI screens will work perfectly inside Muse. End users will see their ESS/MSS and other SAP Portal content being exposed through Muse. So would an Adobe document or an Excel sheet, or Webdynpro app, Visual Composer screen, or even a plain html page. Muse is really the shell around the actual application or content. But its not a dumb shell. It will keep the context of the screen being shown within its framework so that, for example, a guided procedure can be shown.
Adobe’s Apollo has gone into the Alpha release on March 19, 2007. And Muse is build on that framework. At Apollo matures, expect Muse to grow as well.икони

It looks like many many more! While it seems like SAP is going places with its mySAPERP 2005 suite, the fact of the matter remains that the core of its business application suite (sans some new products like the Portal. XI, or CRM) would still be based on the plan old ABAP Kernel. Which means that users will still access the backend SAP functionality through the ol’ and familiar SAPGUI – which is a heavy client based GUI. Application Core really still is a much stabilized and solidified core that last came with R/3 Release 4.6C.