Imagine you have Telerik’s Sitefinity CMS powering the main portion of your website, but have a public 3rd party e-commerce system, an internal 3rd party CRM system interface, and yet another internal 3rd party HR employee portal. Wouldn’t it be nice if the graphics guy could update the company logo on all the sites, or change everything to a holiday skin all at once using Sitefinity’s easy-to-use template system?
If you need to integrate a 3rd party application into a Sitefinity CMS-based website and you can actually get both applications to work within the Sitefinity project, then you probably have it covered with some minor modifications. However, that approach can create quite a messy web.config and bin folder (not to mention dealing with conflicting handlers, providers, and modules – among many other things that might overlap between complex web apps). This is of course assuming that both applications are even .Net.
But what to do when you you want to control the look and feel of a completely separate 3rd party web application with your Sitefinity install?
Approach A: Custom code in the 3rd party app that reads from your Sitefinity DB directly
This approach is direct and simple in theory, but possibly more complex in reality. The biggest problem I see here is directly interfacing with the database instead of using the Sitefinity API – you risk breakage when upgrading. Also, if you have a truly separate 3rd party application (perhaps even on a different server, network, etc), then you might not have easy access to the Sitefinity DB.
Approach B: Add an interface to Sitefinity that publishes the content
This means adding code to both your Sitefinity install as well as your 3rd party app. In that respect, it’s more complex – but it’s also more flexible. Once you’ve created a way for Sitefinity to publish content, it could be consumed by several 3rd party apps. This is the direction I decided to run blindly into…
The intention was to render out the full client HTML of any Sitefinity template, parse it out into logical sections (each ContentPlaceHolder), gather the Theme and header CSS/JavaScript links, and then publish that parsed info in a way that my 3rd party application could easily consume it. Note that the code fixes all links and CSS/JavaScript includes to be absolute URLs, but you will have to also use absolute URLs inside your CSS file if you reference any images.
My first attempt hooked into a Sitefinity event for when templates were published, and saved the parsed content to an XML file in the root folder. I quickly realized that I would actually have to hook into tons of other events as well to keep the XML file accurate (i.e. every time a page was added, that could affect a menu that might be on the template, and there could be other changes in other modules likewise). Not knowing every possible event that could affect the output of a template, I abandoned this idea.
I decided then to have my Sitefinity web site expose a web service that would deliver the rendered content of any template in an easy-to-consume manner.
The downside to the web service is that it will use more resources since potentially every call to a page on the 3rd party app could also mean a call to the Sitefinity web service. The upside is that any change at all within Sitefinity which could affect the template is immediately available to the 3rd party application. My recommendation would be to use some form of caching in your 3rd party app’s consuming code. You could then set a reasonable time to cache the template for each consumer, instead of dictating it at the Sitefinity level.
If your Sitefinity-based site and all your 3rd party apps are running on the same server, then you’d likely want to do some sort of inter-process communication for efficiency. The web service is just an insanely simple and highly platform-agnostic way to get the job done, it does have its drawbacks.
Sample Code Part #1: Adding the web service to Sitefinity
The hardest part of this whole idea was getting the server to render the Template correctly. That portion of the code should be useful to people even if they take an entirely different approach to the inter-application communication.
The download below consists of a Templates.asmx and corresponding Templates.cs file. To follow Microsoft standards, place the .cs file in your /App_Code folder of your Sitefinity project. Place the .asmx file wherever you wish (root perhaps). This is assuming you don’t mind the template service being public… if you want it secure, protect it accordingly.
Also, I used the HTML Agility Pack to parse the template HTML and change all links to absolute, so you’ll need to download the pack and place it in the /Bin folder of your Sitefinity project. If you don’t need this feature, you could easily modify the code.
- Download the Templates web service source code to add to your Sitefinity project
- Download the required HTML Agility Pack to add to your Sitefinity Bin folder
Sample Code Part #2: An example consumer of the Templates web service
You could consume the above web service with any platform, but here is some sample code in the form of an ASP.Net project.