How to change the “Workflow User” in Tridion CMS

In Tridion CMS, the user that performs the “Automated Activity/Decision” tasks in a workflow process can be modified. These steps must be performed in order to successfully switch to a new user on SDL Tridion 2013 SP1:

  1. Finish all your active Workflow processes (as we will update the process definition later on)
  2. Create the new Tridion Workflow User (WorkflowUser) in the CMS, as an
    administrator. (make a note of the uri of this user)
  3. Open the Tridion MMC Snapin, go to “Workflow Settings” and set the ID of WorkflowUser in the “Automatic Trustee ID”
  4. Modify the Log On of the “Tridion Content Manager Workflow Agent” Windows service: set it to WorkflowUser
  5. Grant (WF) User access to Tridion encryption key (to access DB settings in Tridion Config)
    • open command prompt in .NET install location on CMS server (usually “C:\Windows\Microsoft.NET\Framework64\v4.0.30319”): aspnet_regiis -pa "TridionRsaKeyContainer" "{DOMAIN}\WorkflowUser"
  6. Save ALL your (existing) Workflow Process Definitions again to the CMS (or they will continue to assign automatic tasks to the old user)
  7. Restart “Tridion Content Manager Workflow Agent” Windows service
Posted in SDL Tridion, Workflow Tagged with: ,

Rabo Corporate Connect demo


Developed at Rabobank International, using SDL Tridion 2011SP1, IBM Websphere Portal and Angular.

Posted in SDL Tridion

Rabo Corporate Connect

Proud to present the new Rabo Corporate Connect portal that will go live mid March 2015: http://www.rabobank.com/corporateconnect

Our contribution to this project included advice, designs and development using SDL Tridion 2011 SP1.

Posted in News, SDL Tridion

Upgrading from SiteEdit to Experience Manager

During a recent upgrade project, we were in the situation where we had to upgrade several existing Tridion implementations that made use of SiteEdit and had to move over to Experience Manager. In this post I will try to summarize my experiences.

As with most Tridion version upgrades, the client expects the Template implementation to remain working as is, as long as the API remains backwards compatible with the version already in use. However, XPM is basically a completely new product, and using its full powerful potential means that additional implementation steps have to be performed. More specifically, if you want to use “Session Preview” in XPM, be prepared for additional implementation in your Staging website application.

Upgrading vbScript Templates.

First of all, script is deprecated. This should be the ultimate time to move over to a more recent technology and methodology. My advice will always be: stop using vbScript Templates!
However, companies may have hundreds of vbScript Templates that have never been touched since creation, and “just work”. Reimplementing them, just because one wants to move to XPM, will make the transition quite a costly one. Yes, of course there are many more benefits that will be enjoyed by moving away from vbScript Templates, but when dealing with a limited upgrade budget some companies will choose to leave the Template implementation as much as-is as possible. Running existing vbScript implementations on SDL Tridion 2013 SP1 with the legacy pack enabled can be challenging though. More about that in a future post.

vbScript Templates and SiteEdit 1.3

For a minimal upgrade as-is approach, leave the ComponentTemplates untouched, and only change the PageTemplates (or TemplateBuildingBlocks) where the SiteEdit Finalization call is located. SiteEdit 1.3 code to enable SiteEdit on the Page can best be replaced for SiteEdit 2 (2009 etc) code, as this will limit the unwanted settings meant for SiteEdit 1.3 which are now managed in the CMS GUI for use with XPM. Finish by writing out the bootstrap.js URL for your CMS.

<!-- Old SiteEdit 1.3 code -->
[%
   Call SiteEdit.Init(CMS_HOST_NAME, Page, TargetTypeID)
   WriteOut SiteEdit.Finalize()
%]
<!-- New code using SiteEdit2 -->
[%
   SiteEdit2.PageID = Page.ID
   SiteEdit2.PageVersion = Page.Info.Version
   SiteEdit2.TargetTypeID = TargetTypeID
   WriteOut SiteEdit2.Finalize()
%]
<!-- Activate XPM Button -->
<script src="http://[% WriteOut CMS_HOST_NAME %]/WebUI/Editors/SiteEdit/Views/Bootstrap/Bootstrap.aspx?mode=js" type="text/javascript" language="javascript" defer="defer" id="tridion.siteedit">
</script>

