Transport Requests for Development

Objectives

After completing this lesson, you will be able to:
  • List Best Practices for Development
  • List differences between Customzing and development
  • Outline the idea of SAP Software Change Registration
  • Outline the idea of naming concepts and the repository object directory
  • Explain the concept of packages

Planning Change Management for Development

Before starting the development in an SAP system, you should plan how the change management for development is done.

The areas which have to be described in the change management procedure for development are the following:

Planning Change Management for Development

  • Restrict repository object changes:
    • Create a single SAP system for all developments.

      Note

      Usually, there is one development system per SAP system landscape.
    • Ensure proper system and client change options.
    • Assign appropriate user authorizations.
  • Define development standards:
    • Use packages to group repository objects.
    • Establish standards for development and documentation.
    • Maintain versions.

  • Establish project teams:

    • Provide all project teams with training on change management tools.

    • Assign team leaders to projects and assign tasks within transport requests to team members.

  • Use projects to group transport requests:

    • Use the project assignment to import and approve whole projects.

      Hint

      Importing and approving complete projects reduces the potential of errors in many ways.
    • Do not import single transport requests – except for emergency repairs.

The tools that the SAP systems provide for change management are based on creating, documenting, and distributing transport requests. The customer must set up the infrastructure and procedures for the management, verification, and testing of these development changes.

Recommendations for development change management include the following:

  • Perform development efforts in a single environment only: the development system. Set the system change options accordingly.
  • Use packages to group functionally related repository objects. The transport layer assigned to the package enables the same predefined transport route to be used for all objects in the package.
  • When releasing a transport request, document the purpose and the status of the changes.
  • To maintain security, use authorizations to control which users can create, modify, or release transport requests (authorization object S_TRANSPRT). SAP delivers sample authorization profiles that provide the SAP system access required for various levels of responsibility in change management.

It is useful to define development rules, customizing rules, and transport rules that describe:

  • How and where changes are made.
  • How and where these changes are tested.
  • How the quality assurance is done.
  • How and who creates, releases and imports transport requests in the SAP system landscape.

Customizing versus Development

SAP provides various implementation tools for customizing and development.

  • For customizing:

    The Implementation Guide (IMG) is the main customizing tool. Once you decide which business functions you require, the IMG automatically generates a hierarchical list of steps or customizing transactions for customizing.

    The Transport Organizer (transaction SE09) records customizing changes in transport requests, which can be released to the transport system for export to other SAP systems in the SAP system landscape.

  • For development:

    The ABAP Development Workbench (as well as the ABAP Development Tools) provides access to development tools, which cover the entire software development cycle. You can use these tools for customer-specific development and for SAP enhancements of your business processes.

    Note

    ABAP Development Tools are an ABAP-integrated development environment built on top of the Eclipse platform. Its main objective is to support developers in today's increasingly complex development environments by offering state-of-the-art ABAP development tools. These tools include strong and proven ABAP lifecycle management on the open Eclipse platform with powerful UI capabilities.

    The Transport Organizer (transaction SE09) also records ABAP Development Workbench changes in transport requests, which can then be released to the transport system for export to other SAP systems in the SAP system landscape. The Transport Organizer is completely integrated with the Transport Management System (TMS).

The differences between these tools are shown in the following figure.

The Transport Organizer records the customizing changes and ABAP Development Workbench changes in two types of transport requests: Client-specific objects are saved to customizing transport requests. Cross-client objects are saved to workbench transport requests.

Customizing changes consist of table entries.

Enter transaction SE01.

The Transport Organizer can be used for customizing and workbench transport requests. The Transport Organizer:

  • Displays transport requests.
  • Displays global transport information.
  • Provides access to special tools.

The Transport Organizer creates, manages, releases, and analyzes transport requests for development.

To access the Transport Organizer, use transaction SE09/SE10 or SE01 for extended functionality.

All workbench transport requests are displayed according to the selection criteria. Selection options include user (owner of either the transport request or one of its tasks), transport request type, transport request status, and date.

The Global Information screen area provides a quick overview of the status of transported transport requests and repairs.

SSCR Registration Concepts

SAP Software Change Registration (SSCR) process has certain key concepts:

In ABAP-based SAP systems of SAP Business Suite, any user in an SAP system who wishes to create, modify, or delete repository objects, including customer objects, must be registered using the SAP SSCR process. Such users are often referred to as "development users" or (for short) "developers". It is a process for tracking, which users are allowed to develop and which SAP objects are changed in an SAP system.

