10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

Products
Products Industries
Industries Support
Support Training
Training Community
Community Developer
Developer Partner
Partner

About
About

 
Ask a Question Write a Blog Post Login

ABAP Package Concept Part 4 – How to

perform package checks
July 22, 2012 | 1,799 Views |

Tobias Trapp
more by this author

ABAP Development
abap | abap package concept | sapmentor | software architecture

share
0 share tweet share

Follow

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 1/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

In the first parts of this weblog series I discussed basics of the ABAP package
concept: package interfaces and package hierarchies and explained the
benefits:

We can structure ABAP applications.

We can define packages interfaces.
We can define hierarchies of packages with main and structure
packages at the top.

I can give the following résumé: If you want to create maintainable and
evolvable software you need the ABAP package concept. I consider the
package concept as the most important “new” feature of ABAP besides the
web enabling (ICM and ICF) and object orientation! Unfortunately some
aspects of the package concept are more complex than they should be – but
don’t be afraid: There are very powerful tools that will help you too overcome
problems. Now I explain how to switch on package checks and how to perform
package checks as well as some pesky details.

Package checks can be performed in extended syntax check and within code
inspector. There is also the possibility to check all elements of a package (and
the elements of contained packages if you want) in transaction SE80. As a
result you get list of package errors that you can resolve step by step guided
by an explain tool and a wizard. When you resolve an error the former
erroneous element changes its status so that you don’t have to refresh the
whole list which might take a little bit. But before you can use the package
concept you have to switch it on which is described in the following paragraph.

Transparent table PAKPARAM and “check as client”

vs. “check as server”
In AS ABAP 7.0 to 7.02 package checks are switched off by default and you
have to switch it on in transparent table PAKPARAM (see OSS note 792058).
There are two package check modes:

“NONE” is the default value.

With check mode “RESTRICTED” you can perform checks against
package interfaces.
Using check mode “R3ENTERPRISE” you can check dependencies
between structure packages, too. This means that every package in a
development system has to be in a package hierarchy of a structure
package.

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 2/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

When you switch to “RESTRICTED” or “R3ENTERPRISE” the maintenance

dialog for ABAP packages has two check boxes: “package check as client”
and “package check as server”. The first option means that the package check
will produce an error if when the package uses an object that is exposed in a
package interface but declares no use access. This concept is a little bit
redundant and will vanish from the UI with NW 7.31 (= AS ABAP 7.03). The
mode “check as sever” is far more severe because packages have to declare
use accesses and can only use elements exposed in package interfaces
otherwise you will get an activation error. The activation error is very severe
for usage of DDIC elements and you need a special authorization to prevent
an activation error. But don’t be afraid, the transport system is not affected so
they won’t be trouble if you import erroneous elements into an ABAP system.
If you are interested in the details you can read it in the book ABAP
Development from Scratch.

“Enterprise” or “Restricted”
Use the check mode „R3ENTERPRISE“ only if you want to control the
dependencies on the level of structure packages:

Which structure packages from SAP standard do you use?

What are the dependencies between custom developed structure
package?

These features make sense in a larger development project: structure

packages represent software components or huge applications within a huge
software component – think of SAP_APPL for example that contains R/3
modules. Especially ISVs can benefit from this package concept:

If you develop custom software components using the Add-On

Assembly Kit from SAP or you have a complex development landscape
it will help you increase software quality as well as installability.
You can reduce unwanted side effects from wrong dependencies: Let’s
consider the case you are developing an add-on to FI or HR module
and you are using development objects from IS-U solution then you will
get into trouble when those show a different behavior after an IS-U
business function is activated. Using the package concept you can
control that you are building a “proper” add-on.

Switching on package check mode “R3ENTERPRISE” has following

consequences:

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 3/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

All development packages in a system have to be in the package

hierarchy of a custom structure package – otherwise you will get a large
number of package errors.
All packages have to declare additional use accesses: structure
packages have to declare a use access of a virtual default interface
together with a filter interface or a default interface. Main packages or
development packages have to declare use access of a virtual default
interface or a default interface.
Your own structure packages should define interfaces: a virtual default
interface together with a filter interface together with a default interface.

A personal opinion
In my opinion the ABAP package concept is more complicated than it should
be:

We have four different types of packages interfaces and three different