Note that SiteEdit 1.3 output for inline editing is not compliant with W3C standards (invalid use of HTML attributes), so it would make sense to upgrade the ComponentTemplates too.

vbScript Templates and SiteEdit 2

For a minimal upgrade as-is approach, leave the ComponentTemplates untouched, and only change the PageTemplates (or TemplateBuildingBlocks) where the SiteEdit Finalization call is located: add the bootstrap.js URL for your CMS.

<!-- SiteEdit2 -->
[%
   SiteEdit2.PageID = Page.ID
   SiteEdit2.PageVersion = Page.Info.Version
   SiteEdit2.TargetTypeID = TargetTypeID
   WriteOut SiteEdit2.Finalize()
%]
<!-- Activate XPM Button -->
<script src="http://[% WriteOut CMS_HOST_NAME %]/WebUI/Editors/SiteEdit/Views/Bootstrap/Bootstrap.aspx?mode=js" type="text/javascript" language="javascript" defer="defer" id="tridion.siteedit">
</script>

Upgrading Compound Templates with SiteEdit2

Upgrading a SiteEdit2 Compound Template implementation is easy when standard SiteEdit2 Compound TemplateBuildingBlocks have been used:

  1. Import new XPM TemplateBuildingBlocks using TemplateBuilder
  2. Create a Compound TBB for “Enable Inline Editing for Page” and one for “Enable Inline Editing for Content”: Set the configuration options in the parameter settings, and reuse them for all your Compound Templates. These TBB’s use the XPM TBB’s that were imported in the previous step
  3. Replace your SiteEdit2 TBB’s by the Compound TBB’s created in step 2, you can do this in TemplateBuilder if you want, when dealing with a lot of Templates, you might want to use webdav and some tools for “global search & replace”
  4. Enable inline editing for each Field in the corresponding Content Schema in the CMS
  5. Enable inline Editing for your Staging PublicationTarget in the CMS GUI
  6. Add your Staging url(s) to your Staging PublicationTarget in the CMS GUI

Dreamweaver TemplateBuildingBlocks

Optionally, modify your Dreamweaver Templates for full support for MultiValue Fields in the XPM GUI:

@@FieldStartMarker("BusinessPartners")@@
  <!-- TemplateBeginRepeat name="BusinessPartners.Fields" -->
    @@FieldValueStartMarker(TemplateRepeatIndex)@@
      @@GetFieldValue("BusinessPartners", TemplateRepeatIndex)@@
    @@FieldValueEndMarker()@@
  <!-- TemplateEndRepeat -->
@@FieldEndMarker()@@

See more examples

Razor TemplateBuildingBlocks

Optionally, modify your Razor Templates for full support for MultiValue Fields in the XPM GUI. The new syntax is not supported yet, but can easily be added by a custom helper TBB.

Content Delivery Environment implementation

Preventing 404 in XPM GUI

You may encounter 404 errors in the XPM GUI, when trying to edit a field of a Component. This can be solved by creating a static file named se_blank.html in the document root of your Staging website/application.

Ambient Data Framework

One of the great new features of XPM is “Session Preview”, which basically allows you to see your changes on Staging, without the need to publish to Staging. To have this enabled for your existing Staging website/application, you will need to start using the SDL Tridion Ambient Data Framework (ADF) in your Staging web application. This means that Staging must run on an Application Server, be aware of this if your current Staging sites (partly) run on webservers.

When implementing the ADF, it will only be implemented on the Staging target, not on live. This could result in 2 distinct applications (or branches), one with and one without the ADF implemented. Introducing the ADF to your Java application will also introduce dependencies to the frameworks (and versions) used by the Tridion CDE jars, for instance Spring and Hibernate: be aware of potential version conflicts when introducing ADF to your existing Java applications.

