2013 SP1 HR1 - What's in it for us

Hop and skip Thanksgiving, run a left over at Christmas right into the New Year, and wow, where did the time go?

Seems like yesterday SDL Tridion 2013 SP1 was just released peaking everyone's curiosity over the new interface, features and improvements, though I should know better how long it's really been as by force of habit now, writing up the date of the article, I slipped and almost typed 2014 SP1.. heh.
 

To be accurate though, SDL Tridion 2013 SP1 was released last year in November (neat, I can say "last year" for one more day), and during the course of the year, you may have found yourself puzzled by a number of strange occurrences.  Wonder no more, enter 2013 SP1 HR1 released December 17 to slide back into place several puzzle pieces, modules which have acted out of sorts.

The installation spans five areas, each straight forward, not many instructions, yet do exercise caution and don't let you attention waver especially so for Content Delivery.

- CM db - this is a straight forward install, comes about with at least two changes to stored procedures

- CM - also straight forward, you can simply run the PowerShell upgrade script

- Visio - here you'll need to uninstall the previous Visio Workflow Designer Client from current programs and follow up with the executable upgrade

- CD - still manual, though much simpler than expected, there are jar changes in lib folder(s), dll libraries for .NET, and Staging - XPM enabled website(s)

- CEC - extract CEC_2013.1.1.87801.zip, populate changes to locations documented (jars, dlls) plus regenerate the device database

Out with the old, in with the new, there are a number of pre-requisite changes, nice to see the Microsoft .NET Framework 4.5.2 is now supported.

What	State
RedHat Enterprise Linux 6.4	Deprecated
RedHat Enterprise Linux 6.5	Supported
SDL TMS 2011 SP4	Deprecated
SDL TMS 2011 SP5	Supported
Microsoft SQL Server 2008 R2 SP2	Deprecated
Microsoft SQL Server 2012 SP1	Deprecated
Oracle 12.1.0.1	Deprecated
Microsoft SQL Server 2008 R2 SP3	Supported
Microsoft SQL Server 2012 SP2	Supported
Oracle 12.1.0.2	Supported
Microsoft .NET Framework 4.5.1	Deprecated
Microsoft .NET Framework 4.5.2	Supported

Hotfixes cover the following areas, some more significant, with the full list of course available in the online documentation.  

I've taken the liberty to highlight some I found more pertinent and really meant to underline the significance of installing the 2013 SP1 HR1 patch.

1. Content Manager - 20 hotfixes total

87657 - Read publish transaction: state can be demoted from waiting to scheduled server times out of sync

87728 - WebDAV http handler fails for folders with names the same as one of the file extensions defined for multimedia types (link to tex)

87777 - Poor database performance after upgrade from 2011SP1 to 2013GA (reported in 2013 GA)

87921 - Import failed - [Error] System.NullReferenceException: Object reference not set to an instance of an object.

88066 - LoadFlags.KeywordXlinks are not taken into account during the building of content on schema synchronization process.

88102 - Visio 2013 - editing the Workflow Process Definition diagram and saving the changes, and then re-opening the Workflow Process Definition results in an XML validation error

88203 - Updating a component previously subject to a workflow changes its status to Unapproved (when expecting Undefined)

88250 - Resolver for 'Republish Only' on a Dynamic component template includes items that were not published to the chosen target

+ 2 db changes - stored procedures

87401 - EDA_ITEMS_FUNCTIONS query is incorrect

88283 - Advanced search times-out due to EDA_ITEMS_GETBULKSTATUSINFO query times

2. Content Delivery - 3 hotfixes

88163 - Error message displayed in Tridion 2013SP1 has been changed (multiple messages)

88295 - The input data was invalid: stringValue must be a non-empty string or any of the other values should be filled in

88309 - Using virtual folders results in a page not found when using Experience Manager

3. Content Manager Explorer - 15 hotfixes total

87268 - Wrong context used for opening Components

87280 - IncludeComponentLinks set to false in GUI Core Service Publish command

87658 - User with write permission cannot edit Structure Groups

87677 - When adding a field to a Schema on the 'Design' tab and then adding another to the 'Metadata design' tab, the first field (on the 'Design tab' is removed)

88281 - The default value option in Tridion 5.2 does not seem to work correctly (reported in 5.2)

4. Experience Manager - 9 hotfixes total

87717 - When uploading a new image to Experience Manager if the associated Multimedia Schema has Metadata then adding of the image fails with an "Unable to save new item. Name must be unique [...]" error"

87889 - Optional Fields lose context once Update Preview is attempted

88104 - Required to drag a content type twice to be able to place it on the page

88175 - Page not published after editing Fields from Component Link In Experience Manager

5. Context Engine Cartridge - 1

87801 - A hotfix that bundles a number of issue fixes in one go

6. Translation Manager - 1

88257 - XML fragment error when sending a component for translation

7. Audience Manager & Outbound Email - 2

88023 - Added configuration to override the database connection string for Audience Manager

