Applications created using J2EE architecture are supported almost universally. The favorable result? Developers don’t have to write different versions of the same application for various platforms. Five steps are required to run a J2EE application successfully on the SAP NetWeaver platform.
Step 1: Port the application to the J2EE engine
First of all, it’s important to evaluate the application that is to be migrated – its environment, its architecture, and how well it complies with J2EE standards – to determine the risks and costs of the migration. A premigration test then checks all relevant aspects of the application, both functional and non-functional. The outcome of the tests sets the benchmark for the postmigration tests, which ensure that the application still works correctly after the migration.
SAP supports migration with several tools (combined in the J2EE migration kit) that simplify migration to the J2EE platform and safeguard investments for companies that have already successfully migrated their existing products to the SAP NetWeaver platform. SAP NetWeaver Application Server (SAP NetWeaver AS) serves as the basis of the migration kit. Especially suitable for large applications with many modules and deployment units, the tools can considerably accelerate the important migration steps and help avoid error-prone manual work.
To realize J2EE applications in am SAP environment, users can employ the J2EE engine within SAP NetWeaver AS. As an integral part of the SAP environment, the engine implements the J2EE standard, which SAP has equipped with central developments like the following:
- Java connector, responsible for the connection of ABAP and Java
- A database-independent abstraction layer for persistence, named Java persistance
- The ability to easily develop user-friendly Web front ends with Web Dynpro
- Comprehensive J2EE development
Step 2: Integrating the application with SAP NetWeaver Portal
SAP NetWeaver Portal enables a user to bring individual Web applications into the portal as an integrated view (iView). The user can then display and use the applications from a page in the portal along with other iViews from other applications and systems. Different types of iViews allow the user to embed different types of content from diverse information sources. For example, Java iViews are content that is typically written in Java Server Pages (JSP) or Java and that run in the Java runtime. In addition to using the Java iViews provided in business packages from SAP, a company can also develop its own iViews in Java or JSP. Another example would be the use of iViews to wrap existing Internet and intranet sites with Web-based URLs. In this case, the application runs on the same or a different application server and the iView provides a container to wrap the content.
Java iViews are based on HTML-Business for Java (HTMLb) technology and provide several useful functions to integrate with the services of SAP NetWeaver Portal. Java iViews might be the best choice when an application is developed from scratch, with SAP NetWeaver Portal as the primary target platform. When an existing application is migrated to the portal, the most common challenge involves how to map and replace the existing navigation framework with portal navigation. Unfortunately, there is no common solution to this problem because of the different ways of implementing navigation in the original application.
In many cases, additional requirements exist to run applications under SAP NetWeaver Portal and to provide support for a stand-alone mode. In such cases, implementation requires the following major steps. First, because SAP NetWeaver Portal is responsible for managing navigation, headers, and so on, a content package containing iViews, pages, workspaces, and roles must be created. Second, the Java iView can be used as a wrapper for application components. With this approach, the Java iView will dynamically add certain parameters to the URL at runtime, providing context information that includes the selected theme to support the look and feel required by SAP NetWeaver Portal. Third, application components must be capable of understanding context parameters that also indicate that the application runs under the portal. Configuring content packages does not require Java or other programming skills. This work could be performed by a person with good business-analysis skills. Standard portal functionality can control visibility and access rights for such packages.
Step 3: Matching the SAP visual appearance
Supporting the proper styles might become a challenge when porting an application that was initially designed for a different platform. The situation becomes even more complicated when the application must support changing portal themes, such as change-color schema.
SAP consistently uses the same visual appearance and styles in all Web-enabled technologies. For example, an application created using HTMLb and a Web Dynpro application that uses a client-independent programming model for development on the SAP NetWeaver platform will have the same look and feel. The main challenge of the look-and-feel dilemma involves significant effort that often requires brute-force styles of adjustment. Implementation of client-side and server-side style sheet conversion can support the look and feel. The performance of the client-side solution depends to a great extent on the characteristics of the client machine. That’s why EPAM Systems, a software development partner of SAP, proposes a server-side solution as more scalable.
The server-side approach developed by EPAM Systems implements the following schema:
- Automatically retrieve the current theme through the portal application programming interface (API).
- Distinguish between standard SAP and custom themes.
- Apply pregenerated cascading style sheets (CSS) for standard themes.
- Dynamically apply theme styles to application pages at runtime.
Two steps are required to implement a server-side solution. The first creates a conversion matrix or style guide from the application-specific style sheet to the SAP theme. The next step implements the HTTP filter, which processes HTML output and makes replacements based on the matrix or schema defined above.
Step 4: Implementation of single sign-on for the application
Single sign-on (SSO) is a key feature of SAP NetWeaver Portal. It enables the user to access iViews without having to repeatedly enter authentication information. The user has to log on to the portal only once, and all the integrated applications can use the same credentials. SAP NetWeaver Portal can be configured to issue a ticket that is then used by all SAP solutions or to use tickets issued by other systems. It also features very flexible support of different scenarios for SSO.
In the ideal world, the portal and the back-end systems would use the same user IDs. In such a case, no user mapping is required and configuration is as simple as configuring the portal server for SSO with SAP logon tickets and configuring SAP solutions to accept and verify the tickets. But in the real world, SAP Enterprise Portal is often used as an integration point to consolidate access to existing back-end systems that often use different schemas for user IDs and authentication. To solve the problem, the portal introduces user mapping capable of providing a different ID and password for the back-end systems. Such mapping can be based on an SAP logon ticket to an external system or on providing a user name and password for external applications that cannot accept and verify SAP logon tickets.
Step 5: Integrating user management with SAP
Applications to be migrated into the SAP NetWeaver AS environment often have large security databases containing user-password combinations and assignments of users to groups or roles. When the user management engine (UME) is applied as the primary mechanism for centralized user management, the question arises of whether and how to reuse existing repositories or migrate them into the UME. The choice here is between a programmatic approach and a data import. In general, three UME integration scenarios can be selected, depending on the business scenario and application landscape. Using the UME significantly reduces the cost of maintenance by allowing reuse of SAP NetWeaver Portal user information in the J2EE application.
Porting the existing application to the J2EE platform provides a standardized user experience for all corporate applications. The enterprise benefits from central user management and from more efficient integration of the applications with the existing SAP landscape. Moreover, porting minimizes costs by running all the applications on the J2EE platform. For new J2EE application development, SAP offers a model-driven, highly productive development environment that uses visual tools to design and reuse UI components and minimizes coding.