All OT document information and custom attributes can be found in the archive table (e.g. ixos_v1). The data regarding the components of the document are saved in a separate component table (ixos_comp). Every component has a unique name (e.g. application/x-pdf). All information about the data container (ISO images) of the OT archive is saved in the ixos_volume table. The three tables are created via the database from the existing OT system tables and the attribute tables.
The OT archive data are stored in ISO containers. If the data are on a Centera, they are accessed via the Centera API and a Clip ID. When using NetApp, the storage location is defined by a path. An original as well as a backup storage location are created for each ISO image. The OT documents are stored in directories within the ISO. The document content and metadata can be found in the directory.
Storage formats in the OT archive:
- With normal documents, each component is saved as a single file. The name is found in the [COMPSNAME] column. Each component is compressed and can be decompressed with the IXZIP tool.
- Meta components are a combination of several components of the same type (e.g. PDF). An index file can be found in the directory, or is specified in the ATR file.
- BLOB files are data containers for multiple files of different types. Individual files can be unpacked with the IXBLOB tool.
| <Archive table> (e.g. Ixos_v1) | This table is found in the SAPERION database and contains all the index information needed to display a document in the results list. A sample table configuration is defined in the “Ixos_v1.ddc” file. In addition, there is a query form (“Ixos_v1_q.qbe”) as well as an index form (“Ixos_v1_i.qbe”). When you have multiple IXOS tables, you can define multiple federation connectors in the SAPERION core server plug-in in the MMC. |
| Federation_Table_ID | In the Federation_Table_ID lookup table, a document (XHDOC) is allocated for each archive table. |
| Component table (ixos_comp) | A table with component information. The archive and component tables are joined (1:n) via the SAPDOCID and DOCIDSTR columns. |
| Volume table (ixos_volume) | A table with the ISO image information. The component and volume tables are joined (1:1) via the VOLID[1-3] and VOLID columns. |
| IXOS service | This web service pulls the actual document data from the Siemens archive, and can either run over an Apache Tomcat or be started as a separate service. |
| Federation connector | This connector is an integral part of the Java core server, and creates the actual connection between the SAPERION software and the OT service. The federation connector is responsible for exactly one archive table (Ixos_v1) in the SAPERION database. To create multiple archive tables with index information, multiple federation connectors can be created and configured. |
| OT archive | The actual documents are found in this pool. These are structured in ISO containers, which in turn are referenced via Clip IDs. |
The following illustration demonstrates the respective components and how they function.
The SAPERION Rich/Web Client connect to the Java core server and requests the corresponding doc-ument structure. The Java core server discerns from the document UID (XHDOC) that the structure can be found in the OT archive. Based on the configuration in the MMC, the request for the document structure is assigned to the corresponding federation connector.
The federation connector knows from its configuration which URL it needs to use to reach the IXOS service, and sends off a request for the document structure.
The IXOS service then retrieves the index information about the requested document from the archive table. Among other information, the table contains the VOLID which is used to look up the ISO storage location in the ixos_volume table.
Next, the IXOS service needs the directory structure of the referenced ISO container. With this directory structure, the IXOS service can detect exactly where the requested document can be found in the ISO container, without having to load the entire ISO. The directory structure is read when the ISO container is accessed for the first time, and then stored to an internal cache. Based on the component information, the IXOS service can determine the path of the document structure in the ISO and thus read out the needed data. In other words, the IXOS service doesn’t read the entire ISO, but only the needed documents. The cache of the directory structure disappears once the IXOS service is restarted.
If the IXOS service was able to successfully provide the document structure, the structure is stored to the SAPERION cache. All client or API access requests happen via this cache and thus the document can be used in all SAPERION modules.
For successful access via RLINK (SAP), the SAPERION document also supports the following variable:
| SAPDocProt | contains the access rights to the document, where R=Read, C=Create, U=Update, D=Delete, e.g. “RCUD” |
For successful access via RLINK (SAP), the subcomponents also include the following variables:
| SAPProtocol | currently set to the value “0045”. |
| SAPComponentId | contains the table value of the column COMPONENT |
| SAPContentType | contains the table value of the column COMPTYPE_NAME |
| SAPCreateDate | contains the table value of the column DOCDATE |
| SAPCreateTime | contains the table value of the column DOCTIME |
| SAPModifyDate | contains the table value of the column MODDATE |
| SAPComponentLen | contains the table value of the column CLENGTH |