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.
In my last post, I implemented a message queue which decoupled our application and provided a level of redundancy for our messages. But what about messages that are not processed successfully? This could occur for a number of reasons there might be an issue with the consuming application, a network issue or even an invalid message request.
A Deadletter queue, also known as an undelivered-message queue is a holding queue for messages that cannot be delivered to their destination. They provide a mechanism for persisting your failed messages without continually trying to process the same message. The deadletter queue could then be monitored and any failed messages can be examined and appropriate corrective action taken.
In my previous post, I looked at message queues and how they can be utilized in your solution architecture. In the second part of this series, I will explore how you can add messages to a Message queue (Message Publisher) and Consume messages (Consumer) from a message queue with Sitecore and AWS SQS.
Using the example of an Events Booking site where a user finds an event they are interested in complete an event registration form which gets submitted to Event Bookings Application via an API. The Booking Application is known to go down and it is not uncommon to run into connection issue with the API causing booking requests to get lost. The Booking Application is old and unreliable and occasionally goes down.
By adding a Message Queue we decouple the website from the booking application and provide a level of resilience. If an outage does occur or there is an API connection issue instead of messages being lost they will be persisted on the queue. When the booking application comes back online or connection has been restored the messages on the queue will get processed.
If you didn’t make it Sitecore Symposium or my presentation at the Cleveland Sitecore Usergroup then check out some highlights, key takeaways and discover how Sitecore Elevated my experience at Symposium!
Sitecore’s CEO Mark Frost – kicked off the Opening Keynote, welcoming the 3000 in attendance representing 53 Countries.
Mark introduce the theme for this year’s Symposium: Elevate the Experience.
“Because it is EXPERIENCES not products customers are buying today.” Mark Frost
Mark wasted no time in diving into how Sitecore is going to Elevate the Experience!
The basic architecture of a message queue is simple, there are client applications called producers that create messages and deliver them to the message queue. An application, called consumer, connects to the queue and retrieves the messages to be processed. Messages are stored in the queue until the consumer retrieves them for processing.
In this post I will share some the benefits you can gain from utilizing message queues in your application architecture and look at some of the queuing platforms available today. In the following series of posts I will explore how message queues can be utilized with Sitecore:
So in this short post, I’ll cover a few common mistakes that you might make when starting out configuring your DEF project, I know I certainly did and a fellow colleague hit the same issues on a recent project he just started. Hopefully, it will prevent you from falling into the same trap and banging your head against the wall.
Symptoms: You see the following error is logged when you run your pipeline batch and you have a Resolve Sitecore Item Pipeline Step. You will probably see something like this in your Sitecore logs:
[Date/Time] ERROR An item with the same key has already been added.
…
[Date/Time] ERROR Pipeline step processing will abort because a critical error occurred during processing.
Possible Cause: You see this occur during the Resolve Sitecore Item pipeline step processor. It usually means you have duplicate field name on the item you are trying to create in Sitecore. Check the template of the Sitecore item you are attempting to create including any inherited templates and resolve any duplicate fields names.
Symptoms: You have a pipeline batch with pipeline steps that read data from a source, iterates the items and create an item in Sitecore. The Item is created with the correct identifier, however, the fields on the Sitecore item are not populated.
Possible Cause: Most likely this is an issue with Data Location field has been set incorrectly on a pipeline step. Go through each step and check the location value.
Symptoms: You have a Resolve Sitecore Item Pipeline step followed by an Apply Mapping Pipeline step. Your new Item gets created however, all the fields are null. You see something similar to the following in the logs (Debug mode):
[Date/Time] DEBUG Value converted for search. (pipeline: Handle Single Row Pipeline, pipeline step: Resolve Sitecore Item Pipeline Step, field: UniqueId, original value: XXX-XXXX-XXXXX, converted value: XXX-XXXX-XXXXX)
[Date/Time] DEBUG Starting search for item. (pipeline: Handle Single Row Pipeline, pipeline step: Resolve Sitecore Item Pipeline Step, field: UniqueId, value: XXX-XXXX-XXXXX)
[Date/Time] DEBUG Item was not resolved. Will create it. (pipeline: Handle Single Row Pipeline, pipeline step: Resolve Sitecore Item Pipeline Step, identifier: XXX-XXXX-XXXXX)
2/27/2019 9:52:34 PM DEBUG New item was created. (pipeline: Handle Single Row Pipeline, pipeline step: Resolve Sitecore Item Pipeline Step, identifier: XXX-XXXX-XXXXX)
[Date/Time] ERROR Pipeline step processing will abort because the pipeline context has no target assigned. (pipeline: Handle Single Row Pipeline, pipeline step: Apply Mapping Pipeline Step, plugin: Sitecore.DataExchange.Plugins.SynchronizationSettings, property: Target)
[Date/Time] DEBUG Pipeline processor finished processing pipeline steps. (pipeline: Handle Single Row Pipeline, completed pipeline steps: 3)
Possible Cause: Check the Resolve Sitecore Item Pipeline Step and look the Object Resolution section ensure the Resolved Object Location is set: Pipeline Context Target and not Pipeline Context Source. If that is set correctly then you might want to check you the Converter and Processor Types correctly:
If you are using a custom Processor & Converter ensure you have set the SupportIds attribute on your Converter class so that it matches your custom template.
Hope this helps!