88322 - Loading a Mailing also renders the Mailing's Page, which can result in decreased performance

Good grief, hopefully not many of these have crossed your path and so the HR1 will patch things promptly, yet considering the system has been in use for a year now, perhaps it isn't as large a collection of fixes after all, which is a good thing.

Here's looking forward to 2015, it's going to be a great year!  Yet again :)

Manually Importing Tridion Schemas - But it's turtles all the way down!

Every so often in order to validate some content or troubleshoot an issue, I need to recreate the content in a different system.  This is actually a deconstruct and reconstruct process of taking the schemas apart and re-building them in Tridion.

The best thing to have are the XSDs, all the schemas the content is based on, in xml format.  However, even if this is not entirely the case, it may still be possible to import enough to recreate a given issue.  This does get a little tricky at times because of possible relations pre-existing in schemas such as other embedded schemas, linked components (full schemas) or categories and keywords.

These clever turtles all the way down (read relationships) can be noticed with a quick xml scan in the XSD's available for:

1. WebDAV urls

2. TCM URIs (tcm:x-y-z)

Also look for the lack of the "targetNamespace" attribute in the very first <xsd:schema> node as this will indicate an embedded schema.

Review all schemas available and choose the ones without any relationships, import these first.  

Embedded schemas are also good candidates and as mentioned before you can tell them apart immediately by the lack of the "targetNamespace" attribute.

Next, move over to generic content schemas, and again look to determine what is not referenced by any other schemas, or otherwise follow component links to find the furthest relations.

Once you think you have a plan, and possibly by now have drawn a little pyramid of the schemas relations model, move on to the Content Manager Explorer.

In the Tridion CME, proceed to 

• Create a new schema and open the source tab
• Copy the xml to be imported from the original source, paste it in the new schema source and update the namespace with the one from the new schema
• Switch to the Design tab to see if the xml is recognized and translated into the equivalent fields
• If yes, great, save the schema
• If not, figure out what dependencies are missing and either import them or remove them to go on

If some dependencies are missing, don't give up, it may still be possible to partially import what is available.

For instance, if categories are not available, remove these references from the top and carefully remove the associated field(s) so as to preserve the integrity of the xml.  I usually try and re-save the schemas right after such a change in case there is a mistake, because then I will immediately know where I made it!

For example, look for lines such as this:

<xsd:import namespace="tcm:0-5-1/Categories.xsd" schemaLocation="/webdav/010_Schemas/Categories.xsd" />

.. with the corresponding..

 <xsd:element name="Tags" minOccurs="0" maxOccurs="1" type="category:Specific_Category_Name">

Once you have saved all schemas in the CMS, yes, do believe it's possible - this is actually a key component of achieving this, continue on to create some content based on them.  It may take a few tries, quite a bit of patience and definitely plenty determination, but it's been tried, delivered and certainly found useful!

Use Visual Studio to Test XSLT Snippets for Tridion RTF Fields

Recently I've run into some issues with XML and XSLT, particularly the snippets one can add for applying special formatting on RTF fields.  

These snippets can be accessed by viewing a schema's RTF field, selecting the field, clicking the Edit Formatting Features button and navigating to the last tab on the resulting pop-up, tab called "Filtering XSLT".  

I found it quite helpful to run this fast-as-fast-can-be little validation test to narrow down a particular mishap in XSLT.  Certainly, there are much better and more equipped tools out there such as XMLSpy or <oXygen/> for instance, but in my case, speed was of the essence, and as I was not handling a very complex piece of content or elaborate stylesheet, the following steps zapped some light on right away.

1. Open Visual Studio, for instance VS 2012

 

 

2. Load an XML snippet

     Go to File, Open, File.. and select an XML snippet file, for instance the source/content of an RTF field from Saved from Tridion in a sample XML file.  

3. Load an XSLT snippet

     After loading the XML file, the Visual Studio top menu will change and also show an XML main option.  Go to XML, Start XSLT Debugging.  A window will popup to allow you to select the XSLT stylesheet to process.  Navigate to the location of the XSLT, select the stylesheet and click Open.

4. Test run

     Visual Studio will start processing the two files, applying the XSLT to the XML and then reporting back on progress.  It is also possible to add breakpoints here and run through more carefully, or the opposite, run through without any kind of debugging.  The right hand side window will show the resulting XML, labeled with the stylesheet name and an .XML extension.

5. Look for issues reported in Visual Studio

     Any issues detected will show in the Output window so you can take a look and handle them one by one to work through each.

     The only unfortunate discovery I made on this little inside tool is that loading the XSLT becomes cached and the only way to reload it is by restarting Visual Studio.  If anyone found a way to load it without closing, please post back!

Cheers!

Queue Purging in SDL Tridion 2013 SP1

Have you ever pulled the curtain looking for something, anything to help you fix some issue, situation, or state of affairs?

