Workbench vs. customizing requests

 Let's delve into the detailed differences between Workbench and Customizing Requests in SAP's Transport Management System (TMS), followed by some medium-level interview questions and answers.

Workbench vs. Customizing Requests in TMS

In SAP, changes made to the system are recorded in Transport Requests (TRs). These TRs act as containers for changes, ensuring that modifications are properly managed and moved across the system landscape. While both Workbench and Customizing Requests are types of TRs, they differ significantly in what they contain, how they behave, and their impact on the system.

I. Workbench Requests

What they are:

Workbench requests (also known as "ABAP Workbench Requests") are primarily used for transporting cross-client changes that affect the system's core programs, data structures, and development objects. These changes typically apply globally to all clients within an SAP system.

Key Characteristics:

1. Client-Independent: The most defining characteristic. Changes recorded in a Workbench request are effective in all clients of an SAP system once imported.
2. Content:
   • ABAP Development Objects: Programs, function modules, classes, interfaces, data dictionary objects (tables, views, data elements, domains), ABAP reports, enhancements, BAPIs, BADIs.
   • Repository Objects: Objects stored in the ABAP Dictionary and ABAP Workbench (e.g., screens, menus, authorization objects).
   • Cross-Client Customizing: Configuration settings that apply to the entire system (e.g., currency definitions, country settings, user master data settings). These are typically stored in tables that are marked as "client-independent."
3. Transport Layer: Workbench requests are always associated with a transport layer. This transport layer is usually a customer-defined one (e.g., ZDEVC, Y<SID>) that is assigned to a consolidation transport route (e.g., DEV -> QAS). This determines the path the request will take through the landscape.
4. Ownership: Changes are usually specific to developers or development teams.
5. Handling:
   • Created by developers when they start working on Workbench objects (via transaction SE09 or automatically when creating/modifying objects in SE80, SE11, SE38, etc.).
   • Changes are recorded in tasks (TADIR entries).
   • Released by developers using SE09/SE10.
   • Once released, the changes are exported from the source system and become available for import into the target system(s) in the transport route.
6. Impact: Can have a significant impact on system behavior and stability across all clients. Careful testing in QA is crucial.

Example:

• Creating a new custom ABAP report (Z_SALES_REPORT).
• Modifying an existing standard SAP program via an enhancement.
• Defining a new custom table in the ABAP Dictionary.
• Changing cross-client system parameters (e.g., defining new logical systems).

II. Customizing Requests

What they are:

Customizing requests (also known as "Customizing Transports") are used for transporting client-specific configuration settings and master data changes. These changes are typically made by functional consultants and apply only to a specific client within an SAP system.

Key Characteristics:

1. Client-Dependent: The most defining characteristic. Changes recorded in a Customizing request are effective only in the specific client where they are imported.
2. Content:
   • Client-Specific Customizing: Configuration settings made via the Implementation Guide (IMG, transaction SPRO) that are specific to a particular client (e.g., company codes, controlling areas, sales organizations, purchasing groups, GL account definitions, user authorizations (roles/profiles)). These are stored in tables marked as "client-dependent."
   • Master Data: Occasionally, master data (e.g., new GL accounts, material master types) is transported via customizing requests, especially in smaller, controlled scenarios, or as part of initial data load.
3. Transport Layer: Customizing requests typically use the standard customizing transport layer (often implicitly SAP_CUST or a customer-specific customizing layer assigned to the consolidation route). In some cases, if the change is related to development, it might implicitly use the Workbench layer.
4. Ownership: Changes are usually made by functional consultants.
5. Handling:
   • Created automatically when a functional consultant saves changes in SPRO if the client's "Changes and Transports for Client-Specific Objects" setting in SCC4 is set to "Automatic recording of changes" or "Automatic recording of changes (with no transports)".
   • Released by functional consultants or Basis administrators using SE09/SE10.
   • Once released, the changes are exported from the source client/system and are available for import into the target system's specific client.
