SAP NetWeaver 04

SAP Exchange
Infrastructure 3.0:
Java Proxy Runtime 3.0
- J2EE Integration
Document Version 1.1 May, 2005

SAP AG
Neurottstrae 16
69190 Walldorf
Germany
T +49/18 05/34 34 24
F +49/18 05/34 34 20
www.sap.com

Copyright 2005 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in
any form or for any purpose without the express permission of
SAP AG. The information contained herein may be changed
without prior notice.
Some software products marketed by SAP AG and its
distributors contain proprietary software components of other
software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered
trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex,
MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries,
pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner,
WebSphere, Netfinity, Tivoli, and Informix are trademarks or
registered trademarks of IBM Corporation in the United States
and/or other countries.
Oracle is a registered trademark of Oracle Corporation.

countries all over the world. All other product and service names
mentioned are the trademarks of their respective companies.
Data contained in this document serves informational purposes
only. National product specifications may vary.
These materials are subject to change without notice. These
materials are provided by SAP AG and its affiliated companies
("SAP Group") for informational purposes
only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to
the materials. The only warranties for SAP Group products and
services are those that are set forth in the express warranty
statements accompanying such products and services, if any.
Nothing herein should be construed as constituting an additional
warranty.

Disclaimer
Some components of this product are based on Java. Any
code change in these components may cause unpredictable

UNIX, X/Open, OSF/1, and Motif are registered trademarks of

the Open Group.

and severe malfunctions and is therefore expressively

prohibited, as is any decompilation of these components.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,

VideoFrame, and MultiWin are trademarks or registered
trademarks of Citrix Systems, Inc.

Any Java Source Code delivered with this product is only to

be used by SAPs Support Services and may not be modified or

HTML, XML, XHTML and W3C are trademarks or registered

trademarks of W3C, World Wide Web Consortium,
Massachusetts Institute of Technology.

altered in any way.

Java is a registered trademark of Sun Microsystems, Inc.

Documentation in the SAP Service Marketplace

JavaScript is a registered trademark of Sun Microsystems, Inc.,

used under license for technology invented and implemented by
Netscape.

You can find this documentation at the following address:

http://service.sap.com/xi -> Media Library ->
Documentation

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver,
and other SAP products and services mentioned herein as well
as their respective logos are trademarks or registered
trademarks of SAP AG in Germany and in several other

menu names, paths and

options.

Typographic Conventions
Type Style
Example Text

Represents
Words or characters that
appear on the screen. These
include field names, screen
titles, pushbuttons as well as

Cross-references to other
documentation
Example text

Emphasized words or
phrases in body text, titles of
graphics and tables

EXAMPLE TEXT

Names of elements in the

system. These include report

names, program names,
transaction codes, table
names, and individual key
words of a programming
language, when surrounded
by body text, for example,
SELECT and INCLUDE.
Example text

Screen output. This includes

file and directory names and
their paths, messages,
names of variables and
parameters, source code as
well as names of installation,
upgrade and database tools.

Example text

Exact user entry. These are

words or characters that you
enter in the system exactly
as they appear in the
documentation.

<Example text>

Variable user entry. Pointed

brackets indicate that you
replace these words and
characters with appropriate
entries.

EXAMPLE TEXT

Keys on the keyboard, for

example, function keys (such
as F2) or the ENTER key.

Icons
Icon

Meaning
Caution
Example
Note
Recommendation
Syntax

Java Proxy Runtime 3.0 - J2EE Integration

1 Preface..........................................................................................5
2 J2EE Integration ..........................................................................5
2.1 Prerequisites .......................................................................................... 6
2.2 Installing Java Proxy Runtime as Part of the SAP XI 3.0 Adapter
Framework ....................................................................................................... 6
2.3 Configuring Java Proxy Runtime ............................................................ 7
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6

2.4
2.4.1
2.4.2
2.4.3
2.4.4

2.5
2.5.1
2.5.2
2.5.3

2.6
2.6.1
2.6.2
2.6.3

Configuring JPR: jpf.properties (Optional)..................................................................7

Connecting to the SLD: dbconnect.properties (Obsolete)..........................................8
Identifying the Business System: technicalID.properties (Obsolete)..........................8
Logging and Tracing: logging.properties (Obsolete) ..................................................8
Locating Client Beans: jndi.properties (Obsolete) ......................................................9
Assigning Beans to Interfaces: jpf.registry (Mandatory).............................................9

Using Outbound Interfaces................................................................... 10

Application Scenario.................................................................................................10
Application Deployment............................................................................................11
Programming Interface .............................................................................................13
Acknowledgments ....................................................................................................14

Using Inbound Interfaces...................................................................... 17

Application Scenario.................................................................................................17
Application Deployment............................................................................................18
Programming Interface .............................................................................................20

Inbound Proxy Server........................................................................... 20

User Groups and Security Roles ..............................................................................20
Maintaining the JPR Registry ...................................................................................21
Servlet Status ...........................................................................................................23

3 Sender Service Configuration ..................................................23

4 Receiver Communication Channel Configuration ..................24
5 Monitoring ..................................................................................24

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

1 Preface
This document describes how the Java Proxy Runtime (JPR) of SAP XI 3.0 SPS4 or
higher integrates into SAP J2EE Engine 6.40. Two scenarios are discussed; an
outbound scenario and an inbound scenario (also known as client and server
scenario).
In the outbound use case, an application uses proxy beans to send request messages
and, in some cases, to receive response messages. The proxy beans, in turn, call the
Java Proxy Runtime to connect to the Messaging Service (MS) of the Adapter
Framework which sends the messages to the Integration Server.
In the inbound use case, a proxy server application, which essentially consists of an
EJB bean that processes incoming XI messages, is provided. This bean acts as a
listener to the Messaging Service, which receives the messages from the XI Integration
Server. The proxy server bean, in turn, calls the application bean registered for the
particular inbound interface.
For each use case, certain minimum configurations are required to provide JPR and
MS with the data necessary to connect to the SAP XI landscape.
Purpose and Disclaimer
The purpose of this document is to present various information that pertains to the
usage of SAP XI Java proxies on the SAP J2EE Engine, together and in one place. It
by no means replaces the SAP NetWeaver documentation on the SAP Help Portal,
(http://help.sap.com) or other related documents, such as the installation or
configuration guides.
Although care has been taken to provide correct and current information, the author
cannot take responsibility for damages resulting from applying this information.
The information contained in this document is subject to change or addition without
advance notice.
Further Information
For further information on the Java Proxy Runtime, consult the following information
material:

SAP Help Portal at http://help.sap.com Process Integration SAP NetWeaver

SAP Exchange Infrastructure Runtime Connectivity Proxy Runtime Java
Proxy Runtime

Configuration Guide SAP XI 3.0 on SAP Service Marketplace at

http://service.sap.com/instguidesnw04 Installation SAP XI (see chapter Java
Proxy Runtime (JPR))