You sit in the middle of the room scratching your head and thinking you have looked everywhere, done anything and everything you possibly could and yet, you're still facing a problem.

I love that place.  My back against the wall.  Me and the empty space of possibility because I know, I know I am still missing something and I will find it.  All I have to do is find it.  And this time, well, this next idea, I'll have to find it outside the box.

I had such a moment a few days ago when I was troubleshooting a publisher service.

It just wouldn't publish.  No matter what.  Not after restarting, not after putting it in debug mode.

Nothing was written in the logs, and checking the publishing queue with "All" entries showed only a few items, all in some sort of finished state.  

Or did it.

As I was sitting there drawing blanks, I remembered troubleshooting the deployer some time back where the solution was to clear out the transactions folder.  Some things had been left there from previous sessions.  No, no one knows why anymore, they were months old.

"Clear out, clean out.."  Ding! I almost jumped as the light bulb lit above my head.  "Purge!  Let's try purge!".  What if the invisible is not so invisible after all.  What if this unpredictable behavior was due to existing "queued" transactions still waiting to publish or left in some unresolved state.  Bouncing on what if-what if's, I set out to find out on my Indiana Jones leap of faith.

In 2013 SP1, we can purge existing items stored in queues in two very quick steps:

1. Load the SDL Tridion system administration .NET assembly 

2. Purge messages from various queues

Both steps are executed via the command line and with system administration rights.  

Open a Powershell prompt and type (step 1):

> Import-Module Tridion.ContentManager.Automation

Follow with the purge itself (step 2):

> Remove-TcmQueueMessage

This second command also allows you to purge by queue type, just add the respective parameter at the end, one of five:

PublishQueue, DeployQueue, SearchQueue, WorkflowAgentQueue, BatchQueue

In my case, since I was on a test machine, I went full-throttle and cleared all messages. This is what it took, and lo and behold, it worked like a charm, the Publisher started working after one more health-check restart.

Hoozaaa!  

There is another command which allows you to inspect the queue contents as well:

> Get-TcmQueueInfo

Purge is typically recommended periodically for maintenance and to free up room in the database.

Obviously these commands should be coordinated and run outside of business hours when the system is not busy.  

An advance notice is helpful as well in case anyone still happens to be working at the time the commands are issued.  Should their transactions suddenly disappear, at minimum they can relate what happened to the notification and resubmit the work again.

For more information, read through the online documentation.

Tracing in SDL Tridion 2013 SP1 - A walk in the park, or.. beach

Some time ago, a little birdie told me in SDL Tridion 2013 SP1, all windows services can be started in debug mode.

While I have not made the time to check this out, I have through experience and some focused searches discovered that tracing has been taken to yet another higher level.

Some of the logs below will be familiar from previous versions, however, there are a few surprises you won't mind finding out about.

Like a walk on the beach, where tracing back the same path you took to arrive where you are can be both nostalgic and new, here is a collection of traces to walk you from the Content Manager to the Content Delivery and back in case you need to revisit some points in time..

