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.
...
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.).
...
| Note |
|---|
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. |
...
Delete Processes/
...
Versions
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.
...
...
| Note |
|---|
If processes that have already been started in the productive environment are deleted, data inconsistencies occur |
...
With the help of sub-processes it is possible to link several processes. Linking processes or modeling process starts within a process creates dependencies between the processes, because from the time of linking, each overall process combination must be active and compatible as a whole.
Dependencies
Basically, when a process is activated, it is necessary that all processes called in it are also active and that the chain of active processes is consistent in itself. The construct of a chain, however, is basically not to be understood as an independent unit, but is always dynamically composed of the currently active process versions. This is due to the way SAP Business Workflow works, since only one active version can exist in the workflow environment. This means that versioning and activation of a sub-process can also affect processes that are already running.
Based on the above example, the versioning and activation of process B (new version 002) means that even running processes A start process B in the new version 002 after activation, provided that process B was not already started when version 001 was still active.
The knowledge about this behavior is especially important because it shows that processes may actually only be adjusted minimally, since the entire process chain cannot be activated consistently as such.
The activation of a new version of process A and B does indeed lead to new processes being started with version 002. However, processes already running in version 001 of process A always start process B in version 002 from this point on.
This means that used processes must always remain compatible with already activated uses. Special attention is paid to the object list that is transported between processes. If this list is restructured from the perspective of an overall process, this may lead to inconsistencies in processes that are already running.
If entire processes are to be completely restructured, it is recommended to define completely new processes instead of new process versions.
Activation
To ensure that the dependencies described above are adhered to, an automatic activation logic takes place. All processes involved are determined and the target versions are determined. It is ensured that no inconsistencies arise, e.g. by forcing a versioning of process A for the above mentioned case. New versions can be created directly and automatically during activation. Therefore, it is not necessary to manually version all involved processes before activation.
However, if versions have already been created, the user can decide which version should be used. If one assumes the above example, but the user would also have prepared a new version of process A, then this version would be recognized during activation and automatically suggested for activation. In the dialog, however, a new version can still be forced explicitly.
The entire activation process can reach a very high complexity, because each process version can have a different structure. Selecting a specific version can therefore lead to further processes being involved in the concatenation or to chains being broken up or decoupled. For this reason, after each selection of a different version, a complete re-determination of the dependencies is performed.
Once all versions have been determined, it is not yet certain that the constellation is completely correct in every case, since certain process versions may not be compatible with each other. This will be checked immediately after the confirmation of the changes and, if necessary, a complaint will be filed.
...
The following settings are maintained in the basic data:
- Start options and conditions
- Main Object and Status Management
- Various settings that can be inherited (e.g. priority)
Basically, a distinction is made between two types of conditions:
Start preconditions
The start preconditions are the prerequisites for starting a process. The process can only be started if all criteria are fulfilled. The start preconditions must be fulfilled regardless of the selected start options and are checked before each process start.
Autostart Conditions
The autostart conditions are only checked for automatically started processes. The autostart conditions are used to check the data changes that trigger the process. This inevitably means that a data change delta must be taken into account in the autostart conditions. This delta can be determined either completely using the autostart conditions or in combination with the start preconditions.
In order for such a delta to be determined, the objects provide different types of data (current data [including new unsaved data], current stored data from the database, delta between these data). This special data is described in the chapter Container.
Example
A process should be started when the laboratory is set to 100.
A simple variant is to query the source and target laboratories. The system checks whether the new laboratory is 100 and whether the old laboratory was not 100.
Alternatively, the condition shown above can also be checked using the special delta function, which returns the new value for changed values. If the value is unchanged, the value remains empty. By using the delta function, the laboratory 100 does not have to be noted twice and can be adjusted more easily.
Both conditions shown above are equally suitable, but there is a mixture of actual start conditions and the triggering event. In fact, the target laboratory 100 is the actual start precondition and the change of the laboratory is the autostart condition. Only if these conditions are divided correctly, a process could not be started automatically later (manually, by programming or by another process).
The ideal variant should therefore be such that the target laboratory is maintained as part of the start precondition and the data change as part of the autostart conditions. To avoid redundancy of laboratory 100, it is sufficient in this case to simply check whether the laboratory was changed at all in the autostart condition, that is, whether the value of the delta function is empty. The start precondition already ensures that the target laboratory is set to 100 (new) and the autostart condition only ensures that the laboratory has been changed.
...
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).
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.
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.
...
. |
...
The maintenance and function of appointments is described in chapter Sub Objects, section Dates.
...
The maintenance and functionality of the notifications is described in chapter Sub object, section Notifications.
...
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
...
- INITIATOR
...
User name of the initiator. Can be used e.g. for Members or Notifications.
...
- OBJECT
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.
...
- RUNTIME_STATUS
...
Current status at runtime
...
RESPONSIBLES
...
Responsible Person
...
- All
...
List of all process owners. Can be used, for example, for Members or Notifications.
...