How to export Sitecore item data in a customized comparable way with „Sitecore Powershell Extensions“ (SPE)?
ASP.NET Web API 2 is designed as a stateless Web API framework, therefore, the visitor session context is not automatically created on each web request. Normally, for a Sitecore solution, it is necessary to enable Sitecore Context session-dependent features/data in some or even most of Web API calls context.
One of the options is to create Web API Route which would automatically enable session state for all Web API calls that are made via this route. To be clear, we are basically looking for enabling a regular ASP.NET session state in the context of ASP.NET Web API 2 calls.
The solution option which we consider in this specific case has the following implementation approach:
- Register a new route using ASP.NET Web API 2 – a dedicated route for the session-context-enabled Web API calls handling.
- Retrieve the new route’s object using a regular ASP.NET and enrich it with a request handler that creates a regular ASP.NET session state context.
Nowadays, almost every Sitecore solution needs a custom Web API endpoint implementation. One of the common web API uses cases when a front-end component needs to be dynamically rendered at the client-side (eg a browser page). However, there could be some challenging factors of the back-end implementation:
- The Web API response data needs to be presented in JSON format.
- The Web API response data is calculated based on multiple Sitecore items.
– The data evaluation is expensive in the performance perspective so it has to be cached.
– The data cache needs to be invalidated when the corresponding Sitecore items are changed.
- The data to be transferred over the network only the data has been changed, otherwise, the client-side cached version of it will be used.
To serve the data in JSON format via Web API endpoint, it is possible to use ASP.NET Web API 2. Therefore, no significant challenges here.
To cache the data Sitecore HTML Cache can be used. Sitecore HTML Cache invalidates automatically by Sitecore (normally, on Publish). In this case, the Controller Action would need to produce the data and let Sitecore HTML Cache store it. However, it would be good to remove the cache storage responsibility from the Controller Action. In addition, it would be necessary to avoid Controller Action execution if the data already exists in the cache. Luckily, ASP.NET Web API 2 Action Filter attributes exist that can help to do this. The Action Filter attribute has two handlers:
- OnActionExecuting – allows accessing the current request context, including the request parameter object (s) and terminate the request with a custom response without going ahead with the Controller Action execution.
- OnActionExecuted – allows accessing the response result in the cache.
To address the redundant data transfer between the server and the client, HTTP ETag mechanism can be used which allows producing 304 Not Modified HTTP response. Again, A SP.NET Web API 2 can help to solve this.
HTTP ETag mechanism, including Sitecore HTML Cache, can be applied in a generic way to any controller using Action Filter attributes.
After upgrading to Sitecore 9, our customer noticed some odd behaviour regarding channel allocation in Experience Analytics. The problem was that most of the traffic had been assigned to the „Direct“ or „Organic non-branded search“ channels. All the other channels … Weiterlesen
When creating new/custom Path Analyzer maps in Sitecore, sometimes the chosen data does not match the desired result or there is an error in the rules configuration (making them „not working“) – in such cases, it would be helpful to … Weiterlesen
Using the Sitecore Rule engine for solving a use case for automatically filling a field in Sitecore, when saving a page item: an empty Page Description field should inherit the content of an existing Introduction field. Weiterlesen
With extensive updates to the documentation, some small code fixes and improvements, the 2.0.0 version of NitroNet introduces also a brand-new feature called Additional Arguments which allows to be more flexible and more compatible with the handlebars templates created with Nitro by the friendly frontend engineer of your choice. Weiterlesen
We recently had a situation, where we quickly had to grab a virtual whip in order to tame the Sitecore AccessResultCache from going crazy – in terms of reaching it’s allocated size within seconds and thus being constantly cleared by Sitecore.Caching.Generics.Cache
You may be working with personalization conditions on components in the Sitecore Experience Editor, and when trying to preview any of your condition rules – simply nothing changes.
According to the release notes of Sitecore 9.0 Initial Release, the Social Connected application is not included/deprecated since Sitecore CMS 9. As a result, we searched for another option to bring back this functionality to Sitecore 9 – and we found it: the SocialConnect module from Addact Technologies, which is nicely compatible with Sitecore 9.0, Sitecore 9.1 and newer. Weiterlesen