The federation server is a transparent layer in the backend core architecture. External tables are connected to the server via plug-ins, in this case via the IXOS connector. The plug-ins convert the OT BLOBs to SAPERION document containers on the fly, as soon as an archive table from a SAPERION client component (web client, rich client, API) has been accessed.
The federation server manages a list of available plug-ins as well as a list of archive tables (SAPERION DDCs). Each table is assigned exactly one plug-in. A plug-in is a loadable software component (DLL, COM, JAR) that is implemented by the federation interface. This makes read access to external data possible (at minimum) and a written migration of the requested data possible (at maximum).
Federation plug-ins work based on tables. SAPERION simulates a “normal” SAPERION index table to all client requests. For this reason, the table has a special virtual SAPERION UID (XHDOC column), which the SAPERION server can distinguish from normal document UIDs, and thus start the federation service. The virtu-al UID must be created by means of the database before it can be used. Only the last 6 characters of a virtual UID are filled; the leading 38 characters are “0”.
At least one SAPERION Java core server in the system will need an IXOS connector, and thus access to the OT archive. When an object is requested via the IXOS connector, the connector writes it to the SAPERION read cache of the core server. From this moment on, objects are accessed via the SAPERION cache, until the objects in the cache have been replaced.
In a multi-server environment, all the servers in the system are asked whether the requested object is already in the cache. Once found, the object is replicated on the server which made the request. In a typical scenario, only one server will have the data in its cache, because that server was connected to the OT archive and converted the data. In this way, even decentralized servers can have access to the OT data. It is worth mentioning that on occasion, table resources must be used, when the data cannot be found in any cache and the request has to be routed to the central server via the IXOS connector. Alternatively, all Java core servers can be fitted with an IXOS connector, in which case they will all need access to the OT archive.
In addition to the external data table, there is a federation server access table (“Federation_Table_ID”). The DDC in which the UUID can be found is stored here for each UUID (XHDOC). In this way access is ensured, even without DDC context, just as is possible via RLINK or Classic Connector, for example.
The IXOS connector is delivered as a WAR file and is installed on Tomcat as a web service. The core server calls up the configuration routines of the IXOS connector via web service. The service uses the Java classic connector to create the document objects in the cache of the core server.