The function group ALM_ME_PARTNER contains several functions which together provide a means for working with partners of technical objects. e.g equipment and functional locations.
In particular, I mentioned ALM_ME_PARTNER_MAINTAIN for maintaining partner assignments but noted that deletion of partner assignments wasn't possible.
FUNCTION GROUP ALM_ME_PARTNER
Whilst the body of the function module ALM_ME_PARTNER_MAINTAIN contains coding to support deletion, a revision to the function module sees the introduction of the lines below. This addition effectively means that maintenance of existing assignments is no longer possible.
*--- get partners for the technical object and
* delete the partners which are not present.
LOOP AT IT_BAPI_IHPA INTO LS_BAPI_IHPA.
READ TABLE lt_ihpa INTO ls_ihpa WITH KEY
PARVW = LS_BAPI_IHPA-PARTN_ROLE
PARNR = LS_BAPI_IHPA-PARTNER.
IF sy-subrc = 0.
DELETE TABLE IT_BAPI_IHPA FROM LS_BAPI_IHPA.
As an aside: Did anyone else note the dissonance between the comment "delete the partners which are not present" and what the code actually does? Anyway - moving right along to the core topic.
Deletion of Partner Assignments
It seems that the restriction in ALM_ME_PARTNER_MAINTAIN was noticed by another group of developers. They decided to copy ALM_ME_PARTNER_MAINTAIN to come up with their own similar but different implementation. And so function CRM_IHPA_CHANGE_OS is born.
This function allows existing partner assignments of equipment to be deleted. Please re-read the last sentence. Unlike ALM_ME_PARTNER_MAINTAIN, the function is restricted to equipment only and does not support functional locations.
Then follow with
I'd like to introduce a second approach which can be equally applied to either equipment or functional locations i.e. Technical Objects. Another aside: Technical Objects aka TOB => TOB in the name of the function ALM_ME_TOB_PARTNERS.
This second approach extracts the approach to the deletion of existing partners from ALM_ME_PARTNER_MAINTAIN and/or CRM_IHPA_CHANGE_OS.
The first step: Initialize the PM Partner processing with a call to function PM_PARTNER_INIT.
The second step: Mark the partner assignment for deletion with a call to function PM_PARTNER_DELETE_UDKZ. This doesn't delete the partner assignment from the database immediately. The function merely sets an indicator on the partner assignment that comes into play during the saving process. At that point the assignment is physically deleted from the database.
Then proceed with the calls to following as per the prior blog post.
So which approach? I prefer the second, because CRM_IHPA_CHANGE_OS isn't widely used and therefore more likely to be changed underneath your feet. Over the years, I've noticed that the higher the usage within SAP code, the less likely a change of behaviour is introduced. Of course all re-use of non-released function modules comes with the inherent risk that it may change or cease to exist without notice.
To maintain the equipment partners, I’d recommend that the above steps be combined into a class and then wrapped in a function module if needed for remote access.
Don’t forget that changing the equipment partners is part of changing a piece of equipment – so you are advised to ensure you have exclusive use of the equipment. Locking etc.
Write unit tests first! Don't forget your can run them during support packages and when notes are applied to ensure your code still works!