Asset Manager 2210 Extend SAMXXXX_WORKORDER_GENERIC by new entity - zombie entries in List

[DB_Simple]

Hi experts,

at the moment my team is working at some extension for Workorder operation for the MDO Handler Class /MERP/CL_PM_WORKORDER_DO in Asset Manager Version 2210. Our goal was to extend the Entity MyWorkOrderOperation by a field which returns a list of informations to some component parts, which are workorder operation dependent. We then found out that in comparison to the WorkManager, the Asset Manager with its ODATA based structuring does not support lists or structures given as an entity field.  So we must create a new entity which includes our component information and which we need then to link to MyWorkOrderOperation.  At first, we wanted to create a new MDO ID + handler class + entity, which we would then link to MyWorkOrderOperation with the help of setting the new entity as dependend assoziation to it. We then found out that this would perfectly work for the initial sync, but we also wanted the list to be transfered as delta depending on the operation. This means whenever a workorder operation is assigned to a mobil client user and is transferred to the mobil client, we want to transfer the components part information with it. To do this we also have to implement a delta conzept. We thought of using the workorder exchange object for this. After analysing this, we saw that the exchange object itself returns all the changes which were done to any pm workorder, which is to much. We expected that we only get the change information for our mobile client user. We analyzed then the entity MyWorkOrderOpation and its MDO_ID SAMXXXX_WORKORDER_GENERIC and with this its handler /MERP/CL_PM_WORKORDER . Wefound out, that the filtering for the only relevant information is then done by the handler and is quite complex because of a lot of low code setting in the configpanel and with this using different implementation strategies. So copying all suited the methods to a new handler was not an option for us. Instead, we came to the conclusion that we put our new entity in the SAMXXXX_WORKORDER_GENERIC handler. Adding a new entity with the help of the existing BADI structures was not possible, so we created a new ZCL_PM_WORKORDER class which inheritance of /MERP/CL_PM_WORKORDER.
We redefined /mfnd/if_core_omdo_bo_model~define_bo_entity_model. To included the new entity structure and of course the old code with super before.

 We redefined load_entity_details with a super call at the beginning and added our new entity data gathering method in it.

For the data gathering we analyzed the Method GET_OBJKEYS_BY_DISTRIB_RULES and saw that the method fills the tab_bo_entity_keys_distr_rule for all entities defined in the handler. For the delta, we want to collect our data based on the workorder operations delta. So for this we do not need our own delta keylist we just need the ones of MyWorkOrderOperations. So we take the informations of the deltalist of MyWorkOrderOperation and collect our data with the help of its key informations and then return the information to the mobile client.

This worked at first sign perfectly. When a user gets a new workorder operation assigned our entity was perfectly transferring only the information for the new assigned workorderoperation. For the deletion we configured an association with Principle on Delete Cascade in the configpanel. We added this in MyWorkOrderHeader with referential constraint by ORDERID and MyWorkOrderOpetion with referential constraint by ORDERID and Operationnumber

The Deletion seems to be working fine, when an operation was unassigned also our custom component information which depend on the operation are not shown. A frontend developer found then out by accident, when he debugged the new entity, that the entries of some custom component information are still exist, even if the operation on which they depend is not available anymore. They are then just invisible for the user, but exist in the cash. So, you can say we have some zombie entries in the list now… My question is now, did we miss some configuration there? Do you know how to avoid this zombie entries? Is there a step we need to do in the backend so they will be deleted?