3

To add information in case publishing we can use TBBs. How can I add extra information in case of unpublishing. My scenario is as given below:

Consumers are caching the processed content from content delivery so whenever any new publish / unpublish is done then notification needs to be sent to consumer to clear their cache. I am using deployer extension to send cache clear notification.

The additional information required by consumer is: component name if component is published and page name if page is published. I was able to get this easily in case of publish, by parsing the package in deployer extension. However, in case of unpublish I don't have information of page name or component name available in the package and only item tcm id is available in the package.

How can I add this information to the package so that deployer extension can parse the information and get it?

  • 2
    Have you considered using Tridion's built-in cache-management features? – Dominic Cronin May 8 '15 at 7:58
4

Firstly, using page/component name for cache invalidation is not a very solid approach, as this is not guaranteed to be unique so you will most likely get some undesired results should different editors create pages or components with the same name. You are better off using the tcm ids, or the URL/path of the published asset as these will be unique.

Secondly, a better architecture for cache invalidation is to use a storage extension (see this article or the SI4T project for solid examples). The main advantage of storage extensions over deployer extensions for this scenario is that you have a lot more information about the items being undeployed, including being able to track binary removal (which is not possible in a deployer extension) and knowing the URL/path of the removed item.

  • The scenario in our case demands name based caching in addition to tcm id based caching, in order to perform reverse lookup. i.e. getting tcm id from name so that consumer can query the components by name and cache will have name to tcm id mapping. We are making sure that name is unique so that we don't have issues with that. About storage extension: we don't need any other information other than item title in case of unpublish so I am not sure if I will get that information in storage extension. I will check on it and update. – Hiren Kaku May 8 '15 at 6:23
  • Why dont you update your cache implementation to allow storage/flushing by tcm id and query by name - if thats really the requirement? At least then your query by name will just return multiple elements should you have name clashes, rather than causing bizarre side effects – Will Price May 8 '15 at 13:37
  • Thanks a lot for your input, I again went over the issues in case I use name resolution and those are more so I am rethinking my strategy for cache. – Hiren Kaku May 8 '15 at 17:50
2

TBBs are not executed when unpublishing. A simple unpublish instruction is sent to the deployer and that takes care of any known dependencies that can be removed from the delivery system. This is why Will (correctly, in my opinion) suggests using a storage extension. I would consider revising your caching strategy accordingly.

1

Is this something you are looking for ?

http://blog.trivident.com/2012/09/jms-the-nitty-gritty/

http://blog.trivident.com/2012/09/tridion-and-jms-removing-another-spof/

Its not recommend like mentioned by Will to use cacheing with names, names can be changed by editors and are then stuck in memory. Would recommend you to use only tcms.

  • This is not about cache invalidation for odata where we can leverage JMS for spof. This is about sending message to consumers other than odata. – Hiren Kaku May 8 '15 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.