Skip to main content

Posts

Showing posts from 2018

Anatomy of Sitecore Business Rule - Macros

In previous posts, we talked about  field syntax and the basic structure of business rules . This time we are going to dive into macros in the business rules. Macros are used as part of the business rule syntax. The syntax looks like this and calls for 4 parameters. [Property to set, Operator/Macro, AdditionalParameters, Display text]. When I first started working with business rules the difference between operator and macro was confusing. To add to this confusion some of the out-of-the-box macros are named with the term "operator" (like ListOperator who's configuration points to a class called ListMacro and the class implements IRuleMacro). Anything under the path /sitecore/system/Settings/Rules/Definitions/Macros should be a macro and should implement IRuleMacro. Macros have the follow characteristics: They inherit the IRuleMacro interface The interface requires this execute method void Execute(XElement element, string name, UrlString parameters, string value)

Anatomy of Sitecore Business Rule - Field Syntax

In the previous post, I talked about the general anatomy of Sitecore Business Rules . In this post, we will dig more into the rule itself and how you can set one up. In the previous post, I mentioned the "special syntax" a rule has in the "text" field. Let's dig more into what this is. This is broken into 4 parameters, not all of which are required.  Property to set , defines the public property of the class where we want to assign the value coming from the content author input Operator or Macro , the operator we want to use to evaluate the condition. In this case, this will be a string comparison operation Additional Parameters , this parameter will depend on the type of macro that we use, this could be a default text value if we are using the default macro,  it could be a default start path if we’re using the Tree macro ( root=/sitecore/content/myitem )  – think of it like setting a field source when we’re building a template in Sitecore. A full l

Anatomy of Sitecore Business Rules

A powerful part of Sitecore is the business rules engine. Many say it is an underutilized part of the platform. I think part of this is because it is not very well documented. I agree it is a very powerful part of Sitecore so I wanted to spend some time digging in and documenting more about how it works and how to utilize it. First, let's level set at a high level on what this is. I don't want to rehash the intro stuff as Sitecore documentation does a good job at explaining it at a high level . The documentation that is slim is breaking down how it is configured and how to extend it. There are a few blogs out there that show quick and dirty examples of how to create custom rules. Before we go there though I want to break down the anatomy of a rule that currently exists. I think this helps level set how a rule comes together. Once we understand its parts it is easier to create our own, and then the power is really unleashed. Using a rule There are many places where a

Install Sitecore SIF

This is a pretty straightforward task so this will be short but here are a few commands to help you out, because if you don't know or can't remember a searching you must go. First, make sure to launch Powershell in Admin  mode. Register the Sitecore Gallery Register-PSRepository -Name SitecoreGallery -SourceLocation https://sitecore.myget.org/F/sc-powershell/api/v2 Install SIF Install-Module SitecoreInstallFramework Update SIF Update-Module SitecoreInstallFramework Remove SIF  The reason here is version 1 and version 2 do not play nice together unless you specify the version you want it to use Install-Module -Name SitecoreInstallFramework -RequiredVersion x.x.x Uninstall-Module -Name "SitecoreInstallFramework" -AllVersions Verify what has been installed/registered Get-Module SitecoreInstallFramework –ListAvailable

Get a new project build up quickly with NuGet Files

One of the things I hate the most is standing up a new project in Visual Studio and adding all the NuGet packages I need. Especially, when it comes to Unit Test projects or the like where I know I have a base set of NuGet files I will always need. Sadly you can't just update the packages.json file for the project and hit restore. There is, however, a way that is almost as straightforward. Enter the "Update-Package -Reinstall" command. This command reinstalls all the packages in a solution, so, you probably don't want to use this as it will probably blow away some setup you want to keep. If all you want to do is have a project pull in all the NuGet assemblies you just added to a package.json in a project just do "Update-Package -Reinstall -ProjectName <project name>". Now we are in busy. We can put all our standard NuGet assemblies in the package.json file run this command and our project now has all the base level assemblies we were after. That is

Sitecore Unicorn deployment with Octopus and Azure Dev ops

I have been working on getting a Sitecore solution using Unicorn (with auto-sync and publish API call) to deploy to my environments using Azure DevOps and Octopus. The power of all these together is pretty cool. It allows you to take a Sitecore solution from its state in a local developer instance and move everything that is needed, code and content, to a deployed environment. In the end, all your code is deployed along with all Sitecore assets and those assets are also published! It takes just a little bit of setup. This does not go into setting up Sitecore or Unicorn as those projects have that well documented. Once you have those all set up though and you are checking your code and your Unicorn YML files into Azure DevOps you are ready to go here. Azure DevOps Setup These are the build steps I setup. There are really just two steps that need a little customization work.  Copy Unicorn YML files.  This is just a basic copy activity that takes the *.yml files and move

Experience Profile Anonymous, Unknown and Known contacts

When you first get started with Sitecore's experience profile the reporting for contacts can cause a little confusion. There are 3 terms that are thrown around, 1) Anonymous 2) Unknown 3) Known. When you read the docs they can bleed into each other a little. First, have a read through the Sitecore tracking documentation to get a feel for what Sitecore is trying to do. There are a couple key things here to first understand: Unless you call " IdentifyAs() " for request the contact is always anonymous.  Tracking of anonymous contacts is off by default.  Even if you call "IdentifyAs()" if you don't set facet values for the contact (like first name and email) the contact will still show up in your experience profile as "unknown" (because it has no facet data to display).  Enabled Anonymous contacts Notice in the picture I have two contacts marked in a red box. Those are my "known" contacts that I called "IdentifyAs"

Experience Profile Anonymize or Right to be Forgotten

Experience Profile This threw me off a bit at first as the action that is being taken is not very clear. When you open a profile record in experience profile and click on actions, one of the options is "Anonymize". If you click on this action you are sent back to the search screen and that contact you were just on is gone. At this point, you might be able to figure out what happened. At first when just playing around it is a little concern what happened. The red "X" helps here as well, because what you are doing is executing the "right to be forgotten" or "Anonymize" command on this contact. That means their data (their PII data) is removed from the database. Hence, when you go back to the profile search screen you can't find them anymore. Beware though, if you click on it, it is done. No warning here folks.

Back in the Sitecore world again!!

I have recently been able to get back into the Sitecore world and I am excited! I have been living in the Tridion world for a few years and it has been painful. With that being said it is not like Sitecore does not have it's pain points as well. Here are some I have run into as I start playing with version 9. Keep your license file name "license.xml" Using SIF to install locally only works with a license file named "license.xml". I had a temp license for awhile so in the file name I put the expiration date. I updated the install powershell script for SIF with the new license file name (yes in both places) and run the install. The install was fine until it tried to start the indexer window service. That step failed as the service would not start. When I looked at the logs the service said it was still looking for a file name "license.xml" and it was missing. Sure enough the license file I referenced was not copied over. I have not found the root cau