When I first got the opportunity to work with Tridion, the biggest question I needed an answer to was how to integrate various applications with SDL Tridion.  At the time, I was running a project that required migrating about 20 J2EE applications tightly integrated with a legacy Plumtree Portal to a .NET platform driven by  SDL Tridion.  The organization was moving away from J2EE to become a .NET shop, so the apps needed to be rewritten in .NET – our #1 task.  All we had was a barebone Tridion installation and a bunch of manuals that did not mention anything about how to integrate apps into it.  SDL Tridion training also did not cover this topic – although we got some useful hints, we needed to see a proven design.  My intent with this article is to help any new Tridion teams to keep their project moving forward if faced with a similar situation.

The approaches discussed here are not limited to .NET.  They can be leveraged to integrate Tridion content into J2EE apps, mobile apps, or anything that you want, such as PHP, Perl, C++.  In other words, the sky is the limit.

First off, it is important to understand that Tridion offers two publishing models:

1. Static publishing: the Tridion Content Manager publishes content in the form of files to any location you wish via HTTP, FTP, NFS and others.  For e.g. put a jsp file to an app server, or an aspx file to an IIS server in the DMZ.
2. Dynamic publishing: the Tridion Content Manager publishes content in the form of data to the Broker, which is an application configured on your presentation server.  The published content in the Broker is accessed via an API.  This is close to how integration works with other CMS or portal products, except that applications’ requests are not going across the entire firewall back to the Content Manager – which is sweet!

Application Integration with Dynamic Publishing Tutorial

If you’ve chosen to leverage the benefits that the Broker has to offer, i.e. option 2 above, then your app can simply use the functions from the Broker API to retrieve content from the Broker.  If your app is Java-based, then simply include the Broker JAR files and set up some parameters in the web.xml.  The same thing applies to a .NET app, except you’ll be including a DLL instead of the JAR and using the .NET version of the Broker API.  Have a read through the Tridion Content Delivery Implementation Manual for the fine details.  It’s easy after you have everything configured.  The differences between the Java and the .Net versions of the API are just syntax.  All the methods and classes are pretty much the same.

For those that are new to the Tridion architecture, remember, your app does not query the Content Manager directly like it does in most other products out there such as the Oracle UCM, Sharepoint or the legacy Plumtree Portal.  With SDL Tridion, content management is separate from the published content.  So our apps query the published content in the Broker via the Broker API, which is a separate data store from the Content Manager.  You can, of course, make your app talk directly to the CM via the Business Connector or Custom Pages if you have a proper reason to do that, but if you just need to pull some content in an externally-facing app, then Broker is the tool to use.

Application Integration with Static Publishing Tutorial

This is my favourite because of its simplicity – less infrastructure and easy to transition, maintain and in general understand.

On that project which I mentioned in the intro, the mandate from Enterprise Architecture was that, if possible, systems should be loosely integrated without building too much dependency on one particular product.  This means favouring web services over proprietary product API calls inside other systems, as one example.  Loose integration makes it easier to swap systems if introducing another product in the middle or upgrading to a different product.  At an Enterprise Architecture level, it’s a great strategy to manage technical risk from the point of view that Enterprise IT system’s average life span is 5-10 years.  So if a system isn’t meeting your expectations or growing requirements, it’s cheaper and easier to upgrade or replace it when loosely integrated.  I had the pleasure of experiencing the opposite by having to re-factor many applications when a client of mine switched from the old Plumtree portal to Sharepoint (for internal apps) or Tridion (for external).  Of course there are cons to the Static over the Dynamic publishing approach, but I’m not going to get into further debate on this here.

As mentioned, with the Static Publishing model, files get published out to a server location.  These files can be of any kind – jsp, include, aspx, ascx, xml, php, and so on.  You create a Page Template where you can specify any file extension that you choose.  What does this mean?

