1

I'm using SDL Tridion 2013 SP1.

I want to make a REST call for each Page item that's being deployed with a few page metadata values. For that I'm thinking about three options:

  1. Creating a Storage Extension for the item type Page (JPAPageDAOImpl as the example page in Tridion online documentation) and inside make call to an external URL. My concern is if I can access page metadata in Storage Extension, if not, I'll need another approach.

  2. Creating a new Storage Type (which wouldn't be storing anything just making the REST call. In this way I can keep clean the storing of the page in the database and in the configuration file add the new storage type to make the REST call. Again, my concern is if I can access page metadata in Storage Extension, if not, I'll need another approach.

For this one (2)...Can I have something like this?

<Item typeMapping="Page" storageId="database" />
<Item typeMapping="Page" storageId="MyCustomStorageId" />

So, for each page call both of those Storages. And if so, Will the second one (MyCustomStorageId) being called after to commit was completed in the database (in the previous step)?

  1. Creating a Deployer Extension (instead of Storage Extension). This options is less atomic than the previous two, so probably not the best one, again, my concern is if I can access page metadata in Storage Extension, if not, I'll need to go this approach.

UPDATE

I can see in the create method of JPABaseDAO that the commit is being called in there, so if I inherit from JPABaseDAO and call super in create method, I can be sure that the transaction was already committed (or an exception will be thrown).

4
  • From your question, it is clear which 3 options you are thinking about, however the scenario which will be addressed with these 3 options is not clear. Can you please elaborate on the scenario that you are trying to work with?
    – Hiren Kaku
    Nov 24, 2016 at 18:55
  • I need to extract the meta data of the Page and call an external service sending those values, this external service might call the broker database according to those values, so the commit must be done in the broker database first, and then call the external service.
    – polonskyg
    Nov 25, 2016 at 12:57
  • The commit method in JPABaseDAO is called during the Commit process and not after the transaction is committed - which means if you write something in the Commit method and it fails, the transaction will fail and nothing get committed to Broker Nov 30, 2016 at 3:37
  • Thanks for your reply Pankaj, but one thing I'm not getting is that JPABaseDAO has a tx.commit in the create method (line 87). So. if a create override that method calling super, should I safely be in the "after commit to broker database" phase?
    – polonskyg
    Dec 5, 2016 at 14:36

1 Answer 1

0

Not sure what you wanted to do with the REST call after accessing the meta-data, but if you are not doing anything on the Storage Layer of CD (e.g. making something related to storage), I would recommend using the Deployer Extension.

Please note, Storage Extension is invoked in-transaction and if need to to retrieve anything post transaction commit; you wont be able to access that in Storage Extension.

However, the deployer extension, you can execute in pre-commit and post-commit phase.

One more issue with Storage Extension is that if you want to retrieve more details on the page like accessing the Components and Component Templates associated on the page, then it might not be possible but in Deployer Extension you.

Further, I am not very sure and tried this; but my understanding is that you can only access the Page Presentation with in the storage extension. I could not access the Components on the page and I am not sure about the Page Meta data but you can do a quick test.

On the other hand, if you need to access the meta-data, manipulate with it and store that somewhere or such that you need to interact with Storage Layers, then the advise is to use the Storage Extension.

5
  • I need to extract the meta data of the Page and call an external service sending those values, this external service might call the broker database according to those values,so the commit must be done in the broker database first, and then call the external service. What the external service will do exactly is not relevant to me. So, according to what you're saying if I create a Storage Extension, it will always be call during the transaction and not after the commit right? FYI, I'm only interested in meta data of the Page.
    – polonskyg
    Nov 25, 2016 at 13:01
  • Regarding why I want to do it as Storage Extension is that it seems to be more atomic, I can do it only for Page items...Not sure if I can do the same at Deployer level...
    – polonskyg
    Nov 25, 2016 at 13:12
  • I've added an update to the question regarding the transaction commit.
    – polonskyg
    Nov 25, 2016 at 14:22
  • Will post commit phase in deployer extension also make a commit to the Broker database? My guess is no because you can have a storage extension that might do something afterwards, but don't know for sure. (In 2013 SP1)
    – polonskyg
    Nov 29, 2016 at 12:27
  • You would have more control at deployer extension level.Regarding the Storage Extension, it will be called during the "Commit" phase - which means if there is any exception, the publishing will also failed. The deployer extension, you can call before the Commit phase or after the commit phase - any exception in your code, won't fail the publishing in case it is executed post commit The post commit in deployer extension will get invoked after the commit in Broker DB Nov 30, 2016 at 3:35

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.