SHIx: Application component hierarchy enhancements not tracked / deletable

[fabianlupa]

trafficstars

Repo: https://github.com/abapGit-tests/SHI5_with_SHI3

I created an enhancement ID (SHI5) and a component structure (SHI3-GHIER) with transaction SBACH02 and attached the new structure to the application component hierarchy.

That's also whats in the repo. I think the attachment to the component hierarchy is not recorded in the xml files though. So I was looking for what happens after uninstall and pulling again but I cannot uninstall the repo.

The SHI3 object is still used in the enhanced standard component hierarchy structure.

I think the component hierarchy enhancement (SHI6 ? #3077 / #3200 ) needs to be serialized somewhere and considered on deserialize and install. Possibly in SHI3 with reference to the used enhancement id.

I assume if I were to clean up manually and pull the repo fresh the objects will be there but the hierarchy will not have the enhancement. Note the enhancement to the default application component structure forces a transport (for SHI6) while all other object types can be local.

One could also argue that enhanced objects do not belong to the abapGit repo. This would mean you are unable do deliver the application component hierarchy enhancement using abapGit though.

I haven't yet tried the IMG enhancement, only component hierarchy enhancements.

[mbtools]

I'm learning more about app components than I wanted to know...

Not sure if my test helps (750 sp 19)... After first pull, I get a diff

There's no enhancement visible, but it does exist. So you're right that the link is missing in the repo.

I was able to uninstall everything after confirming the popup (but I didn't have the link)

I tried to create the repo again and got a different diff. Some buffering issue maybe

Because, after restarting AG, it went back to the first diff.

[mbtools]

the transport for this:

Looks like we need SHI6 serializer and SHI5 is missing as you noted in the other issue

[fabianlupa]

Thanks for testing!

• The first diff shouldn't be an issue. Obviously the component text has been changed between the two releases but it was only a standard component for the test case. Usually the structure would only include components you own therefore no external difference. Though it is a bit weird that the text is copied into the structure. Not sure if you can overwrite it there and that's why it's copied or it's just redundant.
• Missing link: I guess it makes the most sense to include the "enhancements" you did with the enhancement id you used. In that case they should be serialized with SHI5.
• According to #3200 SHI6 has no TADIR entry and was therefore somewhat included with SHI5, except for the transport handling.

[fabianlupa]

@mbtools Can you check if the link shows up if you force the buffer to be rebuild by updating tables ttreeloads and ttreeloadt with gen_date = '19000101' for the extended structure (id B75212DE330AD111A4610060B03C3B0E) ? (Or use FM STREE_UPDATE_INDX_RESET_DATES )

[fabianlupa]

Rebuilding the buffer doesn't seem to help at all.

When manually extending the application component hierarchy using an extension id with a substructure a TNODE01 entry is created. It doesn't get removed on uninstall and doesn't get inserted on pull -> it's not tracked. Not sure if that entry does the connection that enables the SHI3 structure to show up in the component hierarchy. I tried several reorg reports / function modules to rebuild the node tables after TTREES is updated but they didn't catch that entry.

[mbtools]

STREE_A_I_ASSIGN_TO_COMP_HIER might give a hint. It does a lot with BMFR, GHIER

[fabianlupa]

Thanks, haven't looked at it yet. By chance I just got an error when creating a TOC with SHI3 and SHI6 objects. It mentions report RS_STREE_OBJECTS_TO_REQ_GET to complete the piece list and won't release the transport without it. Might also help. (Surprisingly it uses SHI7...)

[mbtools]

Looking at RS_STREE_OBJECTS_TO_REQ_GET and STREE_INSERT_ALL_IN_TRANSPORT which is called from the report, it's a quite complex task. However, it looks like we could call this function with IV_RETURN_OBJECTS_AND_KEYS = abap_true and then serialized ET_OBJECTS and ET_KEYS for the repo.

Anyway, I don't blame you if we skip on this feature.