What	Where (log or trace file)	How (Config file & Steps)
CME Javascript/CSS	Browser Developer Tools (eg. Sources and Console tabs) IE Firefox Firebug Chrome	http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-9652A9DD-3E44-44ED-98C8-28A7FF955CA0 %TRIDION_HOME% WebRoot\Configuration\system.config 1. Disable JS/CSS minifiers <filters>     <filter for="Script" type="Tridion.Web.UI.Resources.Filters.JScriptMinifier, Tridion.Web.UI.Resources.Filters" enabled="never"> ... <filter for="Style" type="Tridion.Web.UI.Core.Configuration.Resources.Filtering.CssCompressorFilter, Tridion.Web.UI.Core" enabled="never" /> 2. Refresh browser 3. Can call GUI urls with mode=js 4. Check Sources, Console tabs in browser developer tools to set breakpoints and/or follow execution or variable values
IIS	%SystemDrive%\inetpub\logs\LogFiles\ <ID of Web site>	Usually enabled, if disabled, check how to enable depending on IIS version
CMS Events	%SystemRoot%\System32\Winevt\Logs\ Tridion.evtx %SystemRoot%\System32\Winevt\Logs\ Tridion Content Manager.evtx	Enabled by default, look for them in the Windows Event Viewer console
CMS Core Service	Own trace	%TRIDION_HOME%\bin\TcmServiceHost.exe.config http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-FE919074-22B4-4A00-BDB7-92EF0DC20C3C
CME Server Log / CMS WCF	%TRIDION_HOME%\web\WebUI\WebRoot\ Tridion.Web.trace	%TRIDION_HOME%\web\WebUI\WebRoot\bin\web.config http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-16AB0377-ECB7-4FCC-9EB3-128F75AF1E90
CMS Workflow Service	Own trace	%TRIDION_HOME%\bin\TcmWorkflowAgent.exe.config
CMS Search Indexer	Own trace	%TRIDION_HOME%\bin\TcmSearchIndexer.exe.config
CMS Batch Processor	Own trace	%TRIDION_HOME%\bin\TcmBatchProcessor.exe.config
CMS Publisher Service	TRIDION_HOME%\bin\TcmPublisher.exe.config Tridion.ContentManager.Publisher.log	To run publisher in debug mode from command line: not supported, not documented, unexpected results: dies when user running it logs off? -only to be done in Production envs under Customer Support request publisherpath>TcmPublisher.exe /debug ---------------- To have publisher log to file: - In MMC set "Publisher settings" - "Activate logging to publisher actions" option to "true", don't need to restart COM+ or Publisher - Check "c:\program files\tridion\log\Tridion.ContentManager.Publisher.log" - (It doesn't track when rendering in TemplateBuilder template tool) - Publisher log configurable in : \Tridion\bin\TcmPublisher.exe.config
CM Transport	c:\tridion\log\cd_transport_<date>.log	%TRIDION_HOME%\config\logback.xml <property name="log.level" value="ALL"/> or <property name="log.level" value="TRACE"/>
CD Transport	c:\tridion\log\cd_transport_<date>.log c:\tridion\log\cd_core_<date>.log	%TRIDION_DEPLOYER_HOME%\bin\config\logback.xml http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-DF88578C-8B32-4933-A6F5-939DA3275D95
CD Deployer	c:\tridion\log\cd_deployer_<date>.log c:\tridion\log\cd_core_<date>.log	Normal Trace and Hibernate Trace %TRIDION_DEPLOYER_HOME%\bin\config\logback.xml <property name="log.level" value="ALL"/> or <property name="log.level" value="TRACE"/> ----------------------------------------------------- <root level="ON">      <appender-ref ref="rollingCoreLog"/> </root>
OutBoundEmail	C:\Program Files (x86)\Tridion\Log\OutBoundEmail.log	%TRIDION_HOME%\config\OutboundEmail.xml <Log>         <Folder>C:\Program Files (x86)\Tridion\log</Folder>         <Level>5</Level> </Log>
UGC	%TRIDION_HOME%\web\WebUI\WebRoot\ Tridion.Web.Trace	1. Backup %TRIDION_HOME%\web\WebUI\WebRoot\Tridion.UGC.Model.dll 2. Replace with %TRIDION_HOME%\web\WebUI\WebRoot\trace\Tridion.UGC.Model.dll 3. Reset IIS

As with any logging in general, beware lots and lots of data will be accumulated in a very short amount of time.

So

- focus your actions

- limit the number of users in the system during tracing

- check there is enough memory available

- check there is enough storage available

and.. don't forget to turn off the traces when done investigating!

Happy tracing!

Quantifying Rambles

Recently I've come across a concept which oddly I had partaken as a matter of fact, part of life, encountered in my daily routines and more so pretty much everywhere else I turned around.

I'm talking about the myriad of little devices tracking here, there, everywhere, from time to calories, from steps we take to where we are and where we go, and the concept behind it I've come to know is called QS or quantifying self.

Being both a sci-fi fan and a techy, my mind inventoried a quick little list of hot wearable technology:

- watches

- cell phones

- fit bands

- tablets

- chips

.. and then raced ahead on what else is in prototype mode and/or about to hit the market..

- Google (eye)glass(es)

- electronic clothing

- tracking rings and fit bracelets

- more sophisticated watches

- portable SixthSense projections

- self-aware devices fixing themselves or communicating information to each other via 'speckled' computing

.. all capturing, analyzing and measuring themselves or any one person in a given context or scenario.

So then my train of thought took a light curve and I began wondering what life would be like soon enough, what I'd be spending my time using in my working environment.  How would I handle all this semantic data physically, and what would connect me to the software I work with?  The concept is not new, but what's changing is the hardware.

From quantifying self to quantifying content, I think there will emerge a more proprietary standard platform of software to enable communication between devices and even between devices and people!  We are probably already seeing some of it reflected in the meta of responsive design, where HTML is now changing to account for context and descriptive attributes in its format as a language, founded on the principles of XML.

Already today, I can connect to SDL Tridion using my phone, my tablet, my laptop and so why not in the near future, from anything else I might happen to wear.  For instance, I could be walking in a botanical garden wearing the new Google glasses and presented with more in-depth information about the flowers I'm looking over feel inspired to create a new marketing campaign spun from African orchids.  I could press my bracelet and open a projection of the GUI which by now may have morphed into a semantic taxonomy of sorts, ready for me to begin quantifying content, tip-tap, quick selections, move on to typing a few key sentences and off it goes, workflow-ed for approval and review, prepped for publishing in a cloud.

Perhaps another even shorter path to my web_of_things Content Manager could come directly prepped with all the data, and I would simply instruct it at a touch to insert itself in the software for other tracking, management, analysis and use.

The technology is in motion, like spring, it has only just begun to blossom.  Soon enough intelligent-data-aware objects will drive much of what we are and do; set the wheels in motion and start thinking about what this might mean to you.  Start classifying your content and quantifying your future business.

