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 =
JCO.Function jcoFunction = new JCO.Function(jcoFunctionTemplate);
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 =
JCOTableViewModel jcoModel = new JCOTableViewModel(jcoTable);
Finally, the Dispatcher determines the next JSP page and delegates processing control to it:
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.):
<%@ taglib uri="/SERVICE/htmlb/taglib/htmlb.tld" prefix="htmlb" %>
<jsp:useBean id="AppBean" scope="application" class="bean.SapBean" />
headerText="Hello-World Example for SAP Data"
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 |