Vous êtes sur la page 1sur 12

10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | 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 2 Package


Interfaces of Development Packages
December 10, 2011 | 3,418 Views |

Tobias Trapp
more by this author

ABAP Development
abap | package | sapmentor

share
0 share tweet share

Follow

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 1/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

In the ABAP Package Concept Part 1 – The Basics of my weblog series I


explained how the package concept can help you in ABAP development
projects. Now I explain the most important development aspect: package
interfaces that define public APIs. In fact this can help you to define proper
APIs and how to analyze such APIs. I will explain how to check violations of
package interfaces in a later weblog entry because at first I have to explain
package hierarchies and the visibility with hierarchies of packages which will
be the next topic this weblog series.

We call packages, that contain ABAP development objects but no other


packages “development packages”. They are comparable to legacy
development classes but in contrast to legacy development classes they have
additional properties and can possess package interfaces that you can use to
define proper APIs. Packages interfaces are TADIR objects of type R3TR
PINF and can be created and edited using transaction SE80.

A package can contain nearly every ABAP Dictionary element but there are
exceptions: single includes can’t be exposed. But this shouldn’t bother you
because modularization with includes has many disadvantages and shouldn’t
be used.

TADIR types that are not accessible within ABAP Workbench (think of
archiving objects – R3TR AOBJ) can’t be included too but usually they can’t
be called with native ABAP commands so you don’t need them in package
interfaces.

How to create a Package Interface


Creating a package interface is very easy and so is filling them with visible
elements, just edit the interface and drag and drop them. Just go into
transaction SE80, display the package , select it with the context menu and
choose Create – Development Coordination – Package Interface.

Best Practice #1: Create multiple Interfaces


It makes sense to create more than one interface for the following reasons:

You can distinguish different APIs within an ABAP package.


Packages can be structured hierarchically and the content of a package
is visible only to its neighbors. So it can be necessary to expose a
package interface within an interface of the parent package. So it can
be a good design to distinguish between those propagated interfaces
and the ones that can be used by sibling packages in a hierarchy.
https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 2/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

Usually those are allowed to access “internal” package interfaces that


shouldn’t be used from outside the application.

Properties of Package Interfaces


You can define properties of a package interface. One is to define which object
types can be added. SAP distinguishes between package with no restrictions,
packages that can contain only functional elements (like classes, function
modules…) and packages that contain only descriptive objects (“DDIC”
ocjects). In my opinion these properties are not useful and in fact there are
seldom used in SAP Standard. So if you are interested searching for such
interfaces please have a look into table INTF. Here is one of the few examples
of a package interface containing descriptive elements only:

If you look into the visible interfaces you see that it contains only DDIC
elements:

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 3/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

There is another tab in the above picture: “Restriction on Client Properties”. I


don’t use it because I think it’s defines wrong kind of dependency control: it’s
the knowledge of a server package which clients package are used but it
shouldn’t be the other way round. I can think of special situations in application
redesign of refactoring of a package hierarchy where this could make sense
but I can’t recommend it defining those restrictions as a best practice.

Best Practice #2: Keep an Eye on Descriptive


Elements
In my opinion descriptive package interfaces don’t make much sense in
general because an API usually consists of descriptive as well as functional
elements and so you should keep them together in the same interface. And if
you expose a class in a package interface you should also expose the data
elements used by its methods within the package interface.

My second advice is not to put transparent tables into packages interfaces


because it encourages other developers to access the table directly (and
direct access will not be an error in package checks). The reasons are very
simple:

Security: users of a package should use proper APIs containing


authority checks.
Keep the chance to redesign the data model. It’s possible that you have
to change the data model (transparent tables and the dependencies
between them) for performance or other reasons. But if those tables are

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 4/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

part of an public API and they are used by many other applications the
change won’t be possible.

This has consequences on parameters of function modules and classes: they


should contain ABAP structures but names of tables.

How to find Package Interfaces?


Let’s assume you want to use a function module from SAP Standard like
FIMA_DECIMAL_MOTHS_AND_YEAR which calculates the number of
months and years between two dates then you can find the package interface
in the where-used list:

The result is a little bit confusing but in the next blog entry you’ll explain it in
detail:

The correct interface is FS_FIM_INTERFACE_MAIN which contains interfaces


from subpackages within a package hierarchy:

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 5/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

If you look at the package interface FIMA_GEN_DEF you’ll find other very
useful functions modules for financial mathematics:

If you want to use these functions in a package you should define a use
access in your application in the following way:

The error severity “no response” is the default which means that package
checks won’t produce any error messages. Other values “error, information,
warning and obsolete” can be useful when you are changing packages
interfaces or package hierarchies.
https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 6/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

Summary
In this blog entry it was shown

how to create package interfaces and use accesses,


how to analyze a package interface of SAP standard and
how to search in which package interface a certain object is exposed.

You also learned some best practices for creation of packages and also the
consequences in ABAP development. By the way: I discussed the ABAP
Package Package concept in detail during last SAP communities ROCK! and
the video is available here.

