Prologue
Just the other day, I had a very interesting discussion with a client. They have it all nailed down, they know what they want, and a speel on the ESA approach would just not fly. More important than the ESA roadmap or any upgrade discussions for that matter, the discussion was very much centered towards the approach they are planning to adopt. Web Dynpros. The choice of technologies comparing web dynpros vis-à-vis other technologies was the centre of the discussion. Instead of taking an ESA Architect role for this client, the approach had to be more towards the standards required for developing new components as part of a client portal effort for an SAP project. Standards that are required to ensure that all newly developed components:
- Satisfy the identified business requirements
- Provide a cohesive solution across all components
- Leverage SAP functionality whenever feasible
- Minimize coding effort and on-going support needs
- Reduce potential upgrade issues
- Make the development consultants driven towards a “framework” approach
- Align with SAP’s internal development direction whenever possible
- Cover-up for areas that are not addressed by the Enterprise Portal solution fully mapped to business needs
- Create a Content Management tool for the customer with embedded workflow for on-the-fly creation of content
- Create key transactions as web dynpros with user-friendly UIs
- Call iViews from EP into a Sharepoint server as portlets
…….to name a few!
The policies and procedures architected here may be used by the developers involved in the portal project for the client, and can be later on built into the guidelines for the development standards to be used in the project.
The role of a Solution/ESA Architect starts on a different note in a situation like this to lay down a strong foundation for the client. Certainly not the classical definition of an ESA Architect.
The Project Overview
The client is in the process of rolling out SAP based functionality to new users within their organization. Running on R/3 4.6c with BW 3.1 as the core, add-on modules of CRM and APO are to be considered. The aim is to upgrade to mySAPERP 2004 is on the cards and the need to quickly get a few winning projects up and running for suppliers and employees. Now, the question is – what is the choice of technologies that exist and why should web dynpros take the spotlight? And most importantly, how do you get new users on board SAP with this initiative?
These new users:
- Are not necessarily familiar with SAP transactions
- Do not have much inclination to learn a new system
- Cannot spend much time on SAP R/3 Usage trainings
- Only require access to specific portions of SAP functionality
- Require a data entry and retrieval process that is as customized to the necessary internal processes as possible
- Need attractive business graphics to be made sticky
- Should not be required to load any SAP specific software on their individual desktop/laptop computers.
- Are key to funding new projects for IT
To achieve these goals, The client intends to utilize the following SAP components:
- Enterprise Portals 6.0 SP12 or Sharepoint server or both
- Web Application Server 6.40
- R/3 4.6c & BW 3.1
- An ITS to deliver SAP GUI for HTML Transactions
With a myriad of applications in the system landscape, the key processes mapped out looks something like this:
- Thus, the specific goals of this project are to:
- Simplify and streamline a number of SAP transactions for use by employees
- Render a cohesive existence of the SAP application landscape with the rest of the applications
- Deliver the simplified transactions over the Enterprise Portal
- Render a POC approach with the same to move applications out towards SAP Business suite
- Take on an ESA roadmap approach once this initiative has been showcased
The general goal of this project is to satisfy the business requirements while minimizing the total cost of ownership (TCO) for the solution and allow this showcase to enable the systemic migration of 3rd party and legacy applications in the landscape towards the SAP NetWeaver roadmap for an ESA drive in the near future. Each suggested process enhancement must be evaluated on the basis of the cost to realize the solution versus the targeted business benefit. The goal? Lower TCO. The start point for the same becomes freezing of the development approach.
Available Development Techniques
The following solutions and development techniques are under discussion:
1. Web Dynpro
2. BSP
3. Java Server Pages (JSP)
4. SAP Dynpro conversion tool in ABAP
5. Visual Composer
6. Predefined Business Packages from iViewStudio
7. ASP
8. The ITS way
Each of these solutions has potential advantages and disadvantages when evaluated in light of the client’s business requirements. Let us take a Solution/ESA Architect’s view of the advantages and disadvantages of each approach or solution.
1. Web Dynpro
Web Dynpro, built on SAP’s Web Application Server with its core as the Model-View-Controller (MVC) programming model, designed to force a separation between the user interface components of an application and the business logic, driving technical consultants towards a framework-driven approach bringing in more uniformity of approach. Quick look:
- Model – The business programming logic for an application
- View – A layout of components on a screen. This portion contains all the visual elements that will be on the GUI
- Controller – Embodies the logic necessary to flow between the various views within an application and interact with the model. This layer does not contain any business logic, but rather ties the views together and interacts with the model
- Web Dynpro technology embodies the MVC programming model and contains the following high-level tools to aid in developing a business application:
- Automatic support for importing a model from a web service, function group in SAP, a business object in SAP, etc.
- Visual tools for laying out the views, visual tools for binding elements to the context of an application, and automated generation of certain Java Connector elements necessary to communicate with SAP. Fairly straight-forward and can be rendered from the Java stack or the ABAP soon for the client with SAP NetWeaver 2004s .
- An enhanced ABAP editor that looks so similar to the NDS
- In line with SAP’s development approach, brings forth device indepenance for mobile applications in the future.
Advantages:
- The way forward for developing web pages in SAP
- Forces good programming with a framework approach
- SAP’s internal user interfaces being built using Web Dynpro
- Development of the model components build a layer that can be accessed easily for automated processes
Disadvantages:
- Using the same with the ABAP stack is not something that has been tested by us as an SI or by the client.
Java Server Pages (JSP)
Java Server Pages have always been a tried and tested approach for building web content that uses Java and JSP based skills. From what we gathered internally - debugging, testing, error-handling had been an issue while building the same with NDS initially. Things got better with each passing SP.
Business Server Pages (BSP)
Business Server Pages are SAP’s first cut method for building web content leveraging the client’s existing investment in ABAP knowledge. Although this method does not have some of the advantages of the newer Web Dynpro methods, content designed using BSPs is fully supported by Enterprise Portal. Many existing business packages available for the Portal were designed using BSPs. Going forward, this may be found to be useful to leverage existing investments (with low probability)
SAP Dynpro from ABAP stack
Convert the client’s existing SAP Dynpro programs to Web Dynpro metadata. This ability promises to speed the development of Web Dynpro applications because the converted metadata can be used as a starting point for simplifying and customizing the standard SAP Dynpro for the web, guaranteeing to lower development costs and leverage past investments. But this would hold good in the future environment of the client, doesn’t hold good on an R/3 4.6c or even with a Jco connected WAS 6.40 to the same. Either Enterprise or mySAP2004 would have made this a great candidate.
Visual Composer
A great tool that uses a purely graphical approach to build Enterprise Portal content and model a business transaction without requiring any code to be written manually. VC produces a set of metadata representing the transaction. This metadata is then used to generate Java code that can be used within the Portal. With the newer version of the VC touted to be advanced much further, this may be looked upon today as more of a UI-building tool. Good for design-time. Only for displaying data from SAP systems (same crib as the unification server).
An approach to a Solution
In order to achieve our project goals, a delicate balance between the ideal solution from a development perspective and the cost of delivering that solution must be achieved. The identified solution must satisfy the identified business requirements, but the method used to develop that solution should also attempt to minimize the TCO of the component.
The analysis of the appropriate development method can be complicated and often hinges on many external factors and assumptions. The following flow chart, for deciding how to approach a given development request, seeks to standardize the general selection process for the a client project. It is understood that individual development considerations may necessitate deviating from the generally accepted selection process. (An example of this deviation may be external forces such as the necessary development system for a given approach not being available.)
Assumptions:
- It will be possible to use an ITS server to deliver SAP GUI for HTML transactions to an end user.
- The backend R/3 system will eventually be upgraded to WAS 6.40 to support converting SAP Dynpros to Web Dynpro metadata.
- The phrase “satisfy the business requirements” will include any special constraints applied by the business team to this project including (but not limited to) transactions being simple enough for the targeted end user and the cost of the solution not being prohibitive.
Points for Determining Appropriate Development Approach:
1. View the transaction using SAP Windows GUI. Does the transaction satisfy the business requirements? If yes, do not rule out ITS for this development.
2. Evaluate the cost and effort for doing the same with web dynpros – take a linear stand.
3. Is there a business package for the existing R/3 4.6c environment in Portal Content Studio that satisfies all the business requirements? Highly unlikely, but give it a shot. Else, you anyways have the web dynpro route.
4. Are there business packages that satisfies the majority of the business requirements? Either change your key project requirements or take a build approach.
5. Are most of the key identified transactions to be extended over the internet update or display only transaction? Try to start with more of display.
6. How much modification will the standard business packages have to undergo? Does it make sense to build web dynpros afresh?
The Web Dynpro Approach:
The models required to feed Web Dynpro can be developed in ABAP as either a function group or business object. Although SAP’s development environment does support writing base business functionality in Java, the functions for accessing the transaction data that would be chosen may have all been developed in ABAP. Here is a choice for the client - to do the development either in ABAP or in Java or for that matter, even to decide where most of the logic would be written on. It is a long-term strategic decision.
A potential lacuna to accessing the back-end system for everything - such as retrieving a list of possible values, or validating entries if the path of server-side scripting may adversely impact performance - is the load that is placed on the backend server for each call. To minimize this problem (where the LOV is constant or the performance drop is acceptable), services can be developed that retrieve the list of possible values from the backend SAP system when the portal is started up and then supply the possible LOV to the Web Dynpro components that may use the service. (If the list of values is dropped from memory for whatever reason, the service may need to be designed to reacquire the values from the backend system.) Of course, there are pros and cons to this approach as well and will depend on a host of other factors.
Epilogue
After an appropriate development technique has been selected for a given business requirement, a Solution Architect needs to consider several other factors to achieve the goals of the portal development and the road to ESA.
- Whenever possible, reuse components
- Whenever possible, the data necessary to control the transactions displayed on the portal should be maintained on the backend R/3 system.
- All development should maintain a strict separation between the business logic needed for a given transaction and the display logic.
- Whenever possible, avoid customization and custom-code
- Keep the ESA list of Enterprise services handy. I never thought that the ESA preview system could be of so much help.
Now that the road ahead with the SAP NetWeaver initiatives have been set, the next stop should be application, business, instance and system consolidation before the mySAPERP 2004 upgrade. The road to ESA will start soon the above project takes off.....
1 Comment
