Troubleshooting the SDL Tridion Experience Manager with Session Preview

In the past week I had the opportunity to install the Experience Manager with Session Preview on a completely
DD4T and SDL Tridion driven website. Configuring the Experience Manager can be quite painful. Especially if you don’t know how Session Preview (exactly) works and if you have no clue where to start and where to look.

In this post I want to give you some hooks and pointers on where to look if things get interesting 🙂
In fact, if you are DESPERATE about why your Session Preview isn’t working, this post is aimed at you!

But first: thanks to Andrew Marchuk, Daniel and Likhan from SDL Tridion for helping me. Without their help I would still be staring at my screen 🙂

Well, let’s start!

(I’ll assume you have a basic understanding of SDL Tridion).

First, read this answer and the comments: http://stackoverflow.com/questions/10788508/continously-update-preview-alert-on-sdl-tridion-ui-2012/10802033#10802033

Meditate it, let it sink, adjust your setup and try again.

Now, if it still doesn’t work, read on:

First, turn of caching for your website. Just to be sure. After you got Session Preview working, turn on caching again and see what happens. But for troubleshooting the Session Preview I recommend to turn of caching completely. Just to be sure…

1. Do a basic sanity check and check the following for your staging website:

– Open the cd_storage_conf.xml from your staging website and ensure that:

• The

  <Wrapper> 

  element exists! Like this:

<Wrappers>
				<Wrapper Name="SessionWrapper">
					<Timeout>120000</Timeout>
					<Storage Type="persistence" Id="db-session-webservice" dialect="MSSQL"
					Class="com.tridion.storage.persistence.JPADAOFactory">
					<Pool Type="jdbc" Size="5" MonitorInterval="60" 
					IdleTimeout="120" CheckoutTimeout="120" />
					<DataSource Class="com.microsoft.sqlserver.jdbc.SQLServerDataSource">
						<Property Name="serverName" Value="WIN-1CJUK3HE34H" />
						<Property Name="portNumber" Value="1433" />
						<Property Name="databaseName" Value="Tridion_SessionPreview" />
						<Property Name="user" Value="TridionBrokerUser" />
						<Property Name="password" Value="PassWord" />
					</DataSource>
					</Storage>
				</Wrapper>
			</Wrappers>

Of course it should point to your SESSION PREVIEW database! Not to your default, ordinary Broker database.

• Check if at least the following StorageBinding is present in the cd_storage_conf.xml of your website:

<StorageBindings>			
                <Bundle src="preview_dao_bundle.xml"/>				          
            </StorageBindings>   

• Check if you added the AmbientData HttpModule (for .NET Sites!. For java it’s probably a filter) in the web.config of your website:

<add type="Tridion.ContentDelivery.AmbientData.HttpModule" name="AmbientFrameworkModule" preCondition="managedHandler" />

• If you are on a website that is NOT COMPLETELY DYNAMIC (so on a website that’s NOT ON DD4T) check if you added the following module in the web.config of your staging website:

<add name="PreviewContentModule" type="Tridion.ContentDelivery.Preview.Web.PreviewContentModule" />

Again: this module is NOT, I repeat NOT necessary if your website is a completely dynamic website. (e.g. retrieves everything from the broker like DD4T). If you still use this module, you will see that clicking on ‘Update Preview’ will generate files on the filesystem! And it will not show you the updated preview!

• Open the cd_ambient_conf.xml file of your Staging website and check if the following Cartridge is referenced:

  <Cartridge File="cd_webservice_preview_cartridge.xml"/>
  

2. Check the following for your OData Webservice: (The one that is used by the Session Preview, so the one you configured as the ‘Content Delivery Endpoint Url’ on your Publication Target)

• Copy/paste this ‘Content Delivery Endpoint Url’ and paste it into your browser. (Of course inside the company domain…) and see if it responds.

The url looks like this: http://localhost:73/odata.svc/
You should get a response with a listing of all collections that can be retrieved by this OData endpoint. Something along the lines of this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<service xml:base="http://localhost:73/odata.svc/" xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
    <workspace>
        <atom:title>Default</atom:title>
        <collection href="Binaries">
            <atom:title>Binaries</atom:title>
        </collection>
        <collection href="BinaryVariants">
            <atom:title>BinaryVariants</atom:title>
        </collection>
  	....
	....
    </workspace>
</service>

• Open the cd_storage_conf.xml of your OData webservice and ensure that:
• The Wrapper tag is there and is pointing to your SESSION PREVIEW database. So not to your regular Broker Database!
• The StorageBinding with the preview dao bundle is there. Like this:

  <StorageBindings>			
                  <Bundle src="preview_dao_bundle.xml"/>				          
              </StorageBindings>   
  

• Open the cd_ambient_conf of your OData webservice and verify that:
  • The preview Cartridge is there. Like this:

    <Cartridge File="cd_webservice_preview_cartridge.xml"/>
    

Now, do an IISReset on your website and for your OData webservice. This makes sure that your changes to the various configuration files are used when the Content Delivery Instance boots up the first time. DO NOT SKIP THIS STEP! In case you are still in doubt: DO NOT SKIP THIS STEP! (Sorry for shouting)

Now, hit ‘Update Preview’ again. If it is still not working for whatever reason keep reading:

