PlanetPress for life: My Web-based Process Launcher


Necessity is the mother of invention, as they say. I could add that repetitiveness is the mother of automation, and laziness its father. But I don’t want to start a battle of the sexes, so let me just say that repetitiveness and laziness are the parents of automation! The reality is that anytime I have to do the same task over and over again, I find myself wondering how this could be automated, whether I’m home or at work. I’m not talking about fun tasks, like playing guitar, or knowledge-intensive tasks, like design, diagnosis, assessment, etc. I’m talking about tasks like washing dishes, splitting or merging files, logging. But while some tasks may be fully automated, like an alarm clock which I don’t need to set up every day, some other tasks may benefit from more user control, like a job launcher web interface, where a user can view stacked jobs, select and perform actions on the jobs that he decides, at the moment he decides.

In this post, I explain how I’m using the PlanetPress HTTP Server to host a basic web-based process launcher. As it’s the case with the other posts I’ve made in this blog, the context is that I have PlanetPress installed at home (lucky me!). Of course, just as with the other cases I presented, business applications may be just down the corner.


The Problem

My friends and I play music. We usually record our stuff, which result in several files being created. We also take pictures, record movies, write lyrics, etc. After a few sessions, a lot of files may be created. I save those files in a temporary location and, when I have time, I go through each file, eliminating the bad ones and archiving the good ones or simply setting them up for an additional processing stage. Pictures, mp3, playlists and movie files need to be copied in my local drive in appropriate subfolders, but they also need to be uploaded to a file sharing system that our band uses, like an FTP site, Dropbox, etc. In addition, anytime I add files to our file sharing system, I need to warn band members by email so they know which file was added and when.

With that in mind, the idea of having a web manager to view files and launch an archival process with a mouse click is pretty appealing. What I would like to get is:

  1. A custom file management interface available from any computer in my local area network.
  2. More time to focus on the knowledge-intensive task of evaluating the quality of a file.
  3. No time wasted copying files around and writing emails about it.
  4. Ability to do all the archival-related tasks at the click of a button, at the time I decide.
  5. Tracking of all my actions.

The Opportunities

The PlanetPress HTTP/SOAP tools are pretty cool. They kind of went unnoticed when they were released a few years ago, eclipsed by more spectacular features like the PlanetPress PDF tools. But over the years, functionalities like the ability to process HTML Form data or to use Web Services proved to be incredible solution-enablers. Here are a few opportunities I’ve identified as part of a very useable solution.

PlanetPress can serve HTTP Resources

One useful feature of the PlanetPress HTTP Server is the ability to deliver static HTTP resources very fast, like a web server, although it’s not meant to replace a web server. By turning this functionality on in the PlanetPress workflow tool preferences, like shown in the left part of the picture below, I can place any file in a folder of my choice to make it available from within any web browser in my network.


PlanetPress can process HTTP form data

Creating web forms is easy. After a few minutes of searching and experimenting, you can build a very complex form with radio buttons, drop down lists, file upload, etc. On the other side, processing HTML Form data is a bit more obscure, as it may rely on different server-side technologies. PlanetPress makes HTML form data processing rather easy: an HTTP process starts whenever a request is made that refers to the HTTP Server input task’s action parameter. The process data file is an XML file containing all the HTML input form parameters, including paths to local copies of any uploaded files. Contrary to more classical processes, an HTTP process needs to create a response file that will be sent back to the HTTP client. This response is the job file at the end of the PlanetPress process.


HTML table sorting is easy with jQuery

If I am to work with an interface showing data in tabular form, then at least I expect to be able to sort the table based on any column. Fifteen years ago or so, I would have studied JavaScript and the Document Object Model, then tried to code a very basic table sorting script. It would have taken me a while just to come up with a barely usable, hard to maintain solution, that would probably have only worked in my Netscape Navigator only! But we’re in 2014, so I simply googled “Table sorter” and found what I was looking for in the first result that showed!


