Improving SaveApplicationData performance

Question

I'm currently using the core service SaveApplicationData method - sequentially adding new application data to both a specific subject (TCM URI) and to the global application data namespace. This involves potentially thousands of individual calls in succession.

Functionally, this works as intended - but the performance of these repeated save calls is causing a bottleneck. A couple of questions:

1. Is there any way that I can batch up multiple SaveApplicationData calls into a single call. I notice the docs mention that multiple ApplicationData instances can be saved at once - so I could at least batch up the global application data into one call. But presumably the subject specific application data will always have to be saved individually?

2. Is there a more efficient way of storing user-specific data via the core service? I considered creating a new schema field to store this information whilst creating the components - but this application data isn't something that I wish to expose to end users. I'm also loathe to set-up a separate persistence mechanism just for storing this sort of user data.

Thanks,

Ben

Answer 1

API

The Content Manager Core Service API Reference Guide has:

void SaveApplicationData(
    string subjectId,
    IEnumerable<ApplicationData> applicationData
)

Of the two parameters, we have:

subjectId

"The identifier (TCM URI or WebDAV URL) of the subject to which the application data should be associated. Use null to save global application data."

applicationData

"The application-specific data to save. Multiple ApplicationData instances can be saved at once."

It looks like for a given subjectId, we can definitely save multiple sets of ApplicationData, but I don't see a SaveApplicationData method that takes in multiple subjectIds.

I think you're right that "subject specific application data will always have to be saved individually."

User-Specific Data

You can use permissions with components and schemas, but you can also change the timing of your script or refactor the logic if possible.

You can use permissions to control both the creation of components based on a "configuration" schema as well as on the ability to see or edit the components by removing read permission on the containing folders for both.

To avoid needing a component maybe consider changing the timing of your script--use Application Data but only update as needed per user, schedule the update during off hours, and/or "chunk" the updates into smaller requests.

Just like content modeling, if you have a pattern in the data, you can definitely abstract out the differences and only save a "type" (integer) or reference to the full values stored elsewhere. The trade-off, of course, would be longer retrieval times.

Answer 2

With 2011 there's not much you can do there. In 2013 there is an additional process added to Tridion allowing you to execute Batch Operations (functionally equivalent to the old Multiple Operations method in the COM API).

I guess for now your best approach would be to start making these changes using the Asynchronous methods available to the CoreService - some detail available here.