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.
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
- SAP Managed Tags:
9 Comments
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
