<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>bram-stoop on bramstoop.com</title>
    <link>https://www.bramstoop.com/tags/bram-stoop/</link>
    <description>Recent content in bram-stoop on bramstoop.com</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Thu, 29 Aug 2019 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.bramstoop.com/tags/bram-stoop/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Sitecore Hotfix Version Selector</title>
      <link>https://www.bramstoop.com/posts/2019/08/2019-08-29-sitecore-hotfix-version-selector/</link>
      <pubDate>Thu, 29 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.bramstoop.com/posts/2019/08/2019-08-29-sitecore-hotfix-version-selector/</guid>
      <description>BACK TO BLOG OVERVIEW
 Because of the fact we are running a lot of different Sitecore versions for our customers we love to have a good overview of the available hot fixes. Sitecore has a great GitHub page for this:https://github.com/SitecoreSupport. Unfortunately it is hard to list all specific hotfixes per version.
The idea to daily crawl the GitHub page began to rise. A runbook writes the needed JSON data to a private storage account wheres we read the data using a .</description>
    </item>
    
    <item>
      <title>Validate (all) your Sitecore ARM templates on build</title>
      <link>https://www.bramstoop.com/posts/2019/05/2019-05-16-validate-all-your-sitecore-arm-templates-on-build/</link>
      <pubDate>Thu, 16 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.bramstoop.com/posts/2019/05/2019-05-16-validate-all-your-sitecore-arm-templates-on-build/</guid>
      <description>BACK TO BLOG OVERVIEW
 While working with ARM templates and Azure DevOps it definitely adds value to validate all your Json files during build. This might save you a lot of time. To implement this you could setup the following tasks within your build pipeline:
Add a &amp;lsquo;npm&amp;rsquo; task within your build and configure it as below:
Now add a subsequent Powershell task, run it inline and add the following script:</description>
    </item>
    
    <item>
      <title>Rebuild your reporting database with electric speed</title>
      <link>https://www.bramstoop.com/posts/2019/05/2019-05-13-rebuild-your-reporting-database-with-electric-speed/</link>
      <pubDate>Mon, 13 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.bramstoop.com/posts/2019/05/2019-05-13-rebuild-your-reporting-database-with-electric-speed/</guid>
      <description>BACK TO BLOG OVERVIEW
 Since there is a lot of information to be found on the terribly slow rebuilding of your reporting database I would like to provide you with the setup and findings I did while rebuilding the reporting database for one of our customers. I found a configuration/path whereas you will at least process 100k interactions per hour and most likely more. Whenever you want to test this on another environment than production (hopefully) I suggest you take a brief look into one of my earlier posts: Restoring or migrating your Xdb data.</description>
    </item>
    
    <item>
      <title>Restoring or migrating your Xdb data</title>
      <link>https://www.bramstoop.com/posts/2019/05/2019-05-13-restoring-or-migrating-your-xdb-data/</link>
      <pubDate>Mon, 13 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.bramstoop.com/posts/2019/05/2019-05-13-restoring-or-migrating-your-xdb-data/</guid>
      <description>BACK TO BLOG OVERVIEW
 Whenever you want to restore your Xdb data to another environment there are certain steps to take. I will take you through the steps to accomplish this in this post. The described process is valid for Sitecore 9 and Azure PAAS environments and consists of a total of three tasks:
 Restoring or migrating your Xdb data Rebuilding your reporting database Rebuilding your Xdb index  Restoring or migrating your Xdb data</description>
    </item>
    
    <item>
      <title>Rebuilding your Sitecore Xdb index [v9.0.1]</title>
      <link>https://www.bramstoop.com/posts/2019/03/2019-03-21-rebuilding-your-sitecore-xdb-index-v901/</link>
      <pubDate>Thu, 21 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.bramstoop.com/posts/2019/03/2019-03-21-rebuilding-your-sitecore-xdb-index-v901/</guid>
      <description>BACK TO BLOG OVERVIEW
 Since there is no complete out of the box functionality for rebuilding the Sitecore Xdb collection based on all historical data within your sql shards we received a hotfix from Sitecore to backport this functionality from 9.0.2. to 9.0.1. In case you are in need of this hotfix, please reach out to Sitecore and reference: &amp;ldquo;SC Hotfix 232561-2&amp;rdquo;.
 Good news. We&amp;rsquo;ve made a backport of the fix from the 9.</description>
    </item>
    
  </channel>
</rss>