Packasge or Development Class

[Former Member]

Hi,

Why do we want to create a different package for different modules...like SD,MM,PP,FI...Etc.,

Cant we have a single/common package for all the modules together...???

Regards

Jiku

[seshatalpasai_madala]

Hi,

Why dont you save all your files under the C drive, why do you create so meny folders to save your files.

Just to make sure that you are grouping them together which are logically linked with each other, so its for the logical reason that we organize them in packages.

Apart from that in ABAP you can define package usage between packages, so if you dont want somebody to use your elements just dont expose your package interface.

Something like a package in EA-HR should not access something from an ADD-ON like IS-OIL etc.

Regards,

Sesh

[Former Member]

Hi

In the real scenario when we have some 1000 transport requests for all modules and when we try to transport them into Production server just before go live and if some problem happens in a single transport request it will be very difficult to track.

So we have to keep the logically related requests together in a separate packagae so that it will be easy to track, if something goes wrong in transport.

<b>Reward points for useful Answers</b>

Regards

Anji

[anversha_s]

Hi,

By a simpl example, I will explain.

Consider our house. we have many rooms. 1 for kitchen, 1 for bath, Some rooms for sleep.

Each rooms has its own behaviours and characteristics. Also each 1 will be uniquely identified.

Like That consider SAP as our home. All other modules are like rooms.

Each will contains, things related to that.

hope u gt the idea.

Rgds

ANversha

[Former Member]

SAP documentation says, The package determines the transport layer that defines the transport attributes of an object. What is meant by this....I think we are using only one transport layer...

Regards

Jiku

[seshatalpasai_madala]

Hi,

<b>YES you are right we have only one Transport layer, so if the package is local or in the transport layer defines if the objects in it can be transported or not. Hope it is clear now.</b>

<b>Packages</b> are an enhancement of development classes for concepte that allow for better modularization, encapsulation, and decoupling of the SAP R/3 System.

So far, the development classes have been provided with a transport layer as simple containers for development objects. This layer defines the transport route. As an enhancement of development classes, packages are characterized by the basic properties of nesting, interfaces, and visibility as well as use accesses.

Nesting is the ability of packages to embed other packages into themselves within the package hierarchy.

The visibility describes a property of package elements. A development element can be visible outside of its package. (As a rule, it is visible within its package, but never visible in all packages embedded in this package.) A development element is then visible to the outside whenever it is within a package interfacee.

With use access, you have in a package a one-sided right to use the development elements of a package interface of another package.

<b>Package Definition</b>Related objects in the ABAP Workbench are grouped together in a package. The assignment of an object to a package is entered in the object directory (TADIR). The package determines the transport layer that defines the transport attributes of an object.

The packages are entered in the table TDEVC. They can be maintained in the following transactions:

Transaction SE80 -> Enter package -> Double-click the package

Transaction SM30 - Table/view name V_TDEVC

The packages are themselves objects of the ABAP Workbench. They belong to their own packages.

In contrast to its predecessor, the development class, a package has the following additional characteristics:

Packages can be nested.

Packages can contain their 'visible development objects' (visible outside of the package) in package interfaces.

Packages can have use access defined for other package interfaces.

Use

When an ABAP Workbench object is created, the system prompts you to assign it to a package. The package should describe the area that the object belongs to.

The representation of the object tree in the ABAP Workbench (transaction SE80) uses the package as a navigation aid. If there are more than 100 objects of a certain type (that is, ABAP programs), the object tree can no longer be clearly represented and it becomes increasingly difficult to use the ABAP Workbench. In this case, we recommend creating new packages with the same transport layer and distributing the objects to the new packages on the basis of the areas they belong to.

The following naming conventions for packages determine the packages' functions:

Package begins with A-S or U-X:

