arveo Documentation 28.0.1-SNAPSHOT

When you are inside the company network or the VPN, you can use the internal Nexus that does not require authentication. The following maven settings.xml file shows how to configure the required repositories. The settings.xml file can be found in the .m2 directory in your user home directory.

When you are outside the company network and the VPN, you need to use the public Nexus repository that requires authentication. To do so, maven requires credentials. For security reasons, the credentials should be encrypted. Follow the instructions in the Maven documentation to configure a master password and to create an encrypted password.

You should now have created a settings-security.xml file in the .m2 directory like the one shown below:

Then you have to adapt your maven settings.xml as follows:

Make sure to use only https repositories when using credentials. Current maven versions already block the usage of unencrypted repository connections.

The tests are run automatically in a full maven build. The system-test module is configured to automatically start a complete arveo system including all required services and a database. If you want to run the tests manually from the IDE, you can still use maven to start the arveo system. Open a command line in the system-test directory and run mvn -Denv. Maven will start the following processes:

The services will be kept alive until you press enter in the command line.

This will only work if a complete build has been performed at least once (which can be done through mvn install).

Now you can adapt the generated type definition so that it fits the requirements for our project scenario. In this scenario, documents are organized in a two-level folder structure. For example, the project could contain a folder called "invoices" which again contains two folders named "inbound" and "outbound". Each document is contained in exactly one folder and belongs to exactly one project. The document type will contain the following attributes:

In addition to these custom fields, the document will contain some system fields like content metadata (filename, size, mimetype…​) and versioning information like creation- and update-timestamps.

The two type definition interfaces generated by the archetype are not required and can be removed. Don’t forget to remove the registrations from DemoTypeRegistration.java and the generated test class RecordClientIT.java.

Click Generate and download the zip file containing the generated project. Unzip the file to a directory of your choice and open the project in your IDE. Delete the src/test directory.

Open the generated pom.xml file and add the following dependency to the dependency-management section:

Now you can add the required arveo dependencies to the dependencies section:

The tool will use the Spring Shell library to make it easy to write a command line application with features like usage help and simple parameter binding.You can read more about Spring Shell here.

At first, you have to configure the Spring application and add a custom shutdown handler so that the application will shut down all background tasks on exit.Add the following class:

Go to the de.eitco.demo.tool package and create a new class called "ArveoCommand". This will contain the business logic behind the commands available in the command line application.

Now it is time to implement the import. Add the following methods to the ArveoCommand class:

The importProject method will be used to import a project located in the provided root directory. The scenario does not support files located directly in the root of the project, so we will log a warning when we encounter such a file.

The importLevel1 method will collect all files and directories located in the first level of the project structure. Files will be imported directly, directories will be passed to the next importer method.

This method collects all files located in the second level of the project structure. We do not support deeper structures, so we log a warning when we encounter a directory below level 2.

The method used to actually import data into arveo is shown below:

When you start the application again and type help in the CLI, you will see that our new import command is listed. Typing help import will show information about the command’s parameters.

Now you have to add configuration parameters. The configuration parameters for the command line tool must be added to the file src/main/resources/application.yaml. Create this file if it does not exist already. You can copy the entire spring.security section from the file test/system-test/src/test/resource-templates/application-test.yaml in the demo-types project generated earlier in this guide. Replace the ${keycloak.port} variable with the actual value defined in the pom.xml of the system-test module of demo-types (by default 8180).

In the last step, you have to edit the generated DemoToolApplication class and exclude a Spring autoconfiguration that would cause a conflict with the Oauth2 configuration of the arveo SDK. It is also required to configure the application as a non-web application:

Now we can build and run the command line tool. You can either use the IDE or run mvn clean install in a command line for the project containing the demo tool. After the build has finished, you have to start the test system. Open a command line in the system-test module of the demo-types project and execute the command mvn -Denv (see Running the tests). Now we can use another command line in the target directory of the command line tool project to run the tool. Running java -jar .\demo-tool-0.0.1-SNAPSHOT.jar will start the tool. Typing help in the CLI will show all available commands. Typing help import will show help about the import command.

Finally, here is a complete listing of the ArveoCommand class for copy&paste:

Your project structure must have a certain layout to be successfully imported and archived in arveo.

Here is an example of implementing this structure:

The test system already contains a user that can be used for testing. The user’s credentials are:

To import all projects in the folder, type

The import tool will print a message for each imported file.

To operate arveo successfully the operator of the platform must provide and manage the following services.

