GetDataSourceItemByIdOrPath processor in parseDataSource Sitecore pipeline
Sitecore is based on pipeline and processor configurations. Irrespective of XM or XM Cloud, pipelines and processors are here to stay. How much ever you read and know about pipelines/processors, there is always going to be a gap since there are so many of them. With that mindset, in this blog post, I cover the GetDataSourceItemByIdOrPath processor in parseDataSource pipeline since I couldn't find any Google search results relevant to this pipeline processor. If you could get some head-start due to this blogpost and go on to accomplish something better, please let me know and if possible, add this blog post as reference!
GetDataSourceItemByIdorPath process flow:
In this post, I've used the patch:instead option to look at the inner workings of this processor. I added some custom logging to see how many times this processor is fired. I nullified this processor to see what is the impact on the concerned Sitecore interfaces. Also, tried to use it in a scenario. Note that this blog post is based on Sitecore 10.4.0 although these processors are part of earlier Sitecore releases.
List of processors in parseDataSource pipeline:
|
Pipeline |
Processor |
Assembly |
|
parseDataSource |
GetDataSourceItemByIdOrPath |
Sitecore.Kernel |
|
|
GetDataSourceItemByDataUri |
Sitecore.ContentTesting |
|
|
GetDataSourceItemByQuery |
Sitecore.ContentSearch.Client |
GetDataSourceItemByIdorPath Process method:
Interestingly, GetDataSourceItemByIdOrPath class by itself is a standalone class that doesn't inherit from other base Sitecore classes.
Patch Config:
When does this processor fire?
Generally, any item that has a datasource specified should invoke this processor. On further analysis of Sitecore interfaces, this processor fires while loading dashboard texts or graph labels stored in Sitecore core database. Also, probably a coincidence that interfaces doing background calls like these do invoke this method:
The Process method has ParseDataSourceArgs as its input argument and holds the content datasource id and database as member properties. Here is a snapshot of the ParseDataSourceArgs data while loading the Sitecore Launchpad.
How many times this process fires?
Here is a snapshot of the log messages while loading the Launchpad:
On a fresh instance, 10 occurrences - every time launch pad is loaded. In my case, this is one of the first times the launchpad is loaded in this fresh instance and note that none of the interactive graphs (to the right) are visible due to lack of any data although the concerned content/label is retrieved by this processor method every time:
#######
#######
While loading Experience Editor(XPE) for home item, again on a fresh instance, the Process method receives 126 hits. Based on the log entries, its understandable that the process method is successfully fired whenever ribbon label content is retrieved. To give an idea about calls to master db content retrieval, if a home item with one data source is specified, two calls are made to this processor method to retrieve the master data source item data.
Interestingly, this method didn't receive any hits while loading content editor.
Email Experience manager:
There were 79 hits every time email experience manager was loaded and some of the items seem to be repeatedly loaded (like Primary Navigation) as per the log. Note that this is for a blank EXM dashboard without any underlying data. It would be interesting to analyse a possibility to reduce log entry with one of the items as test data (like Primary Navigation) for optimised content loading:
What-if this process is nullified?
I returned null from the void process method and deployed to see that the necessary content in related interfaces like XPE and EXM were still loaded. I went ahead and completely removed the original GetDataSourceItemByIdOrPath processor and the XPE loaded successfully:
Practical Scenario:
As far as I analysed, this is probably a redundant processor because of the ability to nullify this completely and still the interfaces working fine but I will further analyse with the combination of other processors to see if the nullification has any impact down the flow. Another issue probably across the stack is multiple log entries for one retrieval. One successful thing I could do was edit the name for the items (with a custom string prefix within a beginedit and endedit block). This got saved to the respective item name in Core DB but that doesn't have any practical value.
Comments
Post a Comment