Single Transports

You may want to use single transports for the following reasons:

• You only make transports infrequently.
• Your organization does not include fixed import times.
• You want to maintain production systems directly with corrections.

A strategy of single transports has the following risks:

• Increased administration
  Caution

  If you import individual requests into the target system from the import queue, it is up to you to make sure that the objects in the requests are complete and consistent. In contrast to the import of individual projects, the system does not support you in dealing with links between requests when you make individual imports.

• Relationships between transport requests can create inconsistencies in the target system:
  • Import sequence

    It is important that you import requests in the correct order, so that development work is up-to-date in the target system.

  • Incompleteness
    Example

    A request is not imported, but it contains an important data element. You use another request to transport a table that references this data element. Since the referenced data element does not exist in the target system, activation errors will occur when you import the second request.

The single transport strategy is defined as follows:

• Use of transport routes

  Change requests are transported along predefined consolidation and delivery routes (see: Configuring Transport Routes).

• Importing individual change requests in the import queue:

  Select the change requests that you want to transport and then import them into the target system. The requests are imported in the order in which they are placed in the import queue.

• Import all change requests of a project:

  If you want to organize your developments in different projects, use the IMG project functions. If you do this, it is important that you keep your development projects distinct from each other. You can then import your requests in projects.

For more information, see Choosing a Transport Strategy.