1

Context: We capture each publish transaction details in a custom db which has details of the transaction being published like: item being published, who published it, which version of the item is published, when it was published, publication target etc. We have created a GUI extension to enable this information for the user on item selection.
We have a fully scaled up architecture where we have separate CM, Publisher and deployer servers.

Need: I am looking to augment this information with the transaction state as well for each transaction

Question: Is there any option available at the transport layer on the publisher to capture the transaction state like whether the transaction was successful or not? The publisher definitely knows the state of the transaction since I can see that in tcm publisher logs, but not sure how to intercept the information and capture it at the transport layer.
I know of other options of capturing the state at the deployer extension post transaction commit or in the event system but I am looking to capture the same at the transport/publisher layer since I am capturing rest of the details at the transport layer. Please let me know

Improve this question
5
  • 1
    What do you mean by "capturing publish state"? You can query the state of a specific publish transaction via the TOM.Net API or the CoreService API. I would expect something that tracks the state of a publish transaction to run as a background service updating the state in your custom DB whenever the state changes (until it reaches an end state). I don't understand why you would want to do this in the transport layer as this is not a feature of the transport subsystem...
    – Bjørn van Dommelen
    Apr 16, 2015 at 13:21
  • I want to capture whether the "publish transaction state" is successful or not. I have mentioned in the question, that I am capturing other information at the transport layer hence I am looking to capture the same at the transport layer
    – Vipin Kothari
    Apr 16, 2015 at 15:02
  • 1
    The success state will be explicitly communicated back through the transport channel but the failure state will not; in essence the permanent absence of a success state constitutes the failure state (hence the polling of the deployment result by the transport service). Because of this I suggested querying for the status in a certain interval. Note that as Tridion already does this this is in essence a duplication of existing functionality. You could hook the "SetPublishStateEventArgs" event types in the event system which signal the end state of a publish transaction...
    – Bjørn van Dommelen
    Apr 16, 2015 at 15:18
  • @bjorn, your last two comments are great answers IMO. You got my +1 if you move them to an A.
    – Nickoli Roussakov
    Apr 16, 2015 at 15:23
  • @BjørnvanDommelen - If tranport layer is not getting the information for failure then how does it update the information in publish transaction table where if publish is failed then immediately information is updated.
    – Hiren Kaku
    Apr 17, 2015 at 5:42

1 Answer 1

Reset to default
1

The transport service periodically polls the deployer for a deployment result ( The number of times and interval period can be configured in cd_transport_conf.xml).

When it polls one of three things will happen:

  • When the transport service finds a deployment result it updates the status of the publish transaction to the state corresponding with the deployment result.
  • When the transport service does not find a deployment result it sleeps for the configured interval period and retries.
  • When the retry count has been exceeded the transport service updates the publish transaction to the failed state.

If you want to bolt-on your own code to be executed as part of the transport service you will have to create a custom transport connector (this is a java class that implements com.tridion.transport.connection.TransportConnector). See the documentation on docs.sdl.com.

Note that in-the-wild implementations of custom transport connectors are quite rare and as such I wouldn't consider this a safe extension point (that is; it could very well break in the upgrade to 2015).

The method to overwrite would be 

TransportConnector.retrieveFileIfPresent

You will have to parse the file data as a byte array. As the data sent from CD to CM is not part of the public API SDL reserves the right to change the format of said data at any future point in time (for example through a hotfix).

It would be really helpful if you explained how you are currently extracting information at the transport layer (as to my knowledge and official SDL documentation) custom transport connectors are the only supported extension point at this level.

Improve this answer
1
  • We extract the information at the transport layer/publisher by capturing the package using file watcher when the package is created with relevant xml files (for pages and components) and processing it for capturing relevant information. We copy the package to a different location, process it and remove the same. Hence, it does not impacts our publishing process. During publish we add the author information to the xml via the publishing templates so that is already available in the files.
    – Vipin Kothari
    Apr 21, 2015 at 16:44

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.