Purpose
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
If you import single requests from the import queue into the target system, you must make sure that the objects in the requests are complete and consistent. Unlike the import of individual projects, the system does not provide automatic support for dealing with relationships between requests.
- 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
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.
Process Flow
The single transport strategy is defined as follows:
- Use of transport routes
Change requests are transported using predefined consolidation and delivery routes (see: Configuring Transport Routes).
- Import individual change requests from 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.
No comments:
Post a Comment