How to obtain the root storage location for a publication in Tridion 2013?

Question

We have existing Java functionality which requires a filesystem location to find published content in the filesystem folder. In Tridion R5 this was implemented using a Broker instance via Broker.getInstance(), and then using objBroker.getDocumentRoot(pubID).

Now that we are migrating to Tridion 2013, and want to get rid of the deprecated Broker code and cd_broker_conf.xml, I am looking for a way to obtain the root path for a publication from cd_storage_conf.xml. However, there seems to be no way through the API to get this information. Anyone has done this before?

Answer 1

In Tridion 2011 and up, the Broker Storage Layer API took over the deprecated functions. This means classes in com.tridion.storage package. Here is a method that should return the file system location for pages. Note, I've not tested nor compiled this, but it should get you going in the right direction.

String getPageFileSystemStorageLocation(int pubId) throws ClassCastException {
    String fsPath = null;
    StorageManagerFactory storageManagerFactory = StorageManagerFactory.getInstance();

    try {
        FSPageDAO fsPageDAO = (FSPageDAO)storageManagerFactory.getDAO(pubId, StorageTypeMapping.PAGE);
        File storageLocationFolder = fsPageDAO.getStorageLocation();
        fsPath = storageLocationFolder.getAbsolutePath();
    }
    catch(ClassCastException cce) {
        // This means you don't have pages configured to go to the file system.
        // Handle it/log it/call the fire department/whatever...
        throw cce;
    }

    return fsPath;
}

-- EDIT --

I just realized that the FSPageDAO.getStorageLocation() is a protected method in the FSBaseDAO, so the above code won't work as is. However, this can be resolved by finding the exact classes/methods which instantiate the FSPageDAO (because its public constructor takes the storage location as a parameter), or by extending the FSPageDAO with a custom class inside the com.tridion.storage package.

Answer 2

I don't know if you can do this in Tridion 2013, but in Tridion 2011 there's a way to transform cd_broker_config to the appropriate cd_storage_config. Upgrading from R5 straight to 2013 is a pretty big upgrade. Have you thought about upgrading incrementally or even doing a fresh install/setup?

Anyway, here's the doc I found online about transforming a broker config to storage:

As of the 2011 release, SDL Tridion release replaces the Content Broker configuration file, cd_broker_config.xml, with a Storage Layer configuration file, cd_storage_conf.xml, which configures how and where Content Delivery stores items. This also affects custom storage home classes.

Content Delivery automatically transforms your existing deprecated Content Broker configuration into a Storage Layer configuration. In most cases, this results in a working Storage Layer configuration that works the same way as your Content Broker configuration. But in some cases, you may need to update the configuration manually. The documentation topics about upgrading Content Delivery explain how.

The most important differences between the Content Broker configuration and the Storage Layer configuration are:

In the Storage Layer configuration, you can configure multiple storage media and store various types of content in different media. The Storage Layer configuration no longer requires you to use Broker bindings. The Storage Layer configuration no longer requires you to configure a QueryGenerator element. To support backward compatibility, SDL Tridion 2011 SP1 automatically detects your existing Content Broker configuration file and applies an XSLT to transform the file into an equivalent Storage Layer configuration. It uses this configuration and saves the result of the transformation to a file called cd_storage_conf.xml.transformed.

You can choose to continue using your old Content Broker file and having it transformed, or you can rename cd_storage_conf.xml.transformed to cd_storage_conf.xml, and use it instead. However, the Storage Layer configuration that the XSLT produces is by no means optimal, and it is recommended that you check and improve the transformed file yourself. Refer to the installation documentation for more information.

If you have created your own custom home storage classes for several Content Broker bindings, SDL Tridion 2011 will be able to upgrade them only if they implement one of the following home storage bindings (the strings you see are the values of the Name attribute in the Binding element in your Content Broker configuration):

Page Binary ComponentPresentation PageMeta BinaryMeta ComponentPresentationMeta In the event that your Content Broker configuration file contains customizations that the XSLT does not transform correctly, there are several ways to upgrade your configuration:

Reimplement your customization using the Storage Layer framework. Refer to the installation documentation for more information. Change the XSLT. For your convenience, SDL Tridion 2011 also ships with a separate .xsl file that contains the XSLT being applied. This file is called cd_storage_conf.xsl and is located on the installation media in the folder Content Delivery\resources\xslt. If you want, you can try and modify this file to transform your customizations properly. For more information about the Storage Layer configuration, refer to the installation documentation. Extend the Storage Layer. Refer to the Content Delivery implementation topics for details. Present your scenario to the SDL Tridion community in SDL Tridion World (http://www.sdltridionworld.com). Contact SDL Tridion Customer Support.