The task of the lifecycle management is the description and centralized management of lifecycles. Lifecycles are combinations of transitions or transition steps representing the states a given element (associated to the lifecycle definition) can have, and how the states can be changed. A lifecycles may contain any number of branches. In fact, those branches may even form a network. Lifecycle management can be employed to map any kind of organizational procedure. The actual definition of a lifecycle is done by means of transition steps. In order to ensure the integrity of the database, some fields of the Lifecycle Management module cannot be edited.
The transition steps (transitions) are representations of organizational processes and are combined through their assignment to a procedure.
Individual organizational processes are represented using transition steps. The following example is a standard procedure for a review/release process as it would be mapped in Agile e6.
![]() |
In order to assign a state (e.g. 110 - In Work) to several phases, for each phase a unique number (indicator) for the progress indicator has to be created. |
![]() |
Review procedures must not be defined with decrementing IDs since the process indicator with the lowest ID is used as the initial value whenever an item is created. |
Example:
wrong |
|
right |
260 in work | 110 in work | |
240 in approval | 120 in approval | |
230 approved | 220 approved | |
220 released | 230 released | |
120 in change | 240 in change | |
110 withdrawn | 260 withdrawn |
![]() |
In the wrong example all new items would be defined as "withdrawn" rather than as "in work"! |
Configuration of transition steps
You can define that individual transition steps may only be performed by certain
users or user groups. Alternatively, the right to perform a transition may be
linked to a task.
![]() |
The default AXALANT-EXT-ROL is used for the activation and assignment
of individual users. This default setting is defined in the System configuration
-> Licences sub menu. You need to activate the EDB-ROL-ACTIVE parameter in the EDB-ROL section/group of the "Configuration" form (Other parameters). A second parameter is the EDB-CRM-TASK configuration parameter in the EDM-RCM section/group. This parameter is required if you are planning to use the transition steps of the release and change management. If this default is not set all transition must be executed using menu functions. |
You may picture organizational processes as groups of nodes (Progress Indicators)
and links between those nodes (transitions). In order to be able to define the
actual process you first need to define nodes (Progress Indicators).
Every node (Progress Indicators) is identified by a unique ID that can
be used to address the Progress Indicator.
On the object masks the term "state" will be used for the progress
indicator because the user usually thinks in terms of which "state"
an object currently has.
![]() |
It is recommended that the definition of progress indicators is done using a systematic state / phase matrix. |
When creating a new object, the initial state for the new object can be selected by the user. The possible states are part of the lifecycle definition attached to the object and they must be marked as initial states by assigning them as an "Initial" state to the lifecycle. The initial progress indicator can be defined for both insert and revision functions. Usually the lowest progress indicator is the initial value unless defined otherwise.
A filter can be defined for queries to only display objects which are in a
specific phase. This is similar to setting the view to "Global", "Production"
or "Development". The phases can be chosen from a selection menu in
the View mask and are provided in a form of a predefined list.
Some users may want to see only such objects which have reached a certain phase,
e.g. "Prototype". Objects which are in earlier phases - even if they
are released - may not matter to these users. The filter provides a convenient
way to limit the amount of displayed entries to those that are exclusively requested
by the user.
With the previous review / lifecycles only one subsequent state can be assigned when altering the state of an object. This subsequent state is selected from the list of transitions of the review procedure. The procedure is equivalent to a logical OR condition for the subsequent state. (For example an item may be "in progress" or "under review".)
Parallel review procedures allow for the assignment of multiple tasks to a single state change. In order to perform the alteration of a state, all assigned tasks must be carried out. For example an item may have to be tested by "electrical" and "mechanical" engineering before it can be transferred to the next state.
The following diagram illustrates the integration of parallel tasks within a review procedure:
The transition from state 120 (in approval) to state 220 (approved) comprises two parallel tasks:
Those two testing procedures make up a parallel block. Only after all tests in the parallel block are performed and completed, a transition from state 120 to 220 is possible. If the item fails a test or if a test cannot be performed, the object will remain in state 120 unless the state is reset manually to 110. The reset of a state automatically resets all performed tasks within the parallel block.
In order to integrate functions into a status change (transition), one or more userexits may be integrated into each transition definition. When defining a transition step, the userexits are entered in the "pre-action" and "post-action userexit" fields.
![]() |
Please take note of the difference between userexits with a "xedbusr_" prefix compared to those with the "xedbstr_" prefix.
|
For a number of userexits described in this document, additional parameters may be passed with the call (see the description of the corresponding userexit for information on this topic). Such parameters are specified in brackets following the name of the userexit. Example:
xedbusr_tor_set_acc(/TAB_REF=T_MASTER_STR)
Furthermore, LogiView decision tables or procedures can be used in the
customization process. LogiView procedures are used with the following
syntax: LogicModel/Name of the userexit ("parameter")
![]() |
The parameter in the LogiView procedure syntax is not necessarily required but presents an additional option! |
![]() |
For a detailed description of the userexits in the Lifecycle Management module please refer to the edbusr and edbstr files in the userexit documentation. |
The processing of userexits for parallel lifecycles is illustrated in the following diagram:
All post-action userexits are executed together after the last task of the parallel block has been completed. If an error occurs during the execution of a post-action userexit all post-action userexits will be reset. However, the pre-action userexits will remain unchanged.
The Release Management module can be applied with/without the Enhanced Change Management module. If both modules are set active, it is required to adjust the following settings for a proper functionality:
In the Change Management module an object has to pass the state "Approved"
before it can be released. According to this rule, a flag for "Approved"
was introduced to the Progress Indicator of the Release Management module.
It is possible to mark any state within a lifecycle to represent an "approved"
state.
![]() |
The configuration parameter EDB-CHG-CHK-APPROVED-STATE checks if an object that is to be released is in the state "220 - Approved". This check can be deactivated by setting the parameter to OFF. |
The System Flag indicates that a transition can only be performed by the system and not by an individual user.
For each transition within a lifecyle, it can be defined individually if this transition is visible if the Change Management is active, respectively the individual object (e.g. item or document) is controlled by the Change Management. The checkboxes in the Lifecycle mask may have the following values:
= no: Transitions are available for objects that are not controlled by the Change
Management
=
null: Transitions are available with/without Change Management
= yes: Transitions are only available if objects are controlled by the Change
Management
To ensure a proper functionality of the system the following settings for the System Flag and the Change Management Flag should be taken into account:
For Change Management Flag
|
||||
System Flag |
yes
|
no
|
null
|
|
yes
|
a & c
|
a & d
|
a
|
|
no
|
b & c
|
b & d
|
b
|
|
null
|
not a
|
not a
|
1 & 2
|
a) S = "y" is allowed for System only
b) S = "n" is allowed for all trigger calls
c) F = "y" is allowed for objects controlled by the change management
d) F = "n" is allowed for objects not controlled by the change management
1) A transition from "Released" to "Withdrawn" should be
a system transition for objects that are controlled by Change Management
2) A transition from "Released" to "Withdrawn" shall alternatively
be possible for objects that are not controlled by Change Management