Welcome back to another blog post for all XM Cloud enthusiasts. This time I would like to extend the last topic of gated-content a bit and would like to demonstrate another use case, where gated-content might be the right solution for.
If you did not read the last post you can go back and read it here. Once you finished reading that post you got an idea of, how to tackle gated content scenarios with XM Cloud. Based on this implementation we just need to do some extensions to tackle even more scenarios
The use case
Let’s start with the actual use case. Imagine a customer has very critical content, which needs to get published at an exact time on a day. And with exact I really mean exact like, seconds or maximum a min later. As we all know this might be complicated task OTTB for Sitecore. Usually there is always a bit of delay till the actual content is available by the end user. Usually this is also fine for most of the customer. But there are ones out there with those really critical pieces of content where a delay of seconds might cost a lot of money.
So the question is how would you do it normally in Sitecore XM Cloud?
The publishing process
If we have a closer look into the process of what is already there, we see it consists of multiple parts, which rely on each other. Some are OOTB there, some need to be adapted or could be optimized.
Everything starts with the actual item e.g. a News page. Once the editor is done with managing the content in advance, he/she can setup publishing restrictions.
As you can see, an editor can easily setup a datetime based publishing restriction. Together with a proper workflow, you can now simply push the item through the workflow and it will not be considered to be published until this datetime has reached.
So far so good. First thing to keep in mind, you need some process, which actual does the publish operation for that item once the datetime has reached. So far there is not OOTB mechanism to do that. Easiest is, you setup a scheduled task and use that one, which gets periodically triggered to checks and does the actual publishing. For common cases that it totally fine, but for time critical cases this might not be enough. Such a scheduled task runs at minimum every 5 minutes. And that already stresses the CM server a bit ;-). But that means worst case already a 5 min delay.
What comes next? Once the process runs and does the actual publish operation, it also takes a bit time to do so. We know the publish to edge takes a bit longer than the publish to web database, which ultimately was a simple copy operation. Mostly the publish to edge needs longer, cause of the establishment of the secure connection with handshake and all of that. Once that is done, the publish operation itself is quite fast.
Then, once the actual publish is done, edge most likely also needs to do some post publish work. to build up the proper output for the layout service etc. This operation might also take a bit of time,
Ultimately, once everything is up to date in Experience Edge, we need to rebuild the SSG based page on the head application. This can easily be done with some on-demand ISR magic. If you need a bit of inspiration about that, just read this post. With an Experience Edge Webhook, which informs us, once everything is done, we do not even lose more time in here, but get immediate notification.
But if we sum up everything and every step I already heard from customers that the pure process of publishing a piece of content till it is fully available in edge (the update Webhook triggered) it might take a few secs up to 15 minutes. Might change over the time with enhancements on Sitecore site.
For a common publish operation, this might be fine. But coming back to the initial requirement this seems to be unacceptable. For sure we can hook in here or there into the publish process and reduce the time or optimize. But still, pretty sure there will always be some delay. And it depends on the specific requirement, if that delay is acceptable or not.
But what, if there is a way to have it reliable available in the head application EXACTLY at the wished datetime? One way to achieve this might be over gated-content.
How does gated-content help us?
The idea of using gated-content is pretty simple. We eliminate the publish operation and everything around that completely from the equation. That way we do not care if publishing might take seconds, minutes or even hours. We can easily prepare the content in advance and publish it to Experience Edge. The only thing we do now is to restrict the access to that already published piece of content. Next.JS has a pretty nice mechanism to check if a piece of content should be delivered or not. You can leverage middleware functionality the same way we leveraged it for 401 or 403 cases to restrict the access to pages, where e.g. some datetime has not passed yet.
The implementation
Now let us dig deeper into the actual steps, which need to be done to achieve this. And to be honest, if you already have something like 401 and 403 in place it is nothing more like adding a few lines of additional code and a new field in Sitecore ;-). Took me around 1 hour to implement.
As you can see, we are reusing our authorization template and simply extend it with a new field Visibility Date(Naming up to you ;-)). Once an editor maintained a page, he/she can now also add such a visibility date. This means, that the page IS published to experience edge as usual, BUT it will not be visible to any end user until this date time has reached. And because we are using middleware approach, which hooks in into each and every request, before the actual content is delivered, we really impede any kind of content leak in advance, even though it is already in edge.
On the other side, for the sake of simplicity I am reusing the already existing authorization.js middleware function, which checks for 401 and 403 to also check for this visibility date. Here are the needed changes / extensions
First, we need to extend the GraphQL query to include that visibility date and the proper data mapping to our PageItem model.
Next step is the extension of the actual middleware function. During this process I also decided to refactor the code a bit to put the actual checks into a dedicated service to keep the middleware as clean as possible.
So the middleware has just one check and redirects in my case to the start page if the visibility date has not reached yet. What does IsVisibilityDateReached function exactly do? No problem here you are.
This specific one really just check the given datetime against the current datetime to see if it has passed or not.
Note: If you add a date time in Sitecore OOTB the Time zone seems to be UTC+0. Keep that in mind if you manage those time. In my PoC case I wanted to have a news available at 14:35. The Time I had to set in Sitecore was 12:35 because I am located at UTC+2. That way everything worked as expected. Pretty sure there is some config you could override to set another time some for your CM role if needed.
See everything in action
After taking care of all the theory, let’s also have a look how everything works live and in action.
Gif. 1 Restrict content delivery by datetime
The case here is pretty simple. One news has set the date time to a value in the future (For demonstration purpose just a minute). If I try to access the page in the head before that datetime has reached I am redirected to the start page. (That’s my implementation. You can redirect to wherever you want). The we wait a few seconds till the right datetime has passed and we call the page again. This time all is good and the page is actually delivered, because now the visibility date has passed.
Note: This works without publishing just because my Vercel is connected directly to preview endpoint rather to the delivery endpoint. It works exactly the same. I just safe the publish operation for the sake of simplicity.
Conclusion
Within this blog post you recapped a bit the use case gated content and how it could be solved in XMC Cloud via next.js middlware approach. We saw, that we can use and extend that approach to even solve the challenge to publish some page on an exact datetime in the future, by publishing it somewhen in advance and restrict the access completely till this actual datetime has reached. That way the client never gets the actual content and it is really never delivered.
If we now think one step further it might come up, that we not only have to secure the page access. It might be the case, that we have some teaser modules, which refer to that page and already display critical information. In the next post I will also cover such cases and give simple possibilities how to secure not only pages and page access, but all of your components used on pages.
hachweb.wordpress.com 