he Enterprise Portal (EP) is SAP’s corporate portal application that runs primarily on its own J2EE-certified Web application server. Java iViews, the portal components (or portlets) in SAP, deliver business content to the portal user via integrated views of backend systems. Figure 1 depicts the SAP EP populated with a collection of business content.

Figure 1: The SAP Enterprise Portal with Java iViews

Obviously, the EP supports access to SAP’s own enterprise applications, but iViews can also deliver content from other, third-party systems and remote databases. This article introduces the development platform for SAP’s Java iViews and demonstrates some of the key technologies to render data from both SAP and non-SAP systems.Key Technologies in SAP Portal Component Development
DynPage Framework
The portal components for the SAP EP are enterprise applications built on the J2EE platform. SAP’s Portal Component API includes a custom framework called DynPage, which supports J2EE application development for the EP. DynPage provides a collection of interfaces and abstract classes to structure the application architecture of portal components that require dynamic page processing. Essentially an implementation of the Service to Worker pattern, the DynPage framework organizes the Controller and Dispatcher classes and subsequently manages their interaction with JavaBeans and JavaServer Pages (see Figure 2).

Figure 2: The SAP DynPage Framework

The Portal Component API also contains a number of portal platform services that enhance SAP portal components with additional functionality, such as user personalization and access to remote data sources.

The iView Runtime for Java
SAP portal components are deployed as enterprise archives to the iView Runtime for Java (IRJ), the EP’s Java runtime environment. You can develop and build a portal component archive (PAR) file with any commercial IDE you can even use Apache Ant, the open source build tool. For the Eclipse Platform, SAP provides a custom plug-in that supports portal component development projects with wizards and templates based on the DynPage framework. The Eclipse plug-in also enables the hot deployment of portal archives directly to the IRJ.

(An add-on for Borland’s JBuilder is also available and offers similar support, but SAP plans to discontinue its development with the next release of the EP.)

Portal Development Kit
SAP also offers the Portal Development Kit (PDK) as an offline deployment environment. The PDK, which runs as a Web application in an Apache Tomcat servlet container, is built on top of the same IRJ infrastructure as the SAP EP. (Future versions of the PDK will run inside SAP’s J2EE server.) Since it also renders iViews with the look and feel of the EP, you can employ the PDK to develop and test portal components locally. In conjunction with the Eclipse Platform and the SAP plug-in, the PDK provides everything you need to begin working with portal components.

The PDK and Eclipse are both available for download, free of cost under their respective licensing agreements. You can get Eclipse at www.eclipse.org. The PDK, as well as its installation guide and the plug-in for Eclipse, is available at the SAP iViewStudio, where you can register to receive download access.

Your iViewStudio ID also allows you to participate in the PDK developers’ forum and gives you access to a series of technical white papers. Within the installed PDK environment, the Documentation and Examples links from the top-level navigation bar provide a rich source of documentation, tutorials, and example components.Rendering Data from an SAP Data Source
Portal components can access and query an SAP system with the SAP Java Connector (JCo) and the JCo Client portal platform service. You maintain the generic connection parameters of the SAP data source (for example, host name and IP address, client and system number) in the portal landscape via XML files. At runtime, the Dispatcher can use the JCo and JCo Client APIs to access these parameters and connect to the SAP system with them.

You can enable basic single sign-on (SSO) to the SAP system via a nonpersistent cookie, called the SAP Logon Ticket, which contains the digital certificate of the portal server and the user ID of the portal user. You must register the digital certificate and then import it to the SAP system. When using SAP Logon Tickets, the user IDs in the EP and SAP system must be the same, unless you also implement user mapping (which I describe in the next section).

Once a portal user is authenticated in the remote SAP system, the Dispatcher can execute an SAP BAPI (Business-API) or RFC (remote-enabled function call) directly in the backend system. BAPIs and RFCs expose the business processes and transactional functionality of SAP’s enterprise applications, and a large number of functions are available via standard interfaces. In SAP, BAPIs are realized within function groups, and individual methods in the interface are implemented as RFCs. Both BAPIs and RFCs are written in SAP’s proprietary ABAP programming language, and they can be executed by “remote” applications (i.e., applications external to the SAP system).

