Similar to last year’s release of Tridion Sites 9, SDL has again organized a series of webinars dedicated to this year’s planned release of Tridion Sites 9.1.
Three webinars have already been held, each one covering a specific topic. And just as I did last year, I plan to write a blog entry about each of them. That said, this is the first entry in the series of three focused on the new SDL Tridion Integration Framework.
If this sounds interesting -- and it should :) -- then please feel free to scroll down a bit to see what it’s all about. Just a heads up, because this topic is quite large, it will be covered by two blog posts.
The Integration Framework is being developed to standardize, increase reusability and provide a more robust and overall better integration between Tridion and other external/dedicated systems like CRM-s, DAM-s, PIM-s, etc.
The main parts of the framework are shown, listed and explained below:
This architecture is flexible because everything is based on the aforementioned contracts. The goal was to simplify development by abstracting away many technical issues from the developer and allow them to focus on the functionality. All the developer needs to do is to create and register a connector, which will then be automatically consumed by the application.
Speaking of flexibility, the new integration framework enables us to write a connector once, and use the exact same connector in both the CM and DXD. This is because the connector uses the standard integration contract with SDL Tridion. This same contract is used by both CM & DXD which allows them to be re-used effectively. Additionally, the connectors can be written in either Java or C# (no matter which side they are deployed to, they can even be in both languages).
All of this means less friction and greater productivity for developers with complex integration requirements!
As mentioned earlier, the connectors can be written in Java or C# so when loaded, they will be running as a Java or .NET process respectively. These processes are launched by the Connection Manager and are isolated from the “main” application. This means that if the connector process gets corrupted or crashes, the application is not directly affected. Additionally, there is a monitoring mechanism in place so in such cases, the connector may be relaunched automatically.
Besides the process isolation and resilience (via the automatic relaunching), there is also a mechanism for easy logging from within the connectors. This is an example of how SDL has simplified the technical details for developers because this wouldn’t be simple to implement consistently across connectors, keeping in mind that they are in separate processes. Once implemented for the desired contract, the application can log to various destinations (log file, database, cloud tables/analytics, etc.).
Initially there will be two extension points available (for which the connectors can be written) with additional ones planned for the future. These are the External Content Library (ECL) on the CM side and the Public Content API (PCA) (Content Service’s GraphQL endpoint) in the DXD.
New GraphQL operations for connectors:
The available extension points and multi-platform architecture is illustrated below:
Let’s take a look at the following example on what we can achieve using the connector framework, and how:
Take for example, if a Hybris integration for product information is needed, then a connector would be used on the CM side (ECL) to navigate and select a product. The reference to that particular product is maintained within the CM, and then via publishing it gets transported to the DXD side as well. Once published, the product reference can be used by the web application, using the very same connector, to query for that product using GraphQL. Once the product is retrieved from the external system, it can be shown on the website either by embedding its data, or by linking to it.
Additional areas where we can use the connectors:
For each of these areas, “Integration Accelerators” will be made available to help developers use the connectors in an SDL Tridion Sites context. These accelerators are basically sets of out-of-the-box DXA and CMS modules, templates and examples used to jump start development, and/or to provide useful ideas and guidance for more complex/specialized implementations.
As mentioned earlier, this is quite a big topic, so I’ve decided to split it in two blogs and that about wraps it up for the first one :). The second part of this topic will be arriving shortly. 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.