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).


7 responses to “SDL Tridion 2011 AppData

  1. Nice explanation and example, thanks!

    I can see the AppData well suited for systems closely related Web content. To add more to Frank’s explanation perhaps the add-on code could include user ids (email addresses?), intranet database IDs for related components, or third-party content from a service like EBSCO.

    Then maybe we can do a PowerTool to see or manage this data in the CME (third tab after content and metadata)? 🙂

    • Spot on Alvin, all of that stuff could be relevant targets for AppData storage. A PowerTool would be useful – I didn’t mention it , but there’s a ReadAllApplicationData method (or something very similar) that gets all AppData objects for a given item id. It would be the way to go. Could also be useful to have a system-wide view, if possible. Besides displaying the AppData, any tool could also allow the deletion of it (good for a system-wide view and orphaned data). Potentially, with the appropriate permissions, it could also be updated from the tool, although I see this as lower priority than viewing and deleting.

  2. Clear explanation!
    Note that you don’t have to explicitly delete AppData attached to an item; it will get deleted automatically by the system when the item is deleted.
    Also note that AppData is versioned to some extent: if you attach it to a Versioned Item, it gets versioned together with the item (i.e. each version of the item will have its own set of attached AppData).

    Finally: note that we ship an ApplicationDataAdapter class to help with (de-)serializing your own (strongly-typed) objects into loosely typed ApplicationData objects. This class is part of the TOM.NET and provided as a separate .cs file in the CD layout. In 2011 SP1 we provide an out-of-the-box Core Service proxy assembly, which also contains this ApplicationDataAdapter class.

    • Thanks for the info Rick. The AppDataAdapter sounds very interesting, and it’s good to know that data is deleted when the associated item is deleted.

      Could elaborate a little on the versioning? Does it mean that, for example, my page specific data will only be valid for the version of the page for which it was created? Or is it more that the data is persisted between versions until the data changes, and that a rollback/forward will change the current data to match the data at the selected version?

      • I guess it’s the latter of your options.
        Our versioning system treats AppData attached to an Versioned Item the same as the other properties of the item.
        There is only one thing that makes AppData attached to an Versioned Item quite different from the other properties: you can change the AppData attached to *old* versions of a Versioned Item (so in a sense you can change history; you can see it as a time-machine 😉

  3. Pingback: SDL Tridion Event System Newbie Perspective | Tridion Developer

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s