Is it possible to configure Tridion’s deployer to send one ItemType to multiple storage types?

Question

We’re looking to extend Tridion’s content storage layer with a new storage type to allow us to write some of our component presentations into a RavenDB repository. As part of this, we also want to continue storing all of those component presentations in our Broker Database.

Is it possible to configure Tridion’s deployer to send one ItemType to multiple storage types? The documentation and posts I have found on extending the storage layer (such as Julian Wrath’s post 'HowTo: Extending Content Broker Storage') do not seem to address this situation.

For instance, assuming valid definitions of defaultdb and defaultFile would the following result in published component presentations being sent to both storage types?

<Item typeMapping="ComponentPresentation" cached="false" storageId="defaultdb"/>
<Item typeMapping="ComponentPresentation" cached="false" storageId="defaultFile"/>

Answer 1

I do not think it is a valid configuration to have two of the same itemType mappings. So two Item elements with the same value in the typeMapping attribute like you suggested would not work.

Apart from using a deployer extension, you could implement your custom storage layer which calls the Tridion Broker database storage (by invoking the overridden Tridion DAOs) and then stores the data in RavenDB. You'll have to juggle with some DAOs like in this article and this post. I am not sure this is a route you want to take though. It is not an easy task and might a bit too much for what you want to achieve.

Answer 2

I think what you're after is a Deployer extension, not a storage extension. In your deployer extension you get access to the entire transaction package, so you can write your logic to process a given type a special way in addition to the OOTB way. Have a look at Jaime's tutorial on Deployer Extensions: http://sdltridionworld.com/articles/sdltridion2011/tutorials/Deployer_Extensions_With_Eclipse_1.aspx

Answer 3

I'd be interested to see what happens given your example - would there be an error or does the "last <Item> node win"?

I'm still feeling my way around deployer and storage extensions but based on the responses I got, I think you could use a Deployer Extension to process your specific Component Presentations (using what ever business logic you need) to set a new item type, then a Storage Extension to allow you explicitly handle this new item type.

<Item typeMapping="ComponentPresentation" cached="false" storageId="defaultdb"/>
<Item typeMapping="SpecialComponentPresentation" cached="false" storageId="defaultFile"/>

Extra work, but keeps things defined in the cd_storage file so its clear what's happening.

Answer 4

Another approach would be to publish to two separate deployers, and to configure each differently.

My favourite approach is to use ASP.NET web applications as upload servers. If you configure these with suitably populated lib and config directories in the bin directory, you can have the each one treat its content totally differently.

Of course, if you intend to consume the content via the Tridion storage layer, it might get a bit interesting, but I assume your use case is to have both Tridion and another system with different needs consume the content simultaneously.