A multi-portal architecture consists of:
- one or more read-write portals, called "Manage" tenants
- one or more read-only portals, called "Consume" tenants
Each tenant, "Manage" and "Consume", must have its own conf.json file.
The configuration file architecture must be as follows:
/usr/local/afs7/Fluid-Topics/conf/
├── TenantIdOfTheManagePortal
│ └── ConfigurationFiles
├── TenantIdOfTheConsumePortal1
│ └── ConfigurationFiles
├── TenantIdOfTheConsumePortal2
│ └── ConfigurationFiles
└── Etc.
On the "Manage" tenant, the Knowledge Hub is totally manageable in Fluid Topics. It is possible to:
- Publish content
- Manage sources
- Change the Enrich & Clean configuration
- And so on.
On the "Consume" tenants, the KHUB is read-only. It consumes a remote KHUB, managed by one "Manage" tenant. All features to update the KHUB are not available from a "Consume" tenant.
Example
For instance, a multi-portal environment is set for the documentation of OleanDor, company specialized in time machine development.
The following example shows the configuration file architecture for the OleanDor portal organization:
/usr/local/afs7/Fluid-Topics/conf/
├── OleanDor
│ └── ConfigurationFiles
├── OD1000
│ └── ConfigurationFiles
└── 0D2000
└── ConfigurationFiles
Where:
- OleanDor is the tenant for the "Manage" portal.
- OD1000 and OD2000 are "Consume" portals.