I discovered an issue with the Resolve Sitecore Pipeline step in DEF 1.4.1 on Sitecore 8.2 where my Pipeline Batch process would occasionally return and attempt to update the wrong item. In this post, I will explore how that is possible and provide a simple solution to prevent it from occurring.
I ran into an issue with Sitecore’s Data Exchange Framework v1.4.1 where my pipeline batches would intermittently create thousands of duplicate Sitecore items. This caused a bit of management overhead having to clean out the duplicates. Following some investigation, I decided to add some defensive coding by introducing a Custom Resolve Sitecore Item Processor to replace Sitecore’s OOTB pipeline step and prevent duplicates from being created.
Have you ever had to look at the Solr logs for potential issues? It’s not a fun task and the Solr logging UI doesn’t exactly make it easy. In fact, it’s easier to crack open the logs using your favorite text editor. But even that can be challenging.
I’m sure there are plenty of tools out there to help make this task easier like Splunk but what if you don’t have Splunk? I found this handy dandy tool to be pretty quick and useful for parsing Solr logs when troubleshooting issues.
I’ve worked on various Sitecore implementations where the customer has often run into issues with data not being returned as expected the first thing I do now to troubleshoot is to check the Solr Index.
Check Solr Is Up
- If you are not sure of the address of your Solr instance you can locate the url in the following configuration file app_config/includes/Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config and the setting, for example: <setting name=”ContentSearch.Solr.ServiceBaseAddress” value=”https://localhost:8983/solr“></setting>
- Use Solr Ping to check the status of the master solr index http://localhost:8983/solr/sitecore_master_index/admin/ping?wt=json
- You should receive the following output with the status of OK: