Package

Packages were called development classes in the earlier

Version of SAP (from 4.6c onwards development classes are
Packages)
 
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:
In contrast to its predecessor, the development class,

1. 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.
 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.

Okay now let’s learn how to create a program package in SAP, the tcode to do this
task is SE21.

1. Execute TCODE SE21.

2. Just type in any package name you desire, starting with letter Z or Y.

3. Click the Create Button. Give a short description to your program package and click Save or
press Enter.

4. Done, now you can assign any programs or objects into this package.

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

Transaction SM30 - Table/view name V_TDEVC

How to transfer Local Object to a package   

Any component of an application program that is stored as a separate unit in

the R/3 Repository is called a development object or a repository object

If u save a program as local object it will store in tmp package.

And if u want to transfer your program to ur own package then follow
the steps.

If the object is a report-

1.Goto SE38
2.open your report
3.Follow the given navigation:
Go to-> Object Directory Entry-> change mode

and assign the program to your package.

Transport Request:

In sap there are three servers

1. Developement server
2. Quality/testing server
3. Production server

A transport request is used in SAP to transfer customizations.

programs, repairs from one client in SAP to another client. To give an
example, a customized transaction developed in SAP  is first tested in
the Test environment, then regression testing is done in the quality
server and finally the customization is moved to production. All this is
done through a transport request and more specifically through a
Correction and Transport System.

Transport are the vehicles by which your configuration

settings are moved from one client to another client or
environmnet to environment. In development server we
configure the settings. These settings are transferred to
quality/testing server through transport request.
 Transport request is nothing but a tool to transport the
objects from the one system to the another system by using
the transport objects.

SE09: is workbench organizer change requests for

development objects

SE10: is also a workbench organizer include SE09 and

customizing the objects.

They are the vehicles by which your configuration

settings are moved from client to client or environment to
environment. normally configuration client should be the client
that creates transports at any time. you make a
change to a configuration table or program. this is known
as automatic recording of transports. the automatic
recording of transport made at client level.
 

Types of Transports: Client dependent and Client independent

Status of transports: modifiable and customized

Work Bench Request:

It will automatically affect the Production
client and quality client. without transport it effects all clients
and its called table hitting. Workbench requests are created
for your customized programs usually used by ABAPers.
Customizing Requests:
It is Effective only when you transport.
Customizing requests are created during IMG configuration
usually used by Functional consultants.
 

Types OF Transport Requests:

There are two types of transport requests:  

1. Workbench Transport Request

2. Customizing Transport Request

Workbench Request:  

Workbench request records client independent objects like reports,

Functions, tables. Client independent objects are available across the
system irrespective of client.  

Customizing Request:  

Customizing request records client dependent objects like table entries,

SPRO configurations. Client dependent objects are only available to
particular client.  

SE01, SE09 and SE10 are the transaction codes for SAP Transport
Management system.

Below are the steps to merge the transport request.  

You can only merge multiple Workbench transport requests in Workbench request
and same applicable to Customizing request.  
Execute transaction code SE10, select the radio button “Workbench Requests” and
click on display.  

Following list is displayed with the Workbench requests (modifiable):  

  

For example you need to merge above two transport requests into one request.

First click on New and create a workbench request.  

  

Now select the Transport request in which you want to merge another request. Click
on merge button and give the transport request no. Cick on Green tick.  
  

Now expand the request, you will get the entry of merged transport request.  

Change & Transport System (BC-CTS)

Package property that defines the transport behavior of a package – that is, whether and how a
package and all its repository objects are transported.
The assignment of a package to a transport layer ensures that the package is connected to the
Change and Transport System, thereby defining the integration and consolidation system for its
repository objects.

This defines:

- Whether the repository objects of a package are assigned to a local or transportable change
request

- The SAP system in which repository objects are developed and changed

- Whether these objects are transported to other SAP systems within a system group after
development is complete or changes have been made.

Multilevel Delivery:

Here you can activate multiple delivery routes in sequence. You can choose any SAP Systems in
the system group as the source systems of the delivery routes; they do not have to be
consolidation systems. This allows you to implement complex chains of transport routes.

Multilevel delivery is not required in a two- or three-system group. In more complex system
landscapes, particularly in layered development projects that have each other as sources,
multilevel delivery may prove to be a suitable solution:

 
 

If there are SAP Systems in the system group with releases prior to 4.0, you can only use multilevel
delivery under particular conditions. The Transport Management System checks these conditions when
you configure in a mixed system group.
  

With same steps you can add more transport requests in your request.