types of packages.
With virtual default interfaces we can perform a “weak package check”
that exposes all elements of a structure package (restricted to
namespace which can be declared in a filter interface).
You can create defined lists of exposed elements in a so called default
interface – unfortunately there are no usable tools to create such lists.

Luckily SAP created an explain tool that analyzes package errors and even
contains a wizard that can solve package check errors.

If you want to introduce the package concept do the following:

Start with package checks in a sandbox with package mode

“RESTRICTED” and get familiar with the package concept. Check the
results of the package concept and you’ll get a deep result in
dependencies to SAP standard, soon.
Think of defining “strongly encapsulated” packages (package mode “as
server”) for certain packages f.e. new developed applications, packages
that will be transported in a complex landscape or the ones you want to
redesign.
The design of structure packages is more complicated and you have to
consider transport layers, dependencies within your overall
development, dependencies to SAP standard, hierarchy of software
components and so on. I recommend to start with “weak encapsulated”
structure packages i.e. working with virtual default interfaces.
Don’t try to use all features of the package concept – choose a feasible
subset.

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 4/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

NW 7.30 – the complexity raises

In NW 7.10 SAP introduced a change to the package concept of NW 7.0 – I
learned about it when I developed in the ABAP stack of SAP PI. This package
concept is the as in NW 7.30 and you can learn about in SAP Library, you can
find a lot of additional OSS note 1148288 describing migration reports
RS_MIGRATE_PACKAGE_INTERFACES and
SPAK_CREATE_HYBRID_PACK_DATA. If you are confused: NW 7.30 is
shipped in BW and pure AS ABAP systems– don’t mix it up with NW 7.03 (=
AS ABAP 7.31).

I won’t describe details of this package concept but I will give you my personal
opinion:

From my point of view the NW 7.10 / 7.30 ABAP package concept is

much too complicated for a pragmatic use. Instead to simplify it be
reducing the number of package types SAP introduced new ones. The
concept of “weak” and “strong” encapsulation is well thought but SAP
introduced more and more features.
So I want to warn you: don’t use this package concept! You will have to
migrate your “legacy” (= NW 7.0) development and find a solution for
the next EhP because NW 7.31 has the package concept from NW 7.02
that is incompatible with 7.30.
Switch the package checks off using ABAP profile parameter
abap/package_check.

AS ABAP 7.31 – reason prevails

I already mentioned that the package concept of 7.31/7.03 is the same as 7.02
and there are some small improvements from which I mention the most
important: “Package Check as Client” was removed from the UI and “package
check as server” is called “Package Encapsulated”. Furthermore you can
customize the extended syntax check is performed during activation.

In my opinion with AS ABAP 7.31 SAP has a pragmatic package concept that
is still a little bit too complicated but the explain tool makes it easy to use.

Summary
In this blog I explained how to switch on the package checks, differences
between AS ABAP releases and the explain tool will guide you in case of
trouble. I explained to different check modes: “restricted” and “r3enterprise”. In

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 5/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

this next instalment of this web log series I will explain best practices, f.e. how
to start with the ABAP package concept.

Alert Moderator

9 Comments
You must be Logged on to comment or reply to a post.

Former Member

July 23, 2012 at 9:41 am

Hello Tobias,

thank you for your very detailed blog-series about the package concept. Especially for
the parameter settings to turn them off/on;-)

I also think, that SAP has bring us a good tool for handling the complexity and bring us
more stability into our development process – but: The price is very high and it is much
easier, to turn it off instead of using the tool the right way.

In my projects I oftern alternate between using the package concept or ignore it. One
thing, I am afraid, is the fact, that the way of using SAP standard
modules/classes/interfaces will be very small if you use the package checks right. And
this kind of limitation is one of the biggest arguments against using it.

But if you develop your own software component/solution, it will bring a lot more
clarification about a well designed application model and it helps to avoid violations
against this.

Kind regards,

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 6/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

Hendrik

Tobias Trapp Post author

July 24, 2012 at 9:35 am

Hi Hendrik,

I think I’ll continue the series with best practices.

But there is something I would be very interesting to know: Can you image an
ABAP package concept or features of it so that every ABAP programmer would
love to use it?

Best Regards,

Tobias

Former Member

July 24, 2012 at 9:55 am

Hi Tobias,

well, your question is so nice, that i like it ( “ABAP” and

“love” in one sentence …)

Of course, I can imagine: If it should possible, I would like to

