4

It was my understanding that a Deployer Extension was not an officially supported extension point in Tridion and Storage Extension was the supported type which accommodated the same need to perform custom logic upon deployment. However, I have just checked the 2013 SP1 docs and see that they provide instructions on implementing custom deployer modules: http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-DA883F20-294E-4D96-BBDA-1EBDB1C42DBB

So if both are now supported, how do I decide which to use, i.e. in what sample scenarios do I use one over the other?

Improve this question

2 Answers 2

Reset to default
7

Nick the thumb rule is that if you are dealing with Storage of the item or rather Presentations then it makes sense that you should be doing it at the storage layer and hence use of Storage Extension makes more sense. For anything else during the Deployer process use the deployer extension.

Not the main difference: With Storage Extension you are dealing with the Deployer Process with in the same transaction whereas with the Deployer Extension you have two choice - Either you are dealing with the deployer process before the commit or after the commit of the deployer process but not with in the same transaction.

You may want to refer THIS blog post and a small section which may give some insight for your query.

BTW, as far as the SDL Support is concerned, the configuration, the extension point and the concept as such is fully supported and you will get all the help setting it up from the support; whatever is not supported is your custom code, setup and configuration

Improve this answer
2

I prefer deployer extensions for integrations with other systems (search engines for instance) because they give you access on the scope of a full publish actions, whereas i prefer storage extensions for integrations that need to interact with the the same database (such as a custom query table with derivate attributes).

Improve this answer
14
  • I do not agree with your suggestion for integration of search engine as doing it at the Deployer Extension might not give the much needed control that you may get in Storage Extension, plus it would be more effective to do at the storage level by using storage extension. Yes it may have been done at multiple places but the main reason may be the legacy that is coming behind - as prior to 2011 there is only one option - deployer extension
    – Pankaj Gaur
    Jul 9, 2014 at 11:42
  • You may want to refer this discussion here: tridion.stackexchange.com/questions/688/…
    – Pankaj Gaur
    Jul 9, 2014 at 11:50
  • 2
    Maybe you both prefer what you know. ;) All things you guys mention is possible in both systems. The crucial difference is that SEs happen inside a JPA transaction, whereas DEs are just Tridion's own transport package handlers (and subsequent file parse code), running on the outside scope of the SE layer. I like SEs because they follow the more modern Java conventions and are a bit more maintainable if you do complex stuff, while for DEs, some methods that you have to use have set as deprecated for a while.
    – Raimond
    Jul 9, 2014 at 16:26
  • 1
    Implementing a storage extension ensures you get notified when a binary is removed from storage. There is no explicit unpublish action for implicitly published binaries, so deployer extensions don't get the needed notification. See this article for a full description: sdltridionworld.com/community/2011_extensions/…
    – Frank van Puffelen
    Jul 9, 2014 at 17:26
  • 1
    Would it be to much to ask for SDL to make a clear statement in the docs why and when to use SE over DE?
    – Neil
    Jul 9, 2014 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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