A more straightforward way to approach this would be to capture the package name and size (and any other relevant attributes) on the Content Manager / Publisher server. As I am sure you are aware, after rendering, a Transport Package is created and temporarily written to the File System in the
WorkFolder prior to transport.
It would be very easy, using the .NET
FileSystemWatcher (FileSystemWatcher Class), to create a simple Command Line application or Windows Service to monitor the
WorkFolder for new transport packages and record their details to a text or Excel file. (Note that you will have to watch for both
Changed events (see here for a quick reference) as the file may not be completely written when
OnCreated is fired.) Such an application would have minimal overhead and should not interfere with the performance of the Content Manager / Publisher, and would be able to capture details of the transport packages before clean-up occurs.
Addressing the second part (switching on and off) a couple of thoughts come to mind:
- If it is set up as a Windows service, with the appropriate permissions, it can be controlled (
Restart) normally using standard Windows / server management tools.
- The application or service could expose a WCF endpoint that would accept authenticated commands from a Custom Page or GUI button in the Content Manager Explorer.
- Although rather unorthodox, it is possible to read the contents of Transport Packages (which are essentially ZIP files). Your application could look for a "special" Page or Component Presentation (or flag therein) and respond accordingly. Just make sure that your file reader is non-locking to avoid issues with the Transport Service trying to read the file for transport.