The root object is the Process. Each process has a unique, freely selectable Process ID and a continuous version number beginning with 1, as well as a description.
Versioning makes it possible to change and extend processes at a later date without already running processes being affected. When saving, the modeling application checks whether the changes made result in a structural change to the process and automatically proposes the creation of a new process version.
UNBEKANNTER ANHANG
The determination of whether a new version is necessary is fully automatic. The structure of the modeled process is compared with the structure of the generated workflow template. This structure differs as soon as one of the following actions is performed:
Creating new objects (without tasks)
Deleting existing objects (without tasks)
Moving existing objects incl. changing the order of activities and gates
Changing a subprocess from serial to parallel and vice versa
Changing a gateway from exclusive to parallel and vice versa
Enabling or disabling a gateway Repetition
Activating or Deactivating the Multiplication of Activities
All other changes do not lead to a structural change and therefore do not require a new version (e.g. changes to processors, persons responsible, texts, notifications etc.).
It is possible to overwrite the current version. However, if processes already exist for the current version, such changes can lead to unexpected errors with data inconsistencies. Running processes may be irreparably damaged. |
Prozesse/Versionen löschen
Processes or versions that have already been used can no longer be deleted. However, this check only takes place on the current system, where there may be no data at all. The deletion is confirmed with the following popup, where you can also choose whether the entire process or only the current version is to be deleted.
UNBEKANNTER ANHANG
If processes that have already been started in the productive environment are deleted, data inconsistencies occur. |
Basic data
Object list
With the help of the object list one or more objects can be assigned to a process. The objects assigned to a process can be distributed within the process to perform object-specific tasks. At the level of the process, a global definition of all objects supported by the process takes place, while in the sub-objects the set of objects can be reduced to a precise subset of the objects.
The object list has no integrative character. The inclusion of an object in an object list neither leads to a configurable behavior of the respective object in the SAP standard, nor does it enable the direct execution of actions by ProProcess. The latter, however, is achieved by implementing concrete tasks, which can either be delivered by ProNovia or implemented by the customer.
The Process Designer basically defines which objects can be added to the object list of the process. The objects can be selected from a range of supported object types. Furthermore a restriction by means of formulas and the object data is possible (e.g. only documents of a certain document type).
UNBEKANNTER ANHANG
Basically, it should already be clear when defining the object list how the respective objects are to be used within the process. From this point of view, it makes sense to define several entries for the same object type, which may differ from each other in terms of name and conditions. This allows a much easier (and fully automatic) distribution of the objects in the further course of the process. For example: If two sub-processes are available in the process, in which only certain objects are relevant, then it makes sense to separate these relevancies into two definitions already at the process level.
The distribution of the objects to process sub-objects is basically carried out via these object list definitions, but can be additionally limited by filters on the additional data. This results in completely different possibilities, which are less object data- but more process data-oriented. It is conceivable, for example, that the distribution is mapped completely with the help of additional data by defining and maintaining special data for the process flow in the additional data.
For each definition it can be basically determined whether the number of objects should be limited, which can be particularly useful if only exactly one object of a certain object is to be managed in the object list. The initial status determines whether and how the object list can be edited when the process starts.
The order of the entries plays a central role in the automatic assignment of objects. If a new object is added at runtime, the system checks for the object in the sequence shown whether and to which definition the object can be assigned. Accordingly, it should also be ensured that the restrictions are "relaxed" with decreasing priority and not vice versa. For example: If two entries exist for an object type, one with and one without formula and the one without formula has the higher priority, then an object is always assigned to this definition and the other, restricted definition remains empty forever.
Object distribution
In order for the various objects in the process to be processed by corresponding tasks, they must be distributed. This distribution can basically be done completely manually. Especially with large object lists, however, it makes sense to automate the distribution as far as possible. This is possible by restricting the object list for each process sub-object already during process design. By default, the object list is inherited downwards within the hierarchy.
The automatic distribution is always based on the object list definitions of the process. For each process object the inherited definitions are displayed and can be selected explicitly. The selection of at least one entry deactivates the complete inheritance, so that only the explicitly selected definitions are inherited.
UNBEKANNTER ANHANG
As soon as a definition is explicitly selected, additional filters can be defined based on the additional data to further restrict the objects using the additional data. If the object list is not needed for activities, tasks or sub-processes, the object list should be deactivated for these objects or their parent object to reduce complexity.
In the best case, it is no longer necessary to manually adjust the distribution at runtime. However, manual processing can be very useful, especially when activities are multiplied and work packages are distributed to several locations. For this reason, when defining the distribution, special care must be taken to ensure that the object list is deactivated wherever it is not needed. |
Additional functions
The object distribution is designed to setup which are process objects are using which real objects already at design time. Some process objects needs additional settings based on the object list. These objects are enhancing the object list by additional columns. E.g. a object creation task does not need access to the objects of the object list but needs to know where to place the newly created objects.
UNBEKANNTER ANHANG
Person responsible
Process owners have special rights to make changes to running processes. Further information can be found in the user manual ofProProcess. The persons responsible for the process are determined (via existing formulas, if applicable) and saved at the start of the process.
The maintenance of the responsible persons is described in the chapter Members.
Date
The maintenance and function of appointments is described in chapter Sub Objects, section Dates.
Notifications
The maintenance and functionality of the notifications is described in chapter Sub object, section Notifications.
Container
The functionality of containers is described in the chapter Sub Objects, section Container
The most important containers and items are described below:
Container/Item | Description |
|---|---|
HEADER | Kopfdaten |
| User name of the initiator. Can be used e.g. for Members or Notifications. |
| Object reference to the main object. All properties (technical: attributes and methods) are provided within the object. Some data is available in all objects, but each object can provide additional data:
|
Delta data is only available for alphabetical data. However, due to the architecture, numeric values are also offered, but may not be used. | |
| Current status at runtime |
RESPONSIBLES | Responsible Person |
| List of all process owners. Can be used, for example, for Members or Notifications. |
If customer specific container extensions are set up, then the relevant container items can be choosen.
UNBEKANNTER ANHANG