As we all know, with Sitecore 8.2, Sitecore has introduced a new and faster alternative to Sitecore Publishing, called Sitecore Publishing Service. By default, Sitecore publishing works the way it is in its previous versions. The Sitecore Publishing Service is an add-on to Sitecore 8.2 and in case you want to use it, you need to setup and configure it. We will have a look at that in our next post. But here, lets see Why should we use Sitecore Publishing Service, its concept in brief and next a few questions that come in our mind when we talk of using Sitecore Publishing Service in our Production Environment.
Why Sitecore Publishing Service?
- Improved User Experience (A user doesn’t need to wait for the publishing to end. The dialog doesn’t hold the user. It ends saying go to Publishing Dashboard to check the status)
- Better User Feedback (We get details of all the Publishing Jobs at a centralized location – the Publishing Dashboard. Also, we get required details when we click on a Job and fetch its Job Details.)
- Increased Publishing Speed – reduction of the amount of time that Sitecore takes in the publishing of the items, leading to increased throughput.
Basic Concept and Understanding:
On installing the Sitecore Publishing Service, all the features, pipelines and settings of the current system are no more used. They are replaced by the features, pipelines, settings and dialogs of the new publishing system. To understand the Publishing Service better, we should first take a look at the basic terminologies which Sitecore has come up with, related to Sitecore Publishing Service.
- Publishing Jobs:
We all know that Sitecore Publishing happens as a Job in Sitecore. But the Job was Synchronous in nature — means a Sitecore user needs to keep his Publish Dialog open as the Job gave regular updates on the status of Publishing. If the user closes the dialog, there was no way in a normal Sitecore instance that the end user could know whether the items he/she published got published or faced some issues on the way. This in a way, was waste of time and annoying as well – where a user had to sit for a long time, waiting for the publishing to complete and receive an acknowledgement in the end.
Sitecore identified this and came up with an idea to improve the experience of an end user on Sitecore Experience Platform. Now, with Publishing Service, Sitecore has got rid of the blocking Sitecore Publishing Dialog.
A Sitecore publishing job has many tasks to be done. Collectively, Sitecore calls it Manifests. At the beginning of every Publishing Job, a Manifest is calculated by the Publishing Service. There are various conditions which the Publishing Service needs to check. These conditions include checking workflow states of the items — whether the item has reached Final Workflow state or not, checking if the current item is a media file, checking if any other item related to this item needs to be published as well and so on.
The point to note, the Manifest file is going to be one per Publishing Target.
The activity or process of moving items from the Source instance to the Destination instance, is defined as Promotion by Sitecore. The source of truth for the promotion is the activity done prior to this — the Manifest. The complex logic of which items need to be moved is already completed and mentioned in the Manifest file, next Sitecore Publishing Service simply reads the items from the Source Sitecore instance as mentioned in the Manifest and performs the action of writing the items to the destination instance.
- Manifest Results
What follows promotions are the results. Which items were promoted and what changes were included is mentioned here in Manifest Results. It includes other activities like clearing caches on the Content Delivery servers so that the updated items are reflected. Also, as far as the CM instance is concerned, its about making the status of publishing available.
In summary, we can say Manifest is the POA (Plan of Action), Promotion the Action and Manifest Results the Retrospective.
Sitecore has represented this complete activity in a very nice pictorial way:
Let’s have a look at some initial questions that arise in our mind, when we think about Sitecore Publishing Service in our Production environment.
Does it incur extra Sitecore Licensing Charges?
No, The Sitecore Publishing Service is available for us to use without any Extra License Cost!
How many Manifest/s are created during publishing?
Each Publishing Target gets its own Manifest. The reason behind that is very simple — the items to be added/changed/moved to one publishing target can be different – say a case where we have a Preview and a Production CD instance and only after content looks perfect in Preview it is allowed to publish to Production.
What if my Sitecore Publishing Service is down in Production environment?
This is similar to what would you do, if you need to publish something in production environment and your Sitecore instance is down — you will wait. At the same time, the Sitecore Publishing Service is an ASP.NET Website and hence it takes less time to become up and running as compared to a normal Sitecore instance.
I have a custom processor in current Sitecore publishing pipeline. Where will it fit-in now with Sitecore Publishing Service?
Aah! That’s a great question!
We all know Sitecore. They take care of all the situations in advance. I asked the same question on on Slack in PublishingService channel and on Sitecore StackExchange.
As we can see above, there is processor added to it.
Also, the following Event Hooks are worth noting as well.
Conclusion: We all must use the Sitecore Publishing Service extensively in your local environments first — the Common Dev Environment, the QA Environment, the UAT Environment and only when you feel confident, use it in our Production environments. By this, I am not doubting what Sitecore has made, but its about our specific business case!
Happy Sitecore Publishing!