Installation Guide SAP XI 3.0 on SAP Service Marketplace at

http://service.sap.com/instguidesnw04 Installation SAP XI.

For further information on the J2EE Engine, see SAP Help Portal at http://help.sap.com
Application Platform Java Technology in SAP Web Application Server
Development Manual.

2 J2EE Integration
The Java Proxy Runtime (JPR) is typically installed on a "Web AS Java system that is part
of the SAP XI 3.0 technical system landscape. Such a Java business system consists of an
SAP J2EE Engine 6.40 and one or multiple J2EE applications that use Java proxies and JPR
to connect to the Integration Server.

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

2.1 Prerequisites
JPR is currently only supported on SAP J2EE Engine 6.40 SP5 or higher. Any references to
a J2EE server therefore apply to this particular implementation.
JPR requires the Messaging Service (MS) of the Adapter Framework to be installed on the
SAP J2EE Engine. Both JPR and MS are part of the SAP XI 3.0 Adapter Framework (AF).
Only with MS can JPR guarantee the quality of service Exactly Once (In Order) needed for
asynchronous messages. MS provides queuing, persistency, and monitoring of messages on
the application system. As of SAP XI 3.0, the message monitoring functionality has been
integrated into the Runtime Workbench (RWB).

As of SAP XI 3.0, JPR no longer supports J2SE (that is, stand-alone) Java
applications1.
The bean classes generated for outbound and inbound proxies are EJB 2.0 beans.

In this document, the Server Work Directory of the SAP J2EE Engine refers to
the following path:
- On stand-alone server: <SERVER_HOME>\alone
- On Cluster
<SERVER_HOME>\cluster\server0
<SERVER_HOME>\cluster\server1 etc. (on Cluster)
Note that <SERVER_HOME> denotes the root path to the SAP J2EE Engine, for
example C:\usr\sap\J2E\JC00\j2ee.
In addition, the Global XI Directory refers to the following path:
C:\usr\sap\J2E\SYS\global\xi
This path can be reached by all servers in a cluster.

2.2 Installing Java Proxy Runtime as Part of the SAP

XI 3.0 Adapter Framework
Java Proxy Runtime (JPR) utilizes the Messaging Service (MS) of the SAP XI 3.0 Adapter
Framework (AF) to ensure the quality of service Exactly Once (InOrder) for asynchronous
messages. MS handles persisting outgoing messages and incoming messages and where
applicable, reschedules messages that can not be delivered. MS also provides a browserbased user interface to monitor the state of outgoing and incoming messages.
The services provided by MS require connection to a database, which can be the same
database that is used by the application. MS currently supports the following databases:
SAPDB, Oracle, and Microsoft SQL Server.
The Adapter Framework (AF) installation procedure has changed every once in a while over
the past Support Package Stack (SPS) releases. Since AF greatly depends on other services
of the J2EE Engine, it is recommended to always install AF on the corresponding SPS level
of the J2EE Engine. As of SPS09, which is going to be the General Availability (GA) release

In SAP XI 2.0, an exception was made for outgoing synchronous messages of J2SE
applications. This is no longer the case.
6

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

of SAP XI 3.0, the SPS numbers of software components such as XI and the J2EE Engine
will be the same. This make it easier to identify corresponding SPSs.
To install AF, including JPR and MS, you can use a unified installation procedure for the
Software Deployment Manager (SDM).
To install AF individually, the following Software Component Archives (SCAs) and Software
Deployment Archives (SDAs) must be deployed using the SDM:

Two SDAs that contains external adapter libraries, which for licensing reasons, cannot
be delivered to customers by SAP.
aii_af_ra_ms_sonic_client.sda
aii_adapter_jms_provider_lib.sda

Two SCAs that contain AF libraries, services, data base tables, and applications; nn
represents the SPS number, x represents the patch level, for example,
SAPXIAFC09_0.sca
SAPXIAFCnn_x.sca (contains AF core libraries and services)
SAPXIAFnn_x.sca (contains AF applications)

These SCAs require the following development components, which are part of the standard
SAP J2EE Engine:

com.sap.guid (GUID classes)

com.sap.lcr.api.cimclient (SLD access (formerly known as LCR))

com.sap.mdi (SAP metadata interface)

com.sap.mw.jco (SAP Java Connector)

com.sap.rprof.dbprofiles (Exchange Profile)

com.sap.tc.Logging (Logging classes)

sapxmltoolkit (XML libraries for parsers etc.)

security.class (IAIK security classes)

