FirstSpirit Object Service - Administration and Configuration

e-Spirit AG

FirstSpirit Version 5.x

2017-10-06
Table of Contents

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

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.

The portal interface presented in this document relates exclusively to the components on the FirstSpirit side, which are identical for all portal integrations and, as such, independent of the specific portal server. The components on the portal side are described in separate documentation.

In the context of portals, a project's configuration is portal-specific.

For this reason, the portal manufacturer's configuration instructions may differ from the description contained in this document.

Therefore, an alignment must be performed in each case in order to prevent work steps being duplicated and avoid irritation.

This document is aimed at technical project managers and FirstSpirit developers. It is not a handbook for editors.

As a prerequisite, the reader must be confident in using FirstSpirit 5.x and already be familiar with UX-Bridge.

1.1. Functional comparison

The redeveloped portal interface offers significant advantages compared to the old version. The comparison below shows this too:

Table 1. Feature comparison matrix
FeatureOld portal interfaceNew portal interface (FOS)

Update complete sub(trees)

Increment update for navigation and content

Support for all FirstSpirit elements

Expandability of the interface in the project

Inheritance of metadata and permissions

Editor permissions are available



1.2. Topics covered in this documentation

This document describes the interface for connecting portals to FirstSpirit and covers the components required to do this, as well as how to install and configure them.

Chapter 2: The components required for connecting a portal are summarized and described in this chapter.

Chapter 3: This chapter explains how the components used are installed and configured.

Chapter 4: An SSL configuration which may be required is described in this chapter.

Chapter 5: All the adaptations which are necessary in the FirstSpirit project are described in this chapter.

Chapter 6: This chapter presents the FirstSpirit Object Service Admin Interface.

Chapter 7: A comparison of the previous and new interface for integrating a portal can be found in this chapter.

Chapter 8: Certain specific terms used in this document are listed and explained in this chapter.

Chapter 9: This chapter contains e-Spirit AG's legal notices relating to the module described in this documentation.

2. Components

Various components are needed for the portal connection:

The individual components are presented in detail in the following sections.

Architecture
Figure 1. Architecture


The portal-specific Portal Plugin, which deals with importing the content into the portal, is also found within the portal server. This component is described in separate documentation made available by the respective portal provider.

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

  • Editorial changes made in FirstSpirit are transferred to the FirstSpirit Object Service (FOS) via the UX-Bus during a generation operation. The FOS then refreshes its internal data model (see step 1 & 2 in figure Architecture).
  • The FOS determines the changes made and informs the Portal Plugin by means of an event message (see step 3 & 4 in figure Architecture).
  • If the information contained in the event message is not sufficient to refresh the data in the portal, the Portal Plugin requests all the data necessary for a refresh operation via the REST interface of the FOS.

2.1. UX-Bridge/UX-Bus

The UX-Bridge, together with its associated UX-Bus, forms the central element for transferring FirstSpirit content into a portal (see figure Architecture).

The communication required to exchange data between the components which are only coupled to one another loosely is realized via the UX-Bus, which collects all messages into a "central" location and makes them available to the components. The components then retrieve the information which is relevant to them from the UX-Bus and process them further accordingly.

The fundamental advantage of the UX-Bus is the ability to decouple the FirstSpirit Server from the portal server from a technical point of view. This creates a robust and stable infrastructure. A temporary non-availability, caused by maintenance work, for example, is reliably smoothed out by this structure.

Furthermore, decoupling allows more than just one FOS or portal server to be connected. The data managed in FirstSpirit can therefore be distributed across multiple live or test systems, whereby the respective data inventories of the various systems can be distinguished from one another, since every component only ever responds to and processes the messages intended for it.

More information is contained in the UX-Bridge documentation.

2.2. FirstSpirit Object Service module

The FOS module is the component that needs to be installed on the FirstSpirit Server (see figure Architecture).

The functions made available via the module on the FirstSpirit Server can be used to create messages and forward them to the UX-Bridge. These messages are produced by means of a generation operation performed on the FirstSpirit Server and are made available to the FOS on the UX-Bus. They contain all relevant information on the modified data of the FirstSpirit project being used and, as such, inform the FOS of the changes which have been made.

The FOS module represents the starting point of the communication chain between the individual components, in that it collects the relevant information, compiles it, and forwards it to the next component by using the UX-Bus.

2.3. FirstSpirit Object Service (FOS)

The FOS is the link between FirstSpirit and the portal server (see figure Architecture).

It accepts the messages made available via the UX-Bridge on the UX-Bus and refreshes the data inventory stored in its internal persistence layer. In so doing, it uses data matching on the messages received in order to determine which data has been changed exactly. The FOS passes this information on to the Portal Plugin of the connected portal via the UX-Bus in the form of an event message (see chapter UX-Bridge/UX-Bus).

The Portal Plugin of a portal server receives this event message and triggers a refresh operation of the data's live state within the portal. Depending on the portal, the information contained within the event message may not be sufficient for the refresh operation. In this case, the Portal Plugin requests the required data from the FOS in advance, via its REST interface. This may only be a modified element or a subtree, depending on the implementation of the Portal Plugin.

The Portal Plugin is made available by the respective portal provider.

3. Installing and configuring components

Various steps need to be taken before using the new interface:

The FOS can only be used in conjunction with release projects. Therefore, use of the release function must have been activated in the project properties.