Blog post Technical, Tridion
SDL Tridion Sites 9.1 – SDL Tridion Sites Add-on Service
In my previous blogs about the new Integration Framework, I’ve mentioned that the Connectors are deployed using a new mechanism, namely the new SDL Tridion Sites add-on service, but I haven’t gotten into any details about it. This blog serves to remedy that by focusing purely on the new deployment feature and the details surrounding it.
Advantages of the Add-on Service
The advantages of having a dedicated entity/subsystem to deal with extension include:
- Significantly simplified deployment of extensions and their configuration. The extensions are now stored and handled in a centralized manner.
- Zero downtime when deploying and maintaining extension. The extensions (initial deployment or updates) are applied on the fly without the need to restart any servers or services.
- Easier scaling and disaster recovery of servers. If a server crashes and needs to be redeployed or if a new instance of a server needs to introduced into the cluster, the extensions are automatically loaded due to the centralized nature of the system.
- Reduced Total Cost of Ownership caused by less effort of maintaining and upgrading extensions (due to the centralized nature of the system and zero downtime)
Add-on packaging
The new deployment model requires the extensions to be in a specific format called an Add-on package (a Zip file). This package is a single zip file adhering to some predefined rules. It must contain a manifest.json in its root which describes all the extensions in the package. All dependent JARs and DLLs should be in the same folder as the source JAR or DLL of an extension, and finally, all references to JARs, DLLs and other resources in the manifest file must be referenced relatively from the root of the zip.
As hinted earlier, the packages can contain multiple extensions, which is especially useful if we have “related” extensions; extensions that are spanning multiple extension point for a single functionality. An example would be a deployer extension which depends on some custom data that is produced by Tridion Event System.
We can package together extensions from the following extension points:
- Content Manager
- Content Manager Explorer
- Content Delivery
- External Content Library
| Type | Description |
| CDDeployerExtension | Deployer extension point |
| CDMergeableConfigurationExtension | Extension point for merging XML configuration files in the delivery services |
| CDGraphQLSchemaExtension | Content Service extension point for the GraphQL Schema |
| CDModelTransformerExtension | Content Service extension point for transforming the data model |
| CMApplicationDataConfiguration | A reference for ImportExport service to a custom XML file containing the configuration for custom application data. |
| CMResolver | A custom content resolver, which redefines which items to include in the Transport Package that is transported to Content Delivery |
| CMEventHandler | A custom Event Handler that listens and responds to events that occur in Content Manager. Note that through TcmExtension it is possible to register : • Event handler • Custom System Privilege |
| Connector | Tridion Integration Framework Connector extension |
| ECLProvider | A custom provider for External Content Libraries |
| UIEditor | A custom Editor (a GUI extension) |
| UIModel | A custom Model (part of a GUI extension) |
Add-on service architecture
The architecture for the Add-on Service is shown below:
The Add-on REST API allows us, from whatever subsystem, to upload packages and query the Add-on Service for the state of various extensions that have been loaded into that service. The service is backed by two data stores which hold the uploaded packages and an “overview” of the extensions. The service is shipped with a UI for a better user-friendly experience, but of course it can be consumed programmatically as well (it’s an open API). It seems SDL has learned the lesson to ship a UI right away, unlike when Topology Manager first came out :).
The optional authentication is provided via an OpenId Connect Provider. Switching it on and off is easy (just a matter of configuration on the server). Three roles will be available out of the box.
At the bottom of the image we can see various consumers of the service. We can also see that although multiple extensions were packaged together, not all are applicable for all types of consumers. The ones which aren’t applicable are not loaded, they are inactive.
How it works
The overview of how the system works is illustrated below.
Steps:
- The add-on package is uploaded to the Add-on Service. The package is stored on the filesystem, database or AWS S3 bucket. The storage is configurable.
- The application (Content Manager client or DXD client) gets a list of add-ons
- The application gets the add-ons, unpacks them and notifies the relevant extension points
- Each extension point requests all the relevant extensions it needs to load
- The extension point validates the extension data (including binaries) and loads it
For the DXD side, the extensions are currently loaded only on startup due to technical limitations, but this is something which is expected to change.
Add-on Service – Sites 9.1
The Add-on Service in SDL Tridion Sites 9.1 will be shipped with the following features:- Rest API
- UI with ability to:
- Show the list of uploaded packages
- Upload the package (single item upload)
- Download the package(s)
- Delete the package(s)
- See package details view with list of extensions
- Role-base authorization. Three roles: administrator, read-only user and service role
- HTTPS support
- Database, local file system or AWS S3 bucket as a storage
- MS SQL, Oracle, Aurora
- Statuses for add-ons/extensions
- Custom configuration for add-ons.
All of these are pretty straightforward, or were already described earlier with exception to the ‘custom configuration for Add-Ons’. This allows us to store any Add-On specific data for our extensions, for example environment specific search endpoints, group information for the event system, etc.
Add-on Service – Post Sites 9.1
The following features are planned post SDL Tridion Sites 9.1:
- Visual Studio integration. Tooling to more easily to build extensions and add-ons, provide packaging capability in the form of a build process (build manifest file, create zip file, etc.)
- Enable/disable Add-on. In SDL Tridion Sites 9.1 all extension will be loaded from the package. There is no option to disable an add-on except by mimicking this by uploading a package excluding the desired add-on.
- Add-on dependencies and prerequisites. Facilitates dependency resolution in case one package depends on another one, or some other prerequisites.
- Hotfix deployment
- Multi language support. More languages for the Add-on Service UI
- Add-on versioning (history). Similar to Tridion’s versioning, to be able to roll-back to a specific version if needed.
- DTAP environments support. Controlling to which environments in the DTAP street an extension can be “pushed to”.
- Integration with SDL App store and others
- Support for SDL Tridion Docs extension points
This will be all for this week’s presentation, stay tuned for the last topic related to the SDL Tridion Sites 9.1 release about DXA and its roadmap. As always, if you have any questions or would like to share your thoughts, don’t hesitate to get in contact.
Disclaimer: All images are copied from SDL with their permission.