J2EEStandard (J2EE's Servlet classes)

2.3 Configuring Java Proxy Runtime

The following sections describe which configurations of JPR can and must be made.
Configurations used to be, and in some cases are still, made in files and repositories. This
section describes the alternative you can now use in cases where a file is marked as
obsolete.

2.3.1 Configuring JPR: jpf.properties (Optional)

Various configurations of JPR can be made by using entries in the file jpf.properties in
the XI Global Work Directory.

It is not recommended to use this file in a productive environment. It should only

be used to temporarily superimpose configuration values normally retrieved
from the Exchange Profile or the SLD, or to activate special runtime modes,
such as Java Application Response Time Measurement (JARM) monitoring. For
more information about possible entries, refer to the documentation in SAP Help
Portal, or to the comments in the template file.
May 2005

Java Proxy Runtime 3.0 - J2EE Integration

2.3.2 Connecting to the SLD: dbconnect.properties (Obsolete)

The file dbconnect.properties was used by JPR and MS to retrieve the logon data
necessary to access the Exchange Profile in the Integration Server's database, where more
configuration data such as the SLD host and port and other properties are stored. As of SAP
XI 3.0, this logon data has been moved for security reasons to the J2EE Engines Secure
Store. The data is copied into the secure store when the Exchange Profiles connection is
specified2 and successfully established.
To verify that SLD access of the Messaging Service of the Adapter Framework is enabled,
call up the properties page of the service CPACache in the J2EE Engines Visual
Administrator. Check whether the property SLDAccess has the value true. If this is not the
case, the Integration Server URL defined in the property
messaging.system.eventHandler.XI.isconfig.url of the service Adapter
Framework Messaging is used. It has the following format:
http://<host>:<http_port>/sap/xi/engine?type=entry.

See also Installation Guide SAP Exchange Infrastructure Release 3.0 under
Post-Installation Activities chapter 4.2 Activities for the Adapter Engine
Checking the Connection Parameters in the Exchange Profile.

2.3.3 Identifying the Business System: technicalID.properties

(Obsolete)
In SAP XI 2.0, JPR used a technical ID to identify the business system associated with this
JPR instance. During the installation of SAP XI by Software Deployment Manager (SDM), this
technical ID was deposited in a file called technicalID.properties. This file was
located in the Server Work Directory of the SAP J2EE Engine.
This file is no longer created or used. Instead, the JPR instance is identified with the J2EE
Engine instance, which should be declared automatically in the SLD when the Adapter
Framework is installed. The business system name associated with this Web AS Java
system defines the name of the sender service in the outgoing messages (see Section 3).

2.3.4 Logging and Tracing: logging.properties (Obsolete)

As of SAP XI 3.0 SPS1, this properties file is obsolete, since the logging properties of all
Adapter Framework modules, including Messaging Service of Adapter Framework and JPR,
will be deployed in the J2EE Engine.
To change the default logging properties of JPR at runtime, use the J2EE Engine
Administrator tool and call up the Log Configurator service. Switch to advanced mode, and
then choose the Runtime tab page and the Destinations sub-tab.
For the JPR library log, select the destination:
library_com.sap.aii.proxy.xiruntime_JPRTrace
For the proxy server log select the destination:
application_sap.com/com.sap.xi.proxyserver_ProxyServerTrace
You can now, for instance, use the severity drop-down list to change the logging severity.

To specify the connection of a J2EE Engine to the System Landscape Directory, enter
//http:/<host>:<port>/exchangeProfile with the J2EE Engines host and port in
your browser and select Connection from the page menu.
8

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

Note that you can only log into individual files if you change the settings of the LogManager,
(which you can find in the kernel tree of the server node) as follows, and restart the server.
To change the settings, you have the following options:

Set the property ForceSingleTraceFile to NO

Add the path segment com.sap.aii.proxy to the

SingleTraceFile_UnrestrictedLocations

To view the JPR logs, use the LogViewer service and traverse the log tree under the server
instance node to node ./log/libraries/com.sap.aii.proxy for the library log, and to
node ./log/applications/com.sap.aii.proxy for the proxy server log.
For more information, see the J2EE Engine documentation on logging.

2.3.5 Locating Client Beans: jndi.properties (Obsolete)

In a J2SE outbound scenario, the application needs to authenticate itself at the J2EE Engine
when it tries to lookup the proxy bean using the J2EE Engines naming service.

An example of a J2SE outbound scenario is realized by the following situation:

The application client is a J2SE Java program using a proxy bean deployed on
a J2EE Engine.
In the 6.20 J2EE Engine, it was possible to deposit the logon data in a properties file named
jndi.properties, which was located in the work directory of the application. On the
6.40 J2EE Engine, you can no longer use such a file, since the file would need to contain
human-readable password information. Instead, the logon data should either be stored in the
secure store of the engine, or alternatively, assigned to the respective Java system properties
directly in your application program by using Java Properties and put statements, as in
the following example.
// Get naming context
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sap.engine.services.jndi.InitialContextFactoryImpl");
p.put(Context.PROVIDER_URL, "myHost:50004");
// p4 port
p.put(Context.SECURITY_PRINCIPAL, "Administrator"); // admin
user
p.put(Context.SECURITY_CREDENTIALS, "password");
// admin users
pw
Context ctx = new InitialContext(p);

2.3.6 Assigning Beans to Interfaces: jpf.registry (Mandatory)

For inbound scenarios (see Section 2.5), the file jpf.registry is needed in the Global XI
Directory of the SAP J2EE Engine. It contains JPRs interface registry, where inbound
interfaces specified by their WSDL names are assigned their implementing beans.
In order to support a clustered J2EE Engine, for example, a configuration with multiple server
nodes, the file jpf.registry has been moved from the Server Work Directory to the
central Global XI Directory. The Server Work Directory is accessible only from the associated
server node. The Global XI Directory is accessible from all nodes.

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

Although jpf.registry is a text file (with a rather simple syntax), which you
could previously maintain using a simple text editor, it is now strongly
recommended that you use the new proxy server requests described in Section
2.6.2 to maintain the registry. The reason for this is that these requests use
access methods that lock and unlock the file to prevent it being overwritten by
multiple cluster nodes.
File entries are of the form:
<interface_namespace>#<interface_localname>=<bean_name>:<bean_method_name>

If <interface_namespace> or <interface_localname> contain the

characters : or =, these characters must be escaped, since they are syntactical
characters for Java's property readers.

http\://com.sap.aii#myInterface=myBean:myMethod

2.4 Using Outbound Interfaces

The following section discusses J2EE applications that send messages through JPR to the
Integration Server. The application can choose between two send modes; synchronous and
asynchronous.

In synchronous mode, a response message from the receiver is expected. In case of

errors, exceptions need to be handled.

In asynchronous mode, no response is expected, but acknowledgment messages of

various types can be requested (see Section 2.4.4).

2.4.1 Application Scenario

Figure 1 depicts the scenario of a J2EE application that sends messages by using a proxy
bean that represents an outbound interface.
Calling the interface method of the proxy bean from an application class results in a call of
the respective method of the proxy class, which builds and sends a message through JPR to
the Integration Server. JPR is provided by the server in the form of an additional library,
which is shared among all applications using JPR. JPR uses the Messaging Service (MS) of
the Adapter Framework to send the message object to the Integration Server.

10

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

MS
Monitoring

SAP J2EE Engine

Application

Application
Class

OutboundBean

OutboundProxy
Class

JPR
(Library)

Messaging
Service (MS)

HTTP

DB

Figure 1 Java Proxy Runtime (JPR) and J2EE Application - Outbound

Scenario (light grey: generated classes, dark grey: JPR
component)

2.4.2 Application Deployment

A J2EE application typically encompasses not only its own classes, but also the proxy bean,
proxy class, and possible type classes generated by the Java Proxy Generator. When
deploying the application, the generated proxy classes will usually be part of the application
archive contained in the application's .ear file.
The following examples illustrate the relevant entries in the beans deployment descriptors.
For more information, see SAP note 758048. This describes in a step-by-step manner how to
deploy Java Proxy beans by using either the Deploy Tool of the J2EE Engine, or SAP
NetWeaver Developer Studio.

ejb-jar.xml
This descriptor essentially declares the EJB interfaces. You have to enter the names of the
generated Java interfaces.
<ejb-jar>
<description>EJB JAR description</description>
<display-name>EJB JAR</display-name>
<enterprise-beans>
<session>
<ejb-name>MyOutboundProxy_PortTypeBean</ejb-name>
<home>MyOutboundProxy_PortTypeHome</home>
<remote>MyOutboundProxy_PortTypeRemote</remote>
<ejb-class>MyOutboundProxy_PortTypeBean</ejb-class>

May 2005

11

Java Proxy Runtime 3.0 - J2EE Integration

<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>

If you need access to the messageSpecifier values after calling the proxys
send method (see Section 2.4.3), you must deploy the proxy bean as a stateful
session bean; otherwise it is sufficient to deploy it as a stateless session bean.

ejb-j2ee-engine.xml
This descriptor essentially declares the EJB. You have to enter the name of the generated
Java bean class.
<ejb-j2ee-engine>
<enterprise-beans>
<enterprise-bean>
<ejb-name>MyOutboundProxy_PortTypeBean</ejb-name>
<session-props/>
</enterprise-bean>
</enterprise-beans>
</ejb-j2ee-engine>

application-j2ee-engine.xml
Since the generated bean and data type classes need classes of JPR and other libraries, the
following dependencies must be declared in this descriptor3. All library references are of type
weak and have the same provider name, sap.com.
<application-j2ee-engine>
<reference reference-type="weak">
<reference-target
provider-name="sap.com"
target-type="library">com.sap.aii.proxy.xiruntime
</reference-target>
</reference>
<reference reference-type="weak">
<reference-target
provider-name="sap.com"
target-type="library">com.sap.aii.messaging.runtime

If you are using SAP NetWeaver Developer Studio, you may want to check whether the ear
file generated for your application contains copies of the referenced libraries. If so, you
should use a variable class path entry SAP_USER_ADD_LIBS instead of an external entry in
the build path of your project to avoid duplicating the library files. Make sure that the path of
SAP_USER_ADD_LIBS is <SERVER_HOME>\cluster\server0\bin\ext. Refer to the
chapter Working with J2EE Libraries in the J2EE Engine documentation.

To access this documentation, see SAP Help Portal at http://help.sap.com Application

Platform Java Technology in SAP Web Application Server Development Manual
Working with the Developer Studio Working with J2EE Tools Working with J2EE
Libraries.
12

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

</reference-target>
</reference>
<reference reference-type="weak">
<reference-target
provider-name="sap.com"
target-type="library">com.sap.xi.util.misc
</reference-target>
</reference>
<reference reference-type="weak">
<reference-target
provider-name="sap.com"
target-type="library">com.sap.guid
</reference-target>
</reference>
<provider-name>sap.com</provider-name>
<fail-over-enable
mode="disable"/>
</application-j2ee-engine>

As of SAP XI 3.0 SPS1, the library com.sap.mw.jco is no longer needed,

since earlier references to the JCo client in the MessageSpecifier interface
have been removed.

2.4.3 Programming Interface

During Java Proxy generation, all necessary Java classes for the outbound proxy are
generated, that is, the EJB2.0 bean class, the home and remote interfaces, and the local
home and local interfaces. Additional classes are generated for the data types used in the
interface, if necessary.
Using the generated proxy bean does not require any special programming aside from the
normal EJB calls, that is, locating the bean using Java Naming and Directory Interface
(JNDI), creating a home or local home interface, creating a remote or local interface to the
bean, and finally, calling the method of the remote or local interface.
Note that EJB2.0 introduces the concept of co-located, or local beans, that is, beans that are
deployed in the same EJB container system and execute in the same Java VM. An
advantage of local beans is improved performance, because they avoid the RMI-IIOP
overhead of remote beans. Local beans are accessed through the local and local home
interfaces that are generated in addition to the home and remote interfaces known from
EJB1.1. To lookup the local bean rather than the remote bean, prefix the bean name with
localejbs/. As mentioned earlier, local beans can only be called from within the EJB
container system, that is, from other beans or servlets/jsps.
The MessageSpecifier interface can be used to set configuration data for a particular
message or to add attachments to the message. Note that under J2EE, the
MessageSpecifier is provided by value rather than by reference, that is, the actual
instance resides in the remote proxy. Therefore, the method $messageSpecifier()has
been introduced to get an initialized copy of the proxy bean's MessageSpecifier instance.
After the application changes the MessageSpecifier, the application must use the built-in
proxy bean method $messageSpecifier(MessageSpecifier ms) to copy the modified
specifier instance back into the proxy bean. As of SAP XI 3.0 SPS1, the additional method
$messageSpecifierRead()was introduced. which returns a copy of the current

May 2005

13

Java Proxy Runtime 3.0 - J2EE Integration

MessageSpecifier instance of the bean without initializing it. You must use this method to
access data written into the MessageSpecifier by JPR during the proxys send call, such
as to retrieve the ID of the last message sent. To ensure that the MessageSpecifier
returned by this method is in fact the one associated with your bean instance, the proxy bean
must be deployed as a stateful session bean (see Section 2.4.2).

As of SAP XI 3.0 SPS1, the package name of the Java Proxy Runtime was
changed from com.sap.aii.proxy.framework to
com.sap.aii.proxy.xiruntime, in order to separate its classes from the
classes used by the JCo connectivity. JCo connectivity is used, for example, by
WebDynpro applications that automatically refer to the library
WD_RUNTIME/com.sap.ide.jcb.core/lib/aii_proxy_rt.jar4.This
library is a built-in library of the J2EE Engine, deployed as software
component com.sap.aii.proxy.framework. Applications using Java
proxies for SAP XI connectivity, on the other hand, must refer to the library
aii_proxy_xirt.jar of the SAP XI Adapter Framework, which gets
deployed as software component com.sap.aii.proxy.xiruntime during
installation of the Adapter Framework. Furthermore, as of SAP XI 3.0 SPS1, the
libraries themselves refer to different versions of the SAP XI utility library.
The following table summarizes the dependencies.
Connectivity

SAP XI

JCo

uses software component

com.sap.aii.proxy.xiruntime

com.sap.aii.proxy.framework

containing library file

aii_proxy_xirt.jar

aii_proxy_rt.jar

which needs library

aii_utilxi_misc.jar

aii_util_misc.jar

of software component

com.sap.xi.util.misc

com.sap.aii.util.misc

Due to the renaming of the package com.sap.aii.proxy.xiruntime, all

Java proxies generated for SAP XI 3.0 SPS0 or SPS1 before January 8, 2004,
must be generated again so that they contain the new package name.

2.4.4 Acknowledgments
As of SAP XI 3.0 SPS1, sender applications can request acknowledgments from the XI
runtime components, which indicate whether or not the outbound message has reached, and
was processed by, the receiver application. Four types of acknowledgments can be
requested:

System acknowledgment: confirms the successful delivery of the message by XI at the

receiver application

System error acknowledgment: signals an error during the delivery

Application acknowledgment: confirms the successful processing of the message by

the receiver application

Application error acknowledgment: signals an error during the processing of the

message in the receiver application

The reference will be made in your Java Build Path as well as in the
gen_wdp/portalapp.xml file of your WebDynpro project.

14

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

While the first two acknowledgments refer merely to the transport of the message through the
XI runtime components, the latter two refer to the processing of the message on the
application level. Note that System acknowledgment and Application acknowledgment are
positive acknowledgments indicating success, while System error acknowledgment and
Application error acknowledgment are negative acknowledgments indicating failure.
To request the acknowledgments, use the following methods of the MessageSpecifier
interface (see Section 2.4.3):
public void setApplicationAckRequested (String ackListenerName);
public void setApplicationErrorAckRequested (String
ackListenerName);
public void setSystemAckRequested (String ackListenerName);
public void setSystemErrorAckRequested (String ackListenerName);
As its parameter, each method requires the name of an EJB2.0 listener bean that can
receive the requested acknowledgment message. This bean is typically deployed together
with the sender application and handles and interprets the acknowledgments on the
application level.
The listener bean name follows the same syntax as proxy beans (see Section 2.5.1).

Examples:
sap.com/MyProject/MyTestAckBean
localejbs/sap.com/MyProject/MyTestAckBean.
Analogous to a proxy bean, its home, remote, localHome and local interfaces must be
declared in the ejb-jar.xml descriptor as:
com.sap.aii.proxy.xiruntime.ack.AckListenerHome
com.sap.aii.proxy.xiruntime.ack.AckListenerRemote
com.sap.aii.proxy.xiruntime.ack.AckListenerLocalHome
com.sap.aii.proxy.xiruntime.ack.AckListenerLocal
Only then can they be generically looked up by JPR. The bean itself has to implement JPRs
AckListener interface:
com.sap.aii.proxy.xiruntime.ack.AckListener
It contains only the following method:
onAck(com.sap.aii.proxy.xiruntime.ack.AckMessage ack)
This method is declared in the beans local and localHome interfaces.
When sending a message requesting an acknowledgment, JPR will register the requested
acknowledgment and the listener bean name with the outgoing message5.
On the receiver application side, acknowledgment handling is completely transparent. When
JPR receives a message requesting an acknowledgment, it triggers the Messaging Service of
the Adapter Framework to originate the appropriate acknowledgment message

The listener bean name is stored in the messages internal hop list, which collects the SAP
XI processing nodes that the message passes on its way from sender to receiver. The hop
list is copied into each acknowledgment message, thus enabling the acknowledgment to find
its way back to the sender.
May 2005

15

Java Proxy Runtime 3.0 - J2EE Integration

(ApplicationAck with status OK or Error) as soon as the message was either successfully or
unsuccessfully processed by the receiver application6.
Upon receipt of an acknowledgment message on the sender application side, JPR looks up
the listener bean name registered in the acknowledgment message, instantiates the listener
bean, and calls the bean method onAck(). The method parameter AckMessage is an
interface that provides the following methods to access detailed information about the
acknowledgment:

String getType();
SystemAck)

