SAP provides a J2EE-compliant Java application server, the J2EE engine. Porting an application to SAP NetWeaver helps shorten the development time for the new application, decrease maintenance costs, and integrate more efficiently with the existing SAP landscape.

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.

Integration with SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI)

J2EE technology provided by the SAP platform not only offers a convenient and highly efficient means of application development, but also provides the benefits of seamless integration with the existing landscape by using SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI). This integral component of SAP NetWeaver significantly improves the end-to-end integration process. It allows connectivity with all kinds of applications in a heterogeneous landscape. Users can connect to existing integrative solutions by using Java Message Service (JMS). MQSeries (the independent platform middleware software from IBM), or simple object process protocol (SOAP). Alternative ways of connecting include the reuse of existing technologies like J2EE connector architecture-compliant adapters (JCA), XSL transformation, and Java mappings.

The choice of SAP NetWeaver XI is also a step toward the future because all new SAP solutions will use SAP NetWeaver XI as a process integration platform and it is an integral part of open, enterprise service-oriented architecture (enterprise SOA) from SAP.

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 an 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.

EPAM Systems

EPAM Systems (www.epam.com) is a software development company that focuses on SAP NetWeaver development and integration services. With development centers in Hungary, Russia, Ukraine, and Belarus and client delivery and support centers in the United States, the United Kingdom, Germany, and Hungary, EPAM represents a global consulting and solutions organization that leverages the highly-skilled, cost-competitive resources of Central and Eastern Europe. The company provides a broad range of innovative application and product development, reengineering, testing, support, and consulting services for global 500 clients

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.

The three UME integration scenarios

    The j2EE application uses existing and proprietary user management, but shares the same user provider with the UME data source. This scenario can be implemented if a corporate LDAP is used to centralize user maintenance.
    The application is modified to get user information from the UME and delegate all the corresponding management functions to the user management functionality of the portal. This scenario is best suited to a newly written application, but it might be difficult to implement while migrating an existing system. Use of standard portal functionality for user management might be unacceptable from the business prospective. In addition, implementation of this scenario depends on UME functionality and it might be difficult to implement if support of different application servers is required. This scenario might also require migration of the existing user data to the UME.
    In many cases, creation of a UME data source is the best way to integrate user management functionality. If this scenario is selected, existing application users will be exposed to the portal and combined with the user information provided by the different UME data sources. The main benefit of this solution is that the application can keep the existing UI for user management and, if required, can use it independently of the SAP landscape. Another option for data import can be realized with the user management administration console, a Web application that comes preinstalled with SAP NetWeaver AS.

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.

For further information, please contact: press@epam.com