Package detail Software component missing in xml

[ed-holland]

trafficstars

Most of the packages will have the HOME software component. This means customer (local) development. If one creates AddOns using the AAK toolkit to be certified by SAP ICC, the software component is the NameSpace without the /. This is mandatory.

As such, currently when one restores a package from AbapGit, the software component is defaulted to HOME and needs to be corrected.

Extracting also the software component (DLVUNIT) would mitigate this issue.

When creating a new Package, the HOME software component is defaulted. In our Systems it is a mandatory field (700,740, S/4 2020) though.

[fabianlupa]

Hmm, I am not too sure why I added the CLEAR to DLVUNIT (5 years ago...). c7e2ed737ad25dc130b5a3f9cec817172419ebb6

I think the problem might have been that you cannot specify a software component other than LOCAL for local packages. Therefore the "actual value" would have to be stored somewhere separately and considered to not generate diffs / change the value (in a similar way to application component I think).

Also with custom software components you would have to ensure the system has these configured before pulling in abapGit but I assume your use case is on the development side and not for customer deployments. If I recall correctly the AAK installation procedure takes care of that but there's also a maintenance view for the table (that is not automatically transported though).

[larshp]

The user should create the top level package, to specify eg. the transport layer and software component. AbapGit creates the subpackages, these should inherit values from the super package.

[fabianlupa]

That means making manual top level package creation mandatory again?

Edit: Or cleaner integrating the attributes into the clone dialog / API.

[larshp]

use the defaults if you like

but if there are 5 different transport layers, automatic top level package creation by abapGit will never be able to determine which layer its supposed to land in

https://github.com/abapGit/abapGit/pull/4431#issuecomment-765893185

[mbtools]

For reference: https://docs.abapgit.org/ref-packages.html#transports (this might need more details when it comes to namespaces, PRs welcome)

In general, the software component can be different in the target system depending on how the cloning user defines the root package (or sticks with defaults). Therefore, we don't serialize the software component (DLVUNIT).

For namespaced scenarios - I use them myself -, you typically want to predefine the target package and software component. Currently, this is a gap in abapGit (since it's not particularly focused on deployments).

It's not an easy topic (for example, namespace creation is missing https://github.com/abapGit/abapGit/issues/4505) and requires further refactoring and enhancements (for example, to specify a recommended target package/sw comp).

Happy to discuss on a call if you like.

[ed-holland]

The transport layer will be problematic and i would leave it out of the equation. Namespace / Software component are linked when it comes to Upgrades. Just was doing an S/4 upgrade where it was complaining about non-existing namespaces where there is a software component defined. Super Packages are also problematic in light of the AAK as this would create the above problem as the super package will also need a software component / namespace. The AAK does not handle AddOn hierarchies at all.

If the software component is not HOME or a SAP original one, the CVERS / AVERS entries need to be taken into account also. Maybe even the namespace.

I would be interested to hear you experience in this area.

[mbtools]

@ed-holland see slack

[mbtools]

After discussing with Ed and thinking about it some more, I conclude that custom software components (SWC) should be part of repositories. A SWC is required when building SAP-certified add-ons and without it the repository is missing this essential information.

Since a SWC is always linked to a namespace but not referenced in TADIR, it makes sense to add SWC to the NSPC object. I suggest the following logic:

• Serialize NSPC: If a SWC exists in CVERS that matches the namespace, then add the CVERS entry to <namespace>.nspc.xml
• Deserialize NSPC: If CVERS data is found in the xml, then the corresponding entry in CVERS will be create
• No updating of an existing CVERS (probably bad idea, unless it becomes something like an add-on SP update or release upgrade)
• No transporting of the CVERS entry (bad idea)
• AG does not support deleting a namespace, therefore deleting the SWC is not supported either (very bad idea)

In order to maintain the flexibility to deploy (clone) solutions into other systems, we don't want to include SWC (DLVUNIT) in package.devc.xml. It shall remain up to the user of the target system to define this with the root package.

However, when AG automatically creates a package it derives properties from the root package (including SWC). So when AG creates the root package, too (because the user has not created it), we should derive the SWC from the namespace. Example: When creating package /COMPANY/PACK1 the SWC should be set to COMPANY (if it exists in CVERS).

PS: I'm assuming CVERS is the only data related to SWC, or is there more?

[larshp]

let me know if you want to start this task. I would like to go through the details, but dont have the time right now

[ed-holland]

I agree to most of the above except the not adding it to the package. We have more than 50 packages and it has to be set on all the packages, not just the top package. SAP allows to specify software components from other namespaces (that must exist) in a package. Ergo the package does not have to belong to the Software Component of the Namespace.

[ed-holland]

Only CVERS is required. The table AVERS holds the version information which is not relevant in this case.

[mbtools]

SWC doesn't have to be in the package xml. it should be derived automatically when the packages are created first along the following path:

namespace (swc) > root package > sub packages

as a result, all packages will be assigned to the same SWC which is serialized with the namespace.

[ed-holland]

The issues is that this will not be correct in our implementation. Historically, we created our abap code in the name space /JCS/ for all AddOn's. Each AddOn requires his own namespace which is not /JCS/. As such, the development packages are pointing to the SWC of the AddOn although they are in the /JCS/ namespace.

[mbtools]

that contradicts the assumption that namespace = swc that you mentioned at the beginning here.... hmmm

If I understand it right you have in your dev environment the following:

• namespace /jcs/
• swc jcs .
• namespace /addon/
• swc addon .
• package /jcs/pack with swc addon
• class /jcs/cl_class in package /jcs/pack

But how do you get the package and code to be all part of the addon (for AAK and deployment)? Shouldn't it be

• package /addon/pack with swc addon
• class /addon/cl_class in package /addon/pack

?

[ed-holland]

For a SWC, a namespace with that name must exist. The package can be anywhere. A namespace can exist without an SWC

A SWC JCS does not exist (as there is no addon named JCS)

the AAK packaging is using one or more piecelists to define what is in the addon. There is no automatic collection of objects. One has to specify every object that needs to be added to an Addon.

[mbtools]

@ed-holland I enhanced the serializer for nspc to include the software component (if one exists that matches the namespace).

https://gist.github.com/mbtools/86cd5c80dc91e7e05c409f0410b3c004

You can see an example in the sw_component branch of https://github.com/abapGit-tests/NSPC/tree/mbtools/sw_component

Can you give this a try, please?

[ed-holland]

Sure will do when i'm back from Vacation (july 10th).

[ed-holland]

I've looked at your test project and the package does not show the link to the software component. Was that intensional?

[mbtools]

Oversight. I first did the serialization of SWC into xml. Adding it to packages will be next.

[mbtools]

Finally got around to this. #6891 will now include the software component.