String getStatus(); returns the acknowledgment status (OK, Error, or

AckRequestNotSupported)

String getCategory(); returns the acknowledgment error category (transient

or permanent). This is applicable only if status is Error.

IGUID getRefToMsgId(); returns the ID of the referenced message, that is, the
message that was acknowledged by this message

returns the acknowledgment type (ApplicationAck or

String getRefToMsgIdAsString(); returns the ID of the referenced message

as a string
If the acknowledgment status is Error, you can use the following methods to get more
information about the error:

String getErrorCode(); returns the error code

String[] getErrorParameters(); returns up to four error parameters as a

String array, or null if none of the parameters are set

String getErrorCode(); returns possible additional error text

If, in addition to status Error, the acknowledgment type is ApplicationAck, you can use:

String getApplicationFaultMessage (); returns the application fault

message.

String getApplicationFaultMessageNamespace(); returns the namespace

of the application fault message.
For each of the above values, such as Error, ApplicationAck, and so on, the JPR class
com.sap.aii.proxy.xiruntime.ack.AckConstant provides a constant to efficiently
compare values when interpreting the acknowledgment message. Note, however, that in the
case of remote beans, value and AckConstant are different instances because they are
serialized remote objects. Therefore, you would have to compare the values by using the
equals() method on their toString() renditions.
Furthermore, if getStatus() returns AckRequestNotSupported, you can use the
following methods to find out which acknowledgment type was not supported. Each method
returns true if any of the XI modules involved in transporting the message from sender to
receiver is unable to originate the requested acknowledgment.
boolean systemNotSupported();
boolean systemErrorAckNotSupported();
boolean applicationAckNotSupported();
boolean applicationErrorAckNotSupported();

JPR cannot trigger negative system acknowledgments itself, because this would interfere
with the internal transaction processing of the undelivered message. Instead, JPR delegates
this task to the Messaging Service by throwing a DeliveryException.

16

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

SAP XI 3.0 offers the option of configuring message splitting in the Integration
Directory, whereby multiple receivers for a single outgoing message can be
defined. If requested, each of these multiple incoming messages can send its
acknowledgment messages, resulting in multiple acknowledgments received by
the sender. Since the sender Java proxy has currently no way of knowing about
how the split was configured, it cannot determine when the complete set of
acknowledgments has arrived7. Therefore, in the case of split messages, all
acknowledgement messages are currently delivered with the status
AckRequestNotSupported.

2.5 Using Inbound Interfaces

The following section discusses J2EE applications used to receive messages from the
Integration Server. The application can choose between two receive modes; asynchronous
and synchronous. In synchronous mode, a response message is returned to the sender. In
asynchronous mode, no response is sent. In both cases, however, exceptions may be raised.

2.5.1 Application Scenario

Figure 2 depicts the scenario of a J2EE server application receiving messages by using a
proxy bean representing an inbound interface. This scenario requires the JPR ProxyServer
application to be deployed on the server, and its JPRBean to be registered with the
Messaging Service of the Adapter Framework.
Upon receipt of an incoming HTTP message, the Messaging Service calls the onMessage
method of the ProxyServer's JPRBean, which, in turn, calls JPR to handle the message.
Note that JPR is the same library that is also used by sender applications. JPR looks up the
application bean registered in the JPR registry for the given inbound interface, and calls the
bean, by using the generic method invokeMethod defined in the superclass of the bean.
The bean, in turn, calls the application class that implements the generated inbound proxy
interface.

In future versions of JPR, access to the so-called hop list of the message may be provided
which contains the complete path of XI processing nodes for the message and, in the case of
a split, its possible children.

May 2005

17

Java Proxy Runtime 3.0 - J2EE Integration

MS
Monitoring

J2EE Server

Application
Application
Class ("Inbound
ProxyImpl")

InboundProxy
Interface
ProxyServer
InboundBean

JPRBean

Messaging
System

JPR
(library)

JPR Registry

DB

Figure 2 Java Proxy Runtime (JPR) and J2EE Application - Inbound

Scenario (light grey: generated classes, dark grey: JPR
components)

2.5.2 Application Deployment

Deployment of a J2EE server application that implements an inbound interface is similar to
that of the outbound scenario (see Section 2.4.2).
Note, however, that in the beans deployment descriptor ejb-jar.xml, a different set of
interfaces must be declared. This is illustrated in the following example.

ejb-jar.xml
This descriptor declares the EJBs interfaces as base interfaces of the JPR library. The
names of the interfaces <home>, <remote>, <local-home> and <local> have to be
entered exactly as shown here.
<ejb-jar>
<description>EJB JAR description</description>
<display-name>EJB JAR</display-name>
<enterprise-beans>
<session>
<ejb-name>MyInboundProxy_PortTypeBean</ejb-name>
<home>com.sap.aii.proxy.xiruntime.core.AbstractProxyInboundHome4</home>
<remote>com.sap.aii.proxy.xiruntime.core.AbstractProxyInboundRemote4</remote>
<local-home>com.sap.aii.proxy.xiruntime.core.AbstractProxyInboundLocalHome4
</local-home>
<local>com.sap.aii.proxy.xiruntime.core.AbstractProxyInboundLocal4</local>
<ejb-class>MyInboundProxy_PortTypeBean</ejb-class>

18

May 2005

HTTP

Java Proxy Runtime 3.0 - J2EE Integration

<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>

Important Note:

As of SAP XI 3.0 SPS4, all interface names must end with the suffix 4. This
incompatible change between SPS4 and earlier releases was necessary to fix a
bug that prevented remote calls of the proxy beans8. Therefore, inbound proxy
beans that need to be called remotely must be regenerated and redeployed
using the proxy generator of SAP XI 3.0 SPS4 and the above deployment
descriptor.

application-j2ee-engine.xml
Since the generated proxy and type classes derive from JPR classes, the dependencies on
the JPR and other libraries have to be declared in this descriptor file of the EJB application9.
com.sap.aii.proxy.xiruntime
com.sap.aii.messaging.runtime
com.sap.xi.util.misc
com.sap.guid
All library references are of type weak and have the same provider name, sap.com.

ejb-j2ee-engine.xml
This descriptor may contain the JNDI name to be used for the bean. To identify this name
with the inbound interface that it implements, the WSDL name of the interface must be
registered with JPR. At present, this has to be done manually when the application is
deployed, by entering a line in your browser (see Section 2.6.2), as in the following example:
http://localhost:50000/ProxyServer/register?ns=http://com.sa
p.aii&interface=myInterface&bean=sap.com/MyProject/MyInbound
Proxy_PortTypeBean&method=myInboundProxy
The interface is specified by the fully qualified name defined in the Integration Repository.
The bean name is the JNDI name that you defined for the bean in the ejb-j2eeengine.xml descriptor file using the <jndi-name> tag. If you deployed your EJB without
defining a JNDI name, the bean name contains, by default, the prefix sap.com and your
project name10, as in the above example
sap.com/MyProject/MyInboundProxy_PortTypeBean.
The method name is specified by the Java method name derived from the operation name in
the interface's port type. As such, it is the name of the one method generated into the class
implementing the inbound interface (see Section 2.5.3). In our example, it is
myInboundProxy.

This bug only became apparent after XI 3.0 SPS2 when a bug fix was applied in the J2EE
Engines p4 service.
9

See footnote 3 in Chapter 2.4.2

10

Note that the name of your ear-file is also derived from your project name; in our example:
MyProject.ear.

May 2005

19

Java Proxy Runtime 3.0 - J2EE Integration

As mentioned in Section 2.4.2, in addition to remote beans you can also have local beans for
your inbound application. If you want JPR to access the local bean rather than the remote
bean, supply the bean name with the prefix localejbs/ when registering the interface, as
in the following example:
http://localhost:50000/ProxyServer/register?ns=http://com.sap.a
ii&interface=myInterface&bean=localejbs/sap.com/MyProject/MyInb
oundProxy_PortTypeBean&method=myInboundProxy

2.5.3 Programming Interface

Similar to the outbound scenario, the Java proxy generator generates all necessary Java
classes for the inbound proxy, that is, the EJB 2.0 bean class, the home and remote
interfaces, the local home and local interfaces, and possible data type classes.
The application programmer has to provide a class that implements the generated inbound
proxy interface11. This implementing class must be a subclass of the AbstractProxy
class of JPR. Note that the name of that class is derived from the name of the generated
interface by appending Impl to the interface name. This is because the name has to be
generated into the code of the proxy bean, where an instance of the implementing class is
created. Example:
public class MyInboundProxy_PortTypeImpl extends AbstractProxy
implements MyInboundProxy_PortType { ... }
The only method in this class represents the unique operation of the inbound interface and
accepts the data from the incoming message. Its name is derived from the interface name
(myInboundProxy).
Since the implementing class derives from JPR's AbstractProxy class, it can use the
instance variable messageSpecifier, for example, to retrieve attachments from the
message. The generated bean code assigns and retrieves the messageSpecifier
instance by calling the bean methods $messageSpecifier(MessageSpecifier ms)and
$messageSpecifier(), both before and after calling the implementing class.
The important note in Section 2.4.3 regarding how the Java Proxy Runtime package was
renamed, also applies to inbound applications.

2.6 Inbound Proxy Server

To enable JPR to receive messages, a proxy server application must be running on the host
that accepts incoming messages. This server is represented by the ProxyServer Web
application. It must be deployed on the application server (see Section 2.2) and acts as a
listener for messages from the Messaging Service.
The proxy server uses the J2EE Engines central JPR registry to map the name of the
inbound interface found in the message to the name of the associated application bean that
implements this interface.

2.6.1 User Groups and Security Roles

Both the proxy server and the Messaging Service require that certain user groups be created
on the J2EE Engine, and that these users be assigned to the various security roles defined
for JPR and MS.

11

A template of this class is provided in the jar containing the generated proxy and type
classes. It has the extension .template rather than .java, to avoid any existing classes
being overwritten when the sources are extracted from the jar file.
20

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

These user groups are automatically created when a J2EE Engine is installed as a Web AS
ABAP system, because the user information can be retrieved from the R/3 system. However,
if the J2EE Engine is installed as a Web AS Java business system, you either need to create
the user groups manually, using the VisualAdmin tool, or assign existing users to the required
security roles.
To check user groups and users, access the Security Provider service in the VisualAdmin
tool. Choose the User Management tab page, and check the User Tree (preferably in the
Tree tab page) for previously-defined user groups and users. To create user groups or users,
choose the relevant buttons on the right.
The following user groups are used in MS and JPR. Note, however, that you can also assign
other users, such as Administrator users, to the security roles listed below.
User Group

User

SAP_XI_IS_SERV_USER

XIAFUSER, XIISUSER, XIAPPLUSER,

SAP_XI_APPL_SERV_USER

XIAFUSER, XIISUSER, XIAPPLUSER,

SAP_XI_ADMINISTRATOR_J2EE
SAP_XI_CONFIGURATOR_J2EE

<user names>
<user names>

SAP_XI_DEVELOPER_J2EE

<user names>

To check or change security role assignments for MS and JPR, access the Security
Provider service in the VisualAdmin tool. Choose the Runtime tab page, and click on the
following Policy Configurations entries:
sap.com/com.sap.aii.af.ms.app*MessagingSystem
Switch to the Authentication tab page, and check whether the authentication template has
the value basic12.
On the Security Roles tab page, click on each of the roles xi_af_receive and
xi_af_monitor. Role xi_af_receive is used when messages are received from the
Integration Server and should be assigned the internally-used XIISUSER, and
XIAPPLUSER, which is often declared in channel definitions of applications (see Chapter
4). Therefore, user groups SAP_XI_APPL_SERV_USER and SAP_XI_IS_SERV_USER
are automatically assigned. You may want to assign different or additional users and
groups, such as Administrators, to these roles.
sap.com/com.sap.aii.xi.proxyserver*ProxyServer
Switch to the Authentication tab page, and check whether the authentication template has
the value basic.
On the Security Roles tab page, click on each of the roles xi_jpr_list_bindings,
xi_jpr_admin and xi_jpr_register_bindings. Previously-assigned user groups
are different combinations of SAP_XI_ADMINISTRATOR_J2EE,
SAP_XI_CONFIGURATOR_J2EE and SAP_XI_DEVELOPER_J2EE (see Section 2.6.2).
You may want to assign different or additional users and groups, such as
Administrators, to these roles.

2.6.2 Maintaining the JPR Registry

As of SAP XI 3.0 SPS1, maintenance of the J2EE Engines central JPR registry (in file
jpf.registry, see Section 2.3.6) is supported with several requests to the proxy server

12

Sometimes, after re-installation of the Messaging Service, the initial template value may be
No instead of basic. Due to the missing authentication scheme, this disables message
reception altogether.
May 2005

21

Java Proxy Runtime 3.0 - J2EE Integration

servlet. It is strongly recommended that you use this new browser interface, since all
requests use synchronized access methods that lock and unlock the registry for each read or
write access. Otherwise, it cannot be guaranteed that the JPR registry is kept consistent on a
clustered J2EE Engine.
To register an interface and its implementing bean method, enter the following request in
your browser (on one line):
http://<host>:<port>/ProxyServer/register?
[ns=<interface_namespace>&]interface=<interface_localname>&bean=<bean
_name>&method=<bean_method_name>
The namespace parameter, ns, is optional, but all other parameters are mandatory.

http://localhost:50000/ProxyServer/register?ns=http://myNS&
interface=myInterface&bean=myBean&method=myMethod
To unregister an interface, enter the following request line:
http://<host>:<port>/ProxyServer/unregister?
[ns=<interface_namespace>&]interface=<interface_localname>[&bean=<bean
_name>&method=<bean_method_name>]
Here, the parameters for namespace and bean name together with method name are
optional.
To unregister all interfaces, enter the following request line:
http://<host>:<port>/ProxyServer/unregisterAll
To list an interface registration, enter the following request line:
http://<host>:<port>/ProxyServer/list?
[ns=<interface_namespace>&]interface=<interface_localname>
If the interface had been registered with a non-empty namespace, the namespace
must also be entered in the request. In other words, the search returns only exact
matches.
To list all currently registered interfaces in ascending lexicographical order, enter the
following request line:
http://<host>:<port>/ProxyServer/listAll

The proxy server re-reads the registry whenever it is changed, so that newlydeployed service beans are located as soon as they are registered in the file.
There is no need to restart the proxy server application or the SAP J2EE
Engine.
As of SAP XI 3.0 SPS4, the requests listed above have been assigned security roles to
prevent unprivileged users from changing or viewing the registry. The security roles are
mapped to certain user groups so that members of the specified groups are automatically
entitled to execute the corresponding requests. The following table lists the requests with
their corresponding security role and user groups (see also Section 2.6.1).
Request

Security role

User group

/register

xi_jpr_register_bindings

SAP_XI_ADMINISTRATOR_J2EE

/unregister

SAP_XI_DEVELOPER_J2EE

/unregisterAll

22

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

/list

xi_jpr_list_bindings

/listAll

SAP_XI_ADMINISTRATOR_J2EE
SAP_XI_DEVELOPER_J2EE
SAP_XI_CONFIGURATOR_J2EE

2.6.3 Servlet Status

To check whether the ProxyServer servlet is up and running, enter
http://<host>:<port>/ProxyServer/jprtransportservlet in your browser address
field. <host> denotes the host name and <port> denotes the server port number, as in
localhost:50000. The response should read: Transport Servlet is OKAY
It also provides some status information for the servlet.
As of SAP XI 3.0 SPS9, you can obtain a more comprehensive status picture of JPR by
calling the Adapter Frameworks Adapter Monitor (see Section 5).

3 Sender Service Configuration

Aside from deploying your client proxy classes on the application J2EE Engine, you need to
make some minimum configurations in the System Landscape Directory (SLD) when you
implement an outbound Java proxy scenario. This configuration data is used by JPR to
determine the sender service when it creates an outbound message, and by the Messaging
Service to locate the Integration Servers URL when it sends the message.
Use the built-in wizards of the System Landscape Directory tool to create new instances of:

A technical system of type Web AS Java

A business system
In a typical landscape, you enter the following values for the technical system:

Web AS ABAP:

System Name (SID): J2E

System Home: <your hostname>

none (Standalone J2EE)

For the business system, you enter:

An arbitrary name

The type of the associated technical system (Web AS Java)

The name of the associated technical system (to select from the dropdown list, J2E
on <hostname> in the example above)

The related Integration Server (to select from the dropdown list)

This configuration data is accessible by JPR and MS only after the CPA cache
on your application J2EE Engine has been updated. This should be done
automatically, provided the Adapter Framework has properly registered itself
with the Integration Server at installation time13.

13

Currently, the Adapter Framework registers itself under the name af.j2e.<host>. If you
experience cache update problems, check for such a name of your host in the SLDs Content
Maintenance view, by selecting for Class XI Adapter Framework.
May 2005

23

Java Proxy Runtime 3.0 - J2EE Integration

4 Receiver Communication Channel

Configuration
Aside from deploying your server proxy classes on the application J2EE Engine, you need to
make some minimum configurations in the Integration Directory when you implement an
inbound Java Proxy scenario. The configurations include:

A receiver agreement to assign the sender-receiver pair a receiver communication

channel

A communication channel, which specifies the endpoint to which the Integration Server
sends messages for your particular receiver service

The receiver communication channel for Java proxies is the Messaging Service of the J2EE
Engine on which the receiving application is deployed. To specify such a channel, you need
to enter the following parameters on the Integration Builders communication channel page:

Adapter type:

Check radio button : Receiver

Transport log:

HTTP 1.0

Message log:

XI 3.0

Adapter engine: Integration Server

Addressing mode: URL address

Host: <host>

Port: <port>

Path: /MessagingSystem/receive/JPR/XI

Authentication data:

Authentication mode: Use logon data to non-SAP system

User name: XIAPPLUSER

User password: <XIAPPLUSER -Password>

XI http://sap.com/xi/XI/System SAP Basis 6.40

For outbound scenarios, a minimum configuration includes:

Services that define the sending and receiving business systems

A receiver determination that assigns the sender service one or many receiver services

An interface determination that assigns the sender interface a receiver interface

For more information on these configurations, see SAP Help Portal at http://help.sap.com
Process Integration SAP NetWeaver SAP Exchange Infrastructure Design and
Configuration Time Configuration.

5 Monitoring
As of SAP XI 3.0 SPS09, the current status of JPR can be monitored using AFs unified
Adapter Monitor. This gives you a quick overview over the operational status of all SAP XI
Adapters and JPR. You can call the Adapter Monitor from the Runtime Workbench (RWB), by
using the following steps:
1. Choose Component Monitoring.
2. Under XI Components, select Adapter Engine <host>.
3. On the Status tab page, choose Monitoring.
24

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

Alternatively, in your browser address field you can enter:

http://<host>:<port>/AdapterFramework/monitor/monitor.jsp
An overview page like the following, is then displayed. It lists the status of all installed
adapters and JPR on the various server nodes.

Figure 3a Adapter Monitor Overview Page (on a Single-Server J2EE Engine)

By clicking on the JPR line, an expanded view like the one in the following example appears.
It lists the relevant JPR components and their current status or contents. The meaning of the
status traffic lights is as follows:

A green light indicates error-free operation. If configured to severity level Info, the JPR
trace (see Section 2.3.3) will contain information about the configuration settings used by
JPR.

A yellow light indicates that JPR is functional, but that warnings have been issued14.
These warnings should be looked up in the JPR trace and handled accordingly.

A red light indicates that a serious error has occurred, rendering JPR non-operational.
The detailed error messages can be looked up in the JPR trace as well as in the J2EE
Engines application log. Usually they contain hints on how to fix or circumvent the error.

14

For example, if the SLD is currently not accessible to retrieve the Sender Service name but
that name could be found in JPRs local cache, this condition would lead to a yellow status.
May 2005

25

Java Proxy Runtime 3.0 - J2EE Integration

Figure 3b Adapter Monitor Detail Page for JPR

Status and configuration information are grouped into the following sections:
Section

Description

Proxy Server

Shows the status of the proxy server bean that handles incoming
messages; lists the JNDI name and class name of the bean.

SLD Access

Shows the accessibility of the System Landscape Directory; lists host

names and port numbers as well as other parameters used by JPR
and MS for accessing the SLD on the Integration Server specified in
the Exchange Profile (see Section 2.3.2).

Messaging Service

Shows the status of AFs messaging service that handles persistence

and transport of messages; lists the name (JPR) and timeout value
used for the internal connection between JPR and MS, and also the
URL and client ID used by MS to address the Integration Server.

Logical Locking

Shows the availability of the J2EE Engines locking service; lists the
namespace (JPR) used to set logical locks on resources such as the
JPR cache and registry.

Properties

Lists the current JPR properties as found in file jpr.properties

(see Section 2.3.1).

26

May 2005

Java Proxy Runtime 3.0 - J2EE Integration

Registry

Lists the full path name of, and number of entries in, the JPR registry.
Clicking on the subsequent text line opens a separate browser
window, which lists the interfaces that are currently registered. The
result is equivalent to entering the request
http://<host>:<port>/ProxyServer/listAll (see Section
2.6.2) in the browser.

Cache

Lists the full path name and contents of JPRs local cache. Note that
cache entries are only used when runtime access to the information
source is temporarily not available. Cache entries are checked and
possibly updated with each successful runtime access.

JARM

Indicates whether performance monitoring with JARM is currently

enabled (On) or disabled (Off). JARM monitoring allows you to trace
how much time is consumed in the various parts and external calls of
JPR, and can thus be used by system administrators to identify
resource bottlenecks during message processing. To enable the
monitoring for JPR, set the property
com.sap.aii.proxy.xiruntime.withJARM=true in file
jpf.properties (see Section 2.3.1).

Version

Lists JPRs release level number and build date, and the path name
of one of its source files to identify the build source.

May 2005

27