4

We have a requirement that on a page publish, we need to:

  1. Find a component presentation that has a component based upon a particular schema.
  2. Extract certain field vales from that component and store them in a custom database table that's available to our .NET application (on the Content Delivery side).

I think this is a good candidate for either a Deployer extension or a Storage extension - but I'm a little unclear which and why having never written either?

I've ruled out the Event System as this kind of code would be located on the CM, which seems like the wrong "side" to me - my focus is on extending what happens on the CD-side after a page is published.

Read a few articles on Tridion World (this, this, this and this) and I think a storage extension would be the better choice?

Mihai's article seems to be very close to what we need, where he uses a new item type mapping:

<ItemTypes defaultStorageId="brokerdb" cached="true">
    <Item typeMapping="PublishAction" cached="false" storageId="searchdb" /></ItemTypes>

But how does Tridion "know" to use this new item type when content is published, (its not one of the defined TYPE_NAMEs, which is kind of the point)?

I should clarify I'm a .NET/C# dev not a Java dev so this is probably really obvious to Java people - apologies if it is!

Cheers

Neil
  • 2,688
  • 1
  • 23
  • 32

1 Answers1

5

Tridion will not know by default how to deploy your new entity. My advise is to create a Deployer Module (your links should give you enough information about how you can do that) that executes in post-processing phase (of the deployment process), that processes all components from the deployment/transport package, extracts the needed information and uses a custom Storage Extension to store the needed information.

Be careful: you need to set-up in config your new type but you also need to use it yourself from that Deployer Module.

Hope this helps.

Daniel Neagu
  • 1,711
  • 11
  • 13
  • Thanks Daniel - so I'd need both extensions then - one to process the component and set the type (deployer ext) and one to handle persisting the new type in my custom db (storage ext) - is that right? Seems that Mihai's article is missing the deployr ext. explanation, unless I've misunderstoo? – Neil Feb 05 '13 at 12:56
  • 1
    I might be wrong, but isn't the "bundle" in cd_storage_conf that tells Tridion there's more to this storage layer than "just" the defaults? You don't need a deployer extension to extend the JPA level (otherwise it would never work on a website, only on deployers). The deployer extension is an easier extension point in my view. – Nuno Linhares Feb 05 '13 at 13:47
  • Hi Neil. You're totally right, Mihai's article ("Extending Content Delivery Storage in SDL Tridion 2011") is missing the Deployer extension but Jaime's article does not (Deployer Extensions with Eclipse - Step 5: Implementing your Custom Module Class). Check "http://www.sdltridionworld.com/articles/sdltridion2011/tutorials/Deployer_Extensions_With_Eclipse_5.aspx" for more details. – Daniel Neagu Feb 05 '13 at 13:50
  • 1
    @NunoLinhares: you're right, the "bundle" only instructs Tridion about the new types but Neil mentioned that he would like to extract some information from each component and add it to a DB. The Tridion way would be to transform that custom information into an entity, create the Storage extension but also to create the Deployer Extension. To summarize: first the Deployer Extension should be built and then the storage one to actually do something with the extra data. Keep in mind that the second part is indeed optional but if I were you I would want to keep consistent with what Tridion is doing – Daniel Neagu Feb 05 '13 at 13:56