arveo relies on industry standards as much as possible to make integrations as easy as possible.

arveo can encrypt the content with AES 256 and thus protect it against unauthorized access. The key is stored in such a way that maximum security is guaranteed. In order not to re-encrypt all data if the key is compromised, own keys are generated. Only the keys used are encrypted with the customer key and stored separately (Encryption). See also Data Integrity.

arveo allows you to organize documents into folders and records. arveo can control the access rights such as reading, writing or deleting to each document via attributes or access lists and thus grant or deny the corresponding access to the groups or users.

Access rights

For us it is important to continuously ensure that all known vulnerabilities are fixed and that we deliver security patches and hotfixes as early as possible to our customers.

To achieve this goal we integrated all kind of state-of-the-art tools like OWASP dependency check in our build process that perform automated static code analysis. We also perform PEN Tests on a regular basis.

What does Eitco to develop, operate and maintain a secure content service platform?

To allow users and 3rd party applications to identify and find objects in arveo you should define a unique and immutable unique identifier property (Data Modelling). The property must be @Unique to ensure that a user or business application can clearly identify the item. The unique identifier should use the taxonomy of business processes and contain all information to clearly recognize the document. Make the property @Readonly to ensure that the identifier is always set and immutable.

The minimizes the risk of incorrect indexing and undetectability of documents because the index is immutable, duplicate identifiers are rejected and the compliant taxonomy ensures that every user can find documents easy and fast. We strongly recommend building a documented, simple but clear taxonomy.

Your business application or the user must set the value when the object is created (@Mandatory annotation), or you can let arveo create a unique value by adding counter annotations. Add the @Autoincrement annotation if a simple sequential Long id meets your requirements.

If you need a more sophisticated unique identifier you can use the annotation _@FormattedCounter which allows you to create e.g. String identifiers like <year>-<sequence> (Unique Identifier Example)

List data types allow you to store more than String or long value for a property. You can search for each value using the array search operation of the arveo query language (Data Types).

Enumeration data types allow you to set one or more values from a fixed set of values.

Enable that the statutory retention periods are assigned to the records, cases and document types (Retention Periods, Retention Rules) and ensure that the storage container are configured correctly (Retention Container) .

Check if the technically assigned retention periods also correspond to the statutory retention periods. Monitor the audit logs to ensure that the retention period is set and is correct. Monitoring could be automated or could be a random control by an employee.

The operating team must ensure that storage container contain only documents with the same retention period. Please do not use the same bucket in different storage profiles or assign a storage profile containing content with retention to different document types.

Grant the deletion right for your storage containers to arveo. If arveo cannot delete the containers, your operating team is in charge of this task, and you must set the option delete rows only.

Configuring storage containers in arveo-service.yaml and your content storage is an ongoing task for your operating team. Eitco will try to create the buckets or subdirectory on your storage system but can also use already existing ones.

It must be ensured that the system time cannot be manipulated (e.g. NTP server). Suitable map measures that a change in the system time is detected promptly.

Because the new legal data privacy / protection act makes it necessary to erase data even before the expected retention period has expired arveo please take care that the content storage has no default hardware retention activated.

All documents in arveo that are subject to retention are available by the REST API and can be downloaded. The integrity and availability of the content is the responsibility of the provider and operator of the platform. The provider must ensure that failures of the storage systems for database and content are identified at an early stage and take appropriate countermeasures. See chapter Fail Safety for technical and organizational measures for high availability of the arveo platform.

