Skip to Content
Author's profile photo Reiner Markheiser

How-to use the new CBTA Loop capabilities


The looping capability are planned to be shipped with SAP Solution Manager 7.1 SP13

Alternatively you can implement following notes in advance:

  • 2088536 – Downport CBTA Default Components
  • 2088525 – IF and LOOP Default Components for CBTA
  • 2029868 – CBTA – Runtime Library – Fixes & improvements


A test script may need to perform actions against an unknown number of entries in a table. The script may therefore need to:

  • Start at first row and check if there is an entry
  • If entry exists perform one or more actions on the current row
  • Continue with next row


Keyword: DO

It can be used to iterate over several steps. It defines where the loop starts.

  • It must be used together with the LOOP keyword which defines where the loop ends.
  • The EXIT_DO keyword must be used as well to determine when to stop the loop.

The CounterName parameter provides the name of the iteration counter. This counter is incremented automatically at runtime while iterating over the included steps. The actual value of the counter can be retrieve using the regular token syntax.

For instance, when CounterName is set to “COUNTER” its value can be reused in the subsequent steps using %COUNTER% (or $COUNTER$ for specific situations where the percent character is ambiguous).

If you plan to use nested loops please make sure to declare a different counter names.

Component Parameters

CounterName: Specifies the the name of the iteration counter.

Keyword: EXIT DO

It must be used within a loop that has been defined using the DO and the LOOP keywords. The EXIT_DO keyword interrupts the loop as soon as the condition is met.

A typical use case is to check the value of iteration counter that has been declared via the CounterName parameter of the DO keyword.

For instance, when CounterName is set to “COUNTER” its value can be checked using the %COUNTER% token.

Component Parameters


  • Specifies the value of the left operand that is to be checked.


  • Specifies the boolean operator to use.

The operators supported are the ones below:

    • = for “Equal to”
    • < for “Less than”
    • > for “Greater than”
    • <= for “Less than or equal to”
    • >= for “Greater than or equal to”
    • <> for “Not equal to”
    • {contains} for “Contains”
    • {startsWith} for “Starts with”
    • {endsWith} for “Ends with”

An additional operator is supported when testing WEB applications (i.e.: applications running in the browser):

    • {matches} for checking whether the value matches a regular expression. The regular expressions are expressed using the .NET syntax.


  • Specifies the value of the right operand that is to be compared with the left operand.


The options parameter lets you perform some adaptations or conversions of both the left and right operand before comparing them.

The supported options are:

  • /u (for uppercase) – Both values are converted to upper-case before being compared
  • /t (for trimmed) – Both values are trimmed before being compared
  • /i (integer) – Both values are converted to an integer before being compared
  • /f (float) – Both values are converted to a float (or double) before being compared
  • /b (bool) – Both values are converted to a Boolean before being compared

Keyword: LOOP

It defines the end of the loop and must be used together with the DO keyword which defines where the loop starts.


The following scripts was created for transaction VA02 (Change Sales Order) to add shipping information for each line item of an existing sales order.


With DO Keyword the loop starts and the counter is set to ‘1’.


To be able address the row number starting at ‘0’ we take the counter number minus ‘1’ using the CBTA_A_SETINEXECUTIONCTXT component.


Then the scripts reads the value of the first row in the first column to check if an entry exists.


If the value is empty we exit the loop with the EXIT_DO keyword.


Otherwise the scripts performs the required actions for the current row

  • Select row


  • Menu Goto –> Item –> Shipping
  • Enter the required shipping information using the related screen component
  • Go back to main screen

