Intro:
Org.A has undertaken a massive internal portal exercise in tune with the business needs spawning a host of business packages and custom webdynpros on the same. The need for EP to become the sole transaction processing interface integrated with back-end applications, BW, CRM and the underlying ECC 5.0 system is all pervasive as the users want to move away, completely, from the GUI world. Given the nature of the business, the immediate internal use is to span the continental Eurpoean region with a centralization of instances happening here as a move towards a shared services model for LATAM, APAC and NA. This discussion is the outcome of a week-long workshop conducted upon completion of a Proof-of-concept exercise at Org.A, which highlighted the key capabilities of the SAP enterprise portal to facilitate the larger objective of the portal project. The aim of the workshop for Org.A was to arrive at an optimal way forward post considering options across the key considerations to help Org.A arrive at an implementation landscape that is scalable, robust and in tune with Org.A’s future direction with this initiative and alignment with the SAP ESA roadmap. Many a times, an ESA/Solution Architect is posed with one question from all the client – “How do we move forward with our planned EP initiatives?” The answer to the same, I feel, is not so simple & straight-forward, as typically stated by the marketing folks of any System Integrator or a product vendor, who are keener on winning a new deal than putting together the pieces of the jigsaw puzzle for the customer in question. On the same token, the answer is also not hopelessly complex that it can be only deciphered by a rocket-scientist. It is a matter of a structured approach that Org.A will have to take to create a business solution with SAP NetWeaver as the platform. The end objective being “Creating a Business Solution”, keeping in mind the BIG picture & not taking the micro or a limited view of this task, that gets restricted by technological limitations. This blog is an excerpt from one of the discussions in an ESA workshop. The Business need:
If one were to define the initiative vision, it would be as a front-face that needs to provide a single point of entry for all Org.A users interacting with the enterprise to help speed access to information by providing a single intuitive user interface for all back-end applications, facilitating ease-of-use and integrating people, information and processes. The ultimate goal of this Org.A initiative would be to make all applications available through the enterprise portal to create a comprehensive collaborative platform for Org.A users as the internal portal and the extension of business processes to be made available through the external facing portal (EFP) for its business partners to improve supply chain efficiencies and compliance tracking and monitoring by migrating the existing www.Orga.com. Moving forward, the Org.A initiative should lay down the foundation for unified integration, anaytics and the creation of logical datamarts for the busines to accelerate the pace of business leveraging the ESA roadmap with the underlying SAP NetWeaver platform.
The Solution considerations:
Originally, the external facing portal's usage is more or less to facilitate the creation of a portal over the web - not that it finds much buy-in from the corporate IT folks within Org.A. Org.A sees no reason to have their own website on EP just because they are on SP14. Key concern that become larger-than-required discussions stem around performance over WAN, which might not be acceptable to Org.A per internal standards. On the same token, with the useage of light-weight components as propogated by SAP enabling caching of pages for faster download of pages and more importantly - Caching the navigation hierarchy of nodes instead of creating it again when ever it is accessed. Of course, Org.A is also looking at additional features like mouse-over for the links and quick-links to specific pages which are most often used. Personalization takes precedence over many issues owing to a majority of the corporate IT group stemming from the BroadVision days. Something that the EFP may not be able to take on head-on today, there are more nay-sayers than the ones who agree. As the Light Framework may not support the use HTMLB, EPCM, and Java Script (Options can dictate how this can be done), the solution consideration demands the use of alternates as well. Another point of consideration that comes up often is the support of browsers based on PAM slides, some of the users were of the opinion that the pages would not show up in non-supported browsers. What is needed here at Org.A is to leverage the internal development that is being done for the internal portal for the business users at Org.A be exposed to a certain extent to the world outside. Now here comes a clincher - if you are to expose key transactions of your processing system over the internet, would you end up creating named users in EP for the externals? If no, how do you create an audit trial for them? Clearly, these points of concern or key solution considertaions are not points that a Solution Architect can brush off and proceed with designing a solution that would map onto the ESA roadmap. These are probably 1% of the concerns that would be prevalent in the client community.
The Solution Options:
Of course there is always the recourse of using the SAP NetWeaver application server as any other app server and creating your own components using java to create an EFP, completely doing away the need for EFP with EP. But this is not an option that would really help alogn Org.A with the SAP roadmap or the ESA initiatives, its more of killing an existing application and creating your own Frankenstein monster. Well, does it justify a discussion? Yes, it does, but with the intent of shooting it down. It becomes just another app server usage approach to build an application masquerading as the EFP. This falls way off-whack with an ESA roadmap. And the same can also be thought about as an approach towards building these components for the internal portal as well. Option 1: Application build: The Build Approach. Originally coined as a rip-and-replace approach, as discussed above this option may make a lot of sense if this is to be treated as a portal application and not built as a web-application without EP. Here, one may debate over the re-building from scratch a .Net or a J2ee application from scratch as a portal application on the SAP NetWeaver platform frontended by EP and warrant the useage of GP with CAF in tune with the ESA roadmap.
Option 2: Application migration: The porting Approach. In this option, the existing J2ee application archive would need to be deployed on WAS and customized, build the UI layer with the light-weight framework with EP and call the application functionality using either web-services/APIs more in-line with a PBNW approach. The build apsect is done away with.
Option 3: Application Integration: URL iView approach. In this option, call the existing application as a URL iView. A no-brainer.
Option 4: Standalone in DMZ: In this option, for an EFP, work it using option 1 or Option 2, but completely disconned with the core ECC engine but with a look and feel of the internal transaction screens of the webdynpros or business packages, but as a dummy application with its own database. For example, ME21N as a similar look and feel as the internal application via the EFP and having a mail notification to the concerned sales person for the sales order creation via VA01 for the sales area. The idea is to later on manually feed in the sales orders or lay the path for the useage of XI to connect to this EFP application and create the sales orders in VA01.
Outro:
The move with an EFP has to be a much thought-through solution approach considering variuos aspects including audit trial for external users and implications on licensing. The roadmap that one would want to believe with the EFP could be what we see today with the EFP as the first step in infancy. New light-weight components as the IFP route, but creating new document types for external users with different configurations as needed at the ECC 5.0 layer. (E.g. VA01 call new order type with simplified pricing procedure and different number ranges for Sales Order, delivery and Invoice). Whether you follow Option 1 or Option 2, Org.A could introduce this as part of the ECC 5.0 configuration. Going forward, the EFP would host light-weight applications for Org.A, finally, paving the way for composites towards B2B with the EFP. I could be wrong, but maybe, the very factors that led to a B2B bust with a top-down disjoint way of doing buisness over the internet may just become a reality with the bottom-up approach with SAP NetWeaver and ESA. But that is for an analyst/soothsayer to predict.
