Models are the high level building block of a system, these represent the process paths through multiple stages that you wish your data to be processed, or may contain the structure of a website etc..
Data may pass through multiple paths in parallel, models may contain multiple processes, and a given business process may utilise multiple other models.
An example model can be as simple or as complex as you require, however a good rule of thumb is that a knowledge engineer should be able to understand what a single model does. When a model gets too complex for a person to understand, that's a good indication that it perhaps should be broken down into further sub-models.
Sub models are also good for iterating through a set of processing.
Although we did consider the existing standards of Business Process Modelling (BPM), and Business Process Execution Language (BPEL) while designing the system, we found these to be over restrictive for our aims, therefore although there are some similarities, Rulevolution does not stick to these principles, never the less we believe the system is intuitive to use, quick to learn, and very quick to adapt, thus allowing the system to be continually adapted to meet your business needs
Each model is made up of smaller sub-nodes, some of which may action calls to external systems, store or retrieve data from stores (databases included) or manipulate data by way of rules.
There are three different types of Models:
- Diagrams
- Process (the most common)
- Web Sites
¶ Note also:
- Models can be grouped (within a project) into categories, the category is defined when the model is created.
- Multiple different model types may exists within a project/category.
- Models can be renamed (use the model rename to move its category as well).
- A model name should be unique within the project.
- If a model is renamed (in the current version) any reference to that model (e.g. via an Invoke Model action) will need to be manually changed as well. (Auto renaming references is a development roadmap item)