Calling Scripts Pre- and Post-Batch

By Deane Barker

Here’s a request for all software developers building software that does batch processing: PDFMoto, Movable Type – any program that “re-publishes” as a single event. Include functionality to allow me to call an arbitrary script before and after the batch process.

There are a lot of things I may want to do before or after batch, and if you let me run a script, I can extend your program in so many different ways. And I’ll give you bonus points if you “hand” that script information about what you just did in batch. (Note: when I say “call a script,” I essentially mean “run an arbitrary command from the command line.”)

When I was working with Documentum, they had a batch process called WebCache that rendered a bunch of Web pages and then copied them over to a Web server. It was very handy in that it let you define a script (BAT, VBS, SH, even a Java class) to be called before and after it ran (on both the source and target servers). When publishing to Windows Web servers, it was often used to shutdown the Web server before re-writing the Web site and start it again afterwards, so you didn’t have any file concurrency issues. This tool was incredibly flexible and you could do about anything with it.

A while ago, I explored the idea of running Invision Powerboard to handle commenting and discussion for a Movable Type-powered site. To do this, I would need to create a topic in Invision for each entry in Movable Type. If Movable Type would just let me run a script after publishing an entry, and hand that script the newly-created entry ID, this would be trivial.

What about people with remote hosts that don’t support MT? If you had this functionality, you could run MT locally and after every entry, MT could call an FTP script that would sync your local and remote directories (I know – you still wouldn’t have comments, but it’s better than nothing).

(I did find a hack around this, though, for post-batch processing. MT can be configured to ping certain URLs after publishing an entry, so you can set up a Web page at the other end of the ping that would do what you needed. See this post for an example.)

And for PDFMoto (read this first) – what if I wanted to dump my document library in a database? Well, if it would let me call a script and hand that script the path to the XML file it created, this would be no problem. The script could parse the XML and refresh the database.

From there, what else could you do? How about: find users on a mailing list, check the date they signed up, then send them a list of the latest documents added to the library. Powerful, no? There’s no limit.

This is simple functionality, and it would really cost developers nothing. Anything the scripts did is the end user’s problem, so to speak. In doing this, you will have given the users of your product a fantastic tool to integrate it further and further into their organization, and thus keep them buying your product into the future.

This is item #338 in a sequence of 357 items.

You can use your left/right arrow keys to navigate