It means that you can publish out chunks of content as separate “include” pages with all the HTML markup or logic, and your apps simply consume them.  You can also create a Page Template that will render and publish out XML (in the format you chose – refer to Dreamweaver Templating), and your app can consume it by parsing and rendering it.  You can also make the Page Template render the content with HTML markup inside an XML CDATA field.  Once again, the sky is the limit.

Example: Integration with a Custom .NET App

Here is an example where promotional content is managed in Tridion, such as widgets and call-to-actions, and an ASP.NET-based user registration system needs to display this content as right rail widgets.

Seems like a User Control would be perfect for the job.  (BTW, if you’re integrating with Sharepoint, then a Web Part could be used just the same.)  Our user registration system can wonderfully render this User Control in the right rail of its ASPX page.

Step 1: Create a User Control Component Template

Suppose you have a Promo schema with fields such as: ‘title’, ‘promo page url’, ‘promo image’, and “promo text”. Through the magic of Tridion’s Compound Templating we create a Tridion Component Template, “Right Rail CT”, which contains a Dreamweaver template TBB that looks something like this (let’s assume all the fields are mandatory for simplicity’s sake and avoid TemplateBeginIf’s):

<div class="rightrailwidget">

     <a href="@@Component.promoUrl@@"><img src="@@Component.promoImage@@" alt="" /></a>
     @@Component.promoText@@
</div>

Step 2: Create a User Control Page Template

Let’s call this “Right Rail Promo User Control PT”.  The file extension for pages generated by this template is “.ascx”.  It is a very simple template that renders our Promo items using the “Right Rail CT” as User Controls:

<%@ Control Language="C#" ClassName="contentbloom" %>

<!-- TemplateBeginRepeat name="Components" -->
@@RenderComponentPresentations()@@
<!-- TemplateEndRepeat -->
<script runat="server">
    //optionally, whatever you normally put in your code-behind, can go here
</script>

Step 3: Create and Publish the User Controls

Now you can create various Promo Right Rail Widget User Controls as Tridion pages and publish them.  Simply create a new Tridion page in a Structure Group such as “/usercontrols/promos/”, and in it create pages using the “Right Rail Promo User Control PT” template.  Now simply publish it to the same IIS server(s) on which our application is hosted.

Step 4: Consume the User Controls by the Application

Our .NET-based New User Registration application can now include the published user controls on the right rail of its ASPX or Master pages.  It’s pure .NET at this point.  The application’s ASPX page would have a statement like this in its right rail div:

<%@ Page Language="C#" %>

User Registration Step 1
<form id="form1">
<div class="main">
      <!-- Application form fields and other stuff here -->
    </div>
<div class="rightrail">
        <%@ Register TagPrefix="contentbloom" TagName="RightRailPromoWidget1" Src="/usercontrols/promos/promo1.ascx"></div>
</form>

Bullet-proofing (optional)

I like to put in a little bit of bullet-proofing into the application’s logic, so that if a user control is unpublished, the application doesn’t throw a 500 error since it can’t find it.  We do this by loading the user controls into the right-rail div programatically from the code-behind (or inline):

Check this out:

user-registration-step1.aspx:

<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        try
        {
            UserControl promo1 = this.LoadControl("/usercontrols/promo1.ascx");
            RightRail.Controls.Add(promo1);
        }
        catch
        {
            //log as a warning and continue with loading the page without the right rail widget.
        }
    }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server"><title>User Registration Step 1</title></head>
<body>
<form id="form1" runat="server">
<div class="main">
      <!-- Application form fields and other stuff here -->
    </div>
<div class="rightrail">
        <asp:PlaceHolder id="RightRail" runat="server"></asp:PlaceHolder>
    </div>
</form>

</body>
</html>

Now the page will attempt to load the right rail promo user controls, but if they’re not available or not needed, then the page continues to load normally without them.  This could greatly reduce the likelihood of a severity 1 production issue because a content editor decided to unpublish a certain promo.