Lesson 4 of 5
Transport of copies for testing
9 min
Large changes are rarely right the first time. A developer building the fleet contract number enhancement for Contoso may need several rounds in CMQ before it works end to end with pricing, output and the warranty process. If every round meant releasing the original request, the production queue would fill with half-finished versions that all have to be imported, in order, into CMP. The transport of copies exists for exactly this.
A transport of copies is a request type created in the extended Transport Organizer, SE01. You choose the target system yourself, include the objects you want (typically by including the object list of the original, still-open request) and release it. The objects are copied at their current version to that one target. There is no consolidation route involved and, crucially, a transport of copies is not added to the import queue of any follow-on delivery system. It goes to CMQ and stops there. The original request stays open in CMD.
- Original request openCMDK900520 holds the enhancement and stays open in CMD
- Create transport of copiesIn SE01, target CMQ, include the objects of CMDK900520
- Release the copyCMDK900533 is exported with the current object versions
- Import into CMQImported into client 100 for integration testing
- Fix and repeatDefects are fixed in the original; a new copy carries the next round
- Release the originalWhen testing passes, CMDK900520 is released and follows the normal route to CMP
Why programs use them
- Clean production queue. One original request reaches CMP instead of five iterations.
- Test before committing. In-flight work can be integration tested in CMQ while it is still being finished.
- Fewer sequencing traps. Each iteration does not add another version of the same object to the production queue.
- One-off distribution. Copies can also send objects to a system outside the normal route, such as a sandbox, without cascading further.
| Original request | Transport of copies | |
|---|---|---|
| Target | Determined by the transport layer and route | Chosen manually when the copy is created |
| Reaches production | Yes, via the delivery route after QAS import | Never; not added to follow-on queues |
| Status of the original | Released at the end | Original stays open and modifiable |
| Typical use | The change that will go live | Iterative testing of in-flight work |
| Evidence value | Final proof of what goes live | Proof that this version worked; must be confirmed against the original |
Rules for using them well
Transports of copies are useful precisely because they bypass the normal flow, and that is also what makes them risky. Four rules keep them honest.
- The original must still be released. A passing test on a copy moves nothing to production. Track every open original and its copies, and name copies clearly, for example "ToC 3 of CMDK900520, fleet contract number".
- Final evidence comes from the original's import. The copy holds the object versions at the moment the copy was released. If the developer changes anything afterwards, the original differs. After the original is imported into CMQ, run at least a smoke test and the key regression cases, and record the original's number as the build under test.
- Copies change CMQ outside the queue order. Other testers may see new behavior that is not in any build note. Announce each copy import in the test channel and include it in the build log.
- Check what the copy contains. Include all the original's objects, including customizing, or the test will pass with half a change. A copy of a workbench request alone will not bring the output settings recorded in a separate customizing request.
There is also a subtle sequencing effect. When the original is finally released and imported into CMQ, it lands at its own position in the queue. If another request that changes the same object was released in between, the order of those imports decides which version CMQ ends up with. This is another reason to retest after the original's import rather than relying on the copy's results.
- Is the change still being built and needs integration testing in QAS?Yes → a transport of copies is a good fit · No → release the original
- Must the change reach production urgently?Yes → release the original; a copy never reaches production · No → continue
- Does one open original hold every object, including customizing?Yes → copy its object list · No → fix the request structure first
- Is a retest planned on the original's import?Yes → proceed · No → add it to the test plan before using copies
What would you do?
The developer of the fleet contract number enhancement tells Priya: "Copy 3 passed UAT in CMQ, so we are done." The original CMDK900520 is still open, and the developer made one small change to the form yesterday. What should Priya do?
- A transport of copies is created in SE01, goes to a chosen target, and is never added to follow-on queues.
- The original request stays open; only the original reaches production.
- Copies are ideal for iterative integration testing of in-flight work.
- Final evidence must come from the original's import, because the copy holds versions frozen at its release.
- Announce copy imports and track open originals so nothing is forgotten at cut-off.
Check your understanding · not graded
Lesson check
1. What happens to a transport of copies after it is imported into CMQ?
2. Where is a transport of copies created?
3. Why should final testing be repeated after the original is imported?
4. Which is a good use of a transport of copies?