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

有帮助吗?

解决方案

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.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top