When your web application does some routing/redirecting magic, the ADF framework may be unable to map URLs to Pages in the broker. This is for instance the case when sub-domains are used. In that case additional implementation is required: a custom ADF Claim processor may be needed to map Staging urls to the urls that are known by the broker (see: Customized Experience Manager Web site extension). This is comparable to implementing a PublicationResolver to deal with url routing in DD4T (see: dd4t.web publication resolving).

How about no Session Preview?

Well, it is possible of course. What will remain is SiteEdit functionality in a new XPM GUI. The Content Editor will have to commit changes to the CMS, and they will be published to Staging. You may want to disable the “Update Preview” button in the GUI, it can be done in the CMS GUI, Settings section.
(see also: What needs to be configured (on CM) when removing session preview for Experience Manager?)

Posted in SDL Tridion Tagged with: , ,

Experiencing XPM

During a recent project, the client had the need to upgrade their Tridion Systems to 2013 SP1, and upgrade their existing SiteEdit implementations to use the new Experience Manager (XPM). In this post I will briefly describe my first thoughts on the product and it’s implementation implications.

XPM mainly provides functionality to update content on pages while reviewing them on the staging platform, it is replacing SiteEdit. XPM works with the same HTML comments in the output that we were used to with SiteEdit 1 and 2. Therefore, existing SiteEdit implementations will work as is, as long as a new bootstrap.js script is included in the Page Templates. We have now vbScript Templates with SiteEdit 1.3 code successfully running on SDL Tridion 2013 SP1 with legacy pack.
SiteEdit 1 performed its magic using a js/html application in the CDE, which worked without need of an application server. SiteEdit 2 provided an IIS proxy website, that added the editing application to the existing staging website. XPM however has a completely different architecture, which may make it the most complex SDL Tridion product so far: it consists of an Editor in the CMS, a webservice (with data store) and the addition of the ambient framework to your CDE implementation. This means that in order to have a fully functioning XPM implementation (including “Session Preview”), your CDE should run on an application server. A typical Tridion infrastructure will now contain an XPM database and webservice. The webservice may run on the CDE or CME, as long as the CMS can reach it.

By far the best new feature of XPM, and the driving force behind its new architecture, is “Session Preview”, which will basically allow you to modify content of a Page in XPM, and see the content updated on the staging website without the need to republish it from the CMS. This will really have an impact on the number of items in the publish queue, and improve the usability of your Tridion implementation. One other noticeable new feature is that the user is warned when trying to modify content that is in use on other (staging) websites. Use of XPM and its features is now manageable from the CMS GUI, which greatly improves the implementation of Inline Editing: No “SiteEdit” HTML comments are written out when the publication target (and/or content schema) does not allow it. (this without the need to write code to check for preview, target etc)

I really liked to see the XPM GUI at work, it is quite responsive and intuitive. I experienced some issues while using it with IE 11, it performed really well with Chrome.

Installing and configuring XPM can be somewhat complicated. I would recommend these online sources (in this order):

  1. watch the video “Quick Guide to installing Experience Manager (Session Preview)”, hidden in the 2013 section of the live documentation: https://sdl.ssl.cdn.sdlmedia.com/web/634995501191539837YA.mp4
  2. Read the “Quick Guide to installing Experience Manager (Session Preview)”
  3. Read the install guides
  4. Troubleshooting the SDL Tridion Experience Manager with Session Preview: http://albertromkes.com/2013/01/24/troubleshooting-the-sdl-tridion-experience-manager-with-session-preview/
Posted in SDL Tridion Tagged with: , ,

Latest customer: Philips

We are proud to announce that Van der Hoeven IT Solutions will provide SDL Tridion expertise for delivering the new marketing platform for Philips, starting Januari 2013.

Posted in News

Support Tridion Q&A site proposal

Stack Exchange Q&A site proposal: Tridion
If you also think that it is essential that the Tridion community gets its own Open, Free and User driven knowledge base, then please consider following the Tridion Q&A site proposal at Stack Exchange  Area 51. Please commit to the proposal if you feel you could contribute in any way. Support the proposal here.

Posted in SDL Tridion

We are live!


Today the new company website of van der Hoeven Online Solutions went live.
We are looking forward to your comments and contributions.

Regards,
Mario van der Hoeven-Riesebos

http://vanderhoeven-it.com

Posted in News