Tridion Sites 9 - Content API with GraphQL

SDL announced with upcoming Tridion Sites 9 that they also release a new version of their Unified Delivery Platform (UDP). The most promising feature of it will be a completely new public-facing Content API. This API is the new endpoint for content delivery for Sites and Docs and help customers enabling more dynamic and cleaner solutions for their channels.

Unified Delivery Platform update

SDL marketing is trying to rename their technology all the time. We have seen it with Tridion to Web to Tridion. And now what once was Content Delivery (CD) was renamed to UDP and now the introduced a new term: Dynamic Experience Delivery (DED). I will keep UDP for now in this article. :-)

Before we dive into Content API, a short highlight of the other key features of UDP 11:

  • Multiple namespace support. Now one for Sites and one for Docs. This can be extended to more areas in the future.
  • Content mashups possible. Mix content from Sites and from Docs in a single web application.
  • Full-text search supported with Elastic Search technology. Index and Query support is expected with Sites 9.1
  • Docker support. Making cloud orchestration for the microservices easier (scaling and failover scenarios).
  • Content API

Content API

The new content API uses GraphQL which has roots in Facebook technology stack. GraphQL has several benefits compared to other query languages:

  • Single endpoint without versioning required
  • Efficient querying: specify the information you need and get data in one single-trip request
  • Stability: changing data doesn't require changing clients
  • Documentation: simple understandable Graph schema with self-documented feature
  • Support: large community resulting in a large number of GraphQL client tools

Since GraphQL can be consumed by a lot of other platforms it is likely that it will replace the OData web services at some point in time.

Example GraphQL query for the Content API

When installing the Content API the default endpoint will be something like https://YOURSERVER/udp/content. Note that there is also another endpoint for developers without caching. One requirement is that the content is published as DXA (DD4T) rendered JSON. So if you have this in your broker database, no republish actions are required at all and you're good to go.

In the GraphQL example below, we request 3 properties of a published page by URL.

{
  myPageByUrl: page(namespaceId: 1, publicationId: 5, url: "/index.html") {
	url, 
	itemId,
	title
  }
}

myPageByUrl is the container where the query result can be found in the response. The namespaceId corresponds with Tridion Sites and the publicationId and url is the rest of the actual search query. In the inner query we declare 3 properties what we want to receive in the response: url, itemId and title.

A possible response from the Content API could be:

{
	"data": {
		"myPageByUrl": {
			"url": "/index.html",
			"itemId": 123,
			"title" : "000 Home"
		}
	}
}

More complex GraphQL queries

The given example is fairly straightforward and simple. More complex and useful queries can be made as well. To give you an impression of the almost endless possibilities:

  • Get the binary component by ID and by URL 
  • Get contained ComponentPresentation's by page ID and by URL
  • Get items as paginated results
  • Get first X publications
  • Get category and its children keywords
  • Query for component presentations based on taxonomy
  • Get keywords and structure groups related to the page, find parents and expand children
  • Mashup queries (retrieving content from Sites and Docs namespaces in single request)
  • Get items based on query with custom metadata

Probably during Tridion Developer Summit there will be presentations about the Content API with rich GraphQL demos. TDS is hosted in Amsterdam on 6th and 7th september. It is still possible to register and maybe see you there!

Handling rich text content fields in SDL Tridion CMS

In this article, I will explain a little bit about Rich Text Fields in SDL Tridion CMS and how to customize and restrict the usage of styling to some extent with a basic example.

Introduction to RTF fields in Tridion

Tridion supports Rich Text Fields for allowing content managers to create better-looking content. All kinds of HTML elements are supported like the typical Italic, Bold and Underline. By default when enabling RTF features for a text field in your schema design all common tags are allowed:

  • Editing (or copy/paste) as HTML
  • Possible to select some text and apply a style via the buttons in the ribbon bar:

Customization options in Tridion

All this freedom for a content manager may drive front-end developers insane since they need to support all of it with their CSS. Luckily, there are 3 customization options within Schema design to limit the RTF features:

  1. Disable buttons in the ribbon bar
  2. Configure custom styles (matching the class names in CSS)
  3. Filter unwanted HTML (with help of XSLT)

These can be configured per schema content field:

Example case - Transforming HTML

XSLT is a complex but powerful language for transforming XML from one format to another. HTML is just a form of XML and thus XSLT can be used to free RTF content from unwanted tags.

Here, I want to demonstrate how to implement the following requirements:

  1. Make sure all bold texts are using <strong> tag element (and not <b> tag, which is default). This mechanism can later also be applied for converting italic <i> tag to <em> tag, etc.
  2. Only paragraphs, breaks and bold should be allowed in the HTML. This results in the following HTML tags: <p>, <br /> and <strong>

Converting from one HTML tag to another

The 1st requirement can be implemented by inserting the following fragment into the default XSLT:

  <xsl:template match="b">
        <xsl:element name="strong">
          <xsl:apply-templates select="node()"></xsl:apply-templates>
        </xsl:element>
  </xsl:template>

What it does is: when a tag is <b> found, replace it with a <strong> tag and continue XSLT rendering for the inner value of the node.

Filtering unwanted tags

For filtering you basically have two approaches:

  • Black-listing: unwanted tag elements. Use when you want to allow all tags, and exclude a few unwanted tags.
  • White-listing: specify the tag elements you want to keep. Use when the set of allowed tags is known.

In general (as in security), white-listing is the preferred method. Explicitly allowing specific tags gives you the most control over the output and rule out any 'forgotten' tags to appear in the HTML. 

The 2nd requirement can be implemented by using the following fragment in XSLT:

<xsl:template match="/ | node() | @*">
    <xsl:copy>
      <xsl:apply-templates select="/ | p | b | br"></xsl:apply-templates>
    </xsl:copy>