With the LOOP keyword the script goes back to the DO keyword while increasing the counter and processing further line items of that sales order.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hello Reiner,

      We have been waiting for such components for months, this is really great news!

      I suppose the Runtime Library & Default Components doc will be updated in the near future.

      Thank you for having provided explanations for using DO, EXIT_DO and LOOP.

      Do you know if such documentation already exists somewhere for FOR, EXIT_FOR, NEXT?

      I have not been able to install the required notes yet, so I could not check their complexity. Maybe they are equivalent to the others and additional documentation not really urgent...

      Thank you again for this very important release.


      Author's profile photo Reiner Markheiser
      Reiner Markheiser
      Blog Post Author

      Hi Rémi,

      unfortunatelly there is no official documentation available yet for the new capabilities. As the customers I work with also waited for the LOOP features I documented the related use case and wanted to share it for others via this blog.

      The description for each new default component you'll find as usual in the TCE editor as soon you added it to your script. Maybe this helps already.

      Regards Reiner

      Author's profile photo Rutvik Upadhyay
      Rutvik Upadhyay

      Thanks Reiner Markheiser. Really good document to refer for CBTA.

      Author's profile photo Peter O'Leary
      Peter O'Leary

      Hi Reiner

      I am interested in CBTA and how it handles background processing i.e. when you want to move towards fully automated scripting i.e. to run  unattended over night which includes and end to end process which may contain steps using batch jobs. If the jobs don't produce a log or spool output  what are the options to confirm the script has produce the correct result, not just that it completed?

      Can CBTA interrogate spool output?

      Is there any chance we can arrange a call so we can discuss more on the direction of CBTA. Keen to know if their assessment criteria which determines what testing script are or are not candidates for automating.



      Author's profile photo Reiner Markheiser
      Reiner Markheiser
      Blog Post Author

      Hi Peter,

      these are very good questions I also got from other customers which planned to start with Test Automation. Therefore I started to write a document that should provide some guidance for Regression Test that includes also some input for BPCA. Here the link to the draft version of the document:;obj=tilKIOtjHg6J5Xw_2O33e8PdHqr3IcW4flVKn25W79Y

      I hope this answers some of you more generic questions on Test Automation.

      To answer your more specific question regarding CBTA:

      Basically CBTA is able to be executed unattended and it also can handle background jobs. Regarding options to confirm if the script has produced the correct result it is the same approach like for manual testing. Usually I need to ask an application expert, how a manual tester would evaluate if the result is correct or not. Then you typically use a checkpoint to verify if an actual value on the screen meets the expected one. For asynchronous activities like batch jobs it might be necessary to add wait commands or loops for checking the completeness of the job.

      CBTA can basically validate values as part of the spool output as long it is a structured list view. It might not work for all possible output formats.

      For further more individual support SAP has several service offerings in the area of Test Management and Test Automation with CBTA. Please get in touch with your local SAP contact.

      Kind Regards Reiner

      Author's profile photo Peter O'Leary
      Peter O'Leary

      HI Reiner

      Can you please re-confirm that you can load test data into the test data container by excel spreadsheets? or any other suggestions on other technology that can be used so business Analyst can load data into the TDC in advance of testing cycles?

      My belief is you can have multiple test scripts sharing the same this correct?

      Can you pass on parameters from  e.g batch to dialog processing....

      How do we test interfaces in CBTA e.g. we output or input file , how do we test the  correctness of the content of a file, a tricky one could be e.g. Process Orchestration messages.

      Really appreciate your help. I would be interested in getting you feedback on the Framework I am working on to carry out the initial assessment of existing scripts if they are candidates for CBTA.

      Many thanks


      Author's profile photo Rutvik Upadhyay
      Rutvik Upadhyay

      Hi Peter,

      > Yes you can load the test data into TDC by excel spread sheet. You have to define the parameters first and can export them as excel sheet.

      > You can also use the same TDC for multiple test scripts provided all the parameters by importing them from multiple scripts. Avoid any value to the parameter which is not intended to a particular script while creating a variant. 

      > we can pass the parameter values if they are captured by the scripts while recording or u add them manually (with the help of 'object spy'). Then change the type to local  and refer that value from the following script.

      > You can test the interface or file monitoring by recording the procedure for appropriate tcodes, putting the check data condition if required through front end tool.



      Author's profile photo Reiner Markheiser
      Reiner Markheiser
      Blog Post Author

      Fully agree on Rutvik's comment.

      Author's profile photo Peter O'Leary
      Peter O'Leary

      A couple of other questions.

      I am working on a Framework to allow a process where we can make a well though out  decision tree on whether test scripts are candidates for automation (byin this case CBTA). Has anything been develop by SAP? I am happy to share what I have done to date.

      Interested in  your findings to date the percentage when automating existing scripts...that were actually candidates for automation? e.g. on average are 30% of existing scripts meet a criteria to be automated....or is it much higher

      I am interested gaining more material to myself to understanding the additional scripting needed after recording the script, to make it re-useable...examples of the level detail around checks etc passing values, between scripts....has anyone publish a guide with examples of scripting.

      if you are testing a business process, which may be covered by example 7 Test scripts and 2 in the middle are not necessary candidates to be automated by have you tackled  this when the idea is to run the scripts over night without manual intervention.

      Author's profile photo Ajay Hoskote Somashekar
      Ajay Hoskote Somashekar

      Hello Reiner,

      Thanks for the detailed description, could you also provide details on how do we handle passing multiple values for a particular input parameter using the looping concept of CBTA.

      For example: I create a cbta script for creation of Sales Order with single item. Now if the user needs to create the sales order with 10 items I should adapt the script with looping concept. Based on the number of inputs passed to the input parameters for the item the script should execute a single sale order with multiple input item data.

      The catch is script shouldn't open the sales order in change mode enter all the 10 item values in single stretch and save the sales order in finally.

      I looked for documentation on the same but couldn't find the same.

      Please guide.



      Author's profile photo Vick Patel
      Vick Patel

      Hi Ajay,

      Requesting to know if you found the solution to your question yet. Currently, I am in same situation and seeking answer.

      Author's profile photo Peter O'Leary
      Peter O'Leary

      Another quick thing there was a document published in 2011 SAP Solution Manager - How to Guide Test Automation......the problem is prior to CBTA. Is there  a more up to date version that does cover CBTA?

      Author's profile photo Reiner Markheiser
      Reiner Markheiser
      Blog Post Author

      Hi Peter,

      yes it is. Please follow this link to get the How-to Guide for CBTA:

      How-to Guide of CBTA

      Further documents available also at: SAP Solution Manager WIKI - Test Management - Solution Manager - SCN Wiki

      Kind Regards Reiner

      Author's profile photo Peter O'Leary
      Peter O'Leary

      Hi Reiner

      I sent to this email address an Excel Worksheet we are building to allow an assessment to be made on which "Test Scripts" make sense to automate i.e. the benefit from both a Business and Technical 

      The idea is to have the Test Analyst/Engineer to carry out a triage of the testing's scripts before any work starts on recording them.

      I would really appreciate your feedback or your colleagues who may be interested in this.

      My email is



      Author's profile photo Harald Ahorner
      Harald Ahorner

      Hi Reiner,

      I composed yesterday a test script using the new  IF/ELSE/ENDIF CBTA component.

      We figured out, that the system gives you always a FAIL in the evaluation of the IF component, when the condition of the IF statement is evaluated with FALSE and a PASS, when it is true.

      Is there a way to avoid the FAIL behaviour. All what I want to achieve is to route the logic in different ways, depending of the IF condition, without influencing the outcome of the test. Is this maybe a paramenter in the option, which is documented? I was then able to achieve this with the SETCONDITION component.

      Many thanks for your clarifications,



      Author's profile photo Reiner Markheiser
      Reiner Markheiser
      Blog Post Author

      Hi Harald,

      can you double check in the execution report, if the IF component causes the fail of the script ? Maybe the fail is caused by another step in the script.

      I have used the IF component several times and never had this behaviour.

      Regards Reiner

      Author's profile photo Harald Ahorner
      Harald Ahorner

      Hi Reiner,

      Thanks for your reply! We checked this now several times in different areas and it is all over the place the same result. Once the if condition is evaluated to FALSE, this gives you an overall FAIL in the test case, instead of just branching out to the ELSE part of the statement (what it does correctly, but as it is FAILED in the first place it is not very meaningful). I attach you some logs to show you the problem.





      Author's profile photo Marco Kamuf
      Marco Kamuf


      great explanation! Thanks for that.

      I'm currently facing the issue the I want to loop (DO) through a list in TCode "WE05" (iDoc list). My idea was to just check whether the iDoc Number is filled and to exit the loop if not. So far so good, all is working fine until I reach the last row, because there is no empty row attached at the end of the table, therefore the gui component n+1 cannot be found and an error occurs.

      So I'm looking for a way to DO the looping, and create an exit condition based on the existence of the component. Unfortunately the components do not have the "exists" property so a checkpoint on this is not possible. Any suggestion how to overcome this?

      (I'm currently using a FOR loop, by extracting the number of availble entries from SE16N beforehand and then incrementing up to this number, but this is just a messy workaround, which I want to get rid of.)


      Thanks, Marco