In the event that data has to be migrated, arveo offers an extensive export API that enables content and metadata to be exported. arveo saves the hash value (https://en.wikipedia.org/wiki/Cryptographic_hash_function) in the database that was determined when the content was first uploaded (Upload Data). This hash value can be used as a checksum to detect accidental or intentionally corruption of data. If the hash value of the content after the migration is identical to the original hash the migration report proves the correctness of the migration process. To report the completeness of the migration process the arveo API allows you to export a list of all records, cases and documents in a document type.

arveo guarantees high availability, reliability and high performance at all times. The system has to be protected from manipulation attempts by proven and well-thought concepts. The data that is stored and managed in the system is protected via the API. The access and editing rights are managed via attribute based access control. User rights are based on the developed concepts for users, groups and security attributes. More detailed information on this is provided in the relevant chapters of this manual.

Access to all data (documents, metadata) takes place exclusively via the API, with the corresponding protection mechanisms so that the security of the data is guaranteed at all times.

The system operator is responsible for data security and recovery. He must ensure that the backups of the data are checked regularly and that recovery is reliably possible in the event of a failure. The IT processes that ensure the secure, redundant and highly available storage of arveo data in databases and object or file system storage systems are particularly decisive for the proper operation of the platform. These are the responsibility of the operator of the platform, who must implement the availability and security of the systems in accordance with legal and organizational requirements.

We strongly recommend using a redundant file system or object storage system. If you do not at least backup your data periodically a data loss is likely. For high availability with almost zero data loss our storage system should replicate the written content and data synchronously. The operating team of the platform must ensure that an appropriate replication is set up and monitored.

Object storages with REST APIs are designed for the cloud. If you decide to use storage from the Cloud (public or private) we recommend to use object storage via S3 API. Object storages provide a high level of redundancy (even geo redundant) and fail safety. The REST S3 API is very tolerant against network and infrastructure failures.

For the best high availability the provider of your storage system must protect the stored data against accidental, malicious, or disaster-induced loss of data. The better your data replication the better is your availability in case of a failure.

To achieve high availability for arveo the provider must guarantee that all required (content services) run as a cluster.

arveo distinguishes three kinds of data and stores each to the most suitable storage system.

The high availability (HA) of arveo depends highly on the HA of the storage systems for all kind of data. Each of the storage systems and as a result the arveo services follow the CAP (Consistency, Availability and Partition Tolerance) theorem saying that the availability and fail safety of a system depend on:

The CAP theorem in a nutshell predicts that you cannot have all three properties but only two of them.

As arveo is a ECM cloud platform consistency and availability (read/write) of content and metadata are most important. arveo tolerates that network or message failure of either the primary content storage or database node can cause exceptions on the client application. The arveo services do not store data within their containers and focus on scalability and partition tolerance.

arveo support evidence proof long term storage of your content and metadata by storing the content legally secure to either a S3 object storage or a file system. The storage must be redundant. Object storage systems like AWS, NetAPP or EMC Elastic Cloud Storage guarantee the long term availability and integrity of your content.

All changes of content or metadata are persisted as a traceable and immutable version (Versioning) on your storage system and an audit entry is written to the audit log table (Audit Log). arveo creates a version each time metadata including comments and annotations or content of a document is changed by the API arveo} creates a new entry containing the author and the timestamp pf the change in the version management table. The Update API allows you to add a comment to each version. The Version Management API provides access to all version information and metadata and content of previous versions.

For best high availability the provider of your storage system must protect the stored data against accidental, malicious, or disaster-induced loss of data. The better your data replication the better is your availability in case of a failure.

Each arveo service can be configured as a service cluster to achieve HA. Depending on the deployment you can either set up an application server cluster (WAR deployment) or run our containerized applications on a cloud platform like open-stack with kubernetes.

Any document, container or folder type can use the optional recycle bin feature. If it is enabled, entities in the type definition can be moved to and restored from the recycle bin.

The recycle bin is implemented as a boolean database system property DELETED. Entities in the recycle bin will be filtered from normal queries by default, but a client can compose search expressions that override this behavior (see Recycle Bin).

If you delete or purge an object in the recycle bin it is deleted like a document without recycle bin feature and cannot be restored.

arveo consists of several stateless services that allow arveo to automatically scale horizontally. Customers have the choice between an on-premise, cloud or hybrid installation.

The best installation method and the actual steps necessary to set up the system are determined individually for each project.

The deployment may be done as a:

The arveo content services can be provided by EITCO in the Microsoft Azure Cloud in the tenant "eitco-cloud". An integration system and a production system are operated there for the customer. The solution is based on the EITCO cloud stack and is administered via an EITCO management cluster.

Each arveo system has a unique identifier that is part of each entity- and version-id. This concept makes it possible to merge two systems into one. Two systems using the same system identifier cannot be merged because of duplicate entity- and version-ids. The system identifier is a numeric value starting at 0 that must be specified in the configuration file for each installation:

For the installation of the product, certain requirements for the hardware, software and infrastructure to be provided must be met. In a typical cloud environment each arveo service is deployed as a containerized application and is hosted and scaled by a cloud operating system. However, a different setup can be used, depending on the customer infrastructure and the load of the system.

The following chapter describes the minimum CPU and RAM requirements of each arveo service in a production environment.

