14

I'm using the core service to create a new component, and then save some application data against it.

When I create the component programatically - this returns me the dynamic TCM URI of the currently editable version (for example tcm:1-2-v0).

However, if I then attempt to call saveApplicationData using this URI, the core service throws an exception stating that the item with that URI does not exist.

If I strip the -v0 from the end of the TCM URI, saveApplicationData works as expected. Is this the intended behaviour? Is there any way I can use the dynamic URI without having to manipulate the string?

Improve this question
2
  • 2
    This actually happens with any save operation, not only ApplicationData, and I agree it's quite annoying. I tend to have a simple "cleanUpUri" method that ensures I don't use -v0 when saving anything client.Save(cleanUpUri(uri))
    – Nuno Linhares ♦
    Commented Mar 26, 2013 at 10:57
  • This would make a good feature request. If we accept that tcm:x-y-z-v0 identifies exactly the same resource as tcm:x-y-z, it seems reasonable that Tridion should automatically canonicalise this when necessary.
    – Dominic Cronin
    Commented Jun 8, 2013 at 8:29

3 Answers 3

Reset to default
9

The way I understood it, is that for (at least) 2011 SP1, application data is versioned to some extent. However not exactly the same as the versioning of an item (since you can also set application data on non versioned items like Organizational Items).

When you store application data, you store it against the URI of an item (the versionless URI). The application data will internally be stored against the current version of that item. When a new version of the item is created, the application data is implicitly made available for that new version, unless you override it with new application data.

Getting application data made this clear to me. You get the application data for the current version, that is the application data that is set on that version of the item, or on any version below that. When you roll back the (versioned) item, it deletes application data set after the version you are rolling back to.

When setting Application Data through the TOM.NET this is all clear, since you set the application data through the actual Item (and its version), but it seems that using the Core Service you can only set application data for the current version.

Improve this answer
2
  • That's a help description of what's going on in the background. Thanks Bart.
    – Bengineer
    Commented Mar 26, 2013 at 12:06
  • The only version of an item you can ever edit is the current one. How else would anyone expect versioning to work?
    – Dominic Cronin
    Commented Jun 8, 2013 at 8:26
7

I've been playing with saving Application Data within workflow for Tridion 2011 SP1. Since the previous answers all seem to be outside the context of workflow, I thought I should contribute my findings (as it proved rather frustrating to me until I discovered what was going on) as they run counter to Nuno's suggestion to always clean uri's when saving.

My problem boiled down to this: Within an automated workflow activity, if I tried to update the value of a component's Application Data to a different value it seemed like the call to SaveApplicationData had no effect - the original value always remained. I debugged repeatedly to make sure the component tcmuri I was using for the saving & reading was the same and it always was. Enlightenment didn't come until until I cracked the DB open (bad, I know - but I just needed to see) and watched the Application Data as my application attempted to update it.

What I saw was when a component enters workflow, the system automatically creates a copy of the current version's Application Data record with a version of 0. Upon completion of workflow, this version 0 appears to become the new version. For example, if there were 3 versions when workflow began, a fourth entry would be created with version 0. When workflow finished, this version 0 would become version 4.

What caused my troubles was the fact that when I was attempting to overwrite the Application Data value for the component, the component tcmuri I would use came out of the workflow's current subject and was version-less. Therefore my save would update the latest version (NOT version 0 that was currently in workflow) and once the component came out of workflow, unchanged version 0 became the newest version (the updated version was superseded by the "new version" making it look like my change hadn't been saved). I never rolled back the component's version, but I'm guessing if I'd rolled back the latest version I would have then had my updated value...

In order to make this work in the context of workflow I had to add -v0 to the component tcmuri when I was calling SaveApplicationData. So, Kunal's statement about SaveApplicationData not working with versioned tcmuri's is not actually correct.

I do like changes to the Application Data being tied to the workflow version - so if the process is deleted the change to the Application Data is also rolled back. It just wasn't very clear to me in the documentation how important it was to understand the relationship between versioning, workflow and Application Data.

Improve this answer
1
  • Thanks for this useful info which adds to the question and the accepted answer.
    – Jan H
    Commented Jun 8, 2013 at 10:07
6

As far as I know, the Tridion Application Data is not versioned on Tridion 2011.

So it seems logical that the SaveApplicationData does not work with the an versioned TCM Uri i.e tcm-xxx-yyy-v0

Improve this answer
1
  • 1
    FYI: Tridion started keeping the application data per version in Tridion 2011 SP1.
    – Frank van Puffelen
    Commented Jun 8, 2013 at 13:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.