SDL Tridion 2011 AppData

Recently I’ve been working on a GUI extension that involves determining the URL of a published Page and the shortening it using bitly. For the use case I have in mind it doesn’t make sense to get a new short URL every time the extension functionality is called for a specific Page. This means I needed a way to persist the shortened URL, so it could be reused as and when needed.

I knew some of my colleagues had solved the problem in extensions they’d developed so I put the question to them. I received a few answers, and fewer options than answers, but the general recommendation was to use “AppData”.

Here’s what Frank has to say about AppData:

One of the new features in Tridion 2011 that has not gotten much public attention is the so-called application data (AppData for friends). The application data feature gives us a mechanism to store additional, application-specific data with every Tridion item. So if you have a Component in Tridion that corresponds to some file outside in the real world, you could store the path to the file in the Component’s AppData. You can of course also store that information in a metadata field. But doing so exposes the information to every user that has access to the Component. The beauty (and curse) of AppData is that it is only available through the API. It is meant to be produced and consumed by an add-on application.

So, pretty much exactly what I wanted 🙂

Using AppData

Now understanding what I should use I set about understanding how to use it.  The new Tridion .Net API may well have support for AppData, but as the recommended approach for communication with the core application is to use the Core Service, and all the feedback I was getting was telling me to use the Core Service, I was concentrating on, of course, the Core Service. It’s actually a very simple process, as the examples below should show.

When working with AppData you need to provide an application id and, optionally, and item id. The application id is the identifier for the custom application, against which the relevant data is stored. The optional item id allows you to tie the application’s data to a specific Tridion item. Whether or not you specify an item id depends on the type of data you want to store. In my case it was relevant to a selected Page so I would be specifying the item id.

With the code examples it’s important to note that I’m using a proxy class for the Core Service, and a static helper method to get the client object. The focus of the examples is to show how to use the client to interact with AppData, not to show how to create a client connection to the Core Service.

Getting AppData

CoreService2010Client client = ServiceClient.GetCoreServiceClient();
string appDataValue = string.Empty;
ApplicationData appData = client.ReadApplicationData(itemId, applicationId);

if (appData != null)
    Byte[] data = appData.Data;
    appDataValue = Encoding.Unicode.GetString(data);


As you can see, to get the data you call .ReadApplicationData, specifying the appropriate ids. If the AppData object exists, you get the data as a byte array and it to an encoded string. This string can be the value itself, as it was in my case, or it could be JSON or XML representing a more complex set of information. For the latter you would need to process the value further to extra the information you require.

Setting AppData

CoreService2010Client client = ServiceClient.GetCoreServiceClient();
Byte[] byteData = Encoding.Unicode.GetBytes(valueToStore);
ApplicationData appData = new ApplicationData
    ApplicationId = applicationId,
    Data = byteData,
    TypeId = url.GetType().ToString()
client.SaveApplicationData(itemId, new[] { appData });

Setting AppData is almost the exact reversal of the process to get it.  You create an AppData object, convert the string to store to an encoded byte array, set the application id, and then save against the relevant item id. The big difference here is that you can save multiple AppData objects in one go as they’re passed to .SaveApplicationData as an array. I’m not sure how often you’d actually do this, but it’s nice to know that it’s an option.

Deleting AppData

Of course, if you can get or set AppData it’s also handy to be able to delete it. I can imagine that you might tie this in to a delete event in the Event System to make sure that you don’t end up with lots of orphaned application data in your database.

CoreService2010Client client = ServiceClient.GetCoreServiceClient();
client.DeleteApplicationData(itemId, applicationId);

Nice and simple here – call .DeleteApplicationData for the appropriate item id and application id and it’s job done.

Additional Info

If you don’t want to tie your application data storage to a specific item you just need to use null where the samples show itemId. It’s important to remember that, when using AppData, you’re storing information in the Tridion database. Overuse has the potential to bloat the db, so make careful consideration when taking this route. AppData is also not versioned, so if you overwrite a value you will lose the previous value. It may be possible to specify a version number in the item id (if you’re using it) – something like tcm:xx-xx-xx-v1, where v1 represents version 1 of the relevant item (but I’m sure you knew that already).