Assuming that the installation is performed as spring boot services we recommend to set up a minimum of 3 machines. The database and the Content Repository Service carry the highest load and should be deployed on separate machines. All other services and 3rd party services can run on one OS instance. Some services like Archive Link and the Document Conversion Service may consume high CPU and RAM and can make it necessary to outsource them to separate machines.

OAuth2.0 defines several different flows to get an access token. These flows are also called grant types. arveo supports the following flows for user authentication and service authentication.

In Spring Boot applications, the flow to use is configured in the client registration (see example below) in the property authorization-grant-type. The values to set for the different flows are shown in the following table:

To connect the arveo services to an authentication service that supports OAuth2.0, the issuer URI of the authentication service must be configured. Required configuration properties like OAuth2.0 endpoints and public keys will be discovered automatically. If the authentication service does not support auto discovery of configuration options, the required settings can be set manually using the configuration options of Spring Security.

The following example shows a configuration for an arveo service acting as a resource-server using Keycloak.

In case the authentication service uses opaque tokens instead of JSON web tokens, the configuration would look as shown in the next example. In this case, the URI of the token introspection endpoint of the authentication service must be configured.

If the service will communicate with other services, it acts as a resource-server and a client. Therefore, an oauth client must be configured as well. The following example shows a client configuration using the client_credentials grant type for service to service communication:

The arveo services retrieve required information about the user from the access token. The authentication of the user is done by validating the signature of the JSON web token (JWT) or by introspecting the opaque token submitted in the request. Authorization- and additional information of the user like name, e-mail or custom attributes are retrieved from the access token’s claims.

Each arveo service checks the audience (aud) claim of a JWT to ensure that the user is authorized to access the service. The aud claim must contain the service’s name. The following table contains the names of the services.

User rights are read from the scope claim and from a custom claim called authorities. Some services require specific authorities for some features. The required authorities are listed in the service’s documentation.

It is possible to limit the access to a specific service by defining an additional mandatory user right. This can be enabled using the property security.general.role-for-secured-access.

The information read from the access token can be used in ABAC security methods to check a user’s access rights. Sometimes the information in the access tokens might not be sufficient. For example, information about a user’s group memberships might be too big to be stored in an access token. For situations like this, the OpenID Connect (OIDC) user information endpoint can be used to load additional information about a user. Information loaded using OIDC is added to the security context and is available in ABAC security methods, too. To activate this feature, the following configuration parameter must be set:

By default, the URI of the user info endpoint is determined automatically by using the configured issuer URL of the resource-server configuration. Alternatively, the issuer URI for the OIDC lookup can be configured as shown below:

The information loaded from the user info endpoint is cached to avoid frequent requests to the authentication service. By default, the cache entries are kept for 60 minutes. The configuration properties section for the group commons.security.oauth2 contains information about how to change the caching parameters.

Services that require a unique ID of a user use the value of the subject (sub) claim of a JWT or the name attribute of the token introspection response in case opaque tokens are used. The content repository service requires a unique 64 bit integer ID for each user. There are different ways of how to assign these internal IDs to a user. By default, the content repository service assumes that the authentication service is not able to assign numerical IDs and assigns a unique numerical ID to each user when the user performs the first request to the service. The assigned IDs are stored in a database table called cmn_external_users.

The automatic assignment of internal IDs can be deactivated as shown below:

The service will then try to get a numeric ID for the user from the access token by checking for the claim configured in commons.security.oauth2.external-user-management.token-id-resolver.id-claim. By default, the claim user-id will be used. It must contain a value that can be parsed to java.lang.Long.

Keycloak is the recommended authentication and authorization service to be used for arveo. Setup and configuration is covered by the Keycloak documentation. This section contains some best practices and recommendations.

Keycloak uses realms to separate environments. It is recommended to create a separate realm for arveo. The signature algorithm used for the tokens should be RS256, which currently is the default value in Keycloak.

Access to the services and client applications can be controlled by Keycloak clients. Each client should be used for one service or client application. For example, a separate client for service-to-service communication should be created. This must be a confidential client (requiring a client secret) that does only support the client_credentials flow. A client for application-to-service communication does not need to be confidential and should support the authorization_code and/or the resource_owner_password flow.

By default, Keycloak will add several attributes of a user to an issed token like the user’s unique ID in the sub claim. Additional required claims like aud (audience) can be set using token mappers.

When requests from a client to a service or between services fail with a 401 or 403 error code. The request was denied access to the service by Spring Security. Note that the client will still receive a 401 or 403 error code when the actual problem was cause by a request further down the chain between services. It might be necessary to analyze access problems between all services that were involved in the handling of the request. For example, the client might have requested a rendition which had to be generated first. For this, the Content Repository Service will send a request to the Document Conversion Service. When this request was denied access, the client will see a 401 or 403 error code.