As a result of the registration process, an access key is assigned to each developer. The access key is entered and saved on the developer's SAP system in the table DEVACCESS.

The access key is associated with the developer's logon ID and the SAP systems license number. The developer is prompted for the access key during the initial attempt to create or change a repository object.

You must register developers and all SAP repository objects (not customer objects) that are to be modified. When registering an object, you must supply the object program ID, object type, object name, the SAP system's license number, and the release of your SAP system. After registering an SAP object in an SAP system and applying the access key, the key is stored in the database table ADIRACCESS. This will ensure that further changes to the object do not require another key.

Note

Registered object keys become invalid after a release upgrade.

The registration can be done from the SSCR application at https://launchpad.support.sap.com/#/sscr, which can also be accessed from SAP Support Portal, quick link /sscr (https://support.sap.com/sscr).

SSCR provides development reliability, rapid error correction, and high system availability. This can be done by limiting the access to the development and object keys. Most customers are doing the registration of objects and developers centrally.

In SAP S/4HANA Server systems, these keys are not checked, and, therefore not necessary. For details, see SAP Note 2309060 – The SSCR license key procedure is not supported in SAP S/4 HANA.

SAP Note 2501703 – Frequently asked questions about SAP Software Change Registration (SSCR) provides additional technical information about SAP Software Change Registration (SSCR).

Repository Objects and Attributes

The naming conventions for SAP repository objects are listed in the figure "Correctly Naming SAP Repository Objects".

To prevent conflicts with object names when creating repository objects, developers must follow naming conventions. Extended name lengths allow you to use descriptive names. Object names should clearly describe the function of the repository object.

Namespaces differentiate between SAP repository objects and customer repository objects. Customer repository object names must begin with a Y or Z.

Hint

There are also other naming conventions. For example, customer fields in an SAP table definition must begin with ZZ, not with Z. If the object name is a number, the customer namespace usually begins with 9.

For an overview of all of the current naming conventions for repository objects, see SAP Note 16466 – Customer name range for SAP objects.

Using customer namespaces correctly prevents object name conflicts between customer objects and SAP objects. If a customer has a more complex SAP system landscape with different SAP system lines and more than one development system, they require additional naming conventions to prevent object name conflicts.

In the SAP system, customer namespaces can be reserved using the view V_TRESN, which enables developers to assign a specific namespace to a package. For example: you are developing in the SAP system DE1 for a project within the package ZPROJECT1. You have chosen the naming convention ZPROJ1 for this project and maintained it in all your development systems. A developer in the SAP system DE2, working on another project within another package, now tries to create a program with the name ZPROJ1PROGRAM. When saving, the developer gets the message that this name is reserved for the package ZPROJECT1. In addition, the developer is prevented from assigning the object to another package. The developer therefore has to choose a different program name to assign the program to their package. This avoids naming conflicts right from the start when objects are created.

The view CTSRESNAME offers a simplified view maintenance compared to V_TRESN. This naming convention is according to the program ID and object type.

Note

View CTSRESNAME can only be used for development namespace with reserved namespace prefixes. This means that you can only use the V_TRESN view maintenance to reserve naming conventions for the customer namespace Y*/Z* (object type-specific reservations).

