An interesting question has been asked on Tridion Stack Exchange regarding whether there are any frameworks or methodologies for using Test Driven Development with the Tridion Event System. Having done test driven development in my early days as a Java and PLSQL developer and having had developed enough functionality with the Tridion Event Systen, I thought I’d provide my two-cents. Continue reading
On a recent implementation, a large site fully driven by OData, we ran into a scenario where we wanted to retrieve DCPs based on multiple custom metadata values. We quickly realized that there are some limitations around this. For instance: a component with the following custom meta fields, color and shape, having values ‘blue’ and ‘round’ respectively cannot be retrieved in one OData call. This is because each CustomMetas Key/Value is exposed as a separate entry in the CustomMetas collection, and the OData protocol is limited – doesn’t allow querying across properties of multiple entries (not as an AND at least). However, if there is a will there is a way, and in the article I will show an approach to doing so.
- Part 1 – Examining the Problem
- Part 2 – The Generic Workaround
- Part 3 – The Multi-Meta Query Solution
JSP Expression Language has the same syntax as Tridion’s Dreamweaver field rendering syntax. So when you try to render JSP EL in your DWT, the Dreamweaver Mediator replaces it with a blank because it can’t successfully resolve it. Here is a quick tip on how to get around this problem.
To me, OData is simply the Broker API exposed as a web service – at least the most popular functionality of the original Broker API. This is useful if your website is not .NET or Java based (PHP for instance), or if the app that needs to pull content across the internet or via AJAX, or for some other reason where database calls to the Broker are restricted. In this tutorial I cover getting started with OData and also dive into some of the more advanced query string operations.
Many big companies out there are still using Tridion 2009 which is limited to Internet Explorer 6, 7 and 8. As we all know, those browser versions have long become extinct, and those that are still on Tridion 2009 have to hang on to the old browsers. However, it is possible to configure IE9 to also work with Tridion 2009. In this post I explain how.
I’ve recently helped a colleague with an issue when trying to deploy our Tridion DD4T .NET project to a Dev machine. The issue was a “System.BadImageFormatException” related to the Tridion’s Java wrapper Juggernet.
However, at first we were getting the error: “Unable to load DLL ‘xmogrt': The specified module could not be found. (Exception from HRESULT: 0x8007007E)”. It was weird because on my VM, with the exact same files in the bin, it ran fine. Turns out, it worked on my VM because my %TRIDION_HOME% was set with the file in it.
We followed the answers in this post (which you’ve probably read already before coming to this article: http://stackoverflow.com/questions/13918310/unable-to-load-dll-xmogrt-from-tridion-metadata-query) and placed the xmogrt.dll and its dependencies in the bin. However, we now ended with the “System.BadImageFormatException”:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) Server Error in '/' Application. An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Here is how we solved the problem:
- Uninstall all Java (you may have several versions of the JVM installed. Uninstall all of them)
- Install the latest Java 6 JRE (though we installed the JDK 1.6_45).
- Check that it’s successfully installed by typing java –version from the command line.
- Verify that ‘xmogrt.dll’ is in the bin folder of your app and is not corrupt. In our case the ‘xmogrt.dll’ file was only 840kb for some reason. It should be 1630 KB.
- Do an iisreset.
Here is the long answer
xmogrt.dll is an unmanaged C++ assembly that is largely the Juggernet Java wrapper used by Tridion (if you’ve wondered about those jar files in the bin/lib). This compilation version of this DLL must match the CPU instructionset, i.e. x86 or x86-64). It must also match the latest Tridion-supported Java version, i.e. 1.6_xx x86 or 1.6_xx 64-bit (of java 1.7 for Tridion 2013). If there is a mismatch in either, then you’ll receive the “System.BadImageFormatException” error.Look at the Juggernet documentation for more details about how Juggernet works and this error here: http://codemesh.com/products/vfour/tutorial/dotnet/v3/L_02_run_app.html, scroll down to the section “Common Runtime Issues You Might Encounter”. Also, the Juggernet architecture diagram (found here: http://codemesh.com/products/vfour/dotnetruntimes.html) provides a nice deal of insight into understanding how the Tridion CD API is converted to .NET.
With all the anticipation and excitement of the new 2013 Bundle Workflow coming out, I thought I’d dig into my notes about the regular ol’ single item workflow for those still on pre-2013 systems. In this post I discuss some lessons learnt about debugging workflow. Note, this is when I was working with Tridion 2009 SP1, but the same should apply all the way up to Tridion 2011 SP1 HR1.
There are a few methods available for troubleshooting your workflow code. There is no way to use a real debugger on the Workflow VB script since there is no way to set breakpoints in the Visio Automatic Activity Script editor. You can instead keep your VB code as light as possible and keep your workflow logic in C#.
Attach to Process and Set Breakpoints/Debug Normally
To do this, your code must be outside of VBScript editor in a C# Class Library DLL as mentioned above.
One approach to this is to write a stand-alone executable that you call via the workflow VBScript. This stand-alone exe would need to impersonate a user on the CM server, but then can do anything you want. And since this is a stand-alone program running from some directory on the server you can deploy it with a PDB file and attach to its process.
Another common practice of writing workflow code is to write a DLL then register it as a COM+ object or drop it into the GAC. Note that with the GAC approach you can’t easily put the PDB into the GAC with it (at least for the x86 architecture; for x64 there is a folder deeply nested somewhere in Windows where you’ll see your DLL,so you can put your PDB next to it). Then we simply use Process Explorer (http://technet.microsoft.com/en-ca/sysinternals/bb896653.aspx) to find the process using your DLL and attach to it.
Print Logging Statements
If you have some logistical challenges with being able to attach to a process, then we need a way to print debug output statements somewhere – the old fashion way of debugging. This “somewhere” can be two places:
- CM Server’s Event Viewer.
- The finish message. However there is a character limit on how big this can be, and your code may never reach the finish statement.
Using Tridion’s Logger to Print Debug Output
This is the sure way of logging your debug output.
If you’ve moved your workflow code away from VBScript into a C# DLL, then:
Logging logger = TDSE.GetLogging();
logger.LogEvent("my debug output", EnumSeverity.severityError, EnumEventCategory.EVENT_CATEGORY_WORKFLOW);
You can do the same thing right from the workflow VB script:
Set logger = TDSE.GetLogging()
Call logger.LogEvent("my debug output", 1, 22)
The log messages will appear in the CM server’s Event Viewer log.
If you don’t have sufficient access to the CM server, then you can use the method listed below. However, in order to effectively develop Workflow you need to get that server access and the ability to freely see the CM’s Event Viewer. So convince your PM or IT people to grant you that access or you’ll be burning a lot of rubber spinning wheels rather than getting traction.
Using the Finish Message to Print Debug Output
This is a really cheeky approach to debugging. Do it as a very last resort or while waiting for IT requests to get processed instead of twiddling your thumbs.
Start with one line of code which is:
Call FinishActivity("my debug output", "Next Activity’s Title or TcmId")
Add some code before this line. Any output you want to see should go in “my message” parameter of FinishActivity.
Note: there is a character limit to how large the finish message can be. This is driven by the database column size. So if you try and spit out too much debug output you’ll get an error.
So be warned. This is a way to do some quick one off printouts, but don’t rely on this as the main way to debug your code (Although back in the day I’ve gotten through coding a massive workflow with this approach before I realized TOM provided a logger, duh!)
Again, a much better way to log debug output is to use the Logger that comes with TOM.
Some Workflow Errors and Things to Watch Out For
Position in the Workflow
This one was fun to debug… Actually if you carefully read the TOM API, which I did not, it provides an example of how to find out how many more activities are left in the flow. There actually is a comment in the sample code that mentions that this works only if there are no loopbacks. Be warned! If you have a case where you need to find out what the previous activity was or what the next activity is, you can’t rely on the position that Tridion gives you because if you have a rejection of content that takes you back a few steps, the position still gets incremented.
Object reference not set to an instance of an object
An error occurred while executing the Workflow script.
The Script Engine returned the following information:
Line = 41
Column = 0
Number = -2147467261
Source = ContentBloom.Tridion.Workflow
Description = Object reference not set to an instance of an object.
HelpContext = 0
caused by: ContentBloom.Tridion.Workflow
and description: Object reference not set to an instance of an object.
This isn’t the VB dying; it’s a null reference exception somewhere in your C# code. Unfortunately the error doesn’t tell us where – well it tell us which function is being called by VB and its line number – so throw in a bunch of logging statements into that C# code and see where it bugs out.
Application uses a value of the wrong type for the current operation.
Unable to finish the Workflow Activity (tcm:12-671-131104)
Application uses a value of the wrong type for the current operation.
The CM server’s event viewer may show a few errors with some being a blob of XML. If you look closely you’ll see this message. What it means is that the size of the FinishMessage is too big. The database column for this field has reached its limit.
A piece of advise that I learned from a wise Tridion sensei is that it’s not a good practice to localize pages in Tridion if you have a multi-lingual site (though there is an exception to this rule which I’ll discuss below). The reason for this is simple: you lose the ability to centrally manage your site from the Master web publication. Once a page is localized, you have to manage it individually, which is not ideal if you want to centrally update component presentations on a page across all the language sites. So what do you do if you want to obey the rule of not localizing pages and your customer asks to have localized/translated URLs?
Here is a quick Tridion tip. If publishing fails with an error: “Request Entity Too Large”, it means that the size of the package is larger than what the Deployer is allowed to accept. To resolve the issue, simply increase the HTTPSReceiver MaxSize attribute in the cd_deployer_conf.xml file. What scenarios could cause this…
I have recently ran into a dilemma where if an HTML 5 data attribute (any attribute in the form of data-*) was added to an anchor tag within a Rich Text Field, the Tridion GUI would strip it out. There are a couple of solutions to this problem…