Top Takeaways from a Sitecore xDB Cloud Configuration

Unleash the Potential of Power Platform With a Center of Excellence

Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.

Learn More

We recently worked to help one of our customers set up xDB Cloud and had some great findings come out of the project. While the Sitecore documentation is very good in some areas, in some of the newer areas, like xDB Cloud, the documentation can be a little unclear or even lacking at times.  Here are a few points that we learned that we think may be very helpful to you as you configure your xDB Cloud subscription. This isn’t meant to replace Sitecore’s documentation but merely provide some clarification around areas that were unclear or incomplete from our perspective.

1. LicenseID is important.  Your xDB Cloud subscription is tied to your Sitecore license ID.  Temporary licenses are not eligible to be associated with xDB Cloud subscriptions so you’ll have to have your permanent license in order to set this up.  And if you have an older Sitecore license, the license file will have to be regenerated in order to support xDB.  You’ll need to contact your Sitecore sales representative in order to make that happen.
2. DeploymentType should be Prod.  If you have several tiers of environments (Dev, QA, Stage, Pro, etc.) then you may have multiple xDB Cloud subscriptions.  We recommend that you have at least 2 subscriptions, one for production and one for non-production.  This allows you to ensure that your production configuration matches the configuration in your non-production environments.  You could configure your non-production environments to use the same production xDB Cloud subscription but then you start injecting non-production analytics from your internal users, developers, test team, etc. into your production analytics.  So we recommend the two subscription approach.  But note that in all environments, both production and non-production, your DeploymentType should be configured as Prod.
3. DeploymentID identifies the subscription.  In the scenario above, with a production and a non-production subscription, you’ll have 2 DeploymentID values configured.  You’ll have one called “Perficient Production Instance” (or something similar) and one called “Perficient QA Instance” (again, or something similar).  The values provided here are entirely up to you.  Each server that you want feeding analytics data into the configured subscription will use the same value for DeploymentID.  So in a configuration with multiple production content delivery servers, each server will use the same DeploymentID because they’ll all be feeding analytics data into the same xDB Cloud subscription.  Your non-production instances will similarly be configured with the same DeploymentID across those servers (but with a different value from that used in production).
4. DeploymentID is immutable.  This is very important.  Once you’ve configured a DeploymentID and that Sitecore instance has started, Sitecore makes a call to the xDB Cloud services.  It passes the LicenseID and the DeploymentID as part of those calls and looks to see if that LicenseID is registered with a subscription and then if that DeploymentID has been set up.  If the DeploymentID has not been setup, Sitecore first checks to see if you have a subscription available.  If you do then Sitecore sets up that DeploymentID within the xDB Cloud platform but if not, an error is returned.  In the example above, with 2 subscriptions and 2 production CD servers both configured with a DeploymentID of “Perficient Production Instance” then when the first server starts, it’ll make a call to the Sitecore xDB Cloud services, find 2 available subscriptions and register that DeploymentID.  When the second CD server starts, it’ll make the same call with the same LicenseID and DeploymentID, find that everything is already registered and be happy.  When the first non-production servers are brought online (and I realize you’d typically bring non-production online well before production, just stick with the example so you can understand how the system works :)), they’ll use the same LicenseID and the DeploymentID of “Perficient QA Instance.”  It’ll find the DeploymentID is not registered and there’s 1 remaining subscription and it’ll register the DeploymentID and be happy.  But if another server were to come online and attempt to register a DeploymentID of “Perficient Dev Instance” (or anything other than the first 2 that have already been registered), the call will return an error because that’s not an existing DeploymentID and no subscriptions are available to register it.  Should you find yourself in the situation where you’ve incorrectly registered a deployment ID, you’ll have to open a ticket with Sitecore support to resolve the issue.  They can essentially truncate a DeploymentID from their system and allow you to register a new one but the data will not be transferred over.
5. MongoDB ports are variable.  These are the ports that your Sitecore instance is going to use in order to access xDB Cloud’s Mongo instance.  It’s outbound connectivity from your environment to Sitecore.  Sitecore’s official documentation for configuring an xDB Cloud connection points out that the ports are different from customer to customer.  Under the Firewall configuration section, the documentation reads, “You also need to open specific ports for Mongo communication. The ports vary from customer to customer, therefore you should contact support.sitecore.net to obtain your personalized Mongo ports.”  Well, that documentation is a bit dated and doesn’t really provide the whole story.  Turns out, you don’t need to contact Sitecore support.  A more recent Sitecore article on the xDB Cloud service REST API describes how to call Get Firewall Settings (using your LicenseID and DeploymentID as described earlier).  The return results here provide information on the ports, protocols, and host names required for accessing xDB Cloud’s Mongo instance.  We’ve made a request for Sitecore to update the documentation to reflect this change so hopefully we’ll see that incorporated soon.  In the meantime, maybe this guidance will help you.

While there’s certainly a lot more to configuring Sitecore’s access to xDB Cloud than what’s covered here, hopefully this information helps fill in some of the uncertainties we found in the existing documentation.  It’s certainly made our job setting up subsequent xDB Cloud subscriptions much easier.