!--a11y-->
Creating
an Application Integrator Component 
An application integrator component is a subtype of a portal component. On request to an iView derived from this component, the component implementation reads the property ‘TopLayer’ 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 class AbstractIntegrationLayer that evaluates the portal request object and parameters. While 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 will creates content.
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 is accessible from the layer implementation with methods from the layer base class AbstractIntegrationLayer.
The following list shows the parameters available for the layer implementation, sorted by priority.
....
1. Parameters set by the current layer.
2. The layer's layer descriptor file.
3. Parameters set by the preceding layer.
4. Parameters contained in the portal component request object (hence, also HTTP request parameters are available).
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 parameter parameterName.default 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.
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 parameter 'NextLayer' has the value 'NoLayer' (case-insensitive) or is undefined.
The layer descriptor file has the Java properties format and must contain the following properties:
· ClassName
The name of the layer implementation class.
· OptionalParameters
Optional parameters for the layer implementation, separated by a comma.
· MandatoryParameters
Mandatory parameters for the layer implementation, separated by a comma.
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 application com.sap.portal.appintegrator.
· 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 to the Java property file syntax.
You extend the existing layers by implementing the Java class com.sapportals.portal.appintegrator.layer.IIntegrationLayer or AbstractIntegrationLayer. This IIntegrationLayer interface has plenty of methods to implement. The class AbstractIntegrationLayer provides the basic functionality needed to implement a layer and is therefore more convenient to use.
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 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 generates also HTML-comments if the property ' WriteComments' in the layer property file is set to true.
The following methods should not be overwritten:
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.
