# Lifecycle Management

## Key Features

### Procedures

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.

### Transition steps

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.

### Initial Progress Indicator

| 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.

###
States

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.

### Filter for specific Phase

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.

### Parallel review tasks

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:

- Mechanical testing
- Electrical testing

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.

### Userexits in the Lifecycle Management module

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.

- Pre-action userexits are executed before the status of a record is altered.
- Post-action userexits are executed after the status of a record has been altered.

| Please take note of the difference between userexits with a "xedbusr_" prefix compared to those with the "xedbstr_" prefix. Userexits with names starting with xedbusr_ are suitable for review procedures of entities (e.g. for the lifecycle management of items or documents). Userexits with names starting with xedbstr_ are suitable for review procedures of relationships (e.g. for the lifecycle management of bills of material).

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)

- This userexit defines the access rights of the parent entity (e.g. EDB-ARTICLE) of the referenced child element (e.g. parent element = construction kit head, child elements = contents of construction kit). Parameters referencing the relationship table to be applied on the child elements must be defined if this userexit is to be applied to customized entities.
- /TAB_REF optional parameter that defines the location of a relationship table.
- =T_MASTER_STR Name of the relationship table. The access rights of referenced records that are managed by this table are defined by the userexit according to the definitions in the parent record of the main entity(T_MASTER_DAT).

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.

#### Parallel review tasks

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.

### Change Management

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:

- Flag for the state "Approved"

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.

- System Flag

The System Flag indicates that a transition can only be performed by the system and not by an individual user.

- For Change Management Flag:

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