SDL Tridion Sites 9.1 – SDL Tridion Integration Framework – part 1

SDL Tridion Sites 9.1 features sneak-peak

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.

SDL Tridion Sites 9.1 – SDL Tridion Integration Framework – part 1

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:

• Application: runs on a machine and defines a contract (will be explained in more detail later) for integrating with SDL Tridion Sites.
• Connection Manager: The connection manager is hosted in the application and manages all integration connectors (below) in isolated processes. It enables the creation of gRPC (Google Remote Procedure Calls) channels to these processes (may be in a completely different programming language) more about gRPC can be found here.
• Connector: the connector provides the capability to integrate with an external system. It contains the integration implementation logic and implements the contract required by the Application for communication with SDL Tridion Sites (will be explained in more detail later)

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


Extension points

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.

• ECL: will continue working with its own providers, but support for leveraging the new architecture/connectors is introduced.
• PCA: support for GraphQL queries towards external data is introduced, including querying for an existing external item or items using a filter, but also mutations (write operations), and finally listing the available registered external namespaces (for example, SAP Hybris, Salesforce, etc.).

New GraphQL operations for connectors:

• Queries
  • externalItem(ID)
  • externalItems(namespace ID, filter)
    • Can be narrowed down to a concrete type, for example a Contact, Product etc.
• Mutations
  • createXXX(parent ID, input)
    • Example: createContact(…)
  • updateXXX(ID, input)
  • deleteXXX(ID)
• Namespaces
  • List available external namespaces (e.g. hybris, youtube, salesforce)

The available extension points and multi-platform architecture is illustrated below:

Integration scenarios

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:

Commerce:

• Mashup of commerce data & content
• Link to products & categories
• Build experiences for:
  • Campaign/landing pages
  • Category pages
  • Search pages
  • Product detail pages
• Cart/checkout
• Tag content with product SKU/category Ids
• Hybrid navigation

CRM:

• Build CRM forms to collect leads & contacts
• Personalize content with CRM data
• Personalization based on CRM data (for example segments, contact location etc)
• CRM data made available when:
  • Tracking cookie is available
  • Form are posted
  • At login
  • Campaign URL is used
• Tracking of visitor site behavior
  • CRM formulas can be used to segment user

Marketing Automation/Campaigns

• Publish content & assets to be used in external campaigns or email templates
• Mashup of content & forms created in the campaign tool
• Lead capturing forms
• Tracking of site activities
• Triggering of customer journey events

Multimedia

• Manage assets and content from one single interface
• Publish external assets to web sites
• Mark as used in external media repository
• Localization
• Realtime galleries

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.