Blocking of Entities (Block List)

With this function you can prevent that entities are changed that must not be changed due to application specific reasons. For example, in MDG for Supplier changes to certain types of business partner relationships must be prevented, if a particular business partner relationship has been changed.

With the MDG application framework you can block entities to ensure that these entities are not added to change requests. Application specific reasons need to be implemented with an access class using the methods GET_BLOCKLIST_FOR_READ and GET_BLOCKLIST_FOR_WRITE of the interface IF_USMD_PP_ACCESS. The system checks, if application specific reasons exist, whenever an entity is added to the object list of a change request.

Note Note

Because the blocking reason is provided by the access class, only entities with a reuse active area can be blocked or can be used to create blocks for other entities.

End of the note.

This function covers the following use cases that have been implemented in the example access class for the flight data model.

External Reason
The entity is blocked independent of whether any other entity is being processed with a change request, in particular independent of any entry in the block list. In this case the access class throws the exception CX_USMD_PP_BLOCKLIST. Optionally a message can be added to inform the user of the reason for the block. In the flight data model example the airline BA is always blocked this way and an application specific message is raised. All flight connections for airlines X6 and X61 are blocked this way as well.

If the access class does not provide an application specific message, MDGAF adds a generic message. This case is covered with the block of airline CX.
Same Entity Type (Symmetric)
The processing of an entity blocks the processing of another entity and vice-versa. In the flight example the processing of airline CO blocks airline DL, as well as processing of airline DL blocks airline CO.
Same Entity Type (Asymmetric)
The processing of one entity blocks another, but not vice-versa. CX blocks DL, but DL does not block CX. In conjunction with the previous use case, this means that DL could be blocked twice: Once from CO and once from CX.
Other Entity Type
Processing of one entity blocks entities of another type. CARR -> PFLI: Processing of CO blocks all flight connections of CO, CX blocks all flight connections of CO with a number starting with 5 (block list entry), DL blocks flight connections 1111 and 2222 of DL PFLI->CARR, processing of flight connections of CO blocks airline CO.

The following table provides an overview of the blocking use cases implemented in the data model SF:

Reason for Block	Blocked Entity	Comment
External reason	BA	Use case 1: Block with application specific message
External reason	BX	Use case 1: Block with generic message created from the application framework
External reason	Flight connections of airlines X5 and X61	Use case 1: Block with generic message created from the application framework
CO is in change request	DL	Use case 2
DL is in change request	CO	Use case 2
CX is in change request	DL	Use case 3
CO	All flight connections of CO	Use case 4
CX	All flight connections of CO with a number starting with 5	Use case 4
DL	DL flight connections 1111 and 2222	Use case 4
Any flight connection of CO	Airline CO	Use case 4

For more information about the example access class for the flight data model, see the documentation of the access class CL_MDG_FS_SFLIGHT_ACCESS of the data model SF.

Integration

Technical Implementation

Before an entity type is added to a change request, the method GET_BLOCKLIST_FOR_READ is called. If the processing of an entity must be prevented regardless of the processing of any other entity, the access class CL_MDG_FS_SFLIGHT_ACCESS provides the exception CX_USMD_PP_BLOCKLIST. Optionally a message can be added (see use case 1). If the blocking depends on the processing of other entities, block values are returned. The framework checks a table of block list values, whether this entry exists. Only if the entry is not in the table adding the entity to the change request is possible.
After an entity is added to a change request, the method GET_BLOCKLIST_FOR_WRITE is called. The access class provides block values that are added to the table of block values and are considered when determining blocks the next time an entity should be added to a change request.

For more information, see the documentation of the interface IF_USMD_PP_BLOCKLIST.

Activities

When Can Blocked Entities Be Processed?

Finalizing Change Requests Removes its Blocks
After a change request is finalized that caused entries in the block list, the application framework removes these entries from the block list. Then the respective blocks no longer exist. Previously blocked entities can now be processed again.
Using the Blocking Change Request to Process an Entity
It is possible to process a blocked entity using the blocking change request. Example: You created a change request to process multiple airlines and added airline CO to this change request. This causes a block for airline DL and airline DL cannot be added to another change request. However, you can add airline DL to the same change request with which airline CO is processed.
Blocking an Entity with More than One Change Request
If an entity is blocked by more than one change request it is not possible to process the entity with any of the blocking change requests. Example: You process airline CO in a change request, which creates a block for airline DL. At the same time you process airline CX in another change request, which causes a block for airline DL as well. Now it is not possible to process airline DL with any change request until one of the two change requests is finalized.
Blocking an Entity with an External Reason
If an entity is blocked due to an external reason, then it is not possible to process the entity in any change request until the block is removed.
Processing an Entity in an Existing Change Requests Despite of New Blocks
Existing change requests can still be processed despite of new blocks. Example: You created a change request CR_A for airline DL. Now a second change request CR_B is created for airline CO, which causes a block for airline DL. Still the change request CR_A for DL can be processed. Note that this case can only occur, if blocks are created asymmetrically like in use case 3.