How to Remove Obsolete Entity Members

Center of Excellence
Center of Excellence Employee
500 Likes 10 Comments First Anniversary Name Dropper
edited April 2023 in How-To Guides

1088x612_Article_Cover_How-to-Guide (2).png

1.   Abstract

Are you allowed to delete Entity items? What should you consider when deleting an Entity? There are different options to make deletions, like Entity extract or reload, or assigning to a dedicated dummy parent. It’s important to understand the best way to do it since both solutions have different effects.

2.   Context

There may be a point during a Board application lifetime when you realize some Entity items that got loaded in the past need to be cleaned out because they’re obsolete, especially for items that often increase in quantity. You want to prevent continuing to add to max item numbers and to keep the list as clean as possible.

3.   Content

Every Entity member is made of 3 attributes:

  1. Code
  2. Description
  3. Internal IDx

The internal IDx is an incremental ID generated when adding elements to the Entity following the loading order (it is possible to visualize the loading order of the entities items by sorting by ‘none’), This IDx is extremely important because every selection, either defined in Screen or procedure, is storing the internal IDx of selected items, not codes, even if we see them from front end.

Here below we describe 3 methods to remove obsolete Entity members from the application which can be applied depending on the specific case.

 3.1 Manual delete

In case you reach the Max item Number you might be tempted to manually delete unwanted elements from an Entity. This can be done, but it is important to consider the potential consequences this action might have especially in case of a subsequent extract/clear/reload of that Entity.

Deleting members can have different effects with severe consequences on the accuracy of your reporting and/or procedures:

  • All the values of this member stored in Cubes will be removed (if Cube versions exist, could be not aligned anymore)
  • Rule’s formulas using this member will not work anymore
  • Selects and “refer to” based on this member will fail

Because of these effects it is mandatory that a complete analysis is performed before running this activity .

We suggest the following steps:

  • Analyze the Rule’s formulas related to the entities for which a deletion will occur
  • Run the impact analysis and identify all the fixed selections and ReferTo on the Entity for which the deletion will occur
  • Analyze all the Cubes or the most relevant Cubes which contain the elements you want to delete
  • Perform a backup before deleting the members
  • Execute the deletion in maintenance mode to avoid any inteferences
  • Use the analysis done to restore the correct selections, refer to and formulas previously made on the elements just deleted
  • If the Entity where the element is deleted is part of a Cube version, make sure to realign the versions.

Be aware a manual deletion will not free up the slot from the Entity members list, the IDx remain busy and deleted member are not deducted from the Max Item Number saturation. Because of these 2 points we suggest that the next method is used when many Entity members need to be removed.

3.2 Extract, Clear and Reload to recreate IDx

Since incremental IDx is used by BOARD to uniquely identify every Entity member in a selection in Screen and procedures is very important to keep it neat and clean by clearing and reloading the members within the Entity. You’ll also free up all unused slots, due to deletion, from Max Item Number saturation count.

Entity extract/clear/reload is not predictable so we suggest avoiding leaving holes in your IDx sequence and recreate them during the same maintenance window in order to directly check and redefine when necessary all selections involving that Entity.

Using an extract/clear/reload the cleaning obsolete members activity can be directly done within the extracted csv file and avoid any manual activity within Board datamodel.

If you have to clear many members, in order to avoid any gap within your IDx sequence follow these steps:

  1. Back-up
  2. Analyze the Rule’s formulas related to the entities for which a deletion will occur
  3. Run the impact analysis and identify all the fixed selections and ReferTo on the Entity for which the deletion will occur
  4. Analyze all the Cubes or the most relevant Cubes which contain the elements you want to delete
  5. Set "Sort by None" on Entity
  6. Extract the Entity
  7. Extract the tree
  8. Extract All Cubes
  9. Clear the Entity
  10. Import the Entity updated list (with fewer Entity members)
  11. Import the tree
  12. Restore the "Sort by" on the Entity
  13. Import All Cubes
  14. Database Unload/Reload (or Server Restart)
  15. At this point you can review every selection involving this Entity to identify any switched selection and fix them.

Below is an example that shows the effect of the extract/clear/reload process and why it is necessary to correctly repoint selections/refer to/Formulas.

Let’s consider this Entity:

image.png

In a procedure, there is a selection on the C3 member, the Entity member with IDx=3. 

Then the member "C2" is manually deleted:

image.png

And then an Entity clear , extract and reload is performed:

image.png

The procedure selection now selects the member C4 that has the IDx=3 which is not the expected one.

 3.3 Dummy parent

In case the Entity to be cleaned is widely used within the application an alternative option to Entity members deleting is to assign the obsolete members to a dedicated parent in order to quickly exclude them from the user view list. For example, the parent (Active: Y/N) can even be used in security so that elements are quickly removed from the entire application.

Using this technique you can avoid member elimination and keep the IDx list consistent.

This option is suggested in case there is not enough time to organize a dedicated service window or the project/business process is in a critical phase and the technical deletion of elements must be postponed.

By assigning all obsolete members to this parent, we can easily exclude and hide them from any report, Screen or procedure execution. On the other side, your master data remains polluted by obsolete members and saturation remains high. For this reason, this is presented as a temporary solution and it is suggested to organize regularly a maintenance window to execute an extract/clear/reload process.

Be aware that this approach does not eliminate the need to in depth analysis , since the deactivation of Entity elements could generate unexpected behavior in different parts of the application. This means that it must be anyway analyzed the impact of deactivating certain elements through the methods explained above.

Tagged:

Categories