Transport Management for Tests and Components
The transport of the objects in the Extended Computer Aided Test Tool (eCATT) and of the metadata in the Test Composition Environment (TCE) that defines the CBTA tests and screen components is integrated. This enables CBTA tests to be transported.
Since SP02, CBTA uses a repository to manage the CBTA screen components. It stores metadata that is used by the component generation process, with which CBTA can organize the components by catalog. A catalog of screen components is valid for an eCATT system data container and target system, to represent a consistent system landscape.
Note
If you use TCE, apply SAP Note 1871671
(Missing TR number in BAdI call from CL_APL_ECATT_OBJECT
). Otherwise, metadata for TCE and CBTA is not in your transport request.
In contrast to transport management, the download and upload of test scripts that have not been enhanced is not supported for TCE and CBTA test scripts.
After the implementation of SAP Note 2002111, CBTA generates one screen component name per system data container and target system, at recording time. The metadata of the CBTA repository determines the component name. (Before this, CBTA did not use the repository during execution or at recording time.)
Screen component in CBTA 3.0 SP00 and SP01 before SAP Note 197413:
Screen component in CBTA 3.0 SP02 (or in SP00 and SP01 with SAP Note 197413):
A screen component is generated by an SDC and target system, which define its validity. A screen component is still executable for other SDCs/TSs, because the test execution engine does not check its validity and always tries to execute it because it might still be compatible.
The automatic transport of the CBTA repository was not downported to SP00 and SP01, which has the following consequences:
If you do not use CBTA for recording in your SAP Solution Manager target transport system, this CBTA repository transport is not required, because it is used only at design time, not at execution time.
Before you can use your SAP Solution Manager target transport system to record CBTA and generate components (so that the target system is open for modification and creation of the eCATT development object; see SAP Note 1987155
), manage the mass transport of the CBTA repository, manually (see SAP Note 1963411) concurrently to your transport of the CBTA eCATT script and TCE metadata (which are automatically added to your request from the Test Composition Environment and CBTA). Otherwise, regenerated components will be duplicated for the same screen if a re-recording is required, and you get several components for the same screen with the same validity in the same landscape.
Once the target system is used for CBTA recording, inspection and generating new components, it becomes the master of the CBTA data. (This applies to all SPs.) Do not transport any more CBTA objects from the source to the target, otherwise component data can be overwritten by incompatible screen component data, which can corrupt component catalogs. You can control this in SP02, which contains incremental transports: Specify that when screen components of an application area were transported and changed in the target system, new transports must closed for the application area (like Logistics or Human Resources in SAP ECC), for a product version (like SRM or CRM), or for a functional business area. But there is still a risk of overlapping cross-application area components in the scenarios.
Use only one SAP Solution Manager system at a time in the system landscape (DEV, Quality/, PROD...) for CBTA recording.
Example
The following use case shows an example of issues:
The company A&C sets up an SAP Solution Manager development system in which test engineers defined tests for CRM5.
The product system went into production mode, and all CBTA tests were transported.
Test engineers had to review a test that was not working properly for a landscape of one of the subsidiaries of A&C, because the process there involves an additional view. CBTA generates the component
ZVB_CONT_CONTACTDETAILS_001
in the productive system, with validity set to the target systemTS_SUBS5
. A&C still needs the development system, and creates a set of tests for its upgraded system (CRM5 to CRM7). This job creates new components likeZVB_CONT_CONTACTDETAILS_001
with a validity set to the target systemTS_CORP7
. This leads to issues if the newly created components are transported to the productive target SAP Solution Manager system.
Features
Automatic Transport Selection
In CBTA 3.0 SP01, you had to select a transport request each time a screen component was created in the test creation wizard. As of SP02, the request of the master test script is used to store a new or updated screen components. (This is the one you choose from the Test Composition Environment when you save your master test.
With ST-TST SP03 and SP04, apply SAP Note 1945687 to implement this improvement.
This improves the transport request consistency because all screen component test scripts are gathered in the request for the master test script.
Note
A CTS-related message popup can appear and remain in the background. It blocks the process flow in the CBTA wizard. Close it with OK
.
Organization of Transport Requests and Tasks
If a screen component that is shared between business processes and related tests is already part of another transport request, it will remain in the original request without any notice. This is default CTS object handling. No consistency check is made for the request when you release it. It is possible that you transport a CBTA test with only a subset of the CBTA screen components that are involved in the scenario. In this case, when you open a test in your transport target system, the test workbench will raise errors about the missing components until the test and its usage of components is consistent. Once the missing screen components are transported, you can execute CBTA, if you defined the system data container, target component, and tester profile, separately.
To avoid this problem, organize transport requests and tasks based on the scope of your project. Because screen components are dedicated to one system data container and target component, you can create one transport request to be used by all test engineers who are involved in the related test landscape. If the test scope is too large and a synchronized task release too difficult, you can create one transport request for each functional area, as long as cross-business components are properly managed.
FAQ
Should I force a transport of my screen components that were created in a previous release (SP00 or SP01) when my system was upgraded, or when SAP Note 1974513 (CBTA Screen Components: risk of collision) was applied?
Before SAP Note 1974513 was available for SP00 and SP01, CBTA did not use the repository during execution or recording time. This means that no data was stored in the CBTA repository, so there is nothing you can transport; the transport of the eCATT objects and TCE metadata is sufficient.
Can I force the transport of a screen component?
A CBTA screen component is just an eCATT script that is enriched with TCE and CBTA metadata, so you can use any existing standard entry points for eCATT objects transport to transport a screen component, manually.
Are the system data container and target component (assigned to the CBTA master test) also transported?
When you save a CBTA test, the system data container and target component of the test are not automatically added to the transport request. You can define this in transaction SECATT. Enhanced SDC data (from SP02) is not transportable, and must be redefined in the target system with the SUT management tool. This is not really relevant, because the underlying RFC destination and user credential data cannot be transported, anyway.
SUT management tool in the Test Management
work center (
Administration
Goto CBTA Settings
Maintain SUT Systems
.