Troubleshoot the SDL Tridion Deployer Service - Part 2

Here we are as promised, in part 2 of troubleshooting the Deployer I continue to follow more ways to figure out what could be causing certain deployment woes.

Let's take a look at one of the most important lines in the cd_deployer_conf.xml file

<Queue>
        <Location Path="c:\tridion\incoming" WindowSize="20" Workers="10" Cleanup="true" Interval="2s"/>

1. Cleanup set to false - an excellent source of data is letting the deployment package remain in the folder where it was created, instead of having it removed as part of cleanup.  This is possible by setting the attribute Cleanup="false" in the cd_deployer_conf.xml file.  This package then can be inspected to match what is being moved by the Transport service and whether it matches expectations.  Remember to set this back to "true" when done debugging as files may collect here quickly and take up unnecessary space.

Also, this package can be dropped in the incoming folder of a working deployer to ensure there is nothing wrong with the package itself.

2. Is the incoming folder clean - another great checkpoint, having packages left over may cause the deployer to continue and try processing what it finds in this folder, possibly being hung by a transaction it can no longer distribute correctly

3. Increase/decrease WindowSize - use this to control how many packages the deployer allows in the queue and should handle at one point , thus helpful for cases when items are showing as "Waiting for Deployment".

4. Increase/decrease Workers - change this setting to define the number of deployer threads, also helpful when seeing "Waiting for Deployment".  Use it together with WindowSize to fine tune performance - how many deployment threads at a time should handle a given number of packages, carefully, though, tread as logically as Mr. Spock because giving the deployer threads too many packages too handle, will cause whatever cannot be processed at one time to go on hold - in "Waiting for Deployment", and typically this is seen when the WindowSize is more than double the number of Workers

5. Type of deployer and associated problems - there are several types of deployers, beware which one is in use, and possibly issues surrounding it based on type

• Windows Service - think start/stop/restart/dependencies only works for non HTTP/HTTPS transport protocols
• HTTP/HTTPS - think IIS, web.config, upload module, authentication
• • Test URL: http://HOST:PORT/HTTPUpload.aspx
• Java - think Tomcat, web.xml, web-inf classes, war file
• • Test URL: http://HOST:PORT/cd_upload/httpupload

6. Is the issue due to another service, are the Transport and Publisher in trouble, and the Deployer is stuck because of that instead?

7. Are there any extensions or custom modules installed on the deployer ? (http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-894AB0F0-313C-45A3-B8FC-8A02DA894C93)

Has the default behavior of the deployer been modified?

Take note of entries not part of the sample deployer configuration file available from install, such as the example below:

<Module Type="CacheFlusher" Class="com.tridion.examples.CacheFlusher">

8. Multi-threading - is the number of deployer threads too high compared to the number of the server's CPU cores?

9. WindowSize = 0  - if the window size is set to 0 (default), the Deployer sets no limit on the number of items in transit, guess what will happen based on what we talked in the previous points!

10. Constraint violations - may occur for different reasons, varying from table keys, to amount or type of content inserted in the Broker, and probably best addressed by contacting Support.  Prevention is always good medicine so periodically check the hotfixes section on SDL Tridion World for issues already discovered and addressed.

Until next time, happy troubleshooting!

Troubleshoot the SDL Tridion Deployer Service - Part 1

The Deployer Service is step 3, the finalizing step in the SDL Tridion publishing process.

In working with the Deployer, I've come across different reasons something could go sideways, and so in time, several best practices, a certain analysis pattern and some specific areas of interest began to emerge in the way I look at an issue here. 

The purpose of the Deployer service is to complete the publishing process by taking the transport package available in a specified location, usually known as the "incoming" folder, and processing its instructions.  This is done in accordance with the deployer's configuration (a combination of deployment information and data storage options).

It's hard to pinpoint where I begin, hence the brainstorming below.  Typically if there is a specific error I consider that the starting line, and so the next logical step takes me over to the logs, but more often than not, I feel better equipped to work on figuring out an issue if I know the architecture of the system involved.  It also helps to pay close attention to the "behavior" exhibited.  

Time and time again the first question that surfaces especially in situations where seemingly unexplainable ghosting behavior is observed becomes about the number, type and setup of deployers.  These have actually become my favorites: explain the unexplainable!

As I begin the analysis, I make sure I have the following 3 things: 

- the item id

- the publish queue transaction id I will need to trace along

- the timeframe in which the issue occured

.. and of course, as much clarity as I can muster about the symptoms experienced.

1. Are there 2+ (multiple) deployers referencing the same incoming folder - the behavior encountered is somewhat mystical in nature - records will not arrive at their destinations, transactions will not show up in the logs, and so content will not be available on the respective websites.

This can happen should 2+ deployers be configured to monitor the same incoming folder, a racing condition can occur, where the two deployers begin to compete and pickup transports depending on availability.