6. Impact: Primarily affects the functionality and data within the specific client. Less likely to cause system-wide stability issues compared to Workbench requests, but can impact business processes significantly within that client.

Example:

• Creating a new company code (OBY6).
• Defining a new sales organization (VOE4).
• Setting up payment terms (OBB8).
• Assigning a new user to a role (PFCG).

III. Key Differences Summary

Feature	Workbench Request (Cross-Client)	Customizing Request (Client-Dependent)
Client Scope	Affects all clients in an SAP system.	Affects only the specific client where it's imported.
Content Type	ABAP development objects, Dictionary objects, cross-client config, system objects.	Client-specific configuration (IMG settings), some master data.
Transport Layer	Always explicitly assigned to a transport layer (e.g., ZDEVC).	Often uses a standard customizing layer (SAP_CUST) or implicit.
Creation Source	ABAP Workbench (SE80, SE11, SE38), or via SE09.	Implementation Guide (SPRO), or via SE09.
Responsible Team	ABAP Developers, Basis Administrators (for system changes).	Functional Consultants.
Table Type	Typically updates client-independent tables (e.g., T000, TADIR).	Typically updates client-dependent tables (e.g., T001, V_T001G).
Impact	System-wide, can impact multiple business processes.	Client-specific, impacts processes only in that client.
Naming Convention	Usually starts with K followed by SID and a transport number (e.g., DEVK900001).	Similar to Workbench, but conceptually different content. (e.g., DEVK900002).

---

Interview Questions and Answers (Medium Level)

Here are some medium-level interview questions related to Workbench vs. Customizing requests, along with suggested answers.

Q1: Can a single transport request contain both Workbench and Customizing changes? If yes, what are the implications?

A1: Yes, a single transport request can contain both Workbench and Customizing changes. This typically happens if the Workbench changes (e.g., a new program) require corresponding client-specific customizing (e.g., new configuration entries that the program uses).

Implications:

• Layer Assignment: The entire transport request will be assigned to the Workbench transport layer (e.g., ZDEVC) because it contains Workbench objects. This means it will follow the Workbench consolidation route.
• Client Dependency During Import: While Workbench changes are applied to all clients, the Customizing changes within the same request will only be applied to the specific client into which the request is imported. If you import such a request into client 100 of QAS, only client 100 will get the customizing data. If you need the customizing in another client (e.g., client 200 for a different test scenario), you would typically perform a client copy or a selective transport of customizing (Tx: SCC1) within QAS from client 100 to client 200, or re-import the TR specifically into client 200.
• Risk: Combining them can sometimes make troubleshooting more complex, as an issue could stem from either the Workbench or the Customizing part. It's generally a common practice, but understanding the client-dependent nature of customizing within a Workbench TR is key.

Q2: You release a transport request from a development system, but it doesn't appear in the import queue of your Quality system. What are the common reasons for this, and how would you troubleshoot it, considering Workbench vs. Customizing requests?

A2:

Common Reasons:

1. Transport Route Issue: The transport layer assigned to the request is not linked to a consolidation route from DEV to QAS, or the route itself is not correctly defined/distributed.
2. tp Program Error/Buffer Issue: The tp export process failed or couldn't update the target system's import queue buffer.
3. Transport Directory Access: The usr/sap/trans directory (or network share) is inaccessible, has incorrect permissions, or is full.
4. Request Not Fully Released: The transport request was not successfully released (e.g., still has open tasks).

Troubleshooting Steps (distinguishing between Workbench/Customizing):

1. Verify Release Status: In DEV, use SE09/SE10. Check if the request's status is "Released" (green truck icon). If it's still modifiable or has open tasks, it won't be exported.
2. Check Transport Logs:
   • In DEV, from SE09/SE10, select the request and go to "Request/Task" -> "Display Logs". Look for export errors.
   • Check the AL11 directory DIR_TRANS/log for SLOG and ULOG files for global transport issues.
   • Check the dev_w* and dev_tp traces for details on export failures.
