A Master Key to Your Content

Once in a while I find myself in a situation where workflow hasn’t been completed but users have begun content entry or cleanup. Normally these users also have not been setup as site admins, but with some level of custom accesses. This causes the editors to spend time dealing with locking and unlocking items for editing. At times they’ll not even realize and they locked the item, and you start to get a trail of items edited then forgotten.

What’s an admin to do?

Without too much work you can turn-on the gutter icon for ‘Locked Items’, then drill through the tree visual identifying and jotting down what’s locked and who.

Locked Items Gutter Setting

But that’s tedious (and a bit error prone). As with all cool administrative tasks in Sitecore we are best to turn our attention to Sitecore PowerShell Extensions (SPE) in the marketplace

The SPE ships with function that gives us the ability to see and react to locked items on our site.

Get-LockedChildItem

Step 1 – Import Function

By default the function Get-LockedChildItem is not callable. You must first ‘import’ it into your console or ISE session.

Import-Function Get-LockedChildItem

 Import-Function Get-LockedChildItem

If you don’t perform an import of the function, then you’ll receive a red error message like the following

Get-LockedChildItem : The term ‘Get-LockedChildItem’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Step 2 – Get a Report

Before performing any sort of automation on our content tree, we should always produce a report that provides some context of what may get changed. In this case we want to get a listing of all items that are locked

Get-LockedChildItem -Recurse | Show-ListView

Here we are using the ‘Recurse’ flag to walk the entire tree. The collection of items locked are then piped to the very nice Show-ListView, allowing for easy review and export.

Get-LockedChildItem as a Report

We can also run the report for specific users via the -LockedBy parameter

Get-LockedChildItem -Recurse -LockedBy 'sitecore\editor' | Show-ListView

Step 3 – Time to Free the Content

Once we understand who has what locked we can start performing some mass freeing of content with the -Unlock parameter. To unlock everything, we run

Get-LockedChildItem -Recurse -Unlock

If we want to perform some hand picking of section of the site, we can either open the console to a certain node of the tree and run the above or define the start point with -Path parameter. This will unlock all the children of the item defined by path, even providing a nice output of what was unlocked.

Get-LockedChildItem -Recurse -Unlock -Path {85E0AF8C-ED9F-4CDA-BFB2-084015E17634}
#or
Get-LockedChildItem -Recurse -Unlock -Path /sitecore/content/Coffeehouse/Home/About-Us

Unlock for a path

Finally, if we want to unlock for a specific individual we can re-use the -LockedBy parameter,

Get-LockedChildItem -Recurse -Unlock -LockedBy 'sitecore\editor'

Not a Replacement for workflow (i.e. the Disclaimer)

Being able to execute unlocking of content on a mass scale is helpful, but this shouldn’t be the replacement for properly planned and built workflow on your site.

Load Test from the Cloud

Building a any application, but especially high traffic websites on Sitecore one of the final steps before launch is to tune ensure any caching mechanisms have been properly tuned to support the needs of the organization.

One of the difficulties my teams always have is finding a server or two or three with enough available horse power to pound on out site. Running from a simple local machine is good enough for about 2 minutes until it begins heating the entire office.

But this headache and a more reasonably temperature office exists. How did we achieve this utopian level? Through the cloud of course…Visual Studio Team Services to be specific, by the way it’s free to register and take advantage of even.

Visual Studio Team Services provides a number of different tools and services, many for free such as GIT repos, CI, team and task management. One of the services provided is the ability to run scaled load testing from the cloud. Depending on your needs, you have the opportunity to run four types of tests from VSTS, Visual Studio Test, HTTP Archive Based Test, URL Based Test, Apache jMeter Test.

Load Test Options

Two things I found great about the service is, A) I get a decent number of free testing units (called Virtual User Minutes) to perform my testing, and B) I don’t have to purchase a high level MSDN or Visual Studio license. Why? Because it supports my tool of choice Apache’s jMeter.

As easy as 1, 2, 3

I can build and even pre-test my jMeter test scenarios on my local or internal hardware to confirm it generates the proper simulated traffic. After this is as easy as 1,2,3,4..and maybe a 5th step.

  1. Login to Visual Studio Online
  2. Click over to the Load Test screen
  3. Create a new test of type jmeter from the selector
  4. Upload the jmx file representing you developed jMeter scenario
    Load Test Options
  5. Upload your jmx file that defines your test run. Note, that the name of the file is the name the test will be referenced in the other screens.
  6. Set yout number of agents, length of run, and region the test should run from.
  7. Click Run
    Load Test Setup
  8. Smile and sip your coffee as the data pours into convenient charts and table.

Not Accessible to the World, yet?

If your site is sitting behind a firewall and only has internal DNS, with some additional setup you can still leverage the power of the cloud to perform your test, Testing private/intranet applications using Cloud-based load testing.

Testing Sitecore

For testing Sitecore load check-out this pre-started jMeter test provided by Sitecore themselves https://kb.sitecore.net/articles/398589. One thing to note if you would also like to test out or populate out xAnalytics data you will want to disable robots detection via the following patch config. Robots detection needs disabled as the tester does not trigger page events as required by xAnalytics for identifying a ‘human’ user. (Just be sure to turn it back on before site launch.)