Reserving namespaces is the only way to prevent naming conflicts that occur with objects created in complementary software from SAP partners. SAP partners and customer companies can apply for a name space prefix through the Development Namespaces application in SAP ONE Support Launchpad (https://launchpad.support.sap.com/#/namespaces) which can also be started from SAP Support Portal, quick link /namespaces (http://support.sap.com/namespaces). For more information concerning namespaces and reservation use SAP Note 84282 – Development namespaces for customers and partners.

SAP repository objects are listed in the object directory. The object directory is a catalog of all repository objects in the SAP system, including all standard repository objects that are delivered with the SAP system, and all repository objects created by the customer using the ABAP Workbench.

The object directory lists:

  • All SAP standard repository objects
  • All customer-developed repository objects

The attributes for repository objects include:

  • Package
  • Person responsible
  • Original system
  • Original language

Attributes for each repository object are assigned by the SAP system. The object directory is stored in table TADIR. This table is very central to your SAP system’s consistency. To change entries in TADIR, use only the standard functions that SAP provides.

With the appropriate authorization, you can change the package and person responsible for the object. To change object directory entries from the Transport Organizer, choose transaction SE09 and choose the menu path Goto → Transport Organizer Tools. Alternatively, use transaction SE03. Here, choose Transport Organizer Tools → Object Directory → Change Object Directory Entries.

Some repository objects may be generated automatically by the SAP system as a result of customizing activities. In the object directory, these SAP system-created objects are flagged as "generated".

For each entry in the object directory, the primary key is comprised of the following fields: program identification (PGMID), object type, and object name. The program identification is usually R3TR. Examples of object types are PROG (ABAP program), DEVC (package), TABL (table definition).

Packages

The repository is organized by packages. Repository objects are assigned to a package, which formerly has been known as development class. The package:

  • Provides a logical grouping of objects for coordination of development efforts.
  • Defines a repository object’s transport layer.
  • Can control the naming of objects.

Examples of package definitions are shown in the figure below.

Assigning SAP Repository Objects Packages to Transport Layers

A package is assigned to a transport layer. If the transport layer is assigned to an existing consolidation route, the objects of that package are transported to the consolidation system using this consolidation route.

SAP objects modified in the customer integration system follow the consolidation route that is assigned to the transport layer SAP.

When a package is assigned to a transport layer, all objects belonging to that package follow the same predefined consolidation route, usually pointing from the development system to the quality assurance system.

In the figure above, both the SAP transport layer and the standard ZDEV transport layer are assigned to a consolidation route from DEV to QAS, that is, from the development system to the quality assurance system. All repository objects assigned to a package whose transport layer is ZDEV are transportable. In the figure, objects that are assigned to package ZPAK1, for example, use the consolidation route with transport layer ZDEV.

In this example, the transport layer ZTRN is assigned to a consolidation route from DEV to TRN , that is from the development system to the training system. All repository objects assigned to a package whose transport layer is ZTRN are transportable.

SAP objects belong to the preinstalled transport layer SAP. In the figure above, SAP objects that are modified in DEV will follow the consolidation route assigned to transport layer SAP and therefore will be promoted to QAS. There is only one SAP transport layer in a standard SAP three system landscape.

In this example, you can transport only those repository objects (via a Workbench transport request) whose package is assigned to the transport layer SAP, ZDEV, or ZTRN. If an object is assigned to a transport layer that is either blank or for which there is no transport route, you cannot transport the object via a Workbench transport request.

Packages are also objects of the ABAP Workbench and can be created by the Repository Browser (which is part of the Object Navigator, transaction SE80). When creating a package in the customer namespace, by default the standard transport layer is assigned to the package. Users may also choose an alternative transport layer. The transport layer will be used by the TMS tools for the determination of the consolidation route for the objects inside the package.

Customer created packages may begin with the following letters:

  • Y or Z indicates that the package is for customer objects that are to be transported.
  • $ indicates a package for temporary objects that are not to be transported and therefore do not require a transport layer.
  • TEST indicates a package for local objects which provides version management – but no transporting.

The package $TMP is used when a repository object is saved as a local object and is not assigned to a transport request.

You can use view V_TRESN or view CTSRESNAME to specify which packages can be assigned to a namespace. For example, program names starting with the string ZABC can be prevented from being assigned to a package other than the one defined for this namespace in V_TRESN.

The V_TDEVC view holds all packages in the SAP system, including all SAP packages.

As of SAP Web Application Server 6.10, the concept of packages was introduced. Previously existing development classes simply had been containers for development objects with a transport layer that determines how the objects will be transported. Packages extend the concept of development classes with the addition of new attributes: nesting, interfaces, visibility, and use accesses (see the figure "Package Usage for Development").

  1. Nesting of packages, defining the package hierarchy:

    Nesting allows you to split the larger units of the SAP system into a hierarchical structure. The combination of interfaces and use accesses allows developers to hide package elements, and protect them from unauthorized use.

  2. Definition of package interface:

    Packages use interfaces and visibility to make their services known to other packages. All the visible elements in a package can, potentially, be used by other packages; invisible elements cannot. This allows the package to encapsulate its contents and protect its elements from being used by unspecified external packages.

  3. Definition of use access:

    Use access is the right of one package to use the visible elements in the interface of a second package (but not the other way round).

The package concept also offers the option of splitting and encapsulating the SAP system into technical units (the packages), reducing high levels of dependency and decoupling the SAP system on a large and small scale.

Create Transport Requests for Development and a Package

Business Example

Before starting any development, you, as the project team leader, need to create at least one transport request for the project and to assign team members to tasks in the transport request where their activities are then recorded. They may need to create a development object and save it to the transport request. To group your team development, you also need to create one or more packages so that the team members can assign their repository objects to them.

Note

## represents the group number the instructor has assigned to you.

Task 1: Create Six Workbench Requests

Create six workbench transport requests for development within your project.

Steps

  1. Log on to the development client of the development system as the project leader.

    1. Log on to development system S4D, development client 100, with the credentials provided by your instructor.

      Note

      Only the project team leader should have the authorization to create transport requests.

  2. Create a workbench transport request and assign it to your project PROJECT_##.

    1. To create a transport request and assign it to your project, start transaction SE09.

    2. From the Transport Organizer initial screen, choose the menu path Request/Task → Create.... The Create Request dialog box appears. Select Workbench request and choose Copy (Enter).

    3. Provide a Short description. To assign the transport request to your project, select the CTS project that is assigned to your IMG project PROJECT_## in the Project field. Your user is added to the list of users assigned to the transport request by default. You can add additional project members to the transport request. Choose Save (Enter).

      Note

      Alternatively, you could create the workbench transport request from within your project. To do this, choose transaction SPRO_ADMIN, double-click the line of your assigned project, and add a workbench request (on the Transp. Requests tab, choose Assigned CTS requests and then Create Request...). In this way, your CTS project is assigned automatically to the transport request.

  3. How many tasks are associated with your workbench transport request?

    1. On the Transport Organizer: Requests screen, you may need to expand the folder structure of your transport request.

    2. You should have as many tasks assigned to the transport request as there are users assigned.

      Note

      If you have saved the transport request and you want to add additional users, from the Transport Organizer: Requests screen, mark the transport request and choose the Add User button. The Add User dialog box displays. Here you can enter an additional team member and then select Copy (Enter).

    3. Choose Back to go back to the Transport Organizer initial screen.

  4. Repeat these steps five times.

    1. Repeat these steps for creating workbench transport requests five times to create six workbench transport requests in total.

  5. What type of transport request has been created?

    1. The newly created request is a transportable workbench transport request.

      Hint

      Transportable workbench transport requests can be transported to target systems. In contrast to transportable transport requests, local transport requests are local to the SAP system that it was created in and cannot be exported. Therefore, it cannot be transported to target systems.

Task 2: Create a Package

Create a package for your customer developments, assign it to one of your transport requests from the previous task, and release this transport request.

Steps

  1. Create a package ZPACKAGE_## using the Object Navigator.

    1. If you're not logged on already, log on to the development system S4D, development client 100, with the credentials provided by your instructor.

    2. Start transaction SE80. In the initial screen of the Object Navigator, in the section Repository Browser, choose the option Package from the drop-down list.

    3. Choose the name ZPACKAGE_## for your package. Because no Create button exists, choose Display instead.

      Because your package doesn't exist, the SAP system asks you if you want to create it. Confirm this with Yes.

    4. Assign the necessary attributes to the package: enter a meaningful short description, software componentHOME, and the transport layerZS4D. Choose Package typeDevelopment Package. Keep the other fields unchanged and choose Continue (Enter) to create your package.

    5. The SAP system prompts you to assign your newly created repository object (your package) to a transportable workbench request. Select one of the transport requests that you have created for your project in the previous task (using the search help), and confirm the selection with Continue.

    6. Check the assignment to your request in the Transport Organizer (transaction SE09). Here, display all transport requests that are modifiable, but are not yet released, by choosing Display.

    7. Expand the tree structure for the transport request you have selected.

      There is a task described as Development/Correction as part of the transport request to which you have assigned the newly created package.

  2. To transport your newly created package to the subsequent SAP systems of your SAP system landscape, export the transport request containing your package by releasing it.

    1. Following the previous step, in the Transport Organizer: Requests screen, select the task of the transport request containing your package. Release the task (by choosing (More → ) Release Directly from the application toolbar).

    2. Select the transport request itself and release it (by choosing (More → ) Release Directly from the application toolbar again). The transport request with your package is now being exported. Check that the export is performed without errors.

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn