SOBJ: Definition of Transportable Object Types
The transaction or view cluster maintenance transaction SOBJ contains the technical definition of a transport object. It contains all the SAP objects. The following section describes the information it contains about the BW transport objects.
Overview
You can select the required object here with Position. To do so, you must know the technical name of the transport object.
More information about the technical names of the BW transport objects: Transportable Object Types
Piece List
The database tables that comprise the transport object are listed here. The object key is specified for each table in a special notation:
-
/& is the name part of the object key. All tables of the object share this part. It represents the actual name of the object, which can be found on the transport request.
-
/L is the language field
-
A or D is the object version to be exported when the object is transported.
More information about the object versions: BW Versioning Concept
-
/* is the remaining key parts that only occur in the relevant table, and are not part of the object name. No further key components ( /L, /&, A or D) may follow /*.
One of the tables is marked as the header table. It usually does not contain any further key parts other than the object version and name part.
Header Data
If you double-click on the object in the overview, the header view is displayed. A short description, the object type, and the object properties are displayed.
L - Logical Transport Object is always displayed as the type for BW objects.
In BW, the category for nearly all object types is SYST - Workbench Object. This means that the object behaves like a workbench object that is not client-specific, such as an ABAP report, during transport. Some older objects are still assigned to category CUSY - Client-Independent Customizing Object. Objects in this category also behave like workbench objects during transport, but they also allow you to make additional definitions that are not required in BW for multiclient enabling.
Accordingly, the Client-Specific indicator is not set for BW objects. This indicator is automatically set by the system if the tables specified in the piece list are client-specific. BW metadata tables are never client-specific.
The Translation-relevant indicator is set automatically if the piece list contains a text table, that is a table with language keys. Most BW metadata objects are translation-relevant.
The Name length specifies how long the key part /& in the object key of the metadata table is. Note that the individual metadata tables do not necessarily need to have the same key fields. All the tables, however, must have the same value for the total length as indicated by the name length at the location in the key marked with /& for a certain metadata object.
The character set for BW objects is always Syntactic Characters (without a-z). This means that the name of a BW object may only contain uppercase letters, digits and a few special characters, such as slash and underscore. The slash is used to separate namespaces, as in /APO/.
BW objects are lockable, that is, if the object was written to a transport request, it cannot be written to another transport request at the same time (with the exception of transports of copies). This behavior is the same as for ABAP program objects, for example.
BW objects have Name space type no namespace protection. This does not mean that BW objects can have any name; it only means that the transport system does not check the names. The BW maintenance transactions check if the names are correct with a separate program logic that is more complex than the standard checks. This is due to the enhanced delivery concept. For example, custom BW objects may be created with any first letter, not only with Y and Z. Only digits and special namespaces with slashes are reserved for SAP.
Methods
The BW metadata objects usually generate further objects. This is done in the Import Postprocessing step during the transport. The specified function modules are therefore assigned to method AFTER_IMP - After Import. Some objects also have BEFORE_EXP methods that implement preparatory steps and checks for the objects to be exported.
For BW objects, the function module is usually identical to RS_AFTER_IMPORT (for active objects) or RS_AFTER_IMPORT_D (for delivery objects) although each BW object has its own after-import method. Both modules are the same for all BW objects and define the order in which the after-import methods of the individual objects are called. This order is defined by the fixed values for domain RSTLOGO. More information: Transportable Object Types.
Since the entire list of BW objects is called only once in one request of the after-import module, the corresponding overview message in the transport log does not indicate which object is being processed. A message Error occurred in object xyz only indicates the object that happened to be the first in the list, but not necessarily the one that was incorrect. You should therefore expand the entire transport log.
An SAP patch is also called an upgrade. You should also run the BW after-import methods when you import upgrades and patches.
More information