have a “wizard” – better a housekeeper – which assigns my
objects correctly and takes more than 80% of the work for
maintaining, package interfaces, ACLs and so on. Short: Every
ABAP developer would love it, if it is calm but still integrated
and used.

For example: After activation of a development object, a huge

list of violations occurs. The developer will get a dialog in
which all actions to correct them appear and he will have the
choice of perform them or not. Ok, the developer still have the
responsibility and he should take all of them as “default”, so we
will not gain a lot more than today, but: a second audit can
ensure, that these options are taken correctly (for example in a
architectural review). As you may see, sometimes I even
dream of a ideal world

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 7/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

The big advantage of ABAP is the high integration and high

automation in some software engineering principles. So I think,
I should not only adapt some concepts of other platforms in
place of adapt them into the ABAP development concepts.

Kind regards,

Hendrik

Former Member

May 28, 2014 at 3:55 pm

Hi Tobias,

Thank you for this blog, it really clarifies many complex concepts of package design.

We are currently starting to understand the real benefits of package design and are
willing to make our first attempt but, we are still stuck in package check activation and
possible impacts in existing developments.

From OSS note 648898 – “Switching on the package check” we acknowledge the
necessity of switching parameter GLOBAL_SWITCH to “RESTRICTED” in order to
enable package checks but we are concerned with the possible impacts of this change.

Wont this reveal all erroneous dependencies and possibly block current developments
activation?

If you could dwell on section “Transparent table PAKPARAM and check as client vs
check as server” a little more we would be most appreciated.

Regards.

Tobias Trapp Post author

May 29, 2014 at 9:26 am

If switch on package checks there can be activation of DDIC elements if

they use “forbidden” objects. If developers have S_DEVELOP mit activity
94 (overwrite) for DEVC for the development package they can confirm the
error message and activate the element.

There are no other problems especially not with the transport system.

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 8/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

So tell your developers that they will get some more error messages (but
this exactly what you want) but they can nevertheless activate their objects
and transport them.

Best Regards,

Tobias

Former Member

July 9, 2014 at 2:05 pm

Thank you Tobias,

We have now successfully implemented our first package

dependency-aware solution. We are now making an effort to
repack our previous developments properly and accordingly to
the package paradigm.

Thank you for your help, very powerful concept.

Regards.

Nuno Godinho

June 23, 2014 at 9:56 am

Hi Tobias,

Thank you for so much precious information.

I have a main package ZA.

I have a message class ZCX in an encapsulated package ZB. Another package ZC has
an exception class which is referencing this message class in one of its texts.

ZA

\— ZB

\- ZMSG

\— ZC

\- ZCX

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 9/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

I was expecting this to yield a package violation since the package ZB doesn’t have any
package interface nor package ZC has any use access for it.

Afterwards, I tried to create a simple method TEST() in class ZCX with the statement
MESSAGE S001(ZMSG). And now I get a package violation.

So it seems like the checks are not taking into account the message classes used in
exception classes. Do you think this is a bug in the package check? Or am I doing
something wrong? I am using RESTRICTED mode.

Thanks in advance,

Nuno Godinho

http://abapinho.com/en

Tobias Trapp Post author

June 23, 2014 at 10:53 am

How does ZCX work? Does it implement IF_T100_MESSAGE? And are

you working with character literals moved to T100KEY? In this case the
package violation can’t be detected. But S001(ZMGS) in command
MESSAGE S001(ZMSG) is no string literal and refers to ABAP dictionary
objects that are under control of package checks.

Could that explain the behaviour?

Best Regards,

Tobias

Nuno Godinho

January 5, 2015 at 4:09 pm

Hello Tobias,

Indeed the ZCX has IF_T100_MESSAGE but I’m not doing

any manual manipulation of the T100KEY. I simply associate
TEXTIDs with specific messages using the standard SE24
interface and when I raise an exception with a specific text…
the standard takes care of filling the fields with the correct
message data.

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 10/11
10/3/2018 ABAP Package Concept Part 4 – How to perform package checks | SAP Blogs

I think it would make sense for it to be detected since a

message from that message class is being explicitly declared
in the exception class.

I’d say this can be seen as a bug, no?

Thanks for your answer.

Regards,

Nuno

Share & Follow

Privacy Terms of Use

Legal Disclosure Copyright

Trademark Sitemap

Newsletter

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/ 11/11