<! --  ANALYTICS ROBOTS IGNORE ROBOTS    
    Ignore requests and do not write information to the Analytics 
        database when the visitor       
        classification identifies the visitor as a robot.   
    Default: true
 -- >
<setting name="Analytics.Robots.IgnoreRobots">
    <patch:attribute name="value">false</patch:attribute>
</setting>

If data still isn’t properly collecting you may also need to tweak the robot’s timeout value to allow the session to run longer.

<! --  ANALYTICS ROBOTS SESSION TIMEOUT 
        The ASP.NET Session Timeout for auto detected robots.
        When the automatic robot detection identifies a session as 
        being a robot, the ASP.NET Session Timeout 
        is set to this value (in minutes).  
    Default: 1  
-- >
<setting name="Analytics.Robots.SessionTimeout">
    <patch:attribute name="value">5</patch:attribute>
</setting>

Its that simple, and now there is no longer any reason to avoid even basic site load tests for Sitecore or any other application.

During my exploration of leveraging this cloud based load testing I found the following links to be informative:

Planning for Cache in Sitecore

This is a follow-up to my Unofficial Sitecore Planning Checklist, where I try to consolidate as much information as I can find on Sitecore’s built in caching.

One of the easiest ways to improve a visitor’s perceived impression of any website visit is through a well-tuned cache. A cache which has been properly tuned will be able to server of requested content quicker, sometimes magnitudes faster than rebuilding the HTML for a page on each request.

Sophisticated caching scenarios can be configured through third-party tools and applications, but even for the most highly trafficked site properly tuning Sitecore’s different cache options should provide the desired performance gains. As site cache is configured and tuned, be aware the need for vertical or horizontal scaling may become necessary. (For details on scaling Sitecore checkout Scalability)

Determine the cache limits required

The general practice for Sitecore caching tuning is to turn all cache limits off via the following simple cache patch config:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <setting name="Caching.DisableCacheSizeLimits">
    <patch:attribute name="value">true</patch:attribute>
    </settings>
  </sitecore>
</configuration>

With the cache limits now disabled, Sitecore will try to manage based on current traffic and available resources to cache as much as possible. By performing well structured load test or allowing the site to run in this manner, the team should monitor both server resource utilization as well as the Sitecore cache levels to determine areas that should be manually limited to maximize performance.

To monitor what Sitecore has cached you can use the Sitecore admin page, http://&lt; your domain >/Sitecore/admin/cache.aspx, or leverage the Sitecore Marketplace module Caching Manager, https://marketplace.sitecore.net/en/Modules/Caching_Manager.aspx.

Cache Manager Options

After data collection has occurred you are ready to begin to evaluate which caches need their limits adjusted from the default level. For more information on the different cache limits that can be set see Sitecore CMS 7.0 – 7.2 CMS Performance Tuning Guide.pdf and Sitecore CMS 6.6 or later Cache Configuration Reference.pdf.

Configuring HTML Cache of Components

The first level of caching to configure to is review each rendering that is created and set the appropriate HTML level caching on it.

Rendering Cache Option

To turn HTML cache on for the rendering, select the first option Cacheable. From here you can customize the how different variations of the control should be cached via the different ‘Vary By’ options. Finally, you can mark that all cache be cleared when the search index is updated via the ‘Clear on Index Update’ selection.

The following fuller description of each cache option is taken from Chapter 4: Output Caching in Sitecore CMS 7.0 or later Presentation Component Reference.pdf.

Clear on Index Update

The Clear on Index Update property controls whether or not a control clears its cache when an item that is associated with the control is updated in the index. This is useful for any control that uses the new Search API to populate its data sources. For example:

  • You have a control that returns all the products that are on special offer from the index.
  • The Clear on Index Update property for this control is set to True.
  • The price of each product is stored in the index.

If someone updates the price of one of the products on special offer, the Clear on Index Update property will the trigger the control to clear its cache because something has been updated in the index that is bound to the control.

VaryByData

The VaryByData property controls whether or not output caching varies based on the data source of the presentation component.

Set the VaryByData property:

  • To False for components that do not generate different output when used with different data sources.
  • To True for components that generate different output when used with different data sources.

VaryByDevice

The VaryByDevice property controls whether or not caching varies based on the name of the context device.

Set the VaryByDevice property:

  • To False for components that do not generate different output when used with different devices.
  • To True for components that generate different output when used with different devices.

VaryByLogin

The VaryByLogin property controls whether or not output caching varies based on whether or not the user has authenticated. For caching configuration involving the VaryByLogin property, the layout engine treats all anonymous users as a single authenticated user.

Set the VaryByLogin property:

  • To False for components that do not generate different output for authenticated than for unauthenticated visitors.
  • To True for components that generate different output for authenticated than for unauthenticated visitors.

VaryByParm

The VaryByParm property controls whether or not output caching varies based on rendering parameters passed to the presentation component. Solutions built with earlier versions of Sitecore may have used the token VaryByParam instead of VaryByParm. Update any instances of VaryByParam to VaryByParm.

