Export Section

The Export section contains a list of module definitions.

Module

Every module represents a unit of work which can be executed individually, and consists of an optional local initialization section and a list of entities. The local initialization section (in contrast to the global initialization section) is executed when the initialization method of the module is called. Local initialization sections can be used in application servers when you have to do personalized initialization, e.g., based on the current subject.

Each module defines a set of objects on the target system. The following example shows an export section containing two modules. Each of these modules can be run individually. If module "A" is run, the nevisDataPorter creates an organizational unit called "applications" in the LDAP directory and if module "B" is called, the nevisDataPorter creates an organizational unit called "users" on the same LDAP instance.

<export>
  <module name="A">
    <object type="LDAPConnectionPool" name="initalContext">
      <dp:paraVal name="connectionUrl" value="ldaps://aldvia.zh.adnovum.ch"/>
      <dp:paraVal name="username" value="cn=admin,cn=users,dc=durg,dc=local"/>
      <dp:paraVal name="password" value="password"/>
    </object>
    <entity name="ou_appl">
      <dataFilter type="ELMappingFilter">
        <dp:attrVal name="objectClass" value="top organizationalUnit" separator=" "/>
        <dp:attrVal name="ou" value="applications"/>
      </dataFilter>
      <dataSink type="LDAPDataSink">
        <dp:paraVal name="ldapContext" value="${inst.initalContext}"/>
        <dp:paraVal name="basedn" value="${cfg.basedn}"/>
        <dp:paraVal name="rdn" value="ou=#{out.ou_appl.ou}"/>
      </dataSink>
    </entity>
  </module>

  <module name="B">
    <object type="LDAPConnectionPool" name="initalContext">
      <dp:paraVal name="connectionUrl" value="ldaps://aldvia.zh.adnovum.ch"/>
      <dp:paraVal name="username" value="cn=admin,cn=users,dc=durg,dc=local"/>
      <dp:paraVal name="password" value="password"/>
    </object>
    <entity name="ou_user">
      <dataFilter type="ELMappingFilter">
        <dp:attrVal name="objectClass" value="top organizationalUnit" separator=" "/>
        <dp:attrVal name="ou" value="users"/>
      </dataFilter>
      <dataSink type="LDAPDataSink">
        <dp:paraVal name="ldapContext" value="${inst.initalContext}"/>
        <dp:paraVal name="basedn" value="${cfg.basedn}"/>
        <dp:paraVal name="rdn" value="ou=#{out.ou_appl.ou}"/>
      </dataSink>
  </module>
</export>

Entity

A module contains a list of entities. Each entity describes how data is collected from a data source, how it is transformed and stored on a DataSink. See also the description of entities at 3.2.1, General overview, page 8. Each entity in a module consists of an optional DataSource, an optional list of DataFilters and at least one DataSink.

Errors can be handled on the entity level using the optional attribute onError:

• stopModule (default): If an exception is thrown, it is rethrown and the export of the whole module is terminated.
• stopEntity: If an exception is thrown, it is logged and the export of the entity is terminated. nevisDataPorter continues to export the subsequent entity.
• continue: If an exception is thrown, it is logged and the export of the object is terminated. nevisDataPorter continues to export the subsequent object.
• retry: If an exception is thrown, nevisDP attempts to retry for a configurable number of times (maxRetries), while waiting for a configurable amount of time (retryWait in seconds) between retries.

Entities can be nested. For every data object the export of the sub-entities is triggered as soon as the DataSink has finished its operation. For example:

<entity name="parent ">
  <dataSource />
  <dataFilter />
  <dataSink />
  <entity name="child">
    <dataSource />
    <dataFilter />
    <dataSink />
  </entity>
</entity>

Entities can be annotated with a unique ID. This ID can be used to reference entities across modules. This feature is used to avoid redundancy in the configuration.

For example:

<entity name="someName" id="someId">
<entity ref="someId" />

info

Entities must either use name and ID or reference an existing ID.

DataSource

A DataSource describes how to collect data that has to be exported. Therefore, the configuration defines the concrete DataSource implementation to be used through the type attribute.

The concrete configuration of a given DataSource implementation is configured using the paraVal, paraList, paraMap and paraDSource elements. They correspond to the elements in the configuration section (see Configuration Section).

The list of available configuration parameters depends on the concrete implementations. The following example shows a possible configuration of the JDBCDataSource.

<dataSource type="JDBCDataSource">
  <dp:paraVal name="query" value="select id, name from resource where name in "/>
  <dp:paraVal name="parameter" value="${cfg.applist}" separator=" "/>
  <dp:paraVal name="datasource" value="${inst.dataSource}"/>
</dataSource>

DataFilter

A DataFilter describes how to construct attributes on the target record to be exported based on the source record provided by a DataSource. Its configuration basically consists of a bunch of transformation rules. The configuration defines the concrete DataFilter implementation to be used through the type attribute.

The concrete configuration of a given DataFilter is given by three different sets of configuration parameters:

• The first set is used to instantiate a filter instance (constructor arguments). For example, for DataSources and DataSinks, the paraVal, paraList, paraMap and paraDSource elements are used.
• The second set defines the transformation rules used to create the attributes on the target object. These are defined by using the attrVal, attrList, attrMap and attrDSource elements.
• The third set is used to create control values (see also Attribute and Control Values) using the ctlVal, ctlList, ctlMap and ctlDSource elements.

These three sets correspond to the elements used in the Configuration section. By default, all attributes and control values are required and must not evaluate to null. The XML- attribute required can be set to false to skip an attribute or control value which evaluated to null.

The following example shows a possible configuration of the ELMappingFilter.

<dataFilter type="ELMappingFilter">
  <!-- parameters -->
  <dp:paraVal name="skipwhen" value="#{in.app.DELETED}" />
  <!-- attributes -->
  <dp:attrVal name="objectClass" value="top group" separator=" "/>
  <dp:attrVal name="cn" value="#{in.appl.NAME}"/>
  <dp:attrVal name="description" value="#{in.appl.DESC}" required="false"/>
  <!-- control values -->
  <dp:ctlVal name="operation"  value="#{in.appl.ACTIVE ? 'createOrUpdate' : 'update' }"/>
</dataFilter>

DataSink

The DataSink defines where the target record created by the list of DataFilters has to be stored (e.g., it defines how to access the LDAP directory and where in the tree the target record has to be stored by defining a base DB and an RDN). The configuration defines the concrete DataSink implementation used through the type attribute.

The concrete configuration of a given DataSink implementation is given by the paraVal, paraList, paraMap and paraDSource elements. They correspond to the elements in the Configuration section. The list of available configuration parameters depends on the concrete implementations.

The following example shows a possible configuration of the LDAPDataSink.

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