USE:
In most cases eCATT recordings will be added to test case repository to support interface postings which require manual actions (and are normally done by users). Usually these manual steps generate new business documents in SAP backend system and these document numbers must be passed to following interface test cases in the process chain. For this purpose the IFTT variables concept is used.
Next test case, which Parent ID points to the eCATT step, will have values propagated in Previous Variables 1-5. This will happen thanks to XPath expressions (1-5) that will be defined in this step.
SAP eCATT stores a special log after each script execution. The logs are accessible by SECATT transaction and they contain all system responses:
Picture: Sample eCATT execution log that creates outbound delivery,
Technically the log is stored in SAP system as an XML message. The native XML content can be displayed by executing function module ECATT_LOG_SHOW_PARAM_XML and entering the eCATT execution number.
As already mentioned, in most cases there is a need to pass to the next test cases the document numbers that were created during current eCATT test case execution. Usually standard SAP transactions return the document numbers by system messages (as presented on the screenshot). if not, it is possible to read them inside eCATT recordings (instruction GET).
To fill the variable with such document number, first we need to define an XPath expression that will be able to fetch the value from eCATT xml log. The XPath syntax for standard SAP message is following:
/GuiScripting/ProcessedScreen/Message[Id="XX"][Number="YYY"]/ParameterZ/text(), where:
XX is a message class (like VL)
YYY is a message number (like 311)
Z is Parameter number (1,2,3,4)
The node main GuiScripting is common for all eCATT logs, the other node names are visible in the tree structure in the regular eCATT log viewer.
Example: to fetch delivery number that was created by tcode VL01:
/GuiScripting/ProcessedScreen/Message[Id="VL"][Number="311"]/Parameter2/text()