Thanks to Christian Bach and his cool tablesorter jQuery plugin (, I now can easily create a sortable table in HTML.

XML and XSL are awesome

The eXtensible Markup Language (XML) was first introduced around 1997 and had a huge impact on how data is represented as well as how it is displayed. Before XML, other markup languages did exist, HTML being the most prominent example. But it wasn’t a good idea (it still isn’t today) to store information as an HTML file, mainly because HTML mixes up information and how to represent it. XML, on the other hand, is purely about information.  Its counterpart, the eXtensible Stylesheet Language (XSL) is basically an XML file containing special tags and templates to transform an XML file into something else, like another XML file, an HTML file, a CSV, etc.


In the problem I am considering, the opportunity I see is that the contents of the table I want to display can be an XML file, while the way to display it can be described in an XSL file. This method makes it easy to modify the data (XML) without worrying about how its going to be displayed.

The Workflow

With all the opportunities I have identified, the work is almost done for me. Almost. A few processes need to be implemented.


A Startup Process to set things up

When the PlanetPress Services starts, I want it to create all the required files for the web application to work right away. These are XML, XSL, CSS and JavaScript files. Some of those files are downloaded as a zip package from the web and extracted to the proper folder, specified by a global variable (because it is used elsewhere). The process must execute only once, when services start. That is precisely what a startup process does.

HTTP Processes to handle browser actions

Thanks to the HTTP Server Input task, each HTTP Process (Refresh, Upload, Delete and Archive) is launched when the user clicks on a button or web link in the interface. Most of these processes are simple, such as the Refresh process which only updates the XML file and redirects the client to the original URL he was at when he clicked on Refresh.


The Upload process starts when the user clicks on the ‘Upload’ button in the web interface, after selecting a file he wants to upload. This process only saves the uploaded file to the folder whose contents is listed in the XML, then redirects the web client to the original XML (which is displayed nicely thanks to XSL).

The Archive and Delete processes are pretty similar. They both are triggered when the user clicks on an ‘archive’ or ‘delete’ link next to the file he wants to perform an action on. Clicking on an ‘archive’ link next to a file named ‘abc.txt’ for example, is equivalent to going to the URL http://myserver/archive?f=abc.txt. All in all, any action I would like to perform on a file could be implemented in the form of a web link that triggers a corresponding HTTP process doing the following:

  1. Capture the file name from the XML generated by the PlanetPress HTTP Server.
  2. Clean up the file name with Regular expressions and JavaScript (hey, we’re never too safe)
  3. Do what it has to do to the file (e.g. copy the file to another location to trigger an archival process)
  4. Update the XML listing (only if the process actually changes the contents of the table).
  5. Finally, I have made each process add one line to a log file that I can view at any moment, to keep track of actions that were performed.

Subprocesses to eliminate redundancy

When several processes do the same subset of tasks, it is very convenient to put them into a subprocess and have those regular processes call it instead of repeating the same actions. This makes the whole workflow much easier to maintain. Here are the subprocesses I have implemented:

  • Update XML : This subprocess simply updates the XML file. All of my subprocesses modify the contents of the table, so all of them use this subprocess.
  • Create redirect page : By calling this subprocess before they terminate, every HTTP process is just returning a simple redirect link to the web client, making sure that whatever action they choose to perform, they’ll always end up viewing the HTML table. Redirection is implemented with a page containing a single meta refresh tag. I should add that the use of this tag is discouraged by the W3C, but for the application I’m building, it’s really not a problem.
  • Clean up file name : A few subprocesses require an input parameter that may contain invalid characters (e.g. a file name containing a slash). This subprocess only cleans up the file name using a JavaScript. If subprocesses can be seen as functions, then this one requires an input parameter which is assumed to be a PlanetPress Workflow job information. All it does is to update the value of a job information.
  • Log : This subprocess only adds one line to a log.txt file, with information coming from the calling process.

The Fun

So in the end, I got what I wanted: a nice web interface that lets me upload, view, delete, or archive files. I also have a simple but nice logging system to keep track of actions performed on files.

Pushing the reasoning further, the workflow I have implemented can be easily upgraded by adding more actions that can be performed on each files, such as: print, email, upload to FTP, etc. Furthermore, in addition to web links, I could also implement custom HTTP form actions for each line, like the ability to select which printer I want to print to, or which recipients I want the file to be emailed to, etc.

This post took me more time to write than to actually implement the workflow. I hope it can give you some ideas for the PlanetPress HTTP Server. From a web-based job launcher, to a web-based data-entry system, once you know what it can do, the possibilities are endless.

If you would like to obtain a copy of the workflow, feel free to email