When a service denies access for a request, the first things to check are:

The Spring Security framework provides extensive logging capabilities to analyze access errors. To enable full logging, set the logger org.springframework.security to TRACE in all services involved in the request handling.

The X.509 authentication is based on encrypted communication between client and server using SSL or TLS. When establishing the encrypted connection, the server requests a certificate from the client and validates it. Only if this validation is successful, the connection is established. The client certificate data can then be used by the application to authenticate the user. Each client must therefore be issued its own certificate.

Since validation of the certificate is already performed by the server when the connection is established, a service cannot offer open endpoints that do not require authentication, unlike when using OAuth2, for example.

Furthermore, it should be noted that the client certificate cannot be forwarded to other services. Thus, if the service needs to send requests to other authenticated services, another certificate or an authentication mechanism such as OAuth2 must be used for authentication at the downstream services.

X.509 is therefore particularly suitable for internal services such as importers that access the arveo service directly, and for additional security in a service landscape for clients that already use another authentication mechanism.

The X.509 authentication mechanism can be activated as shown in the following example:

In the above example, a PKCS12 keystore is configured for the server certificate and a JKS trust-store for validating the client certificates. With client-auth: need the server is instructed to request a certificate from the client (Spring documentation).

The OAuth2 authentication mechanism must be deactivated by setting the following configuration properties:

To extract the name of the user from the certificate, a regular expression is used to parse the subject of the certificate. By default, the value of the CN property is used for the username. This behavior can be influenced by defining your own regular expression. The regular expression must define exactly one group with the desired value.

To be able to access the arveo services from a client application or to authenticate requests from one arveo service to another with X.509, an appropriately configured HTTP client must be used. Both the Java Client SDK and the services provide configuration properties to enable X.509 for the HTTP client:

Here the HTTP client is assigned a PKCS12 keystore with the client certificate and the X.509 authentication is enabled. The OAuth2 authentication mechanism used by the HTTP client by default must be disabled:

The following example shows how to use OpenSSL to generate a pair of self-signed certificates for client and service.

A common architecture consists of a front service that exposes an API to human users and a back service (the Content Repository Service) that the front service calls to do part of the work.Both services are OAuth2 resource servers and validate the bearer token of the incoming request.

When the front service calls the back service, it has two options:

The OBO flow implements the second option. It replaces the older, non-standard impersonation feature with the standardized OAuth2 token exchange grant.

The OBO flow relies on Keycloak’s Standard Token Exchange (token exchange V2), which is available from Keycloak 26.2. It does not require the legacy fine-grained admin permissions of the older token-exchange implementation.

Two clients must be configured: the OBO client used by the front service to perform the exchange, and the user-facing client whose tokens are exchanged.

Both services use the EITCO Spring Security OAuth2 starters (de.eitco.commons:cmn-spring-security5-oauth2-*). See the library README for the full reference; the settings relevant to the OBO flow are summarized here.

To prevent overload of the database, timeouts for statements and transactions can be configured. By default, the system uses a timeout for statements of 15 minutes and a timeout for schema modification statements of 30 minutes.

The example above sets a timeout of 10 seconds for generic statements (queries, inserts…​) and 60 seconds for schema modification statements. The configuration properties can be found in the configuration properties overview.

Only Documents can contain content elements. A Document in the repository can contain several content elements. For example, a document could contain a content element with the original content (like a TIFF image or a Word document) and a PDF rendition. Each content element has a contentName and some more properties like the media type. The contentName is a label that uniquely identifies a single content element contained in a Document. For example, a Document might contain two content elements that are identified by the contentNames 'content' and 'rendition'.

The contentNames are not only relevant for uniquely identifying a content element contained in a document, but serve as reference for further customization of the repository. The repository does accept configuration options that are directly related to contentNames and the Document type definitions define restrictions regarding the allowed contentNames.

Type definitions define which contentNames can be contained in the entities stored in the definition.

Each content element is stored in a storage profile, which defines the place where the actual content will be stored. The contentType parameter can be used to define what kind of content a content element can contain. When the media type is set to application/octet-stream, any kind of content can be used.

It is specified in the type definition, which content elements this type definition may have.

The content elements of the entities are stored in a JSON field in the database which contains the storage-ID and additional metadata like size, media type and a hash. The actual content data is not stored in the JSON field.

