How to import multiple XES event logs in a loop within a directory folder?

greg.vanhoudt

To scale up an experiment, I am writing a collection of plugins to automate and facilitate its execution. To that end, we aim to loop over multiple event logs performing the same steps automatically multiple times (calling Inductive Miner, conformance checks, etc.)

To that end, the plugin should not have any input parameters (besides perhaps the file path to the desired folder) and start working automatically on all XES files found in that folder. Can I then recycle the existing import plugins' code to achieve this? If so, which one is most suitable? I have found multiple import plugins on https://svn.win.tue.nl/trac/prom/wiki/ProM610/Plugins, but I am unsure what exactly the differences are.

hverbeek

Hi Greg,

If using batch/script files is OK with you, you can do this using any importer. Downside is that you will be using ProM without the GUI. Not all plugins may be available then.

On https://icpmconference.org/2020/process-discovery-contest/downloads/ you will find a couple of downloads, which include batch/script files to start several miners (discovery algorithm), like the Inductive Miner, or start a replay of a log on a model (classification algorithms). The batch file (like Discovery.bat) starts ProM in a command-line interface (CLI) mode, and then runs a JavaScript script. This is quite flexible, also because you do not need to compile the script. A plugin can be called from the script by using its name, in lower case, and with series of non-a-z0-9 characters replaced by a single '_', like the Inductive Miner ('Mine Petri net with Inductive Miner, with parameters') can be called using the 'method' mine_petri_net_with_inductive_miner_with_parameters. The obligatory first argument of the plugin (the PluginContext) should not be included when calling this method.

You can then use a batch file to iterate over all logs in a folder, and call the other batch file to discover a model, or replay a log on a model.

Kind regards,

Eric.

greg.vanhoudt

Hi Eric

Thanks for the speedy reply and for the resources you provided.
Quick follow-up: what if I want to batch files with plugins which are not available via CLI?

Thanks!
Greg

hverbeek

Hi Greg,

That would not work. If some plugin requires a 'UIPluginContext', it can not be called in the way I described from a CLI plugin context. The only workaround I know is to check the plugin sources whether it uses a method that requires no UIPluginContext (that is, either no plugin context or a generic PluginContext) and to directly call that method.

Do you have examples of such plugins?

Cheers,

Eric.

greg.vanhoudt

Hi Eric

An example of this would be "Mine Behavioral Patterns with COBPAM" from the package "BehavioralPatternMining".

Another one is "Search for Local Process Models" from "LocalProcessModelDiscovery". However, it seems there are also source functions only requiring a generic PluginContext. So this one could be rather easy to call from CLI?

Best regards
Greg

hverbeek

Hi Greg,

Yes, if they require the generic PluginContext, then they can be called from the CLI.

The "Mine Behavioral Patterns with COBPAM" indeed only has a variant that requires a UIPluginContext. However, its main method "miner.mine(context, log, param)" requires only a PluginContext. It is straightforward to reuse this source in the script. A thing to realize is that for the script you need to be explicit in the Java package names for classes: It will not recognize the class BehavioralPatternParameters, instead you need to use org.processmining.behavioralpatternmining.parameters.BehavioralPatternParameters. The following should work in a script:

miner = new org.processmining.behavioralpatternmining.algorithms.BehavioralPatternMiner();
params = new org.processmining.behavioralpatternmining.parameters.BehavioralPatternParameters();
params.setDiscovery(log);
bPSet = miner.min(context, log, params);

bPSet then contains the result of the 'plugin'.

The local process models plugin indeed has a variant that requires only a PluginContext. You can call this one directly from the script as described earlier. However, this variant takes the default parameters by default, If you want to run the plugin with different parameters, you need to call the underlying method directly from the script.

Cheers,

Eric.

greg.vanhoudt

Hi Eric

Thanks for all the information, this should at least get me going. If there are any other issues, I'll surely let you know on this forum

Kind regards
Greg