In the next installments I’ll discuss:

types of packages and packages hierarchies and hierarchys of


interfaces
how to perform package checks
package checks in NW 7.30
architecture of large scale ABAP technologies

Alert Moderator

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

Peter Inotai

December 15, 2011 at 11:43 pm

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 7/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

Hi Tobias,

Really nice blog with a very interesting topic.


I miss the different types of package interfaces (filter, default, virtual default) and also
structure packages from this blog. I hope it will be mentioned in one of the next blogs.

You mentioned NW 7.30 as new package check concept, but I believe it’s already
available as of NW 7.10. Or am I wrong?

Thanks,
Peter

Tobias Trapp Post author

December 15, 2011 at 11:59 pm

Hi Peter,

I mentioned above that package hierarchy will be explained in the next


instalment. The reason is simple: I recommend to start with RESTRICTED
checks to get experience with this concept. R3ENTERPRISE require
structure packages and these require special considerations when you
producing software components using the AddOn Assembly Kit of if you
have a complex development landscape. But the discussion of the details &
best practices would have this blog entry too complicated in my humble
opinion.

Please be aware that in higher Releases the interface types will change and
you’ll have to migrate the package interfaces.

Yes NW 7.10 uses a new package package concept but who is using 7.10?
Besides CE und PI it is BW and the banking solution. In the last SAP
Mentors Quaterly was explained by the one and only Thomas Jung – and
everything is heading towards 7.31. NW 7.30 on ABAP makes sanse if you
are using AS ABAP as a sidecar or for BW (especially BW with HANA).

Cheers,
Tobias

Peter Inotai

December 16, 2011 at 12:47 am

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 8/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

Hi Tobias,
Thanks for your quick answer.
I agree R3ENTERPRISE requires much more work than
RESTRICTED setting.
Unfortunately we’re still developing in SAP R/3 Enterprise
4.70/6.20, so I have no experience with 7.30/7.31. Even in ERP
6.05 the basis release 7.02, which doesn’t contains the new
package check concept.
Do you know if it will be included in ERP 6.06?

Unfortunately for most of the customers 7.30/7.31 is not in


scope for the near future.

I had already a chance to logon to NW 7.10 TREX system,


where I saw the new approach. We also have a BW/BI 7.30
system, but my first impression was that it looked the same as
in NW 7.10.
Since I don’t develop here it’s different to get an impression or
use it daily.

However it’s clear that sooner or later all developers have to


get familiar with the new concept since it will be included in
package builder.

Cheers,
Peter

Former Member

July 10, 2013 at 10:22 am

Hi Tobias,

A great blog that has certainly got me thinking how I can move away from the paradigm
of one-package-per-functional-module.

However, I’ve a question on reuse of standard objects based on your example function
module FIMA_DECIMAL_MONTHS_AND_YEARS. You identify the function module is
available in Package Interface FS_FIM_INTERFACE_MAIN, but the function module
itself is not released.

In this apparent contradiction, which setting wins? Is is reasonable to reuse this function
module due to its presence in the Package Interface despite its non-released status?

Thanks,

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 9/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

Nick

Former Member

January 28, 2015 at 2:30 am

Hi Tobias,

I saw a message in SUBPACKAGE saying “No longer Visible; Propagation


incomplete(manual analysis required!)” This happened in the standard package and its
corresponding sub-package.

Is that any settings we need to change for the standard?

Regards,

Kart.

Tobias Trapp Post author

May 3, 2016 at 9:52 am

Sorry, I don’t understand the question.

Former Member

March 10, 2016 at 3:00 am

Hi Tobias,

Thank you for your excellent article of package interface!

I have a question that how can we reverse or cancel the change implemented on a package interface?
There is no version management of Package Interface.

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 10/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

I’m looking forward to your helpful answer!

Thank you very much!!

Tobias Trapp Post author

May 3, 2016 at 9:51 am

Yes, this is a problem. You can say that an interface is obsolete but nothing
more. There is no API for migration and rebuilding interfaces.

Kiran K

December 17, 2016 at 6:30 am

Tobias,

Gone through your series of blogs on ABAP Package Interfaces but I was not able to
comprehend on how this concept can be used in our day to day development
activities.Moreover,creating a Package is mostly considered as a Basis activity so I am
still trying to understand……

Is this just limited to group commonly used FMs or Classes so that they can be found
easily in the form of a repository or there is more to it from the coding point of view.

“If you want to use these functions in a package you should define a use access in your
application“

When we can call the FM or Class without bothering about its package can you please
let us know what is the advantage of defining a package interface ?

Thanks.
K.Kiran.

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 11/12
10/3/2018 ABAP Package Concept Part 2 Package Interfaces of Development Packages | SAP Blogs

Share & Follow

Privacy Terms of Use

Legal Disclosure Copyright

Trademark Sitemap

Newsletter

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packages/ 12/12

Vous aimerez peut-être aussi