enaio® repository-manager
enaio® repository-manager establishes the connection between SAP® and the enaio® system and organizes and manages storage and retrieval of documents in both enaio® and SAP®.
Data Model in enaio®
The data model in enaio® consists of two structures. One is the technical structure, which is generic and responsible for actual data storage, and the other is the public structure, which consists of a customer-specific object definition. The actual documents (which can be found in the technical structure) are referenced in the public structure with reference documents.
The technical object definition contains one or several folders of a type, which should be known according to the SAP® content repository. Specific documents, such as invoices, can be found in such a folder.
A reference to these documents can be made from the customized object definition (also named 'descriptive structure', for example, customer – project – invoice) with a cross-type reference document (shown as a green arrow).
These references are created via the enaio® data2ecm module.
The name of the descriptive and technical object definition also refers to the access rights of the user accounts. Full access should only be for the technical user for the technical object definition. The technical user is the 'root' user by default. Full access rights for the technical user are required for objects of the object definition.
You can install more than one repository in the enaio® system, each of which represents a separate technical cabinet that should be given a name that indicates the relevant SAP® repository (e.g., SAP_P01_E1).
Technical Object Definition
The technical object definitions are also installed.
The object definition for ArchiveLink consists of a cabinet that contains the following fields:
Field name |
Description |
---|---|
Content repository |
Name of the content repository |
ArchiveLink Version |
ArchiveLink log version number (e.g., 0046) |
Document protection |
Document protection, a user-defined combination of the operations 'r' (read), 'c' (create), 'u' (update), 'd' (delete) defines the ArchiveLink ACL (AccessControlList). If SAP® does not provide information when a document is created, the default value will be valid (normally 'rcud': i.e., the document is protected from all operations). |
DocID |
Document ID that unambiguously identifies the SAP® document. |
Creation Date/Time |
Date and time of creation |
Last modification Date/Time |
Date and time of the last modification |
Barcode |
Optional: Temporary unique ID that can be used to assign a document located in enaio® to a business transaction in the SAP® system. |
Barcode sent to R/3 |
This document flag indicates whether the barcode and thus the document have already been reported to SAP®. |
Barcode processing error | This document property identifies documents in which an error occurred during barcode processing. |
Legal hold lock |
Specifies that the document has to be retained due to legal reasons (legal hold) so that the document or its components cannot be deleted. This property was introduced with version 7.0. It is enabled for specific scenarios only. |
Expiration date |
Retention period for the document and its components This property was introduced with version 7.0. It is enabled for specific scenarios only. |
The cabinet contains the following three document types:
Document type |
Main type |
Description |
Default components |
W-Document |
Used for general documents |
Scanned components |
B/W-Document |
Used for FAX documents. |
Text components |
W-Document |
Used for text documents |
As can be seen from the table, depending on the document type of the SAP® system ('image/tiff,' 'fax,' or 'text') the documents will be saved in the enaio® system with the relevant document types.
The mapping of which MIME type will be saved in which enaio® object type is defined in the configuration of enaio® repository-manager. This separation offers advantages in data storage and archiving, especially when it comes to administration and performance.
The structure of the single document types is always the same:
Field name |
Description |
---|---|
Component_ID |
Component ID ('data' for multipage TIFF files or data, data1, data2, etc. for single page TIFF files) |
Content type |
MIME type (image/tiff or application/pdf, for example) |
FileName |
File name of the 'source file'. As it is always filed through Apache Tomcat's working directory, the name is always a temporary file name. |
Creation Date/Time |
Date and time of creation |
Last modification Date/Time |
Date and time of the last modification |
ArchiveLink Version |
ArchiveLink log version number (e.g., 0046) |
Application Version |
Version number of the application (e.g., 1.0) |
Charset |
Character set (optional) |
Compressionstring |
Compression with gzip is performed by the content server for components with a size that exceeds the adjustable threshold value CompressionSize. This offers advantages for storing, especially for storing print lists that have an uncompressed size bigger than 2 GB. With previous compression they are usually reduced to 10% of the original size. With this administrative information, the content server is able to determine the uncompressed size of the component and which compression parameters have been used. |
Assignment of SAP® Structures to enaio®
It is necessary to map SAP® structures in the technical object definition as part of enaio® repository-manager’s task to map SAP® structures in enaio®.
enaio® object |
SAP® object |
---|---|
Folder |
Documents |
Documents |
Component |
ILM
Only one cabinet with a document type is required for ILM. These are part of the object definition.
-
Cabinet/folder type: SAP ILM collection
-
W-Document type: SAP ILM resource
The ILM objects are managed exclusively by SAP. Displaying in enaio® and other scenarios with reference documents is not relevant because these are not stored in a readable format.