FirstSpirit Object Service - Documentation for Developers

e-Spirit AG

FirstSpirit Version 5.x

2017-10-06
Table of Contents

1. Introduction

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:

  1. 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.

  2. 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.

1.1. Architecture

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 FirstSpirit Object Service module installed on the FirstSpirit Server
  • The UX-Bridge including the UX-Bus
  • The FirstSpirit Object Service (FOS) including its internal persistence layer
  • The portal server including the portal-specific Portal Plugin

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.

Architecture
Figure 1. Architecture


The individual components always interact in accordance with the following schema:

  • A change to content made on the FirstSpirit Server creates messages during a generation operation, which are made available on the UX-Bus. These messages contain all relevant information on the modified data.
  • The FirstSpirit Object Service (FOS) receives the messages and refreshes the data inventory stored in its internal persistence layer. It then uses the data matching procedure carried out during this step to determine which data has been changed exactly. The FOS passes the result of the alignment on to the Portal Plugin of the connected portal via the UX-Bus in the form of event messages, after it has first indicated the start of the schedule by sending a status message. The portal is informed of potential changes to content via ChangedContent messages. The information transfer is concluded by another status message.
  • The Portal Plugin accepts these service messages and triggers a refresh operation of the data's live state within the portal. Depending on the portal, the information contained in the event message may not be sufficient for the refresh operation. In this case, the Portal Plugin requests the required data from the FOS via its REST interface, to enable it to perform the refresh.

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.

1.2. Portal Plugin

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.