The Alfresco Records Management (RM) modules are installed on top of Alfresco Content Services and use a similar REST API and service architecture. This document provides an overview of the standard patterns that have been used throughout the RM modules.
RM is split into two main parts - a repository integration and a Share integration. The Share module communicates with the repository module using REST API calls. The repository module includes integration with the Alfresco database.
- Community Source Code
- Enterprise Source Code (for partners and customers)
- Community License
- Enterprise License (this file will only be present in clones of the Enterprise repository)
- Issue Tracker Link
- Community Documentation Link
- Enterprise Documentation Link
- Contribution Model
An understanding of Alfresco Content Services is assumed. The following pages from the developer documentation give useful background information:
The RM Share module communicates with the repository module via REST APIs. Internally the RM repository module uses a three layer model:
- A REST API layer responsible for converting API requests into service calls.
- A Java service layer responsible for handling business logic.
- A DAO layer responsible for CRUD operations against the database.
The REST API endpoints fall into two main types - v0 (Webscripts) and v1. The v0 API is older and not recommended for integrations. The v1 API is newer but isn't yet feature complete. If you are running RM locally then the GS API Explorer will be available at this link.
Internally the GS v1 REST API is built on the Alfresco v1 REST API framework. It aims to be consistent with this in terms of behaviour and naming.
The Java service layer is fronted by a Java Public API, which we will ensure backward compatible with previous releases. Before we remove any methods there will first be a release containing that method deprecated to allow third party integrations to migrate to a new method. The Java Public API also includes a set of POJO objects which are needed to communicate with the services. It is easy to identify classes that are part of the Java Public API as they are annotated @AlfrescoPublicApi.
Each Java service will have at least four beans defined for it:
- A 'lowerCase' inner bean, which is the actual service implementation.
- An 'UpperCase' wrapper bean, which includes security and transaction management. This is the bean that should be used by third party integrations.
- A bean to handle transactions on the service methods.
- A bean to handle security restricting who can call different service methods.
The DAOs are not part of the Java Public API, but handle CRUD operations against RM stored data. We have some custom queries to improve performance for particularly heavy operations.
We use standard Alfresco data modelling to store RM metadata. We extend the Alfresco patching mechanism to provide community and enterprise schema upgrades.
| Decision | Rationale | Date |
|---|---|---|