1. Open the logback.xml file of your Staging website, and set the loglevel to ‘VERBOSE’.
2. Open the logback.xml file of your OData webservice and set the loglevel to ‘VERBOSE’.
3. Clear both logfiles! (So you have a fresh start)
4. Clear the ‘Tridion’, ‘Tridion Content Manager’ and ‘Application’ Windows Eventlogs on the Content Manager Server
5. Clear the ‘Application’ Windows Eventlog on the Staging WebSite server
6. Clear the ‘Application’ Windows Eventlog on the Odata webservice server

Do an IISReset (You edited the logback.xml file, so this is necessary!)

Now, hit ‘Update Preview’ again and check out the logfiles in this order:

• cd_core.log of your Staging website
  -> Anything unusual? Especially error’s and warnings with regard to the Ambient Data Framework are important! Take them seriously and double check the cd_ambient_conf.xml and the cd_storage_conf.xml of your staging Website. Also, check if all HttpModules and/filters are present in the Web.config of your website! (See above)
• cd_core.log of your OData website. If this file is (almost) empty that means that the ‘Update Preview’ request NEVER reached the OData webservice. This could be due to:
  – Network issues: are the IIS Bindings of the OData webservice correct?
  – Can you connect to the OData webservice using your browser?
  – Is your publication target pointing to the correct Content Delivery Endpoint Url (your OData webservice)?
• If there is data in the cd_core.log of your OData webservice, check to see if there are error’s or unusual statements.
  • If you search for your adjusted content do you see it? If so, this means that your changed content is correctly send to the OData webservice. If not, that means that your staging website cannot connect to the OData webservice. Again: Check IIS settings and network settings.
• Open the Session Preview Database using SQL Server Management Studio, and open the table ‘Component Presentations’. After you hit ‘Update Preview’, you SHOULD see something added to this table. If not: check if you referenced the correct Session Preview Broker Database in BOTH of your Wrappers. (In the cd_storage_conf.xml of your Website and in the cd_storage_conf.xml of your OData webservice!)

If you see an HTTP error 400 BAD REQUEST after you click on ‘Update Preview’ check the following:

• Open the Windows EventLog ‘Tridion Content Manager’ on the Content Manager server and check if you see the same error here.

If so, try the following:

Stop the TcmServiceHost windows service on the Content Manager Server. (Be careful, The SDL Tridion Content Manager stops working now!)
Next, browse to the SDL Tridion install directory\bin with the command prompt and start the TcmServiceHost.exe with the -debug command. Like this:

TcmServiceHost.exe -debug

Now, open Fiddler on the Content Manager server, apply a filter to show only traffic from the TcmServiceHost and hit ‘Update Preview’ again. Now you have the request and you can inspect it to see if there’s anything unusual. E.g. the Content-Lenght is 0. That’s weird, because that means no data was send!

The last resort consist of tracing everything related to the OData webservice. If everything above failed, do the following:

Open the Web.config of the OData webservice and add the following code:

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.ServiceModel" switchValue="All">
        <listeners>
          <add name="TraceListeners" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\Temp\trace.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

Adjust the ‘initializeData’ path to a path of your choosing.

Now, hit ‘Update Preview’ again, and after it’s finished, open the trace by double-clicking on it. (If you don’t have the tracetool, download it here)

Find he first red colored entry, and inspect the error message. In my case the ‘maxReceivedMessageSize’ of the OData webservice was too small.

You can adjust this setting in the Web.config of the OData webservice. Here is an example of the updated part of the Web.config:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="True" />
    <behaviors>
      <endpointBehaviors>
        <behavior name="webHttp" >
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
	  <!-- HTTP support. In case of HTTPS these services have to be commented. -->	
      <service name="Tridion.ContentDelivery.Webservice.ODataService">
        <endpoint  behaviorConfiguration="webHttp" binding="webHttpBinding" bindingConfiguration="AdustedBindingConfiguration" contract="Tridion.ContentDelivery.Webservice.IODataService" />
      </service>
      <service name="Tridion.ContentDelivery.Webservice.LinkingService">
        <endpoint behaviorConfiguration="webHttp" binding="webHttpBinding" contract="Tridion.ContentDelivery.Webservice.Ilinking" />
      </service>
	  <service name="Tridion.ContentDelivery.Webservice.AccessTokenService">
		<endpoint behaviorConfiguration="webHttp" binding="webHttpBinding" contract="Tridion.ContentDelivery.Webservice.IOAuth2AccessToken" />
	  </service>
    </services>
	<!-- In case of HTTPS support uncomment this block.
	-->
	<bindings>     	  
		<webHttpBinding>      
			<binding name="AdustedBindingConfiguration" maxReceivedMessageSize="2097152000" maxBufferSize="2097152000">
				<readerQuotas maxArrayLength="81920" maxBytesPerRead="5120" maxDepth="32" maxNameTableCharCount="81920" maxStringContentLength="2097152" />
			</binding>
	    </webHttpBinding>
    </bindings>
	
	
  </system.serviceModel>

Note that ‘maxReceivedMessageSize’ and ‘maxBufferSize’ should be the same!

Don’t forget to remove this settings once you resolved all your issues!

Phew! I *really* hope your Session Preview service is now working properly.
If this isn’t the case consider asking it on StackOverflow (and while you’re there, consider committing to the SDL Tridion Exchange Proposal)
The community is really helpful and very knowledgeable. Of course you can also open a support ticket with Customer Support.

Have fun!