</xsl:template>

This fragment is basically processing all X(HT)ML elements and it copies only the allowed tags to the output to be processed further.

Complete XSLT solution

Below the complete file, including a conversion for <i> to <em>.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:output omit-xml-declaration="yes" method="xml" cdata-section-elements="script"></xsl:output>
  <xsl:template match="*[      (self::br or self::p or self::div)     and      normalize-space(translate(., ' ', '')) = ''     and      not(@*)     and      not(processing-instruction())     and      not(comment())     and      not(*[not(self::br) or @* or * or node()])     and      not(following::node()[not(         (self::text() or self::br or self::p or self::div)        and         normalize-space(translate(., ' ', '')) = ''        and         not(@*)        and         not(processing-instruction())        and         not(comment())        and         not(*[not(self::br) or @* or * or node()])       )])     ]">
    <!-- ignore all paragraphs and line-breaks at the end that have nothing but (non-breaking) spaces and line breaks -->
  </xsl:template>
  <xsl:template match="br[parent::div and not(preceding-sibling::node()) and not(following-sibling::node())]">
    <!-- Chrome generates <div><br /></div>. Renders differently in different browsers. Replace it with a non-breaking space -->
    <xsl:text> </xsl:text>
  </xsl:template>
  <!-- added bold to strong conversion -->
  <xsl:template match="b">
        <xsl:element name="strong">
          <xsl:apply-templates select="node()"></xsl:apply-templates>
        </xsl:element>
  </xsl:template>
  <!-- added italic to em converter -->
  <xsl:template match="i">
    <xsl:element name="em">
          <xsl:apply-templates select="node()"></xsl:apply-templates>
        </xsl:element>
  </xsl:template>
  <xsl:template match="/ | node() | @*">
    <xsl:copy>
      <xsl:apply-templates select="/ | p | b | i | br"></xsl:apply-templates>
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>


 

 

 

 

SDL Connect 2017 - Tridion Sites and Tridion Docs

The SDL Connect 2017 conference was held in San Jose, California. Connect is a yearly user and partner conference where language and CMS technology provider SDL announced their strategy and roadmap for the coming year(s). Below some notes from the sessions that I attended.
 
SDL Tridion DX
One of the most visible changes is bringing back the Tridion brand. At SDL Connect they announced the new SDL Tridion DX digital experience product. The product is actually a suite that combines web content management (SDL Tridion Sites) and DITA-based structured content management (SDL Tridion Docs).
 
 
Tridion DX contains a unified experience layer with the support of Tridion Open Content API targeted to any digital touchpoints: mobile, desktop, watches, bots, in-store displays, etc. With these APIs, it is possible to create content mash-ups blending marketing content, commerce content and product information. All this information can be personalized by leveraging AI and Machine Learning capabilities.
 
 
Tridion DX will be launched mid-2018 and will replace their 2 current content products SDL Web and SDL Knowledge Center. Until that date there can still be some confusion, since marketing will only use Tridion DX, but the underlying product names stay a bit longer: SDL Web 8.5 and SDL Knowledge Center 13.
 
SDL Knowledge Center and Tridion Docs
Tridion Docs will be the new name of SDL Knowledge Center (KC) by mid-2018. Until then the product will still be named KC version 13. Knowledge center is a product which enables companies to manage technical content (i.e. manuals) in a structured way. The product supports the industry standard Darwin Information Typing Architecture (DITA), which is an XML based structure to create, produce and publish information. Publishing targets are typically documentation portals, download centers, and support sites.
 
The end of October 2017 release of KC 13 has some major improvements:
  • Support for new delivery stack (DXA) shared with SDL Web with better touch points experiences
  • Upgrading is simplified by Powershell script support, automation, and centralized configuration
  • Enhanced translation workflow
  • Enhanced productivity by UI improvements
 
By using DXA in the delivery stack also new benefits are introduced:
  • Improved site navigation options (more flexible, can be based on taxonomy)
  • Multilanguage support for the UI
  • Personalization and filtering support
  • Search is now powered by Elastic Search
 
SDL Tridion Sites 9
Tridion Sites is the content management system that is formerly known as SDL Web 9. It is mostly used for managing multi-language/branded content for marketing and commerce sites. By combining both Sites and Docs in Tridion DX the content silo boundaries are removed and content managers have a more unified experience when working with content. For the customers of the content, this change will also be noticeable since the pre-sales marketing content is more aligned with the post-sales product content.
 
Experience regions can be used to partition a page. The regions are user-defined and customizable per page template. A region can be used to position components in a certain area of a page. Regions can also be restricted to be only used for e-commerce integrations.
 
 
Other announced features include:
  • Image editing support (basic manipulations like cropping, rotating and scaling). The manipulation is stored in the metadata and source image is untouched.
  • Tridion Open Content API for creating content mashups.
  • Integration Marketecture - integration with external CRM/Marketing/E-commerce systems via Accelerators and Connectors
  • Improved cloud support
  • Prescriptive Personalization (old SmartTarget/Fredhopper product) based on:
    • Web attributes (i.e. IP based geolocation, company, time of day or referrer source)
    • Database attributes (i.e. CRM or marketing databases)
    • Behaviour-driven (user actions on touchpoints)
  • Adaptive Personalization by using real-time AI and Machine Learning technology. See picture below.
West Coast meetup - preview of new CME UX design
During the West Coast community meetup, SDL showed that they are very busy working on a new UX design for their Content Management Explorer. The first UX drafts are very promising and radically changing the way we work with the CME. Also, they emphasized the goal of open API based platform with connectors for extensibility. The downside is that we need to wait until Tridion DX 10 is announced to see what they can deliver since it's quite a big step.