Developers set the VaryByParm property:

  • To False for components that do not generate different output when passed different rendering parameters.
  • To True for components that generate different output when passed different parameters.

VaryByQueryString

The VaryByQueryString property controls whether or not output caching varies based on query string parameters passed in the URL. The VaryByParm property causes output caching to vary based on rendering parameter values passed by the developer. The VaryByQueryString property causes output caching to vary based on parameters passed in the URL query string.

Developers set the VaryByQueryString property:

  • To True for components that generate different output when supplied different query string parameters.
  • To False for components that do not generate different output when supplied different query string parameters.

VaryByUser

The VaryByUser property controls whether or not output caching varies by the domain and username of the context user.

Developers set the VaryByUser property:

  • To False for components that do not generate different output for different users.
  • To True for components that generate different output for different users, when the number of active users between publishing operations is relatively small. The VaryByUser treats all anonymous users as a single authenticated user.

To avoid excess memory consumption, avoid using the VaryByUser property except in solutions with relatively small numbers of users, or monitor cache utilization closely. The VaryByLogin property causes Sitecore to generate different output depending based on whether or not a user has authenticated, differentiating anonymous users from authenticated users. The VaryByUser property causes Sitecore to generate different output for each user

Other Caches

Sitecore contains a number of other caches that help to lower the number of calls required to the database for item information and indexes. These are best described in a post from the Sitecore Tactics blog entitled How Sitecore caching work.

Additional Helpful references

One Final Note

Starting in Sitecore 8.2, the Cache APIs where refactored, creating breaking changes to any custom cache providers used in previous versions. Be sure to check out the change list, https://doc.sitecore.net/sitecore_experience_platform/developing/developing_with_sitecore/cache_api_changes.

 

Guide To Creating Dimensions And Filters

Quick Refresher: The customer has asked the Sitecore team to provide additional reporting views using data already being collected by Experience Analytics. (To understand the full request take a look at the first part of the guide.)

This post covers the first two steps

Step 1: Create New Dimension

All of the data that is reported against, starts with a dimension. A dimension consist of a Sitecore Artifact in the Marketing Control Panel and a corresponding, compiled aggregation method and table(s) to support the proper data.

Therefore, creating new dimensions is a task that involves both developers and business intelligence analysts. The BI Analysts work with the customer to help define the questions that they want to ask of the data, and then help the developer understand how the currently collected data can be aggregated to get the needed answers.

This is a process in itself, which we will investigate further in future posts.

Step 2: Create New Filter

Filters are created once, and can be reused throughout different segments. Filters are built using the Sitecore Rules engine to define conditions that must be matched so the element will be added to the resulting data set.

  • Launch the Marketing Control Panel from the Sitecore Launchpad
  • In the content tree, expand Experience Analytics -> Filters
  • Right-click on Filters, choose Insert from the context menu, and then select Filter
  • In the dialog box, provide a Name for the filter
  • Click OK to close-out the Message Dialog
    Image One
  • There are minimal data fields to be filled out for a filter. Expand the Data section of the item and you will see a Rule field to complete
  • Click Edit Rule to open the standard rule editor
  • Choose the rule that best fits the data that you are looking to filter. Sitecore has done some backend magic, which spoofs the ‘current contact’ to allow rules to properly pull users into the filter in the form of Sitecore.ExperienceAnalytics.Aggregation.Rules.AggregationAdaptor.AggregationAdaptorTracker object
  • Finally, be sure to select the action ‘add visit to segment’ to ensure that the contacts are added to the resulting dataset
  • Click OK
    Image Two

As always, feel free to tweet me questions or comments @thecodeattic or on Sitecore Slack Community as @gillissm.

This post originally appeared at https://www.paragon-inc.com/resources/blogs-posts/guide_to_creating_dimensions_and_filters.

 

 

Guide Book to Sitecore Reporting

Taking a journey without a good guidebook can be exciting and scary all at the same time. Having looked at the journey our data moves through from collection, squeezing through formatting to arrive at reporting, I thought we should have some more detailed guiding points (the cheap man’s guide book) as to what we can ‘do’ on the journey.

My first guide book takes a detailed look into the built-in reporting of Sitecore, http://www.paragon-inc.com/resources/blogs-posts/guide_book_to_built_in_reporting.

Journey Into the Aggregation Process Part 2

hope you are not feeling to weary just yet, as we embark on the second leg of the Sitecore Experience Platform data journey. In this leg of the journey we will see how the data points go from living in tables into bright, colorful, and insightful tables and charts. Understanding how these tables and charts populate will allow you to take control of your organizations data and make meaningful decisions to further engage customers. http://www.paragon-inc.com/resources/blogs-posts/journey_into_the_aggregation_process_part_2

 

Journey Into the Aggregation Process

Pack your bags and get ready for an exhilarating trip through Sitecore Experience Platform’s data aggregation process. This introductory post will help you and your team get on board with the basics of data movement as a site visitor becomes an important data point in understanding customer engagement with your brand. http://www.paragon-inc.com/resources/blogs-posts/journey_into_the_aggregation_process