Log Generation - GabrielSiq/LogGenerator GitHub Wiki
Intro
This is a quick tutorial for producing logs using this log generator. For details on the modeling, project structure and functionality, refer to project report.
Setup
In order to use this log generator there is very little setup needed. This repository includes sample input files that define a set of processes for simulation. Those do not use all of the parameters and features of this tool, but showcase a common usage scenario. After reading the next section, I recommend going through the sample input files to get familiarized with the syntax.
This tool was developed using Python 3.7. The necessary dependencies can be found on the requirements.txt
file. Simply install them in your Python environment using your preferred package manager. For pip
, $ pip install -r requirements.txt
. The tool should be able to run in that environment.
Input
The first step in generating process logs is defining the simulation environment and processes involved. These are contained in 7 definition modules, which the user must supply. For syntax, refer to sample input files.
activities.xml
: Global list of activities utilized by all processes. Every activity used in any process must be specified here first before being referenced anywhere else. This file contains the default parameters for each activity. Those can be overwritten when defining a process model for speed of development.
resources.xml
: List of resource types and quantities, available in the simulation environment. These will be shared among all running process instances. The available quantities of each resource can be overwritten when executing simulations, as explained in the next section. The purpose of this feature is to allow for more easily simulating a specific scenario over several resource configurations.
data.xml
: Definitions of all data objects utilized by processes in the simulation. Currently, the only supported format is form
, which contains a name and a collection of fields, that hold data. A simple example can be found in the sample file. When defining the fields of a form, those can contain default values - to be read and modified during the simulation - or be initially empty. The sample file contains one empty field named "Class".
models.xml
: List of process models utilized in the simulation. References previous definitions. Here, activities from the master list can be referenced and have some of their parameters modified. Refer to input file for syntax and report for modeling.
data.py
: Definitions for all routines used by activities to process and modify data objects. Each function's name should match the ID of the activity it refers to. It should expect one parameter, input
, which is a dictionary containing all forms/fields this activity expects to read. It should return a dictionary containing the updated form/fields which the activity is expected to write. For it to properly function, we rely on three assumptions:
- The expected forms/fields have been properly defined in the
data.xml
file. - The expected forms/fields have been appropriately referenced in the master list of activities.
- The function defined in
data.py
is an exact match to the activity ID - it only reads and writes what is defined inactivities.xml
.
rules.py
: Definition for all routines used by gateways to determine execution flow based on data objects. Similar to data.py
. Each function's name should match the ID of the gateway it refers to. It should expect one parameters, input
, containing all forms/fields tied to this process instance (not just one specific activity). It should return the ID of the gateway (defined in models.xml
) through which the execution is determined to proceed. See sample file for example.
config.py
: Additional simulation-level configuration, such as input and output path, or length of simulation.
Execution
The most basic use case for the tool is very simple. After defining all files from the previous section, simply import the SimulationManager
class, instantiate it with the desired start and end dates for the simulation, and run the simulate
function.
from datetime import datetime, timedelta
from simulation_manager import SimulationManager
sm = SimulationManager(start = datetime.now(), end = datetime.now() + timedelta(days=3))
sm.simulate()
The log will be found in the output folder specified in the config file. Alternatively, you can specify a file name when simualting.
sm.simulate(name='simulation01')
Lastly, you can also overwrite the quantities of available resources through the simulate function in order to quickly simulate multiple scenarios. To do that, use the resource_limit parameter. It should receive a dictionary with the ID of each resource and the desired quantity.
sm.simulate(resource_limit={'support' : 150, 'trust': 40})