FirstSpirit enables customer-specific projects, which are subject to a huge variety of different requirements, to be realized. One of these requirements is often to transfer the content maintained in the content management system (CMS) to a portal server and then use it there.
With its open and expandable system architecture, FirstSpirit provides the optimum conditions for integrating editorial content into various portal servers, such as SAP, IBM, Liferay or Sharepoint.
Particular benefits can be achieved by combining a portal server with the FirstSpirit CMS, as this sees the individual technical characteristics of a pure portal-server solution, such as sophisticated navigation adaptations, complemented by the functional strengths of the FirstSpirit system and transferred into a successful complete system.
Portal integration with FirstSpirit always consists of two parts:
Components on the FirstSpirit side
These components are used to determine and prepare the necessary editorial data, and to transfer it to the portal server. They are usually generic, i.e., independent of the specific portal server to which the data is being transferred.
Components on the portal side
These components are used to process the editorial content and transfer it from the CMS into a specific portal server; therefore, they are always particular to a certain portal server.
This document will describe the components on the FirstSpirit side and their functionalities in order to depict the requirements for implementing the necessary component on the portal side. The component on the portal side is explained in separate documentation.
This document is aimed at portal developers, who should be able to implement the possibility of portal integration with its help. It is not a handbook for FirstSpirit developers or editors. As a prerequisite, the reader must be confident in using FirstSpirit version 5.x and already be familiar with UX-Bridge. |
A portal is connected to FirstSpirit through an architecture consisting of components which are coupled to one another (see figure Architecture).
These components are:
The Portal Plugin deals with importing the content into the connected portal. It is made available by the respective portal provider, who describes it in detail in separate documentation.
The individual components always interact in accordance with the following schema:
The contents from FirstSpirit (images, texts, etc.) are not transferred from the FOS. If you wish these to be available, they must be transferred separately. There are several processes for implementing this. For example, the contents can be transferred via the UX-Bridge. However, we recommend a solution using a file system.
The Portal Plugin is the connection element facilitating communication between the FirstSpirit Object Service (FOS) and the portal. It receives the service messages pushed by the FOS via the UX-Bus and itself uses the REST interface of the FOS to communicate with the latter (see figure Communication between the FOS and the Portal Plugin).
The REST interface is used to query further data from the FOS if the information transferred is not sufficient for refreshing the data inventory in the portal. Ideally, this step is omitted.
In the case of a full generation operation, the affected project is set to maintenance mode in the FOS and the Portal Plugin is informed when it starts and ends. No further information is sent, nor is it possible to query data for this project via the REST interface (see chapter Maintenance mode).
Once the maintenance mode has been terminated, the Portal Plugin independently performs a complete alignment process, whereby it discards the portal's entire existing data inventory and reads it in again using the REST interface.