2. Are licenses correct - validate the path specified for configuration files, and if necessary, remember to request licenses ahead of time from SDL Customer Support.

3. Are there multiple destinations in the target - this is important to be aware of proper permissions and correct paths or urls. 

4. Is there a "rogue" deployer running somewhere - another mystical behavior, the clue here is to watch if transactions just "disappear" and don't show up in known logs at all, with some other deployer running and picking up jobs.  An interesting place to check in this case is the QUEUE_CONSUMERS table, look for machines activated which should not be. Deactivate what should not be in use anymore.  Note the deployer itself is not registered in the QUEUE_CONSUMERS table, the reason this is mentioned is to serve as a hint for what machines may possibly be carrying it which should not.  It is possible to have a deployer installed and running from a Content Manager server, although the preferred setup for scalability and performance is to decouple Content Delivery from Content Management.

5. Check what hotfixes are installed - perhaps the error message is a clear indication of an issue already fixed, an excellent source for this is available on http://www.sdltridionworld.com, I login and visit the Support section to check what hotfixes are posted and/or have been installed.

6. Check cd_core and cd_deployer logs - I look here to trace a specific transaction or item, best bet is to put these in DEBUG or TRACE mode, however beware logs will grow quite rapidly depending on the volume of data published.  Also search for "ERROR"s or "WARN"ings. 

7. Are there jars missing - probably one of the lengthier checks, but this can be scripted for comparison against a working site or the installation folders.  Typically the errors for this will be "Class not found", or "java.lang.NullPointerException", and so I follow the stacktrace to determine what call may have originated the issue and therefore what is missing.

8. Is the storage configured correctly -  beware what is defaulted and what becomes inherited.  Beware what is going to the file system or to the database.  Beware what is cached.  Beware the database connections information is up to date and test connections are working.

9. Is the cd_deployer_conf.xml correct - is the xml formatted correctly, are locations and paths correct?

10. Setup hibernate logging - If errors seemingly database related  are seen, this logging can trace most calls to the database.  This type of logging comes with a high warning: information will be logged quickly so use it to replicate the issue fast and when ready, turn off promptly.  Check Tridion StackExchange for steps on how to enable it and detect what hibernate entries look like.

By now, I may have solved the issue, or otherwise I am in possession of quite some good information and ready to perform more indepth analysis.  If I still cannot determine root cause or fix the issue, I continue my research further to increase the information collected.

In Part 2 of the article, I follow on with more clues, tips and fixes.

How to Setup Classic Editing Workflow in SDL Tridion 2013 SP1

SDL Tridion 2013 SP1 introduced two new approaches related to workflow functionality.  As such the product now provides four types of workflow for implementations:

• Bundle Workflow
• Task Workflow
• Programmatic Workflow
• Classic Editing Workflow 

The last type of workflow is also known as legacy workflow these days, having been superseded by the Bundle and Task workflows.  I recently did some work using this type of workflow and while getting started, I made my way across the following steps I thought would be useful to keep track of.  As interesting and beneficial the Bundle and Task workflows are, perhaps some implementations will decide to retain legacy workflow for a while longer, so here we go.

1. Classic Editing / Legacy workflow does not install by default, so the previous default Component and Page Process will not be available in the box.. out of the box

2. Workflow diagrams are created and edited with Visio.  Installing Microsoft Office Visio 2013 is preferred, otherwise Visio 2010 is also supported (although you may need to install updates the first time the client runs)

3. Install Visio Workflow Designer Client from Content Manager\Additional Products\Visio Workflow Designer is necessary as well.  This is the extension applied to Visio which enables connectivity between Visio and the Tridion Content Manager.  Once this runs, the next time you open Visio, you will notice and recognize several new Tridion icons appear in Visio, under the SDL Tridion Workflow Shapes section.

4. To bring in previos classic workflow processes, you can export Tridion Visio diagrams from 2011 SP1 locally and import them in 2013 SP1 using Visio Tridion functionality

5. When working on step 4 above, if you get this screenshot on the 2013 system, you have not installed the actual legacy pack 

"Workflow Script Type with Name 'VBScript' was not found in the configuration file"

Run the installer and make sure the following option is set:

SDLTridion2013SP1CM.exe LEGACY_VISIBLE=TRUE

6. Once all this is in place, proceed to associate the newly imported workflows as needed in Schemas for Components, Structure Groups for Pages or Publications for Templates.  

Should some of the concepts need refreshing, review them again, and remember, workflows were meant to introduce simplicity as well as security by making sure that specific users go through steps in a specific order.  Always strive to simplify a given workflow and the results will be rewarding. 

SDL Tridion 2013 SP1 - How to Setup a 2nd Broker

Whenever I've come across installing Tridion, I've always installed at least two broker databases, and lately three if you count the Session Preview broker as well.  The first broker is for Staging websites, while the second is used for Live sites.

As is the case with a repetitive action, the more you do it, the faster and better you become at it.

