ABAP Package Concept Part 2 Package Interfaces of Development Packages
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. 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:
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 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:
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.
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
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?
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).
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.
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?
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?
Sorry, I don't understand the question.
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.
I'm looking forward to your helpful answer!
Thank you very much!!
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.
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 ?