Sitecore Corner

Note: Although we are going to use XM Cloud for this article, keep in mind that this is 100% compatible with Sitecore DXP 10.3 as webhooks are also available there.

Having honed our skills in crafting Sitecore Connect Recipes using existing connectors, we now turn our attention to the realm of custom integrations. In this next chapter of these series, we delve into scenarios where no pre-existing connectors are available, but alternative integration methods such as webhooks and APIs can be leveraged.

Building Webhooks Trigger Integration: XM Cloud and Cloudflare

Business Case

The business case we are going to explore is one that has haunted many of us in our careers: the eternal struggle of clearing the CDN cache after publishing.

Step 1: Setting Up Connections

Neither XM Cloud nor Cloudflare provide out-of-the-box connectors, leaving us to handle this integration on our own – we won’t be leveraging any pre-existing connections this time. However, as part of the recipe building process, we will create an HTTP Connection for Cloudflare.

Step 2: Creating the Recipe

As mentioned before, XM Cloud does not have any out-of-the-box connectors available. However, the good news is that XM Cloud provides a webhook functionality that we can take advantage of for our scenario. So, let’s proceed with creating a new recipe and select “Trigger from a webhook” as our starting point.

Game Plan

Let’s build our game plan for this specific scenario:

1. Create a Recipe triggered by a webhook in Sitecore Connect
2. Set up a webhook in XM Cloud to call the Sitecore Connect endpoint
3. Configure the Sitecore Connect webhook endpoint to consume the payload provided by the XM Cloud trigger
4. Determine whether the cache should be purged based on the webhook payload. (Note: We will explore a simplified scenario, which must be expanded for real-world scenarios.)
5. Call the Cloudflare API to purge the website cache

Recipe Step 1: Trigger

We already created the recipe using the “Trigger from a webhook” starting point, but now we have to configure it. The webhook comes with a guided setup which is really useful so let’s utilize it.

In the first step of the wizard, we are only required to provide an event name. It’s important to note that the event name provided here will determine the endpoint that the webhook will listen on. (see the screenshot)

After selecting the event name, you can proceed in the wizard by clicking the “Next” button. This will cause the webhook to be into “waiting mode” and expect the payload from our application. Leave the screen like this and let’s move to the next step.

Recipe Step 2: Setup a Webhook in XM Cloud

For our trigger we are going to utilize the Webhook Event Handlers functionality of XM Cloud.

1. Navigate to “/sitecore/system/Webhooks”
2. Create a new “Webhook Event Handler” (name doesn’t matter, I will be using “Sitecore Connect For Begginers Publish End”)
3. The fields that are mandatory are the following:
   • Events – publish_end
   • Enabled – checked
   • Url – The workato webhooks url which was provided in the previous step.
   • Everything else can be left as default.

My webhook configuration works like this.

After the item is saved. Let’s publish an item to trigger the webhook execution and procede to the next step.

Recipe Step 3: Payload Configuration

If everything was setup correctly in the previous step and the publishing process has finished succesfully, the webhook waiting screen should have changed to the following.

You will also notice that workato automatically detected what http verb we used, what data type we are using and the actual payload:

So the only thing left is to click the Setup Webhook button and our webhook is good to go ! (that was easy wasn’t it :)) Now let’s move on to validate the payload and decide under what conditions we want the CDN to be purged.

Recipe Step 4: Adding some conditions

With our data model already loaded in the recipe, let’s create a simple descision model around it. I will build a simple “IF condtion” which we already used multiple times to verify that the event name is indeed “publish:end” and that the RootItemId is the itemId of the default home item.

Note: This is just an example and shouldn’t be used for production 🙂 #HabitatIsNotAStarterKit.

With the condition ready, there is just one final step in our game plan, calling the Cloudflare API to purge the cache.

Recipe Step 5: Cloudflare Cache Purging

As mentioned earlier, Cloudflare does not provide a pre-built connector for integration with Sitecore. However, they offer a robust and well-documented REST API that we can utilize for our purposes. The Cloudflare API includes an endpoint specifically designed for purging zone caches, which aligns perfectly with our goal. By leveraging this API endpoint, we can programmatically clear the CDN cache after publishing content. Let’s proceed with building the action itself. Workato has a built-in HTTP action, so let’s use it

After we select the HTTP Action let’s see how it is setup

We have several parameters that need to be filled here

1. Connection Name – Name of the connection
2. Authentication Type – Cloudflare comes with several out of the box authentication options. In this example I am going to use header authentication with Api Key. (If you want to check for different options take a look at the security section here)
3. The headers for the header authorization. As I mentioned earlier I used the X-Auth-Key header with my API Key.
4. Base URL – The base url for the Cloudflare API. At this point they are at version 4, so I used the following: https://api.cloudflare.com/client/v4/
   

With our HTTP Connection set, let’s move to making the API call itself. I will not go into much details as there is guided setup for the action and great documentation by Cloudflare on the specifics, so the important thing is that the request is POST and the URL is in this format “zones/{identifier}/purge_cache“

Note: You will notice a that I am using some wierd Property called cloudflare_zone_id_secret. I will make a separate mini blog post on environment properties and how they are used to not overload this one.

And with this our Recipe is completed !

Step 3: Testing the Recipe

So we have 2 test scenarios:

1. Scenario 1: Publish an item in Sitecore that matches the condition and make sure the cache is purged.
2. Scenario 2: Publish an item in Sitecore that doesn’t match the condition and make sure the purge cache step is not getting executed.

As we have explored the recipe testing multiple times in the previous articles in the series, I will just show the expected outcome of each scenario:

Scenario 1

Scenario 2

If both of the tests are succesful – we can start the recipe !

And there you have it! We successfully tackled a common integration scenario that has often caused headaches in the past. With just a series of simple steps, we were able to overcome the challenge of clearing the CDN cache after publishing content. The beauty of this solution is its flexibility – the webhook we created can be easily adapted to trigger from your DevOps or other processes, allowing you to automate cache purging and ensure optimal experience for your website.

Conclusion

With the powerful functionalities that come with XM Cloud, such as Webhooks and the GraphQL API, and the flexibility of Sitecore Connect, I believe these two platforms will become inseparable when it comes to tackling various integration scenarios. While there may not be an out-of-the-box connector for XM Cloud, we have demonstrated that integrating it with Sitecore is a straightforward process, leveraging the capabilities of both systems.

As both XM Cloud and Sitecore continue to evolve and enhance their integration capabilities, we can expect even more powerful and intuitive ways to connect the two platforms. This synergy between XM Cloud and Sitecore Connect empowers organizations to leverage the best of both worlds, enabling them to deliver exceptional digital experiences while seamlessly integrating their content and marketing workflows.