NOTE: We are currently working on updating the Blog post content to reflect the refactoring in Sitefinity PublishingSystem introduced in our latest releases.
In addition we're planning on extending the sample project with a couple of pipes we encounter as frequently requested by clients.
Please find attached an updated sample - PublishingSystemExtensions60 that works with Sitefinity 6.0 and includes an example of a DocumentInboundPipe where you can restring the documents to be indexed only form a specified Document Library.
Please keep in touch as we continue our work in progress on updating the post content and sample project
How many times have you experienced the need to provide data from you application or to consume some data from other applications? In most of the cases you need to implement some sort of data conversion to other format and then apply some business logic over it. If you have to work with data that has an identical structure it is easy, but what about working with data that has a different one? Sometimes such data conversions might be a very complicated thing to do. The idea of the Sitefinity publishing system is to solve this kind of problems. For example, you have to create a search for Content Items and Pages. Clearly, they have a completely different structure as data types. So here's what we did to solve this problem. We created 2 pipes – one for the content items and one for the pages that convert the input data into identical structure and create another pipe that knows how to put this data into the search provider. I believe you already see the benefit of this.
In the publishing system you have Inbound Pipes, Publishing Point and Outbound Pipes. What are their purposes? First we have a publishing point - this is the place where we accumulate the data from different sources. We have 2 types of publishing points out of the box - persistent and pass through. Persistent pipes store the data into the database and the pass through immediately push the data that is received. The data is coming from the inbound pipes into the publishing point and after that is processed by the outbound pipes. On the other hand, we have Push and Pull pipes. Push pipes pass the data to the publishing point when they receive it. Pull pipes expect someone to request to get the data from them. With this you can have various scenarios like:
- 1. Push Pipes, Persistent Point and Pull Pipes.
- 2. Push Pipes, Pass through Point and Push Pipes
- 3. Pull Pipes, Pass through Point and Pull Pipes.
The first scenario is very useful when you import data from somewhere and you want to store it. With this approach, you collect data which you cannot guarantee that will exist upon the request from the external source (for example importing an RSS feed).
The second scenario is useful in cases when you want to flush some data from the Sitefinity CMS into some external source like Twitter, but you don’t want to persist this data.
The third option is good for scenarios like RSS in Sitefinity – you have the data and there is no need to duplicate it in the publishing point.
You can also have a combination between Pull and Push pipes on both sides of the publishing point.
The publishing system is invoked every time when you save item with the Fluent API. This creates a Schedule Task that will invoke the publishing system in a background thread.
Basically this is the brief explanation of the Publishing System concept.
I have attached a sample of how can you create custom pipes.