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.
4
-
Why are you trying to do this?– Dominic CroninCommented Apr 16, 2014 at 10:06
-
I need to capture information about every publish transaction made.– user899Commented Apr 16, 2014 at 10:10
-
2If 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 CroninCommented Apr 16, 2014 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 ReyesCommented Apr 17, 2014 at 5:32
Add a comment
|
5 Answers
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.
answered Apr 16, 2014 at 9:55
-
2And 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 Commented Apr 16, 2014 at 10:02
-
I need to capture the package on publisher side. Please let me know how to do that.– user899Commented Apr 16, 2014 at 10:03
-
Check cd_transport_conf.xml on the CM side, I think there's a similar configuration in there.– Nuno Linhares ♦Commented Apr 16, 2014 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.
answered Apr 16, 2014 at 10:21
-
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.– user899Commented Apr 16, 2014 at 10:23
-
1@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. Commented Apr 16, 2014 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. ;-) Commented Apr 17, 2014 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.
answered Apr 16, 2014 at 10:26
-
1A simpler way to do this is to create a destination which deploys to local file system. :)– RaimondCommented Apr 16, 2014 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 Commented Apr 16, 2014 at 14:07
-
1That's not needed. The transport package will just be dropped on the file system. :)– RaimondCommented Apr 16, 2014 at 14:21
-
1@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 Commented Apr 16, 2014 at 15:06
-
1
Seeing that no answer was ever marked as accepted I thought I'd resurect this and try and help anyone else with the same problem. In my case the publisher packages weren't being deleted and therefore filling up the server, so my scenario appears to be exactly what the OP is after.
In our environment we run the transport service under a different account and I’ve discovered now that this account didn't have the required permissions to delete the package files from the Root Storage Folder once a publish completed. After I gave the account the necessary permissions the packages were automatically cleaned up as they're supposed to be.
Therefore I'd suggest the solution to the OPs question is to either change the account the transport service runs under ensuring it doesn't have delete permissions to your configured Root Storage Folder or explicitly deny delete permissions to the default transport service account.
-
The consequences are the transport packages will be there without any cleanup and fill up the disk space. I would not recommend this option. Commented Sep 15, 2016 at 16:18
We had similar requirement where we wanted to capture the package so that we can store the details of items published into database. We did not wanted to use event system as it might add some time to the publish transaction.
The approach we used was:
- Created windows service with file watcher, which will continuously monitor the location of package creation
- as soon as package is created it will copy the package to other location so that even if package is deleted we still have a copy of it to work with.
- Extract the information required from the package and delete the package.
answered Sep 15, 2016 at 14:20
