7

We would like to get rid of the Tridion Broker as part of a project and publish content directly to a repository as part of a Storage Extension.

My question is, is there any deep dependency that Tridion has on the Broker that might mean things work in a sub-optimal way, or gotchas that I should be aware of?

Update - We are going to be using Tridion purely as a content store which will push out JSON. There will be no functionality or any form of business logic/UI.

Improve this question
5
  • 1
    What's the thinking behind this? I think your main issue would be dynamic linking.
    – Rob Stevenson-Leggett
    Commented Jul 25, 2013 at 16:38
  • Client would like to use Elastic Search as the store rather than the broker and its associated services.
    – mpaton
    Commented Jul 25, 2013 at 17:29
  • file system is also broker, please edit your question.
    – Raj Kumar
    Commented Jul 25, 2013 at 17:57
  • 3
    Also should consider if the Tridion UI is desired, as it depends on the Session Preview, which depends on the Broker. I would suggest a hybrid approach - do all your heavy lifting with Elastic Search, covering 90% of things, and behind the scenes have the normal broker there for linking, but also with all other normal content. Could give you more flexibility in the future rather than an extreme no-broker solution.
    – robrtc
    Commented Jul 25, 2013 at 19:21
  • Consider including some form of the Tridion Object Model (and handling published status) as a "form of business logic," which you'll get "for free" if templated out to your JSON format. Mainly authors should still be able to create pages and the CPs on them.
    – Alvin Reyes
    Commented Jul 26, 2013 at 23:46

4 Answers 4

Reset to default
8

I will assume that what you mean with the Broker is the Tridion Broker database.

It is possible to publish everything to the file system, it includes, content, linking info, metadata and references, however this functionality is deprecated and will be removed in future releases, having said that, in future releases, linking, metadata and references will always be stored in the Tridion broker database.

If what you want is to override the storage layer and create a custom one, it will for sure affect key features like the Tridion CD API, Dynamic Linking and of course it won't be supported by either Customer Support or R&D.

Other key feature that depends on the Tridion Broker database is the Session Preview functionality.

Improve this answer
7
  1. Dynamic Linking is the big one as Rob mentions.
  2. any DCPs embedded on Pages will render UCs/Tags.
  3. Any code that queries CPs using Criteria/Query API will need to be gutted/replaced.
  4. If you use P&P, then any personalized content will be rendered and filtered via User Controls/Tags, and this will need replacing
  5. If you use UGC, same as #4.

When starting a fresh implementation Broker/no-Broker is a decision to be made, but once it's done and the site is live, you have a lot of work on your hands to get rid of the Broker.

Improve this answer
5

I would be vary wary of any approach that removes all Content Delivery functionality, or the ability to hook into it. Customers I have seen that take this approach due to whatever requirements, tend to become very dissatisfied in the long term. Usually they bought Tridion for the whole package of functionality, CM + CD.

Some typical issues are:

  1. Upgrading - if you build your own Content Delivery framework, this needs to be tested and updated before the client can upgrade their Tridion version. Maybe the people/organization that created the framework have moved on, and no-one knows how the heck it works any more anyway. I have even had customers who didnt even have the source code for their framework!
  2. New product features - Tridion releases a new version or module with feature X that is amazing. The sales guy does the hard sell, the customer MUST have it... but wait - it requires Content Delivery elements, which are not part of your framework

So think carefully before following this route. You can still publish JSON to Elastic Store with Tridion, but I would try to keep standard Tridion CD for as much as possible...

Improve this answer
4

This sounds like an unusual implementation.

It might be worth blueprinting your website to allow you to localize the templates to render the json. The new child publication could be used with a new deployer for you to test if this gives you the output you need without any missing functionality.

Improve this answer

Your Answer

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

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