The standard BAPI I chose (BAPI_COMPANYCODE_GETLIST) is the traditional “Hello, World” example for Web-enabling SAP. The jcoClient object in the Dispatcher executes it via the jcoFunction object:

IFunctionTemplate jcoFunctionTemplate =   jcoRepository.getFunctionTemplate("BAPI_COMPANYCODE_GETLIST");JCO.Function jcoFunction = new JCO.Function(jcoFunctionTemplate);jcoClient.execute(jcoFunction);

The Dispatcher class then sets the return parameters of the function (here, a BAPI table parameter called COMPANYCODE_LIST) to the jcoTable object. Within the DynPage framework, you can maintain the BAPI table parameter as a JCOTableViewModel data model before setting it to a JavaBeans component (here, valueBean). The putValue() method binds valueBean to the “AppBean” name in an SAP-customized scope for portal components (Not shown here, of course, are the bean’s getter and setter methods for the model property):

JCO.Table jcoTable =    jcoFunction.getTableParameterList().getTable("COMPANYCODE_LIST");JCOTableViewModel jcoModel = new JCOTableViewModel(jcoTable);valueBean.setModel(jcoModel);putValue("AppBean", valueBean);

Finally, the Dispatcher determines the next JSP page and delegates processing control to it:

this.setJspName("SapView.jsp");

From the JSP page (here, SapView.jsp), you can access the bean and render the data model via SAP’s HTML-Business for Java (HTMLB) tag library. The model attribute of the tableView element serves to access the JavaBeans component (here, AppBean) and get the data from the bean property (model). The HTMLB tag library descriptor (htmlb.tld) defines the other attributes of the tableView element (You can find complete documentation for HTMLB within the PDK platform.):

As I mentioned in the previous section, you can build the PAR and deploy it to the PDK from Eclipse. Figure 3 shows the portal component as rendered in the ComponentInspector test environment of the PDK.

Figure 3: The “Hello, World” iView for SAP Access

Rendering Data from a Non-SAP Data Source
To demonstrate access to a non-SAP system, I use the open source MySQL database as the external data source. However, the programming constructs from this example are valid for all JDBC-compliant databases. As with an SAP data source, you must maintain the connection parameters for third-party systems and remote databases in the portal landscape XML files.

Instead of managing a special data model and using HTMLB to output on a JSP page, this example employs the Portal Data Viewer (PDV) service of the SAP API. The PDV also provides an implementation of HTMLB, but it can render tabular data directly in the EP without JSP programming.

While you can access non-SAP systems with SAP Logon Tickets, another method to enable remote authentication from the EP is via user mapping. In this process, the portal administrator can correlate (or map) a portal user to the ID and password for a remote system. A custom table in the EP’s LDAP directory server stores the mapped credentials. At runtime, the Dispatcher class can access this table via the SAP Portal Component API and retrieve the logon credentials. In the following code snippet, KEY is the destination system (here, the MySQL database) that is registered in the portal landscape:

bConn = new backend(KEY);broker.enrich(bConn);un = bConn.getUser();pw = bConn.getPassword();

Once the Dispatcher class determines the mapped user name (un) and password (pw) for the portal user, you can access the database and query it via the standard connection of the DriverManager:

Connection con =    DriverManager.getConnection("jdbc:mysql:///my_db",un,pw);Statement std = con.createStatement();ResultSet res = std.executeQuery("select * from my_table");

Finally, you set the result from the query (here, res) as the data source for the PDV service, which automatically renders the output in the EP:

ISource pdvSource = portalDV.createSource(request, res);portalDV.setSource(pdvSource);

Figure 4 depicts the PDV output of the MySQL database iView. In addition to its automated rendering mechanism, the PDV service supplies a number of standard features, including column sorting, tabulation, and user personalization.

Figure 4: The Database iView via the Portal Data Viewer

SAP for Web-enabled, Enterprise Java Apps?Who Knew?
The two examples in this article provide the simplest of introductions to portal component development for the SAP EP, but they are enough to get you started with SAP’s Portal Component API and the available development tools. While SAP may not be the first name you consider when it comes to Web-enabled, enterprise applications in Java, you might be surprised what you can learn.