In my web log on Resolving MIME repository ID numbers onto paths (Resolving MIME repository ID numbers onto paths), I was refering to SPAU – see http://help.sap.com/saphelp_nw04/helpdata/en/c8/61ec66e33611d1954b0000e82de14a/frameset.htm for more info on this trx – and the MIMEs being shown as hexadecimal numbers. The mentioned reports unveiled the real name of the MIMEs. After running these reports, we discovered two problems.
First, we saw that all MIMEsmentioned in our SPAU output were our own MIMEs and absolutely not related to SAP objects. That was strange, since the above mentioned help stated “Only those objects that have been modified by you and are being redelivered by SAP in an upgrade are presented for adjustment.” One can always reset the objects to original, but I wondered why these objects were in the SPAU in the first place. OSS confirmed that these objects were not correctly analysed as deleted objects and that this bug will be fixed. They even offered a solution for clearing our SPAU list. One needs to apply note 634146 in order to reset the objects back to standard.
Second, we discovered that we historically misplaced some MIMEs in a SWCF_MIMES package. This package doesn’t seem to exist in 6.40 anymore. The MIMEs are thus somewhat unassigned. Setting them in the correct package via SE80 (by right clicking on the MIME, see also image), gave us the message “Object from incompatible object layers”.
Deleting the object wasn’t allowed either with “Package SWCF_MIMES does not exist” as reason. The solution here is transaction SE03. (Transport Organizer Tools). Via Object Directory -> Change object directory entries one can a put a filter on packages, which in our case was SWCF_MIMES. All the MIMEs for this (ghost) package are shownand can easily be put in the correct package.
As you can see, with the right tools, and help from OSS, a SPAU can be easily cleaned with a healthy system as result.
