Repositories

All runtime data in the nevisDataPorter is stored in repositories. A repository is reminiscent of a scope, e.g., page, request or session known in web applications. Each repository has a unique name. The name of the repository and the name of the data item can be used to access any data from within the XML-configuration using the unified expression language specified as part of the JSP 2.1 standard (JSR-245).

The following table gives a short overview of the existing repositories in use.

Repository	Name	Description
Configuration	cfg	Contains all variables defined in the configuration section and all configuration values passed programmatically during the intialization.
Runtime configuration	rtCfg	Contains all variables passed programmatically or through the event system during the export of a module.
Implementation (plug-in factories)	impl	Internal data repository which is generally not used in configurations. Contains factories which are used to create instances of concrete DataObjects, DataSources, DataFilters and DataSinks.
Instance (plug-in instances)	inst	Contains all objects instantiated in any initialization section and all instances which are registered programmatically.
Input (data)	in	Contains objects returned from a DataSource. The name is derived from the name of the embedding entity.
Output (result objects)	out	Contains objects which have to be exported by a DataSink. The name is derived from the name of the embedding entity.
Control (control objects)	ctl	Contains objects which contain control information which can be consumed be any DataFilter in the chain or the DataSink. The name is derived from the name of the embedding entity.
Constants	const	Contains constants defined by nevisDataPorter. E.g., the NULL object which is used to have an explicit representation of null.

In the following chapters some of the repositories are explained in more detail.

Configuration repository

All variables defined in the configuration section (see Configuration Overview) are put into the configuration repository. Plug-ins can reference these configuration variables. You can also pass configuration variables programmatically from within your application when calling the initial method of the DataPorter object. This allows to parameterize your configuration file. All values passed at the intialization phase are additionally stored in the configuration repository ("cfg"). Values received in the export phase, e.g., from the event system, are stored in the runtime-configuration repository ("rtCfg").

Implementation repository

All implementations of DataObject, DataSource, DataFilter, DataSink and EventSource are registered programmatically at the implementation repository under a unique name. In the configuration file these names are used to refer to the respective factory. nevisDataPorter uses the configured name to retrieve the corresponding factory from the implementation. This factory is used to create new instances of a given plug-in.

The following configuration fragment shows how the name "LDAPDataSink" is used to create the built-in DataSink to access an LDAP directory.

<dataSink type="LDAPDataSink">
    <dp:paraVal name="ldapContext"   value="${inst.initalContext}"/>
    <dp:paraVal name="operation"     value="createOrUpdate"/>
    <dp:paraVal name="basedn"        value="ou=${cfg.appl_ou},${cfg.basedn}"/>
    <dp:paraVal name="rdn"           value="cn=#{in.appl.RESOURCENAME}"/>
</dataSink>

Plug-ins can be registered in the configuration file in the setup section.

<setup>
    <factory class="ch.nevis.idm.dataporter.factory.NevisIDMConnectionPoolFactory"/>
    <factory class="ch.nevis.idm.dataporter.factory.NevisIDMSourceFactory"/>
    <factory class="ch.nevis.idm.dataporter.factory.NevisIDMSinkFactory"/>
    <dataFunction class="ch.nevis.idm.dataporter.NevisIDMDataFunctions"/>
</setup>

Here, the specified class has to implement a Factory interface and has to provide a public parameter- less constructor.

In addition, plug-ins can be registered programmatically with nevisDataPorter by registering a factory using the registerInstanceFactory(Factoryfactory) method. The interface Factory defines two methods. The first method returns a description of the plug-in, the second creates a new instance using the passed configuration. The description returned by the first method contains the previously mentioned implementation name, the plug-in type and all its possible and mandatory configuration parameters including their types and possible values.

Instance repository

Next to the implementation repository there is an instance repository. All the DataObjects that are defined in the global or local initialization sections are automatically registered at the instance repository under the configured names.

The following configuration fragment shows the definition of a JDBC connection pool and can be placed in any initialization section.

<object type="JDBCConnectionPool" name="dataSource">
    <dp:paraVal name="connectionUrl"     value="jdbc:oracle:thin:@hispano:49185:ESAU"/>
    <dp:paraVal name="username"          value="system"/>
    <dp:paraVal name="password"          value="managed"/>
    <dp:paraVal name="driver"            value="oracle.jdbc.OracleDriver"/>
</object>

Now we can reference the instance dataSource from the example above. The following configuration fragment shows how the previously instantiated JDBCDataSource can be accessed from an the instance repository.

<dataSource type="JDBCDataSource">
    <dp:paraVal name="query"         value="select name from application where name in (#?)"/>
    <dp:paraVal name="datasource"    value="${inst.dataSource}"/>
    <dp:paraVal name="parameter"     value="${cfg.appl_list}" separator=","/>
</dataSource>

A nevisDataPorter client can programmatically register concrete plug-in instances by using the registerInstance method. E.g., if you run within an application server you may have a javax.sql.DataSource in your JNDI tree which you want to register at the nevisDataPorter so you can use it for all your JDBCDataSource objects.

Input-, output- and control repository

Each entity in a module has its unique name. The input-, output- and control repositories contain records with names identical to the entity currently in process. Thus the input-, output- and control repositories are related to each other.

Each record returned from the DataSource is stored by nevisDataPorter in the input repository under the name of the embedding entity. The input repository is cleared from all data before the new data is written into it. In the output and control repositories, corresponding identically named empty records are created. Then the DataFilter chain is processed.

A DataFilter may access source records from the input repository or variables from the configuration repository to create attributes on the destination objects or values on the control object.

<dataFilter type="ELMappingFilter">
<dp:attrVal name="objectClass"   value="top group" separator=" "/>
<dp:attrVal name="cn"            value="#{in.appl.name}"/>
<dp:attrVal name="description"   value="#{cfg.description}"/>
</dataFilter>

In the example shown above, three attributes are created on the target object: The attribute objectClass is set to a list containing the values "top" and "group". This is configured in a static way, i.e. the two values are read directly from the configuration file. The second attribute is the most common case. The attribute cn is written to the value of the attribute name in the input data object. As the current entity is named "appl" in the example (data not shown), the entity is selected in the input repository through the sub-expression "in.appl". The third attribute description is set to the value of the attribute description stored in the configuration repository ("cfg").

At the end the DataSink exports the destination object to the target system. The records in the control repository are used to pass control messages along the execution path while the records in the output repository hold destination objects to be exported.