3. Verify Transport Layer and Route:
   • Workbench Request: In SE09/SE10, select the request and go to "Request/Task" -> "Display Object List". Note the packages of the objects. Go to SE09/SE10 and check the Transport Layer assigned to the request properties.
   • Customizing Request: Typically, these will be associated with the default customizing layer, but it's worth confirming.
   • In STMS on the Domain Controller:
     • Go to Overview -> Transport Routes. Check if a consolidation route exists from DEV to QAS that is assigned the relevant transport layer (e.g., ZDEVC for Workbench, or the standard customizing layer).
     • Ensure the route is active and distributed.
4. Check Transport Directory Access:
   • From DEV, use AL11 to navigate to DIR_TRANS. Try creating a temporary file to confirm write access.
   • Check OS-level permissions and disk space on the usr/sap/trans share.
5. Check Target System Buffer:
   • Log on to QAS, STMS_IMPORT. Check if the request is manually visible.
   • Check the usr/sap/trans/buffer/<QAS_SID>buffer file at the OS level. If the request is not listed there, it means the export or update to the buffer failed.
6. Restart RDDIMPDP (if needed): On the QAS system, ensure the RDDIMPDP background job is running (SM37). This job is responsible for updating the import queue. If it's not running, schedule it via SE38 -> RDDNEWPP.

Q3: Explain the significance of the SCC4 settings for "Changes and Transports for Client-Specific Objects" and "Cross-Client Object Changes" in relation to Customizing and Workbench requests.

A3: The SCC4 transaction (Client Maintenance) settings are fundamental in controlling how changes are recorded and transported in an SAP system, directly impacting the behavior of Customizing and Workbench requests.

1. "Changes and Transports for Client-Specific Objects" (for Customizing Requests):

   • Significance: This setting controls how client-dependent customizing changes (made via SPRO) are handled within that specific client.
   • Options:
     • "No changes allowed": No customizing changes can be made in this client. Ideal for Production clients.
     • "Changes without automatic recording": Changes can be made, but no transport requests are automatically created. Changes are "local." Used for sandbox or training clients.
     • "Automatic recording of changes": When a user saves client-specific customizing data, the system automatically prompts for or creates a Customizing request. Ideal for Development and Quality clients.
     • "Automatic recording of changes (with no transports)": Changes are recorded in local customizing requests, but these requests cannot be released for transport. Rarely used.
   • Impact on Customizing Requests: This setting directly dictates whether (and how) client-dependent customizing changes are stored in transport requests. For proper Customizing transports, this must be set to "Automatic recording of changes" in the source client (e.g., DEV client).

2. "Cross-Client Object Changes" (for Workbench Requests):

   • Significance: This setting controls how changes to cross-client objects (which primarily constitute Workbench objects like ABAP programs, Dictionary objects) are handled. This applies globally to the system, not specific clients.
   • Options:
     • "No changes to cross-client objects": No changes to cross-client objects are allowed. Ideal for Production systems.
     • "Changes to cross-client objects allowed": Changes can be made to cross-client objects.
     • "Changes to cross-client objects and to repository and cross-client customizing objects allowed": Most permissive setting, allows changes to all cross-client types.
   • Impact on Workbench Requests: For Workbench requests to be created and managed, this setting must allow changes to cross-client objects in the development system (e.g., DEV). If it's set to "No changes," developers won't be able to create or modify ABAP objects.

In summary:

• SCC4 settings for "Client-Specific Objects" primarily govern the creation and behavior of Customizing Requests.
• SCC4 settings for "Cross-Client Object Changes" primarily govern the creation and behavior of Workbench Requests.

Both are crucial for a well-controlled transport landscape, preventing unauthorized changes in production and ensuring that changes are properly recorded and transported from development.