The following example is an object of type Document, for which two content elements are defined: "content" and "LARGE_CONTENT".

Using the contentType attribute of the @ContentElement annotation one can define the required content type for a content element. The content type application/octet-stream is used as a wildcard type for any type of content. For example, if the value of the contentType attribute is set to application/pdf, only PDF files can be stored in the content element.

It is possible to define the content type of a new content element when it is uploaded. The server will trust this information, so the client is responsible to send the correct content type. If the client does not define the content type, the server will automatically detect the content type of the uploaded binary data.

If a type definition of type DOCUMENT does not contain any @ContentElement annotations, the server will automatically assign a content element with the name content to it. This content element accepts any kind of content type.

The following Table contains an Overview of the available attributes of the @ContentElement annotation.

A StorageProfile defines on which storage the content elements are saved. Access to the storage backends (like filesystem or S3) is handled by storage plugins.

A StoragePlugin is defined in the StorageProfile, which is used to access the connected storage. The same plugin can be used in several StorageProfiles. Each StorageProfile can have a different set of parameters (access data, URls, …​) for the plugin.

Each profile is identified by name and defines the storage plugin to use. Plugin-specific settings can be configured in the pluginSettings map. So the plugin class name determines the storage technology and the plugin settings.

If a content element has been saved using the named StoragePlugin, the plugin defined in the profile will return a contentID, with which the stored data can be retrieved later. This id, which is usually of type String, is saved with the document. It is a task of the storage plugin to implement, which contents this id has. Usually it is a UUID, but it may also be a text string.

A plugin is assigned to each profile based on the fully qualified class name. Any name-value pairs can be specified for the configuration of the plug-in. The profiles are identified by their name.

There are two ways to map a specific content element to a storage profile.

The following example shows the simplest possible configuration. The type definition does not contain any content element. It implicitly uses the default content element named content. The content element will be stored in a storage profile called my_document, or, if no such profile exists, in the default storage profile.

The next example shows the same type definition, but with an annotation that defines which storage profile to use.

The next example shows a type definition that contains two content elements. The "rendition" content element will support only PDF documents. The PDFs contained in the rendition content element will be stored in an S3 storage. The content in the other element will either be stored in a profile called my_document-content, in a profile called my_document or, if neither of those profiles exists, in the default profile.

Large content elements can be stored in several chunks to improve download performance and to avoid timeouts in storage plugins using remote storage systems like S3. It is recommended to use chunking for large content elements and when clients are expected to perform partial downloads. Clients use partial downloads or ranged requests to resume failed downloads or in scenarios like video streaming.

The service uses a plug-in interface for connection to the specific storage provider. The following plugins are currently available:

Class name: de.eitco.ecr.server.storage.plugins.BucketOrganizerPlugin.

The BucketOrganizer is not specific for a specific storage technology or storage interface but delegates storage requests to other storage plugins.The selection of the target plugin depends on the retention information of the document that contains the content element to be stored. The selection criteria that are used to select the target plugin can be configured in terms of a list of bucket selection rules.

The relevant retention information of the document is defined by the values of the system fields RETENTION_DATE and LITIGATION_HOLD. This value pair is matched against the bucket selection rules.The matching process starts with the first rule and continues to the next rule if the rule does not match the value pair.The matching process ends at the first rule that matches the value pair.The storage profile named in this rule will be used to store the content. Each bucket selection rule consists of three parts that are separated by the pipe (|) symbol.

As mentioned above, arveo uses a plugin interface for the connection to the storage backends. This section describes how to write a new storage plugin.

All classes and interfaces required to implement a custom plugin are contained in the dependency

A storage plugin must implement the interface de.eitco.ecr.server.storage.StoragePlugin. Custom plugins should extend the class de.eitco.ecr.server.storage.AbstractChunkingStoragePlugin. This abstract implementation provides support for chunking and encryption. Plugins that do not use a retention-aware storage-backend should extend the class AbstractSimplifiedStoragePlugin.

In addition to the interface to implement, there are some guidelines to respect when writing a custom storage plugin:

When the creation of a rendition fails, the system will re-try to create the rendition. The number of re-tries can be configured, the default is three (see configuration properties). When all retries have failed, the rendition message will be added to a dead letter queue and the status field of the rendition will be set to -1 (FAILED). For this to work, the message queue in ActiveMQ must be configured to use an individual dead letter queue as described in the ActiveMQ documentation.