Lesson 2 of 5
Request types: workbench, customizing and their tasks
10 min
Two people can change Contoso's system on the same morning in completely different ways. A consultant adjusts the output settings for fleet invoices in the Implementation Guide; a developer changes the form that prints them. Both changes are recorded in transport requests, but not the same kind. Knowing which kind carries what is the first step to sequencing them correctly and to knowing what a test actually covered.
| Workbench request | Customizing request | |
|---|---|---|
| Carries | Repository objects (programs, classes, CDS views, forms, dictionary objects) and cross-client customizing | Client-specific customizing entries made in one source client |
| Scope after import | Whole system, every client | The target client only |
| Locking | Objects are locked to the open request until it is released | Entries are not locked to one request; the last import wins |
| Typical author | Developer | Functional consultant or configuration lead |
| Contoso example | CMDK900412: fleet invoice form change in package ZCMC_SD | CMDK900418: output settings for sales area 1710 / 10 / 00 |
Requests, tasks and numbers
A request is the container that is exported and imported. Inside it are tasks, one per person who records changes. When a request is created, each assigned team member gets a task; the request owner can add more people later. Tasks are released first, then the request. Only the whole request is transported; a task never travels alone.
Request and task numbers follow a fixed pattern: the source system ID, the letter K, then a number starting with 9, such as CMDK900412. The SID in the number tells you where a request came from, which helps when a production import log mentions a request nobody recognizes. Requests are managed in the Transport Organizer: SE09 and SE10 open the same standard view, and SE01 offers the extended view with extra request types such as transports of copies (lesson 4) and relocations.
- Create requestOwner creates a workbench or customizing request and names it clearly, with the defect or change ID
- Tasks assignedEach team member gets a task to record their changes
- Record and unit testChanges are saved into the tasks in CMD and checked by the builder
- Release tasksEach person releases their own task when their part is done
- Release requestRelease exports the content to the transport directory (data and cofiles)
- Queued for CMQThe request is added to the CMQ import buffer and shows in its import queue
Where client settings come in
Whether customizing is recorded at all depends on the client settings maintained in transaction SCC4. A development customizing client is normally set to record changes automatically, so every IMG change prompts for a request. Quality and production clients are normally set so that customizing cannot be changed, which forces everything through transports. Some settings are deliberately maintained directly in each system, such as opening posting periods or exchange rates, because they are operational rather than design decisions. Testers should know which is which: a value changed directly in CMQ is not something a transport will ever bring to CMP.
Locking and the last-import-wins problem
When a developer changes a repository object, it is locked to that open request. Another developer who wants to change the same object must be added to the request or wait until it is released. That protects code from being changed in two places at once. Customizing behaves differently: table entries are locked only while the customizing transaction is open, and once saved, another consultant can record the same entry in a different request. Both requests then carry different values for one entry, and whichever is imported last wins. Requests also record only the table keys at the time of release, so the values exported are the values in CMD at that moment, not when the change was first made. Before-and-after values are visible only if table logging is active and you use the change log reports.
| Request | Type | Content | Why it matters for testing |
|---|---|---|---|
| CMDK900412 | Workbench | Fleet invoice form: new contract number field | Affects every client after import, including training client 200 |
| CMDK900418 | Customizing | Output settings for the fleet invoice, sales area 1710 / 10 / 00 | Without it the new form is never triggered |
| CMDK900421 | Customizing | Same output entry, changed again by a second consultant | If imported after 900418, it silently replaces that value |
Three requests behind one change at Contoso. The test is meaningful only when all the right ones are imported, in the right order.
What would you do?
Maria reports that fleet invoices for Great Lakes Fleet Services still print without the contract number in CMQ, although the developer says the form change CMDK900412 was imported this morning. What should she check first?
- Workbench requests carry repository objects and cross-client customizing; customizing requests carry client-specific settings.
- Requests contain tasks, one per person; tasks are released first, and only the whole request is transported.
- Request numbers start with the source SID, K and 9, for example CMDK900412.
- Repository objects are locked to an open request; customizing entries are not, so the last import wins.
- Some values are maintained per system and master data never travels; know what a transport cannot bring.
Check your understanding · not graded
Lesson check
1. A consultant changes the sales document type settings for sales area 1710 / 10 / 00. What kind of request records it?
2. Which statement about tasks is correct?
3. Why can two customizing requests conflict without warning?
4. What does the request number CMDK900412 tell you?