2

We have a utility for monitoring directories and taking actions when files appear in those directories. It's in java and takes the form of a standalone jar which launches several threads when started:

  • One thread periodically (every minute or so) checks for new instructions regarding which directories to monitor.
  • Another set of threads periodically checks each of the directories being monitored. New files are placed in a notification queue.
  • Another set of threads service the notification queue and run actions for each new file.

Now, the powers that be want to reimplement this utility within JBPM. The main goal is to permit file arrival to start workflows within JBPM. Secondary goals are to make the process more highly available, and perhaps to simplify deployment by having it run inside Jboss rather than as a standalone utility.

I have past experience with WebSphere process server--IBM's BPM system--but JBPM is completely new to me. I'm struggling to see how to recreate this program as a set of JBPM processes, and it's not even clear to me that JBPM is the right tool for the low-level logic of reading directories and processing lists of files.

I could write a simple one-step business process that just calls into the entry point for the old monitor utility. With more work, I imagine I could decompose the old logic into a couple of different business processes calling each other. I have a hard time seeing the point, though. On a more practical level, the utility is supposed to start up automatically--without being called by anything--and I haven't been able to figure out how to do that for something deployed within jboss.

Should I be pushing back on this requirement to use JBPM? Or suck it up and get coding?

Martin Schröder
  • 354
  • 1
  • 4
  • 19
Kenster
  • 123
  • 7

1 Answers1

3

Certainly, jBPM may be overkill for the operations that you describe. However, you get a bunch of items for free (for some definition of free) when you use a modern business process management tool.

  1. Monitoring -- Every process can be monitored with neat visual indicators.
  2. Reporting -- Number of processes triggered, time to handle, delays in the system, etc.
  3. Graphical design of processes -- Adding a new process can often be done using the web tools in the graphical editor, especially if the primitives are to hand.

More importantly than that, to some extent the whole process becomes future-proof. Here are some of the things that might arise in the future;

  • Human interaction. Some files may have to be reviewed, signed off or redirected by one or more humans. The BPM environment handles human-tasks handing things off to computer-tasks quite readily. Also, the BPM structure allows notification of the humans who have work to do.
  • Multi-computer interaction. BPM isn't restricted to a single server; you can set up a number of co-operating servers that send each other messages.
  • Perhaps the most important aspect is that there is a fundamental evolution from file management to document management, and from task management to work flow management. BPM systems can help bridge this gap.
BobDalgleish
  • 4,644
  • 5
  • 18
  • 23