Application component, software component, transport layer, package interfaces

[former_member566586]

Context:

I recently encountered a situation where my usage of the type c1 did not compile on someone else's system. I mistakenly thought c1 was a builtin type, but it is actually a data element defined in package APPL->CCMB.

Thinking I can't be the only one to make this mistake, I ran a where-used list and there's actually over 300 uses of type c1 on my system. How can you tell which are (architecturally, let's forget about its semantic meaning for now) valid uses and which are not?

There are package interfaces which should help me find this information. I know what these are for, but I don't know how they are utilized in practice. Additionally, not every package will have one defined.

- Do people nowadays create and rely on package interfaces or are they an obsolete concept?

- What if a package interface is violated? Is it a serious enough error to prevent transport release?

My main question is:

My customer's system is not necessarily going to contain the same objects as my own. How can I then tell what is okay to reuse and what is not?

In general, I would like to know:

In SAP, we have some more concepts which are not entirely clear to me:

- Application component

- Software component

- Transport layer

These terms all look like they could be responsible for what ends up on a customer's system. What are they for and how do they interact?

In the spirit of sharing knowledge, I choose to ask this publicly instead of asking a colleague because I want people to reach meaningful results when googling information about SAP development. Feel free to include links to any relevant articles or books.

[RAF]

Hi,

component CCMB (customer interaction center) is obsolete with S/4 and therefore removed.

If you convert your system, any usage of CCMB will give you an error in respective reports.

Applicaction component: mainly you need this if you check for notes

software component: what is installed on your system: find a complete list via the menu: system->status

SAP system is built upon several layers (components)

transport layer: please check with your basis team

[former_member566586]

Thanks for the answers. However, CCMB still exists on my S/4HANA 2020 system. How is this possible?

[johannes_gerbershagen11]

Package interfaces can be used in "use accesses" of the client-package. The theory behind is, that you encapsulate your service-package, declare a package interface with exposed objects and declare the package interface as use access in all client-packages.

The transaction SE21 and the ABAP Test Cockpit/Code Inspector contains a package-check, but this check doesn't report violations in my system (SAP Basis 7.40) even if i declare a non exposed object and set the error severity to "error".

You can find a similar discussion about your topic an stackoverflow

[Sandra_Rossi]

I started this topic in stackOverflow, which is only related to software components. I think it doesn't bring information to the question of Frederik which is much broader.

[RAF]

Hi Frederik,

sorry none of us has a 2020 S/4 - besides you at SAP has more insights.

Current official information states that CIC is not part of S/4

https://launchpad.support.sap.com/#/notes/2229726

[gabmarian]

In my opinion from the perspective of portability the most important concept is the software component. It means a set of development packages always deployed together, with individual versioning and potentially dependencies to one another. Each package belongs to exactly one software component. When you install a SAP product, such as ECC you install a bunch of these components.

I can't speak for standard SAP / add-on development but I guess programmers pay careful attention not to violate these dependencies, otherwise consistency would be broken.

For in-house developments this is usually not much of an interest, as these are often tailored to a sole system where developed and used. However, if you plant to design something distributable in the customer namespace you have to decide which components are the minimum requirement needed to be present on every target system for your stuff to work.

If you want something to be usable across all SAP systems, use only objects from components SAP_BASIS and SAP_ABA which can be found everywhere. If you develop an ECC extension, you can also use things from SAP_APPL.

Package interfaces can help you to identify which is a part of a package's internal implementation and which parts is designed for outside use. Sticking to those reduces the risk of required refactoring on your side if a new version of the objects is coming out. By no way they deemed obsolete, but as far as I can see SAP doesn't really bother to add package interfaces to older part of their software. In newer stuffs on the other hand changes are higher you will stumble on them. Use them if you can.

Application component is a business domain based functional categorization of the packages marking their place in the application hierarchy. Although not obligatory, I prefer to fill this also for my custom packages and use standard objects from packages of the same application component to be as "semantically correct" as possible.

[former_member566586]

Thank you for your well-written answer!

[matt]

As an add on developer, I can confirm. As a rule of thumb though, if it's in a package beginning with S or RS, it's usually safe. We always import to a basis only stack - just to be sure. I recall once finding part of the HR module incorrectly is SAP_BASIS...

In-house developers have hit similar issues when migrating to s4hana - this is because some industry solutions and other packages are no longer available in s4hana.