Creating an Application Integrator Component

How an Application Integrator Component Works

An Application Integrator component is a type of a portal component. On request to an iView created from this component, the component implementation reads the TopLayer property from its profile. The property value points to a layer descriptor file. This layer descriptor file describes a single layer of the component. A layer is a Java subclass of the AbstractIntegrationLayer class that evaluates the portal request object and parameters. When the layer is processed, it changes and/or creates parameters. After the layer is processed, it looks for the next layer descriptor file and if there is one, processes it. When all layers are processed, every layer is called to send the content to the client. Usually only the last layer of the processing chain creates content.

Passing Parameters between Layers

Every layer implementation retrieves its parameters from a map-like structure and passes its calculated parameters back to the same map instance again. Before a layer is processed, the map is filled with parameters from its layer descriptor file. The map can be accessed from the layer implementation with methods from the layer base AbstractIntegrationLayer class.

Parameter Sources and Priority

The following list shows the parameters available for the layer implementation, sorted by priority.

1. Parameters set by the current layer.

2. The layer descriptor file.

3. Parameters set by the preceding layer.

4. Parameters contained in the portal component request object, including the HTTP request parameters.

5. Parameters contained in the portal node object.

6. Parameters contained in the portal component profile.

If none of these parameter sources has a value, the parameterName.default parameter is searched in the sources. The order shown above is maintained so you can set a default value in the layer descriptor file without overwriting the value from a source with a lower priority.

End of Layer Processing

The value in the map stored under the name NextLayer is the name of the next layer property file. The processing chain ends when the NextLayer parameter has the value NoLayer (case-insensitive) or is undefined.

Layer Descriptor File

The layer descriptor file has the Java .properties format and must contain the following properties:

• ClassName

  The name of the layer implementation class.

• OptionalParameters

  A comma-separated list of optional parameters for the layer implementation.

• MandatoryParameters

  A comma-separated list of mandatory parameters for the layer implementation.

Creating the Component

An Application Integrator component is a portal component that has following parts:

• The portal component archive descriptor file PORTAL-INF/portalapp.xml with a SharingReference entry to the com.sap.portal.appintegrator application.

• A starter class that inherits from com.sapportals.portal.appintegrator.AbstractIntegratorComponent . The starter class will be specified as the component class in the portalapp.xml file. The implementation of the class will be empty.

• Each layer used in your component needs a corresponding PORTAL-INF/property/layername.properties file. Each property file provides properties for one layer. The file content must comply with the Java property file syntax.

Implementing Your Own Layer

You extend the existing layers by implementing either the com.sapportals.portal.appintegrator.layer.IIntegrationLayer or the AbstractIntegrationLayer Java class. The IIntegrationLayer interface has plenty of methods to implement, whereas the AbstractIntegrationLayer interface provides the basic functionality needed to implement a layer and is therefore more convenient to use.

AbstractIntegrationLayer Methods

The AbstractIntegrationLayer class provides the following methods:

• init(..)

  This method initializes the layer class to handle a single request. You do not have to override this method. The AbstractIntegrationLayer class implementation stores the parameters in the object (member) attributes. These attributes are used in other implementations of AbstractIntegrationLayer , therefore your layer implementation class should call super.init(..) once, in case you override this method.

• getNextLayer()

  With this method you return the name of the properties file that describes the layer that should be processed next. Your implementation can decide the next layer at runtime but you can also put a NextLayer property into the property file of the layer that specifies the next layer and not override this method.

• render(IPortalComponentResponse)

  This method generates the output. The AbstractIntegrationLayer implementation of this method also generates HTML-comments if the 'WriteComments property in the layer property file is set to true .

Do not overwrite the following methods:

• epilog

• prolog()

• processLayer()

The methods in your layer implementation class are called in the following sequence:

1. Constructor with no argument of your layer class

2. init(..)

3. prolog()

4. processLayer()

5. epilog()

6. getNextLayer()

7. render(IPortalComponentResponse)

When the processing chain contains more than one layer, the calling sequence is as follows:

1. Constructor with no argument of first layer

2. init(..) of first layer

3. processLayer() of first layer

4. getNextLayer() of first layer

5. Constructor with no argument of the next layer

6. init(..) of the next layer

7. processLayer() of the next layer

8. getNextLayer() of the next layer

9. render(IPortalComponentResponse) of first layer

10. render(IPortalComponentResponse) of the next layer

During the first processing step each layer is initialized, processed and checked if there is a next layer. Rendering is done in a second processing step where every layer in the processing chain has the opportunity to output something. However, it is good practice to produce output only from the final layer in the processing chain.