Java Proxy Objects (XI 3.0-Compatible) 

Definition

All Java objects that are created from a service interface from the Enterprise Services Repository (ES Repository) in an SAP system, are called Java proxy objects. Multiple proxy objects are created in the system for each service interface (Java classes or Java interfaces). Java proxy generation in the ES Builder creates Java proxy objects that are XI 3.0-compatible (interface pattern: stateless (XI 3.0 compatible).

The services of this interface pattern reference exactly one operation; the operation references message types and the message types in turn reference data types. All objects referenced to service interfaces (including fault message types), are also called Interface Objects. They are the counterparts of the generated proxy objects.

Structure

You can divide the different interface objects into two classes: The service interface itself and the corresponding parameters and data types.

Each generated proxy object can be assigned to its corresponding interface object in the ES Repository even after generation.

Interfaces

Interfaces have a category (outbound, inbound, abstract) and a mode (synchronous or asynchronous). For more information, see Communication Parameters.

The ES Builder Java runtime for Java proxies of Java proxy generation does not provide queuing for the asynchronous processing of messages. If an error occurs when sending an asynchronous message, an exception is thrown.

In the case of J2EE applications, only the categories 'outbound' and 'inbound' are relevant. Depending on the category, the following proxy objects are generated:

●      You call an inbound service interface to start a service that, in the synchronous case, returns a result. Proxy generation generates a Java interface for an inbound service interface. To make this service available, implement this interface using a Java class. Note the following for the implementing class: If the name of the generated Java interface is JavaInterface, then the implementing class must be JavaInterfaceImpl and it must be located in the same package as the generated Java interface.

●      Outbound service interfaces are called to send a message. An outbound service interface is mapped to a Java class.

●      Additional bean classes are generated for J2EE applications. In this case, send and receive messages by using the bean classes and not directly by using the proxy classes. These classes are not required for Java standalone applications.

In general, the signature of the generated method for a service interface SI from the ES Repository, looks as follows (in the synchronous case, without return parameters):

●      Outbound:     public <class for response message> SI(<class for request message>)

●      Inbound:        public <class for response message> SI(<class for request message>)

The class for the input or output message corresponds to the data type referenced by the message type used. No public global classes are generated for message types (fault message types are the only exception here).

Parameters and Data Types

Irrespective of the category, the following objects are generated:

●      A class for each complex data type generated that contains set/get methods for accessing the respective fields.

●      Classes are not required for simple data types. For example, if you use a simple data type of type xsd:string, Java proxy generation does not generate a separate global class for the data type, instead it uses the corresponding Java data type java.lang.String.

There are special conversions for XSD elements and enumerations that can occur an unlimited number of times. More information: Tables, Enumerations.

Example

The following graphic illustrates how a service interface from the ES Repository is mapped to a Java proxy:

The original names of the interface objects are highlighted in bold. In the case of the service pattern stateless (XI 3.0 compatible), the name of the service interface and the name of the operation are identical (XI 3.0 message interfaces implicitly only have one operation).

You can see that Java proxy generation has enhanced the names (also see: Naming Java Proxy Objects).). The method bookOut expects the formal parameter om of type Ct_Type. Therefore, you transfer the data type directly. The message type is included internally by the proxy runtime by using the private class Om_Message.