Here are several pseudo-steps as an easy recipe to get you through this setup fast as fast can be in Tridion 2013 SP1.

1. Install the actual database and know the database credentials ahead of time*: run the Powershell script

& '.\Install Content Data Store.ps1' 

2. Name your broker something different than what is in the database already (eg. Tridion_Broker_Staging)

3. Update your (second) Deployer cd_storage_conf.xml with the new broker information and configure how you want different item types to be handled.  A second separate deployer is required to write to the new database.

4. Update (another) corresponding website cd_storage_conf.xml to show content from the second broker.  A separate website is necessary as well to show content stored in the new broker.

5. Loop back into the Tridion Content Manager Explorer and create the necessary [Staging] target type and publication target(s).

Specify the deployer information based on type installed and apply the publications you want to store content in the new broker.

.. and voila, the second broker should be active and receiving content when you publish.

Happy brokering!

---

References (login required):

*http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-396764E5-8C75-4444-B12A-3EA8ECF4A3C1

Quick Check List for SDL Tridion 2011 SP1 Personalization and Profiling Setups

In SDL Tridion 2011 SP1, setting up pesonalization and profiling can be somewhat challenging given the range of configuration touch points spans both the Content Manager and the Content Delivery systems.

If you are looking for an installation, configuration and implementation path, you could likely follow these steps (depending on whether this is .NET or Java based): 

1. Check the Target Publishing Language in the Publication Target is dynamic (JSP/ASP/REL)

2. Check the cd_deployer_conf.xml file includes TCDLTransformer class, for PageDeploy for example

3. Update the cd_storage_conf.xml (or cd_broker_conf.xml if still using that) to enable Item Types for the elements you want to track (eg. PageTracked, Timeframe etc)

4. Update the cd_wai_conf.xml to represent your website and settings for your personalization and profiling requirements such as host, cookies, tracking info

5. Update the web.config to support the httpModule TridionWAIHttpModule

6. Restart Content Delivery services and web servers for changes to take place

6. Proceed to enable item tracking such as Component and Page Template tracking in the CMS using template building blocks

7. Check if tracking is working after publishing your changes from the CMS by viewing content from a browser

8. Continue to implement personalization and profiling requirements using CMS functionality and API calls and test they function as expected after publishing and viewing pages from a browser 

Additional references for Personalization and Profiling can be found below.

Setting up/Configuring Reference:
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/reference_CD033408F5CD4A119BDA616851A10B3F

Setting up P&P (WAI) for a .NET application
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/task_FF19F86A63E246F793D64495849EDEDF

Implementing:
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/idheading-158522992

Reference API:
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/pp_concept_B72F4D64713F4682B61C838A013DF8F8

Tips for Troubleshooting the SDL Tridion Transport Service

The SDL Tridion Transport Service is step two of the content distribution process.  This service is somewhat mystical for two reasons:  it resides on both the Content Manager and Content Delivery systems and it is more difficult to troubleshoot than other services.

Since I've been on a quest lately to shine the light on the unknown, let's take a look at it!

The Transport Service is a mechanism which gathers published items and their dependencies into a package.  It then submits this package from a Content Manager to a Content Delivery system by using sending and receiving modules enabled for different protocols.  These protocols are activated in the cd_transport_conf.xml file for the Content Manager and in the cd_deployer_conf.xml for Content Delivery.

* Local file

* HTTP

* HTTPS

* FTP

* SFTP

* SSHFTP

Under certain conditions, the Transport Service may not start, or start and stop immediately, or otherwise report an error message during the lifecycle of the publishing process.

What can you do to troubleshoot it?  Here is a quick list to walk you through a number of checks:

1. Windows event logs (Tridion.evtx and Application)

Look for messages such as the one below, which is a pretty clear indication that the java version the Transport Service was trying to use could not be loaded (the issue in step 2).

"The description for Event ID 100 from source TCDTransportService cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. 

If the event originated on another computer, the display information had to be saved with the event. 
The following information was included with the event: 
Could not load Java runtime libraries at C:\Program Files (x86)\Java\jre7\bin\client\jvm.dll" 

2. Does the java version installed match the version required by the specific SDL Tridion version installed?

Some machines are configured to pop up a small notification icon to nudge you  forward to the next java update. It's easy to click on it and accidentally install an unsupported version.  Make sure you have the right version, use "java -version" from a command prompt.

3. Publisher Service will not start if the Transport Service does not start

There is a dependency between the Publisher Service and the Transport Service, hence if you notice the Publisher Service does not start, it may be an indication something is off with the Transport Service

4. The transport service log

This log is located on the Content Manager server.  When set in debug mode from the logback.xml file, it can provide more details around the processing involved in transporting items, and therefore potentially narrow down something more specific about an issue.

5. Is a custom transport used, if so, is it written, configured and used properly?

Occasionally, someone may want to use a protocol other than what is available by default.  This is possible by creating a class which implements the com.tridion.transport.connection.TransportConnector java interface, and creating the appropriate Sender and its protocol schema.