These packages are for SAP standard objects. Customer objects cannot be created in them. Changes to objects of these packages are recorded by the Transport Organizer (Request management) and can be transported (see field transport layer.

Package begins with Y or Z:

Customer objects can be created in these packages. Changes to objects in these packages are recorded by the Transport Organizer (Request management). The objects can be transported to other SAP Systems (see the field transport layer ).

Package begins with T (private test package):

When you create a package of this type, you can specify whether you want changes to be recorded. If so, objects that are edited are recorded in local requests by the Transport Organizer. This package does not belong to a transport layer. Objects can only be transported to other SAP Systems if a transport request is created.

Package begins with $ (local package):

Changes to objects are not recorded by the Transport Organizer. The package does not belong to a transport layer. The objects cannot be transported.

Package begins with a namespace prefix:

If you have reserved a namespace, then you can create packages (and other objects) whose names begin with the namespace prefix.

(Example of a namespace prefix /COMPANY/, example of a corresponding package /COMPANY/DEVCLASS)

Changes to these packages are recorded by the Transport Organizer, and can be transported.

<b>Transport Layer in ABAP Workbench</b>

Definition

The Change and Transport System supports the distribution of development work on large projects across multiple SAP Systems.

The packages in each development system are grouped into one transport layer.

The transport layer determines whether objects are assigned to a local or transportable change request.

Use

Each of your SAP development systems is assigned a transport layer as its standard transport layer. If you use Extended Transport Control, you can assign different standard transport layers to certain clients.

You can define at the most one consolidation target for each SAP System and transport layer.

When you create a package, it is assigned the standard transport layer of the SAP System.

If you want to assign a different transport layer to a package, you require the administration authorization for the Change and Transport System.

The objects in a package automatically have the transport attributes defined for the corresponding transport layer.

If a consolidation route originating in their SAP System is defined, then the objects are assigned to a transportable request, and transported into the consolidation target when it is released.

If a consolidation route is not defined, the objects are assigned to a local request, and are not transported.

Customizing settings are not assigned to a package. They have the transport attributes of the standard transport layer of the system or client.

It is best to assign a package a standard transport layer for which a consolidation route originating in the development system is defined.

To display and maintain the transport layers and routes, use the Transport Management System (transaction STMS).

Only the system adminstrator can make changes.

Caution:

The tables TSYST, DEVL, TWSYS, TASYS are no longer productive as of Release 4.0A and cannot be maintained.

Regards,

Ses

[Former Member]

Hi,

Delivery class is the one which controls the table, while upgrading, maintaining and copying.

The delivery class controls the transport of table data when installing or upgrading, in a client copy and when transporting between customer systems. The delivery class is also used in the extended table maintenance.

There are the following delivery classes:

A: Application table (master and transaction data).

C: Customer table, data is maintained by the customer only.

L: Table for storing temporary data.

G: Customer table, SAP may insert new data records, but may not overwrite or delete existing data records. The customer namespace must be defined in table TRESC. (Use Report RDDKOR54 here).

E: System table with its own namespaces for customer entries. The customer namespace must be defined in table TRESC. (Use Report RDDKOR54 here.)

S: System table, data changes have the same status as program changes.

W: System table (e.g. table of the development environment) whose data is transported with its own transport objects (e.g. R3TR PROG, R3TR TABL, etc.).

Behavior during client copy

Only the data of client-specific tables is copied.

Classes C, G, E, S: The data records of the table are copied to the target client.

Classes W, L: The data records of the table are not copied to the target client.

Class A: Data records are only copied to the target client if explicitly requested (parameter option). Normally it does not make sense to transport such data, but is supported to permit you to copy an entire client environment.

Behavior during installation, upgrade and language import

The behavior differs here for client-specific and cross-client tables.

Client-specific tables

Classes A and C: Data is only imported into client 000. Existing data records are overwritten.

Classes E, S and W: Data is imported into all clients. Existing data records are overwritten.

Class G: Existing data records are overwritten in client 000. In all other clients, new data records are inserted, but existing data records are not overwritten.

Class L: No data is imported.

Cross-client tables

Classes A, L and C: No data is imported.

Classes E, S, and W: Data is imported. Exisitng data records with the same key are overwritten.

Classe G: Data records that do not exist are inserted, but existing data records are not overwritten.

Behavior during transport between customer systems

Data records of tables of delivery class L are not imported into the target system. Data records of tables of delivery classes A, C, E, G, S and W are imported into the target system (this is done for the target client specified in the transport for client-specific tables).

Use of the delivery class in the extended table maintenance

The delivery class is also analyzed in the extended table maintenance (SM30). The maintenance interface generated for a table makes the following checks:

You cannot transport the entered data with the transport link of the generated maintenance interface for tables of delivery classes W and L.

When you enter data, there is a check if this data violates the namespace defined for the table in table TRESC. If the data violates the namespace, the input is rejected.

Regards