In this article you will learn:<\/h2>\n\n- What the Int4 IFTT variables are<\/a><\/li>\n
- In which regression testing scenarios we use Int4 IFTT variables<\/a><\/li>\n
- How Int4 IFTT variables process<\/a><\/li>\n
- How to configure Int4 IFTT variables<\/a>
\n<\/div><\/li>\n<\/ul>\n
\nReading time: 8 minutes<\/p>\n<\/div><\/span><\/strong><\/span><\/em><\/p>\nIntroduction<\/h3>\n
On my previous blog “Int4 IFTT Database Comparison Rules”<\/a>, I am mentioning Int4 IFTT variables<\/strong>. So, what are those variables, when should we use them and how to do the configuration? If you are looking for smart and efficient regression testing, Int4 IFTT variables can deal with some complex and demanding scenarios. All these topics will be explained extensively in this article.<\/p>\n <\/p>\n
What are the Int4 IFTT variables?<\/h3>\n
They are nothing more than simple configurable variables, which are used during the test case creation, execution, and validation.
\nVariables are the container for values that can be used during regression testing. Each variable contains two values, one fetched based on the reference message\/document and the one fetched ad-hoc during test case execution.<\/p>\n
<\/p>\n
In which regression testing scenarios do we use Int4 IFTT<\/a> variables?<\/h4>\nThe use cases of variables are plenty and I am specifying some of them, so if you are looking for an exact regression test case solution it will be listed below.<\/p>\n
\n- During test case creation you can use a variable in order to search for a proper message based on a specific field value.<\/li>\n
- For inbound test cases, they are used to substitute particular fields of original payload messages to avoid posting duplicates or just for testing needs.<\/li>\n
- They are used to correlate interface messages with documents posted in the backend systems.<\/li>\n
- In outbound test cases they are used to search the middleware platforms to find a proper message that would be validated as a part of a test case.<\/li>\n
- In complex regression testing scenarios, variables are used to store and transfer values between sequential test cases. For example, we can have a scenario where the inbound Sales Order is posted in our system and then a Sales Order Confirmation is sent back. So, using a variable we can store the inbound Sales Order number and use this number to fetch the proper Sales Order Confirmation message and validate it according to our needs.<\/li>\n
- Before the test case execution, you can pre-populate the values of the predefined variables, so the test case can be tested according to our needs.<\/li>\n
- Also, variables are used to compare values of any specific fields between the saved message and the newly created one during test case execution.
\n<\/div><\/li>\n<\/ul>\n <\/p>\n
How Int4 IFTT variables process<\/h3>\n
You can define multiple variables for each Int4 IFTT Configuration Object<\/a>. During this configuration, you can specify a set of variable processes for each created variable. The specified variable processes define how and when the selected variable is going to be handled. Each variable processing instruction contains an Action<\/strong>, a Variable Procedure<\/strong>, and a Processing Parameter<\/strong>.
\nLet’s get into some details of each Int4 IFTT variable processing configuration element.<\/p>\nAction<\/span><\/strong> specifies when and in which situation the Variable Procedure will be triggered. As I already mentioned it is very important to understand that, each variable contains a container with two values, the one (reference value) that is calculated based on the reference message\/document and the one (current value) that is calculated ad-hoc during test case execution.<\/p>\nThere are four predefined actions to choose from, in order to fulfill your requirements:<\/p>\n
<\/div>\n\n- Populate variable before execution:<\/strong>
\nThis action is triggered before test case execution. It is used to load to the variable container the reference value.<\/li>\n- Generate value for a new message:<\/strong>
\nThis action is triggered before test case execution. It is used to generate new values and to substitute the message that will be injected into the middleware for processing. The values will be stored in the container as current values.
\nAction must be always preceded by action Populate variable before execution to spot the place in the message that will be substituted with a new value.<\/li>\n- Populate variable after execution:<\/strong>
\nThis action is triggered after the execution of the test case and will populate value from assertion results into reference and current value fields in the container.<\/li>\n- Locate new message using variable value:<\/strong>
\nThis action is limited only to outbound test types. This testing type must be preceded by other test case that will trigger the interface document to the middleware. This might be an eCATT recording, another interface posting that triggers the response or calls by API from external testing software.
\nThe action will be triggered to find a specific message in the middleware. The value that would be searched must be previously read by action Populate variable before execution
\n<\/strong><\/li>\n<\/ul>\nVariable Procedure<\/b><\/span> defines how the value of the variable will be loaded or how the variable should be filled with a new ad-hoc generated value during test case execution. For each <\/span>action<\/span>,<\/b> there are different procedures available that allow us to accomplish various scenarios. <\/span>
\n<\/span>Please find below the list with the available <\/span>variable procedures for each action<\/b>.<\/span><\/p>\n
\nAction <\/span><\/strong>– Populate variable before execution:<\/p>\n\n- Read variable from the saved message (XPath):<\/strong>
\nPopulate the variable with value fetched from the saved reference input payload. The value is fetched by running the XPath expression or Int4 Flat File syntax (depending on message format).
\nApart from loading value, the place in the message will be marked and used by the next action “Generate value for the new message” <\/strong>to substitute reference value with a new one.
\nThe XPath or flat expression must be provided as a string in the parameter field. XPath expressions must be ended with \/text() function to extract node value, not the node object.<\/li>\n- Read variable from the previous case:<\/strong>
\nThis procedure can be used only for test cases configured to run in sequence. It will load the variable value from the previous test case. The variable name from previous test cases must be provided as a parameter. Test cases are linked in sequence in the test cockpit.<\/li>\n- Read the user-defined value from the cockpit:<\/strong>
\nThe variable is populated using the value provided by the user during the test case creation. The value is provided for each variable only once per test case.<\/li>\n<\/ul>\n <\/p>\n
Action<\/span> –<\/strong>\u00a0Generate value for a new message<\/p>\n\n- Replace value with constant:<\/strong>
\nThe current value will contain the constant passed in processing parameter. The constant should be provided as is without any brackets.<\/li>\n- Generate GUID:<\/strong>
\nGenerate random value in a GUID format.<\/li>\n- Generate number from number range:<\/strong>
\ngenerate value for a new message from a predefined number range. This is the most common way to generate new document numbers in end-to-end testing together with SAP back-end. Please provide as parameter the name of the Int4 IFTT number range<\/a> that was created for the particular variable.<\/li>\n- Generate random value:<\/strong>
\ngenerates a random value. The value of the parameter defines the upper limit of the range. it is possible also to generate negative numbers. For example, passing -100 in parameter will generate random numbers from -1 to -100<\/li>\n- add prefix:<\/strong>
\nuse reference value read by the previous action and add prefix specified in the parameter. This might be useful to indicate other systems that messages are coming from automated testing.<\/li>\n- add suffix:<\/strong>
\nuse reference value read by the previous action and add suffix specified in the parameter. This might be useful to indicate other systems that messages are coming from automated testing.<\/li>\n- Read variable from the previous case:<\/strong>
\nThis procedure can be used only for test cases run in sequence. It will load the variable value from the previous test case. The variable name from the previous test cases must be provided as a parameter. Test cases are linked in sequence in the test cockpit.<\/li>\n<\/ul>\nAction<\/span><\/strong> – Populate value for a new message<\/p>\n\n- Read variable from DB res (XPath):<\/strong>
\nPopulates variables with data obtained from the Data Base.\u00a0 As a prerequisite, the configuration object must contain database comparison rules<\/a> and choose for comparison tables and fields that later on will be loaded to the variable. The field and table are specified in the parameter as XPath expression.
\nif there would be more than one value then all of them will be returned. Additionally, you can extract a particular row by adding its number. I will present you with such a case in the example section.<\/li>\n- Read variable from eCATT log (XPath):<\/strong>
\nIf test type is eCATT a variable can be populated from the eCATT<\/a> execution log. The value is obtained from the log using the XPath expression. see details here.<\/li>\n- Read variable from outbound msg (XPath):<\/strong>
\nApplicable only for the outbound test types. Populates variable with data fetched from outbound message using XPath or flat expression after test case execution. The expression is passed in the parameter field.<\/li>\n<\/ul>\n <\/p>\n
Action<\/span><\/strong> – Locate new message using a variable value<\/p>\n\n- Find using XPath:<\/strong>
\nThis procedure will search all middleware messages of the current tested interface from a recent period to look for value loaded by action populate variable before execution<\/strong>.
\nThe value will be checked in the field specified by XPath or flat-file expression and passed as a parameter.
\nThe XPath expression, like in other cases, must be ended with text() function.<\/li>\n- XPath value contains Variable:<\/strong>
\nSimilar to Find using XPath<\/strong> procedure but it will not require the variable value to be equal to the value extracted by XPath expression.
\nIt will check if the value extracted by the expression contains the variable value.<\/li>\n- The variable contains XPath value:<\/strong>
\nSimilar to the previous procedure, however in this case the variable needs to contain the value extracted by the expression.<\/li>\n<\/ul>\n <\/p>\n
Processing Parameter<\/span><\/strong> is an input string with instruction that is consumed by the variable procedure.
\nAs pointed in the variable procedure explanation points most of the time for processing the parameter you need to provide an XPath<\/a> or flat-file<\/a> expression.<\/p>\n<h3id=”4″>Example Int4 IFTT variables configuration<\/p>\n
Let me provide you with an actual use case scenario.
\nWe have Inbound Sales Orders documents through SAP PO to our SAP S\/4 HANA system (IDOC: ORDERS05, message type: ORDERS). After the document gets posted, automatically there is a Sales Order<\/p>\n
Confirmation document generated and send back (IDOC: ORDERS05, message type: ORDRSP).
\nWe want to test this scenario end to end, that means, we are going to validate:<\/p>\n
\n- The inbound Sales Order actually posted IDOC<\/li>\n
- The outbound Sales Order Confirmation the actual outbound message from PO<\/li>\n<\/ul>\n
In order to validate those two types of documents, we will need two Int4 IFTT Automation Objects.
\nOne for the Inbound interface and one for the Outbound. The test cases need to communicate with each other in order to identify the right Sales Order Confirmations based on each Sales Order. This communication between the test cases is possible after configuring the Int4 IFTT variables. So let’s go and have a look at a step by step configuration for this scenario.<\/p>\n
The Int4 IFTT variables configuration is under the Int4 IFTT Automation Objects.
\nGo to transaction \/int4\/iftt_conf_mass and create a new Int4 IFTT Automation Object<\/a>.<\/p>\nSelect the Automation Object that you want to configure and double click on Variables.
\n<\/span><\/p>\n![\"Object](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/07\/1.Object-Header-VARIABLES_SALESORDER.png\")
<\/a><\/p>\nNew Int4 IFTT Automation Object VARIABLES_SALESORDER<\/em><\/p>\n <\/p>\n
Create a new variable.<\/p>\n
Select it and double click on Variable Processing.
\n<\/span><\/p>\n![\"Int4](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/07\/2.IFTT-Automation-Object-VARIABLES_SALESORDER.png\")
<\/a><\/p>\nNew Variable DOCNUM for Automation Object VARIABLES_SALESORDER<\/em><\/p>\n <\/p>\n
One more interesting thing that we want to implement at this point, is creating a new document number for every test case execution. This way we are going to avoid posting duplicates on both systems, our posted document will have a unique predefined document number and we are going to be able to identify the documents created by Int4 IFTT.<\/p>\n
So, the first Action<\/strong><\/span> that we need is “Read variable before execution”<\/strong> and we choose the variable processing “Read variable from the saved message (XPath)”<\/strong>. For processing parameters, we need to provide the actual XPath expression. In our case:
\n\/\/E1EDK02[QUALF=”001″]\/BELNR\/text()<\/p>\nIn order to create a new document number, I will use another interesting feature of Int4 IFTT, the Number Ranges<\/a>. I created a proper Number Range for this scenario named NR_DOCNUM.<\/p>\n <\/p>\n
Now, we need the “Generate Value for new message” Action<\/span><\/strong> and “Generate value from number range”<\/strong>\u00a0as variable processing. For processing parameters just provide the Number range name.<\/p>\n![\"VARIABLES_SALESORDER_DOCNUM\"](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/07\/3.VARIABLES_SALESORDER_DOCNUM.png\")
<\/a><\/p>\nVariable Processing Configuration for variable DOCNUM<\/em><\/p>\n
\nThe first Int4 IFTT Automation Object is ready. Now, let’s configure the second one.<\/p>\n
Again, create a new Automation object and create a new Variable for it.<\/p>\n
![\"Int4](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/07\/4.IFTT-Automation-Object-VARIABLES_SALESORDERCONF.png\")
<\/a><\/p>\nNew Variable DOCNUM for Automation Object VARIABLES_SALESORDERCONF<\/em><\/p>\n
\nThe first variable processing action<\/span><\/strong> for this Object will be again “Read variable before execution”<\/strong>. But now as a variable process, we choose “Read variable from previous test case”<\/strong>\u00a0and provide as a processing parameter the name of the variable from the previous automation object. This way you can pass variable values from one test case to another. Please note that variables can store multiple values during one test case execution.<\/p>\nThe last a<\/span>ction<\/span><\/strong> that we need is “Locate new message using the variable value”<\/strong>\u00a0and the procedure “Find using XPath”<\/strong>. The last thing is to provide the correct XPath expression in the Processing Parameter.<\/p>\n![\"VARIABLES_SALESORDERCONF_DOCNUM\"](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/07\/5.VARIABLES_SALESORDERCONF_DOCNUM.png\")
<\/a><\/p>\nVariable Processing Configuration for variable DOCNUM<\/em><\/p>\n
\nThat way you can create sequential test cases to any document type of this kind.
\nYou can read more about testing end-to-end business processes<\/strong><\/a>, with a great complete testing example, in the blog “Testing business processes with Int4 IFTT”<\/a>\u00a0by Krzysztof \u0141uka.<\/p>\nSummary<\/h2>\n
Int4 IFTT variables form the core configuration for smart and effective regression testing. After reading this article, you should understand the functional and technical details about the Int4 IFTT variables. Moreover, now you should be able to configure the Int4 IFTT variables on your own.<\/p>\n
Do not forget to check out the rest of our Int4 blogs<\/a> and learn more interesting features of Int4 IFTT. If you want to find out more about this (or other) Int4 IFTT features, just book a consultation with the product demo or contact us<\/a>.
\n<\/span><\/p>\nRead also<\/h4>\n
1. Int4 IFTT Integration with SAP Solution Manager Test Suite<\/a><\/p>\n
- \n
- What the Int4 IFTT variables are<\/a><\/li>\n
- In which regression testing scenarios we use Int4 IFTT variables<\/a><\/li>\n
- How Int4 IFTT variables process<\/a><\/li>\n
- How to configure Int4 IFTT variables<\/a>
\n<\/div><\/li>\n<\/ul>\n
\nReading time: 8 minutes<\/p>\n<\/div><\/span><\/strong><\/span><\/em><\/p>\nIntroduction<\/h3>\n
On my previous blog “Int4 IFTT Database Comparison Rules”<\/a>, I am mentioning Int4 IFTT variables<\/strong>. So, what are those variables, when should we use them and how to do the configuration? If you are looking for smart and efficient regression testing, Int4 IFTT variables can deal with some complex and demanding scenarios. All these topics will be explained extensively in this article.<\/p>\n
<\/p>\n
What are the Int4 IFTT variables?<\/h3>\n
They are nothing more than simple configurable variables, which are used during the test case creation, execution, and validation.
\nVariables are the container for values that can be used during regression testing. Each variable contains two values, one fetched based on the reference message\/document and the one fetched ad-hoc during test case execution.<\/p>\n<\/p>\n
In which regression testing scenarios do we use Int4 IFTT<\/a> variables?<\/h4>\n
The use cases of variables are plenty and I am specifying some of them, so if you are looking for an exact regression test case solution it will be listed below.<\/p>\n
- \n
- During test case creation you can use a variable in order to search for a proper message based on a specific field value.<\/li>\n
- For inbound test cases, they are used to substitute particular fields of original payload messages to avoid posting duplicates or just for testing needs.<\/li>\n
- They are used to correlate interface messages with documents posted in the backend systems.<\/li>\n
- In outbound test cases they are used to search the middleware platforms to find a proper message that would be validated as a part of a test case.<\/li>\n
- In complex regression testing scenarios, variables are used to store and transfer values between sequential test cases. For example, we can have a scenario where the inbound Sales Order is posted in our system and then a Sales Order Confirmation is sent back. So, using a variable we can store the inbound Sales Order number and use this number to fetch the proper Sales Order Confirmation message and validate it according to our needs.<\/li>\n
- Before the test case execution, you can pre-populate the values of the predefined variables, so the test case can be tested according to our needs.<\/li>\n
- Also, variables are used to compare values of any specific fields between the saved message and the newly created one during test case execution.
\n<\/div><\/li>\n<\/ul>\n<\/p>\n
How Int4 IFTT variables process<\/h3>\n
You can define multiple variables for each Int4 IFTT Configuration Object<\/a>. During this configuration, you can specify a set of variable processes for each created variable. The specified variable processes define how and when the selected variable is going to be handled. Each variable processing instruction contains an Action<\/strong>, a Variable Procedure<\/strong>, and a Processing Parameter<\/strong>.
\nLet’s get into some details of each Int4 IFTT variable processing configuration element.<\/p>\nAction<\/span><\/strong> specifies when and in which situation the Variable Procedure will be triggered. As I already mentioned it is very important to understand that, each variable contains a container with two values, the one (reference value) that is calculated based on the reference message\/document and the one (current value) that is calculated ad-hoc during test case execution.<\/p>\n
There are four predefined actions to choose from, in order to fulfill your requirements:<\/p>\n
<\/div>\n- \n
- Populate variable before execution:<\/strong>
\nThis action is triggered before test case execution. It is used to load to the variable container the reference value.<\/li>\n- Generate value for a new message:<\/strong>
\nThis action is triggered before test case execution. It is used to generate new values and to substitute the message that will be injected into the middleware for processing. The values will be stored in the container as current values.
\nAction must be always preceded by action Populate variable before execution to spot the place in the message that will be substituted with a new value.<\/li>\n- Populate variable after execution:<\/strong>
\nThis action is triggered after the execution of the test case and will populate value from assertion results into reference and current value fields in the container.<\/li>\n- Locate new message using variable value:<\/strong>
\nThis action is limited only to outbound test types. This testing type must be preceded by other test case that will trigger the interface document to the middleware. This might be an eCATT recording, another interface posting that triggers the response or calls by API from external testing software.
\nThe action will be triggered to find a specific message in the middleware. The value that would be searched must be previously read by action Populate variable before execution
\n<\/strong><\/li>\n<\/ul>\nVariable Procedure<\/b><\/span> defines how the value of the variable will be loaded or how the variable should be filled with a new ad-hoc generated value during test case execution. For each <\/span>action<\/span>,<\/b> there are different procedures available that allow us to accomplish various scenarios. <\/span>
\n<\/span>Please find below the list with the available <\/span>variable procedures for each action<\/b>.<\/span><\/p>\n
\nAction <\/span><\/strong>– Populate variable before execution:<\/p>\n
- \n
- Read variable from the saved message (XPath):<\/strong>
\nPopulate the variable with value fetched from the saved reference input payload. The value is fetched by running the XPath expression or Int4 Flat File syntax (depending on message format).
\nApart from loading value, the place in the message will be marked and used by the next action “Generate value for the new message” <\/strong>to substitute reference value with a new one.
\nThe XPath or flat expression must be provided as a string in the parameter field. XPath expressions must be ended with \/text() function to extract node value, not the node object.<\/li>\n- Read variable from the previous case:<\/strong>
\nThis procedure can be used only for test cases configured to run in sequence. It will load the variable value from the previous test case. The variable name from previous test cases must be provided as a parameter. Test cases are linked in sequence in the test cockpit.<\/li>\n- Read the user-defined value from the cockpit:<\/strong>
\nThe variable is populated using the value provided by the user during the test case creation. The value is provided for each variable only once per test case.<\/li>\n<\/ul>\n<\/p>\n
Action<\/span> –<\/strong>\u00a0Generate value for a new message<\/p>\n
- \n
- Replace value with constant:<\/strong>
\nThe current value will contain the constant passed in processing parameter. The constant should be provided as is without any brackets.<\/li>\n- Generate GUID:<\/strong>
\nGenerate random value in a GUID format.<\/li>\n- Generate number from number range:<\/strong>
\ngenerate value for a new message from a predefined number range. This is the most common way to generate new document numbers in end-to-end testing together with SAP back-end. Please provide as parameter the name of the Int4 IFTT number range<\/a> that was created for the particular variable.<\/li>\n- Generate random value:<\/strong>
\ngenerates a random value. The value of the parameter defines the upper limit of the range. it is possible also to generate negative numbers. For example, passing -100 in parameter will generate random numbers from -1 to -100<\/li>\n- add prefix:<\/strong>
\nuse reference value read by the previous action and add prefix specified in the parameter. This might be useful to indicate other systems that messages are coming from automated testing.<\/li>\n- add suffix:<\/strong>
\nuse reference value read by the previous action and add suffix specified in the parameter. This might be useful to indicate other systems that messages are coming from automated testing.<\/li>\n- Read variable from the previous case:<\/strong>
\nThis procedure can be used only for test cases run in sequence. It will load the variable value from the previous test case. The variable name from the previous test cases must be provided as a parameter. Test cases are linked in sequence in the test cockpit.<\/li>\n<\/ul>\nAction<\/span><\/strong> – Populate value for a new message<\/p>\n
- \n
- Read variable from DB res (XPath):<\/strong>
\nPopulates variables with data obtained from the Data Base.\u00a0 As a prerequisite, the configuration object must contain database comparison rules<\/a> and choose for comparison tables and fields that later on will be loaded to the variable. The field and table are specified in the parameter as XPath expression.
\nif there would be more than one value then all of them will be returned. Additionally, you can extract a particular row by adding its number. I will present you with such a case in the example section.<\/li>\n- Read variable from eCATT log (XPath):<\/strong>
\nIf test type is eCATT a variable can be populated from the eCATT<\/a> execution log. The value is obtained from the log using the XPath expression. see details here.<\/li>\n- Read variable from outbound msg (XPath):<\/strong>
\nApplicable only for the outbound test types. Populates variable with data fetched from outbound message using XPath or flat expression after test case execution. The expression is passed in the parameter field.<\/li>\n<\/ul>\n<\/p>\n
Action<\/span><\/strong> – Locate new message using a variable value<\/p>\n
- \n
- Find using XPath:<\/strong>
\nThis procedure will search all middleware messages of the current tested interface from a recent period to look for value loaded by action populate variable before execution<\/strong>.
\nThe value will be checked in the field specified by XPath or flat-file expression and passed as a parameter.
\nThe XPath expression, like in other cases, must be ended with text() function.<\/li>\n- XPath value contains Variable:<\/strong>
\nSimilar to Find using XPath<\/strong> procedure but it will not require the variable value to be equal to the value extracted by XPath expression.
\nIt will check if the value extracted by the expression contains the variable value.<\/li>\n- The variable contains XPath value:<\/strong>
\nSimilar to the previous procedure, however in this case the variable needs to contain the value extracted by the expression.<\/li>\n<\/ul>\n<\/p>\n
Processing Parameter<\/span><\/strong> is an input string with instruction that is consumed by the variable procedure.
\nAs pointed in the variable procedure explanation points most of the time for processing the parameter you need to provide an XPath<\/a> or flat-file<\/a> expression.<\/p>\n<h3id=”4″>Example Int4 IFTT variables configuration<\/p>\n
Let me provide you with an actual use case scenario.
\nWe have Inbound Sales Orders documents through SAP PO to our SAP S\/4 HANA system (IDOC: ORDERS05, message type: ORDERS). After the document gets posted, automatically there is a Sales Order<\/p>\nConfirmation document generated and send back (IDOC: ORDERS05, message type: ORDRSP).
\nWe want to test this scenario end to end, that means, we are going to validate:<\/p>\n- \n
- The inbound Sales Order actually posted IDOC<\/li>\n
- The outbound Sales Order Confirmation the actual outbound message from PO<\/li>\n<\/ul>\n
In order to validate those two types of documents, we will need two Int4 IFTT Automation Objects.
\nOne for the Inbound interface and one for the Outbound. The test cases need to communicate with each other in order to identify the right Sales Order Confirmations based on each Sales Order. This communication between the test cases is possible after configuring the Int4 IFTT variables. So let’s go and have a look at a step by step configuration for this scenario.<\/p>\nThe Int4 IFTT variables configuration is under the Int4 IFTT Automation Objects.
\nGo to transaction \/int4\/iftt_conf_mass and create a new Int4 IFTT Automation Object<\/a>.<\/p>\nSelect the Automation Object that you want to configure and double click on Variables.
\n<\/span><\/p>\n<\/a><\/p>\nNew Int4 IFTT Automation Object VARIABLES_SALESORDER<\/em><\/p>\n
<\/p>\n
Create a new variable.<\/p>\n
Select it and double click on Variable Processing.
\n<\/span><\/p>\n<\/a><\/p>\nNew Variable DOCNUM for Automation Object VARIABLES_SALESORDER<\/em><\/p>\n
<\/p>\n
One more interesting thing that we want to implement at this point, is creating a new document number for every test case execution. This way we are going to avoid posting duplicates on both systems, our posted document will have a unique predefined document number and we are going to be able to identify the documents created by Int4 IFTT.<\/p>\n
So, the first Action<\/strong><\/span> that we need is “Read variable before execution”<\/strong> and we choose the variable processing “Read variable from the saved message (XPath)”<\/strong>. For processing parameters, we need to provide the actual XPath expression. In our case:
\n\/\/E1EDK02[QUALF=”001″]\/BELNR\/text()<\/p>\nIn order to create a new document number, I will use another interesting feature of Int4 IFTT, the Number Ranges<\/a>. I created a proper Number Range for this scenario named NR_DOCNUM.<\/p>\n
<\/p>\n
Now, we need the “Generate Value for new message” Action<\/span><\/strong> and “Generate value from number range”<\/strong>\u00a0as variable processing. For processing parameters just provide the Number range name.<\/p>\n
<\/a><\/p>\nVariable Processing Configuration for variable DOCNUM<\/em><\/p>\n
\nThe first Int4 IFTT Automation Object is ready. Now, let’s configure the second one.<\/p>\n
Again, create a new Automation object and create a new Variable for it.<\/p>\n
<\/a><\/p>\nNew Variable DOCNUM for Automation Object VARIABLES_SALESORDERCONF<\/em><\/p>\n
\nThe first variable processing action<\/span><\/strong> for this Object will be again “Read variable before execution”<\/strong>. But now as a variable process, we choose “Read variable from previous test case”<\/strong>\u00a0and provide as a processing parameter the name of the variable from the previous automation object. This way you can pass variable values from one test case to another. Please note that variables can store multiple values during one test case execution.<\/p>\n
The last a<\/span>ction<\/span><\/strong> that we need is “Locate new message using the variable value”<\/strong>\u00a0and the procedure “Find using XPath”<\/strong>. The last thing is to provide the correct XPath expression in the Processing Parameter.<\/p>\n
<\/a><\/p>\nVariable Processing Configuration for variable DOCNUM<\/em><\/p>\n
\nThat way you can create sequential test cases to any document type of this kind.
\nYou can read more about testing end-to-end business processes<\/strong><\/a>, with a great complete testing example, in the blog “Testing business processes with Int4 IFTT”<\/a>\u00a0by Krzysztof \u0141uka.<\/p>\nSummary<\/h2>\n
Int4 IFTT variables form the core configuration for smart and effective regression testing. After reading this article, you should understand the functional and technical details about the Int4 IFTT variables. Moreover, now you should be able to configure the Int4 IFTT variables on your own.<\/p>\n
Do not forget to check out the rest of our Int4 blogs<\/a> and learn more interesting features of Int4 IFTT. If you want to find out more about this (or other) Int4 IFTT features, just book a consultation with the product demo or contact us<\/a>.
\n<\/span><\/p>\nRead also<\/h4>\n
1. Int4 IFTT Integration with SAP Solution Manager Test Suite<\/a><\/p>\n
- XPath value contains Variable:<\/strong>
- Read variable from eCATT log (XPath):<\/strong>
- Generate GUID:<\/strong>
- Read variable from the previous case:<\/strong>
- Generate value for a new message:<\/strong>
- Populate variable before execution:<\/strong>
- In which regression testing scenarios we use Int4 IFTT variables<\/a><\/li>\n