Home > Engine & Repository

Repository Administration

This section specifies EBX.Platform repositories administration, including their installation and migration.

Technical Architecture

This section describes installation and deployment constraints.

Single repository per Java Virtual Machine (JVM)

A JVM that runs EBX.Platform is limited to a single EBX.Platform repository.

Single JVM per repository

A repository cannot be shared by several JVMs. If such a situation occurs, it may lead to unpredictable behaviors.

In this version, EBX.Platform does not ensure itself a locking that would guarantee the above constraint. Hence, it is the responsibility of the administrator to verify it.

Exception: several JVMs may share a single repository if all these JVMs do not perform updates on the repository.

Multiple repositories per relational database

EBX.Platform supports multiple repositories on a single relational database instance. This is possible by the specification of distinct tables prefixes (property ebx.persistence.table.prefix ).

New repository installation

If the specified EBX.Platform connection has, on the relational database, the rights to create tables and indexes, then the repository installation is done automatically. Otherwise, the administrator has to execute the SQL scripts located in the ebx.jar file at the following paths:

  • com/onwbp/adaptation/rep/rdb/oracle/ddl.sql for Oracle.

  • com/onwbp/adaptation/rep/rdb/db2/ddl.sql for DB2. Note that on DB2 Z/OS, the datatype BIGINT is defined from "version 9.1" and more. For the previous versions, we can use the datatype DECIMAL(19,0) instead of the datatype BIGINT. If we work with those Z/OS versions, we have to replace BIGINT by DECIMAL(19,0) in the above "ddl.sql" file.

  • com/onwbp/adaptation/rep/rdb/sqlserver/ddl.sql for SQL Server.

  • com/onwbp/adaptation/rep/rdb/postgresql/ddl.sql for PotgreSQL.

  • com/onwbp/adaptation/rep/rdb/hsql/ddl.sql for HSQLDB.

If the property ebx.persistence.table.prefix has a specific value, the administrator should prefix the names of all the tables and indexes with this value.

Automatic migration of a 3.7 repository

If the target database is empty and the source repository of version 3.7 is correctly located, EBX.Platform performs an automatic migration of the source repository. It is launched when server is started up (more precisely when a first request triggers EBX.Platform cache initialization).

The process is the following:

  1. Install a new EBX.Platform environment. Its ebx.properties file must refer to a specific repository through properties ebx.persistence.factory, ebx.persistence.url and optionally ebx.persistence.table.prefix.

  2. Provide a source repository. The folder ebxRepository/Adaptation/ must contain a fileSystem_3.5 repository as the installation source.

  3. Optionally edit the file ebxRepository/Adaptation/.ebx-private.  The value of property repositoryId must be changed so as to be unique in the enterprise (it must have 12 hexadecimal digits).

  4. Startup the new EBX.Platform environment and launch a Manager.

The migration will complete only if all schemas used by adaptations in the repository to migrate are correct (no validation errors).

This process allows to install several repositories on a single relational database instance (by specifying distinct prefixes on property ebx.persistence.table.prefix ).

Repository backup

Repository backup is delegated to the underlying RDBMS (Relational DataBase and Management System). The database administrator must use the standard backup procedures of the underlying database.

Repository attributes

A repository has the following attributes:

  • repositoryId. It uniquely identifies a repository (at least in the scope of the enterprise): it is 48 bits (6 bytes), and it is usually represented as 12 hexadecimal digits. This information is used for generating UUID (Universally Unique Identifier) of entities created in the repository and also of transactions logged in the audit trail (it plays the role of the 'UUID node' part, as specified by RFC 4122 ).

  • repository label. It provides a label for the user so that he knows the purpose and context of the repository (for example, «production environment»).

  • store format. It identifies the underlying persistence system, including the current version of its structure.

Data Source Configuration

The persistence data source of the repository has to be configured by the administrator in the persistence part of ebx.properties file. He can configure the data source either manually or by specifying a JNDI (Java Naming and Directory Interface) on his J2EE server that will define the connection to this data source (for instance, see Oracle data source configuration on WebSphere Application Server 6 or SQL Server data source configuration on WebSphere Application Server 6 ).

Archives directory

Archives are stored in a sub-directory named archives into ebx.repository.directory (see configuration ). This directory is automatically created during the first export.

When manually creating this directory, be careful of the access rights: the EBX.Platform process must have read-and-write access to it.

Note: The file transfer between two EBX.Platform environments must be done outside the product. Tools such as FTP or simple files copies through network sharings are efficient.

Furthermore, cleaning the directory is not done by EBX.Platform and is the responsibility of the administrator.

The following drawing illustrates this procedure:

o3

Monitoring and Purge

Application Server Runtime

EBX.Platform is monitored through the monitoring of the J2EE application server.

Relational Data Base

The persistence data source of the repository must be monitored through RDBMS monitoring.

File System

In order to guarantee the correct operation of the software, the disk usage and disk availability of the following directories must be supervised:

It is important to note that:

  • The cleaning of the above directories is not ensured by EBX.Platform: this is the administrator's responsibility. 

  • For audit trail, if large transactions are executed with full updates detail activated (the default setting), the disk space needed can be quite large. For more information, see Audit Trail section.

See also configuration / tuning section.

EBX.Platform Repository

Some entities are accumulated during the execution of EBX.Platform. It is the administrator's responsibility to monitor and to purge these entities.

Branches and versions

In order to keep the cache and the repository to a reasonable size, it is recommended to close branches and versions when they are no longer used, and to periodically purge them. For more information, see Branch and version: purge & reopen section.

User interactions

User interactions are used by the Manager Component as a reliable means for an application to initiate and get the result of a service execution. They are persisted in the technical branch "ebx-interactions". It is recommended to regularly monitor the user interactions table, as well as to clean it, if needed.

Workflow history

The workflow events are persisted in the workflow history table, in the technical branch "ebx-workflow-execution". This table is continuously filled. Please note that when a process terminates normally, the records are not deleted. It is recommended to regularly delete old records.

 

Home > Engine & Repository