Welcome back to another blog post about Sitecore XM Cloud. Recently I was confronted with the topic how to integrate an external DAM (not Content Hub DAM) into XM Cloud, more specifically into Pages Editor. This blog post shows a possible way, how this can be easily achieved even though we are not able to customize the Pages itself at the moment.
The use case
First of all, let’s talk about the use case itself. Pretty sure many customer have exactly such a requirement and approaches either way some partner or Sitecore directly with the question:
How can we use OUR DAM solution in XM Cloud?
Of course there are multiple ways of doing this.
The good old way would be to write some customization for Sitecore, deploy that and you have your own integration. With such kind of integration most likely Content and Experience Editor would work even though we are in XM Cloud. But two considerations about that one. First: Don’t do that! We do not want you to write CM Role customizations e.g. .NET code unless it is really necessary for some reason. And second it would really only work in Content and Experience Editor. It would most likely not work with Explorer or Pages Editors. And we all know, that Editors should prefer using those editors over the legacy ones for many many reasons.
Second possibility would be a more manual one. Simply provide some Single-Line field and let the editors copy & paste e.g. public links into XM Cloud. Works perfectly fine apart of the fact that it might end up in massive manual workload for the editors. So again, not really the preferred solution.
Third one would be the best one. We integrate directly into Pages and Explorer editors, so that we can use 3rd Party DAM data as if they would be in XM Cloud Media Library. We can see such an approach in the integration of Content Hub DAM into XM Cloud.
Fig. 1: Dialog in Pages Editor to choose from Content Hub DAM
As editor you can easily choose from where you would like to get the asset. It offers a simple search and pushes back all the needed information into XM Cloud image field.
Fig. 2: Generate or grab the public link from the target asset for XM Cloud
But to have such kind of integration working, we would need to extend the Pages / Explorer code itself. And as we all know this is not possible at the moment. Therefore no way to integrate any other 3rd Party DAM like Content Hub DAM is integrated nowadays.
So, what can we do then?
In the following chapters of this post you will get one possible answer for this question. Keep on reading to find out more…
The approach
Now let us talk a bit about the approach, which was chosen in this post before digging deeper into that one. If we recall the last chapter, we do not have that many possibilities when it comes to customizability capabilities in XM Cloud directly or one of its SaaS tools like Explorer or Pages. So we need to move our custom logic more towards into head application direction. This means that we simply build what ever is needed in the head directly. If we do it smart enough it will integrate smoothly into the overall editing experience of Pages WYSIWYG editing flow. The idea is to create some custom react component, which offers some controls for the editor to interact with the 3rd Party DAM. If the editor chooses something the result will be propagated back to XM Cloud into the right Datasource. If you are smart enough, you build such a component ones and reuse it wherever it is needed. Of course you need to be a bit careful that this kind of logic is only offered in editing mode on the editing host, not the head which delivers the live site 😀
The editing flow
Everything starts with a new React component, which takes over responsibility of rendering the controls, which is aware of all the integrations and holds all the needed information to fully work. That react component can be easily placed into a specific component to enable 3rd Party DAM integration capabilities.
Fig. 3: Embed the new react component into the existing JSS renderings
As you can see the new component is just placed above the actual image in my case. I am just positioning the controls as needed. In my case I will use absolute positioning to move them at top right of the image itself. The new component just needs information like Datasource and FieldName. All the rest will be taken from environment variables and given implementation under the hood. As you can see there is a new field beside the actual Image field from the component. I have decided to just extend the Datasource with that field, which in the end holds the public link of the external DAM. Then there is some fancy logic to determine which image should be used. It is simply using the JSS image as long as there is no image in the external image field. If there is one, it switches to render that one.
Now let’s have a short look into the actual DamImageHandler component. IT contains of multiple individual parts
1. Some checks if we are currently in edit mode to ensure it will only be used in editing not for live visitors and with a feature flag mechanism to safely insert all the new controls and testing on QA or STAGING before tacking life we are quit safe in building something like that.
Fig. 4: Prechecks to ensure component is only rendered when needed and wished
2. The new controls (2 buttons, Add and Remove), which are placed over the image, to give the editors inline editing capabilities
Fig. 5: New controls to enter the external DAM integration capabilities
3. A new Modal dialog, which opens as soon as the editor interacts with the buttons.
Fig. 6: Chakra UI Implementation of Modal Dialog to offer DAM integration capabilities
4. A Tab module as part of the dialog to choose from which DAM you would like to grab data. In a real world scenario you would skip that one most likely, cause you only have one DAM available. But for demo purpose you can quickly switch between different DAM solutions to demonstrate all of them. (And of cause how easy it is to implement not only one, but many integrations)
Fig. 7: Tab Module to offer different DAM integrations
5. The actual implementation of the DAM integration. In this example it is the integration with Frontify. This one offers a little full text search as well a grid like view of the assets to choose from. On Save it grabs the public link and uses GraphQL management API to update XM Cloud Datasource accordingly.
Fig. 8: Extract of the UI code for the Frontify integration
6. The underlying services code, which lets the magic happen. The first service, the FrontifyService, has just one functionality to grab all the assets from the Media Library of a given Brand / Library. Because Frontify offers, similiar to Sitecore, a GraphQL API it was quite easy to find out the exact call and build it in next according to this documentation https://developer.frontify.com/d/XFPCrGNrXQQM/graphql-api#/details-concepts/endpoint-and-queries. The first PoC query (to be refined afterwards) is the following, which grabs all the assets from one library based on a given query string.
Fig. 9: Primitive GraphQL query to get all assets from Frontify
Now that we have our assets we simply store them in our state variable to properly update the UI with all the given assets. As soon, as an Editor chooses one assets and clicks save, another service function is called to update XM Cloud. For the sake of simplicity I implemented an ItemService, which offers an UpdateItem function again with some very simple PoC like query (And yes, this time I have used GraphQL variables mechanism ;-)).
Fig. 10: Primitive GraphQL query to update an item field
And that’s it already. When we now take everything together we have a first approach of a full blown 3rd Party DAM integration built in the head application, which nicely feels like inline editing flow of Pages editor. But enough of theory. As always, we now also see everything in action.
Everything live in action
Gif 1: Use case live and in action
The little video above shows, that we are using a real instance of Frontify with some demo assets. We jump from Frontify to Sitecore into the Content Editor to see that there is an image field, which we can use as usual with JSS, but also some new ExternalImage field, which is currently empty. Now opening the Pages editor loads the page as usual with only one difference. Because we are in edit mode we see 2 new buttons on the images. Add external asset and Remove external assets. We click on the Add external asset button, which opens the modal dialog and automatically loads the Frontify assets via GraphQL and present them in a simple Image Grid. We are using the full text search to find a proper asset, choose it and save. The dialog closes and immediately updates first the asset in XM cloud again via GraphQL and the loaded image in the frontend. Next we click the Remove button, which also immediately triggers an XM Cloud and frontend update. Finally we also examine the underlying Datasource after applying an external image. This shows some preview/public link from Frontify, which is used to render the image now, as long as it is there. Once it is removed, the original Image field from Sitecore will take over again and renders the image from the XM Cloud Media Library.
Fig. 11: Image series to demonstrate the look and feel
Conclusion
Let us finally have an overall look, what we did here. Within this blog post we tackled a quite common challenge of integrating a 3rd Party DAM into XM Cloud editing flow. As our options are limited at the moment fairly valid approach is to put such logic into the head application directly. We saw a step by step approach with the example of Frontify integration. Everything at all this integration was done pretty fast (less than 5 hours) and works already pretty smooth. Next phase is ahead and a lot of improvements can be done. But it already shows nicely what is possible with a bit of custom implementation and API first solutions.
hachweb.wordpress.com 