Documentation Center

Examples of Experience Manager integration with website setups

A number of common website implementation scenarios, and how to integrate the Experience Manager website extension with them.

An IIS website that contains web applications and/or web services

Your setup: You have defined one of more web services and /or web applications that run in the same IIS process as the website, and share its libraries, assemblies and configuration.

Possible problem and solution: Relative URLs may be directed to URLs relative to the root of the web application rather than the root of the website, but Experience Manager is unaware of this. To fix this, create a Claim Processor in the Ambient Data Framework that performs the same redirection for Experience Manager.

A controller class performs .NET routing and uses the Content Delivery API to retrieve content

Your setup: Your .NET website has registered a route in global.asax, to be picked up by a handler. The handler picks up some routed properties and uses the Content Delivery API to map them to a Page and/or Component Presentations.

For example, your global.asax might contain the following:

routes.Add("Check Component Presentations", 
	new Route("ComponentPresentations/{PubID}/{CompID}/{CompTemplID}",
		new Tridion.Test.ComponentPresentationHandler()));

Possible problem and solution: Following the standard instructions for setting up the Experience Manager website extension results in an enabled PreviewContentModule which writes session content on disk. The URL is redirected to this content, and any routing is bypassed. To fix this problem, remove PreviewContentModule and add a custom Claim Processor that creates the right Preview Session context that causes the API to return session-specific content.

A controller class performs .NET routing and uses custom logic to retrieve content

Your setup: Your .NET website has registered a route in global.asax, to be picked up by a handler. The handler picks up some routed properties and uses custom logic to map them to a Page and/or Component Presentations. This may mean that content is looked for in a specific disk location.

For example, your global.asax might contain the following:

routes.Add("Check Component Presentations", 
	new Route("ComponentPresentations/{PubID}/{CompID}/{CompTemplID}",
		new Tridion.Test.ComponentPresentationHandler()));

Possible problems and solutions:

  • Following the standard instructions for setting up the Experience Manager website extension results in an enabled PreviewContentModule which writes session content on disk. The URL is redirected to this content, and any routing is bypassed. To fix this, do not remove PreviewContentModule, but add a Claim Processor for the Claim with URI taf:session:preview:request:forwarding, a Boolean that specifies whether requests should be forwarded or not.
  • The Page and/or Component Presentations to be retrieved based on the custom logic are not known to us. To fix this, add a custom Claim Processor in which you specify which Page is associated with the request (using the Claims with URIs taf:session:preview:request:full_url and taf:session:preview:request:real_path) and which Component Presentations are associated with the request (using a Claim with URI taf:session:preview:request:component_presentations).
  • Experience Manager places the content on disk (under the web application root) but the custom logic is looking for the content elsewhere. To fix this, use the following Claim URIs to specifiy where Pages, binaries and Component Presentations may be found: taf:session:preview:request:session_component_presentation_root_path, taf:session:preview:request:session_page_full_path, taf:session:preview:request:session_binary_full_path and taf:session:preview:request:session_componentpresentation_full_paths.
  • The custom controller is unaware of the paths for session content. To fix this, change the custom controller to be able to pick up these paths.