Skip to Content
Technical Articles

Creating CBTA test configurations in productive SAP Solution Manager 7.2 instances

Customers using a two-tier or three-tier SAP Solution Manager 7.2 landscape normally do not allow any changes in their productive Solution Manager instance without using transports. Any changes must be orchestrated by the SAP Transport Organizer. This is a best practice and a recommended setup. Some workarounds are possible, but all have some disadvantages. For more details please have a look at SAP note 1987155 (How To Create eCATT Objects on Productive systems).

In general, when using test automation tools like CBTA (Component Based Test Automation) the transport approach might become a hassle. CBTA test configurations are eCATT objects in disguise and so they are subject to rules about the changeability of development objects in an SAP ABAP system.

This means that CBTA test configurations need to be developed in a development Solution Manager instance. Then they must be transported and tested in a QA Solution Manager instance, eventually. Finally, they must be transported to the productive Solution Manager instance where they are executed in regular test phases, e.g. during regression tests.

With SAP Solution Manager 7.2 SP08 there is a new option available to avoid the transportation of CBTA test configurations from the development system, then to the QA system and finally to the productive Solution Manager system.

By implementing SAP note 2653468 (eCATT – using local objects without registration in object directory) you will be able to create and execute CBTA test configurations in your productive SAP Solution Manager instance directly, without interfering with the SAP Transport Organizer.

After implementing SAP note 2653468 you must maintain a namespace (e.g. “ZCBTA”).

As of SAP_BASIS 7.40 SP20 there will be an entry in the customizing implementation guide (transaction SPRO) at the following menu path:
“SAP Referenz-IMG -> SAP NetWeaver -> Application Server -> Test Workbench -> Extended Computer Aided Test Tool (eCATT) -> Expert Settings -> Configure CTS/TADIR Handling”

If you are on SAP_BASIS 7.40 SP19 (after the implementation of the SAP Note 2653468, including related notes) you may use transaction SM30 and maintain the table ECCUST_LOCAL_OBJ as outlined above.

This namespace is used as a prefix for your newly created CBTA test configurations and assigned to a local package (e.g. $TMP).

Now you can create and execute CBTA test configurations in your productive SAP Solution Manager directly.

 

/
8 Comments
You must be Logged on to comment or reply to a post.
  • /
  • “Now you can create and execute CBTA test configurations in your productive SAP Solution Manager directly.”

     

    But you cannot copy a test configuration within the Test Composition Environment (TCE).

    In order to create a copy you need to use transaction STCE.

    🙂

  • Hi Guido,

    thank you for this helpful article.

    Would you recommend to record CBTA scripts directly in productive instance or still see the transport variant from D-Q-P as best practice? And for what reasons?

    Thanks in advance!

    Amani

  • Hi Amani,

    I have seen both approaches at customers:

    1. To record directly with the P instance of SolMan is the more pragmatic approach since you do not have these administrative tasks related to the transport requests.
    2. The transport variant is not that straight-forward, for sure. However, you are forced to test/run your test automation scripts in different instances and this improves the quality of your scripts I think.

    So it’s like you might have guessed: It depends. 🙂

    In general, if there are no restrictions due to guidelines or organizational processes, I normally recommend option 1 as outlined above. It also helps to gain acceptance for the test automation approach within an organization.

    Since quite a few customers only have a 2-system-landscape for their SAP Solution Manager, it might also be a good idea to leave the D system for customizing only, without having a “kind of productive” usage for the D system.

    Best regards,

    guido

  • /
    🙂
  • Hello Guido,

     

    Thanks for details, so you are talking about Workaround 1 within your blog right ?

    As you rightly mentioned it all depends.

    With Workaround 1 below restriction is what is mentioned

    in a restricted namespace, eCATT objects can be created without the need to register them in the object catalog – that means, they are not registred at all and all features and object safety mechanisms which come due to object registration do not apply; especially, these objects are not transportable, do not have a property of originality and could be overwritten by imported objects with same names

    Meaning the automated objects can be overwritten from the transports & these automated objects cannot be further transported to another system though production is the last system in TR mechanism.

    Thanks,

    Aj