Validate all steps were followed accurately as described in the documentation (login required)

http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/task_E724DA16924F4CF4A3E00B160445F2DA

6.  HTTPS Uploads

Should HTTPS be chosen for transporting items, the only way this can take place if if there is a certificate added in the keystore, so that the transport mechanism is allowed to access its destination.  The certificate may be imported into the default CACERTS keystore or a custom one.

Look for an entry such as the one below to tell if there is a custom store in use:

<Sender Type="HTTPS" Class="com.tridion.transport.connection.connectors.HTTPSTransportConnector">
  <KeyStore Path="c:\mydir\myks.keystore" Secret="mypassword" />
</Sender>

  

An incorrect configuration in cd_transport_conf.xml such as a KeyStore node in cd_transport_conf.xml missing from the HTTPS Sender will cause the Transport Service to fail.

The step by step procedure to add a keystore is explained in the documentation (login required)

http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/concept_90BCCB544F8E46F4AF88EDCDAC17987F

7. Transporting using a proxy

When sending content across servers, from an internal network out to an external public one, many organizations use proxies to protect the data.  It's possible to misconfigure this proxy and cause the transport to break down.  The proxy configuration differs based on type of protocol used, as well as the type of proxy, generic or application specific, and so the changes to watch for will be done in the Publication Target and/or the registry, full details available in the documentation (login required).

http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/concept_455C61B06FAB4502B5AF573332E6C33E

8. Is the cd_license missing?

It may be easy to forget about the cd_license.xml file on the Content Manager server, and this is definitely a requirement for the Transport Service to operate.  

9. Last but not least, simple as it may be, do not forget to restart the Transport Service after changes made to (re)configure it.

As Alfred Pennyworth (Batman Begins, 2005) best put it: "And why do we fall sir?  So that we can learn to pick ourselves up."

Should the Transport Service happen to behave unusually, grab your flashlight, follow my trail and see how quickly you can demystify the strange..

7 Things I bet You Didn't Know about Experience Manager

In the past few weeks, I've had a chance to shine the flashlight a little closer on the SDL Tridion Experience Manager interface of the Content Management System, especially so for the new SDL Tridion 2013 SP1 version out since the first week of December.

Here is a list of things I uncovered and found worth noting:

1. The SDL Tridion Live Documentation for 2013 SP1 has a video on the entire Experience Manager install, configuration plus installation steps.  There are architecture illustrations as well, easy to follow if you look for the 1-2-3 steps marked on the diagrams. 

http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-3C70F892-69F4-4FEE-922D-39F1AFEBD539

2. The Content Manager Explorer Dashboard has been morphed into a slide-out navigation, therefore any extensions created for Experience Manager and previously visible on the Dashboard need to be re-coded for the slide-out navigation panel.  

3. You must remember to re-install Default Template Building Blocks from TemplateBuilder to ensure the newly updated TBBs are introduced in the Content Manager.

4. The Dreamweaver call RenderComponentField() is deprecated and replaced with the following new Dreamweaver calls.  The main reason for this is to allow multivalued embedded fields to be editable from Experience Manager, something many have been looking forward to.

@@FieldStartMarker(FIELDNAME)@@ and @@FieldEndMarker@@

@@FieldValueStartMarker()@@

      @@GetFieldValue(FIELDNAME, 0)@@

@@FieldValueEndMarker()@@

They also must be used in proper order or else will not output the equivalent tags which are recognizable by Experience Manager.

@@FieldStartMarker("fieldname")@@

     @@FieldValueStartMarker()@@

          @@GetFieldValue("fieldname")@@

     @@FieldValueEndMarker()@@

@@FieldEndMarker()@@

5. The SessionPreview token session length is configurable in cd_storage_conf.xml.  Update the <Timeout> element, measured in milliseconds, for example 60000 for 1 minute, 120000 for 2 minutes and so on.  

<Wrappers>
  <Wrapper Name="SessionWrapper">e
    <Timeout>60000</Timeout>
    <Storage Type="persistence" Id="db-session" dialect="MSSQL" Class="com.tridion.storage.persistence.JPADAOFactory">
      <Pool Type="jdbc" Size="5" MonitorInterval="60" IdleTimeout="120" CheckoutTimeout="120" />

The session length accounts for the little trip Experience Manager takes while a user clicks UpdatePreview to save new changes in the browser and the session database.

6. Enabling multiple targets for Session Preview (eg. Live and Staging) may cause ExperienceManager not to work. Experience Manager should only run on Staging type sites, not on Live.

7. There is a number of fixes provided exclusively for Experience Manager in 2013 SP1, and they vary from editorial to technical.  For instance, when clicking on "Finish Editing" the latest changes done on the page are shown during reloading of the page.

So if you plan on tackling the installation, configuration and implementation for Experience Manager keep the above pointers in mind when you do and you will definitely have a brighter go of it!