# How to capture transport package?

We need to read the transport package(on publisher) when a page is published. The package is deleted immediately. Is there a way to retain the package for a longer duration? We have different servers for publisher and deployer. I want to retain the package on publisher side.

-
Why are you trying to do this? –  Dominic Cronin Apr 16 at 10:06
I need to capture information about every publish transaction made. –  user899 Apr 16 at 10:10
If you can share just a little more of your thinking, people might be able to help. Are you certain that capturing the package on the publisher is actually necessary? –  Dominic Cronin Apr 16 at 11:00
Capturing transport package details might be useful for things like performance monitoring and testing, though Tridion includes logs and a publishing queue for this. The use case matters because it'll help identify the supported approach for what you're trying to do. Any problems won't be found with what you build now, but if/when the transport package format, approach, or conventions change. –  Alvin Reyes Apr 17 at 5:32

Yes, modify your cd_deployer_conf.xml to have Cleanup="false" in the Queue Location configuration:

<Queue>
<Location Path="c:\tridion\incoming" WindowSize="20" Workers="10" Cleanup="false" Interval="2s"/>
</Queue>


Now restart the deployer and start publishing.

-
And remember to change it back again and clean up the directory once you've finished whatever you need to do... Many a system has unexpectedly stopped publishing in the past because of a lack of space issue due to someone making this change –  David Forster Apr 16 at 10:02
I need to capture the package on publisher side. Please let me know how to do that. –  user899 Apr 16 at 10:03
Check cd_transport_conf.xml on the CM side, I think there's a similar configuration in there. –  Nuno Linhares Apr 16 at 10:27

To capture information about every Publish Transaction made I think you need to check out the appropriate Event Handlers, they can indicate exactly when and what is rendered and published.

If I'm not mistaking the Transport Package itself is not part of the public API, which I why you will see there aren't many things documented about it. Rather than trying to use an internal implementation detail (the transport package), you can better look at a Storage Extension in case you are interested in what is exactly deployed. More info can be found in this article for one.

-
Our publisher and deployer are in two different domians. We have consdered this option but wehave firewall issues. hence we are trying to achieve this on publisher side. –  user899 Apr 16 at 10:23
@user899 For the event handlers it doesn't matter where the Publisher is located, as you have the event handlers available on the CMS and the Publisher server. If your issue is that you want to use the data you find in there on the Delivery side (where your Deployer is), then you should take a look at a Storage Extension. –  Bart Koopman Apr 16 at 10:26
I don't think I've seen any public APIs for the transport package itself either, just clever hacks and ways of physically transporting it. ;-) –  Alvin Reyes Apr 17 at 5:35

To achieve inspection of the transport package on the publisher side, I guess you could go down the route of implementing custom transport (login required), but it seems to me to be an unusual way to solve the problem of logging publish events.

An alternative, more common, solution might be to implement an Event handler that captures and logs publishing events.

-
A simpler way to do this is to create a destination which deploys to local file system. :) –  Raimond Apr 16 at 13:17
@Raimond Possibly, but I think you'd have to also create a local deployer service to pick up those packages and report success, otherwise all your publish jobs would report failure, right? I'd still prefer an Event System –  David Forster Apr 16 at 14:07
That's not needed. The transport package will just be dropped on the file system. :) –  Raimond Apr 16 at 14:21
@Raimond Yes, the transport package will be dropped to disc and can be inspected, but without a deployer to process it I think the Publisher/Transport service would keep polling for a status update and eventually fail the job. It's my understanding that the OP is looking for a way of programmatically inspecting the data without interfering with the existing deployment process –  David Forster Apr 16 at 15:06
Ah yes, of course! –  Raimond Apr 16 at 15:09