Introduction

Service virtualization and testing (SVT) solutions like Int4 IFTT (Certified ABAP add-on for SAP Solution Manager – SAP Solman) provide SAP developers and SAP functional consultants with ways to quickly simulate the interfaces/APIs of any 3rd party, non-SAP systems as well as B2B/EDI partners. Simulating those external systems allows to quickly run test scenarios during the development (DEV) and integration (SIT) phases of the project. This allows your SAP S/4HANA projects to be delivered and tested on time and within budget.

Reading time: 3 minutes

What are the 3 main problems during SAP S/4HANA transformation projects which can be solved by SVT solutions like Int4 IFTT?

1. Decouple – 3rd party systems and EDI partners either don’t exist or are very difficult to reach. This means that testing some of the most crucial SAP business processes depending on those (Order to Cash, Purchase to Pay, or Logistics) will be very complex and time-consuming. That can lead to project budget increases and lower customer satisfaction.
   
2. Eliminate delays – manual creation of mockups is either very time-consuming (transaction WE19) and cannot be reused or does not work at all (in case of outbound IDOC messages, ABAP proxy messages). Working in a decoupled SAP environment is not possible without proper service virtualization.
   
3. Stay in control – the time to create and maintain non-existing, before the SAP S/4HANA project, 3rd party non-SAP systems cause one issue – all SAP developers and Functional consultants need to wait to have their business processes tested.

How can I start using service virtualization & testing solutions for my SAP S/4HANA project?

Int4 IFTT is a script-less SAP API testing tool that secures the growth of companies eliminating the risk related to manual entering of data. Thanks to the service virtualization of connected systems, testing of SAP environment undergoes without third-parties involvement. Int4 IFTT lets you run all tests independently providing you the best conditions for development.

To learn more about int4 IFTT, visit our product page. You can apply for a trial licence of int4 IFTT to discover how our solution might help your business. You may also want to check out our article on SAP Blog to learn more about SVT solutions like Int4 IFTT.

Don’t hesitate to hit us up and arrange a call where we can present to you the benefits of our solution and how it works in detail.

Also don’t forget to join our webinar on April 26, to learn how to simulate any 3rd-party system and EDI partner in no time and remove the delays caused by dependency on those non-SAP applications!

The post What are the 3 main problems during SAP S/4HANA transformation programs which can be solved by SVT solutions like Int4 IFTT? appeared first on INT4.

In this article you will learn:

In this article you will be able to find out how to enable self service testing for SAP S/4HANA projects so everyone who is interested will be able to execute test cases and not only the testing team members with specific skills.

Reading time: 5 minutes

What is the general problem with test automation for SAP S/4HANA projects?

On most of the typical SAP S/4HANA projects using testing can only be executed in two ways:

a) Member of a test team with specific test tool access and skills can run it

b) Testing can be run automatically in the background

What it means is that the majority of people involved in the SAP project cannot use any kind of test automation on their own, without asking the teams for help.

Why would you want to give access to test automation on SAP projects to all users?

Imagine you’re a retail or automotive company and have a huge purchasing organization using EDI to receive all inbound Purchase Orders from hundreds of your vendors. Each of your vendors has it’s own IT landscape where they do many IT projects so they ask you to send or validate EDI messages many times everyday. In order to help your vendors you need to maintain a large testing team whose only purpose is to communicate with your B2B partners to send them new EDI test messages and validate their own which are sent to your system.

Question:
What if you could give your vendors a self service tool so they could do the testing on their own?

How to implement Self Service testing (Citizen testing) for SAP S/4HANA projects?

With different communicators like MS Teams, Slack, chatbots like SAP Conversational AI SAP project members or B2B partners can communicate much more easily but why not use the same tools to allow them to communicate with SAP Testing tools? In case you need to speed up your testing and allow your SAP project members or B2B partners the possibility to run testing on their own you can simply create a BOT who will be executing the test cases for them. With Int4 IFTT we’ve already implemented such solutions for Slack (Figure 1)

Figure 1 – Slack bot to execute test cases for SAP S/4HANA projects

and SAP Conversational AI chatbot – Figure 2

Figure 2 – SAP Conversational AI chatbot – self service testing

Demo of the SAP Conversational AI chatbot self service testing

Summary 

This approach enables a complete self service testing giving anyone the possibility to run a specific set of test cases eliminating the need to have special tools installed and special skill sets.

Let’s make testing be available to everyone with citizen testing!

The post How to enable Self Service testing (Citizen testing) for SAP S/4HANA projects? appeared first on INT4.

In this article you will learn:

In this article you will learn:

Reading time: 5 minutes

Introduction

Int4 IFTT supports various interface types that can be tested in terms of SAP End-to-End testing. Synchronous and asynchronous, AIF, CPI, IDoc Interfaces and many more options to fill specific requirements. In this article, I would like to explain functional and technical details about testing IDoc interfaces using Int4 IFTT.

Int4 IFTT enables testing of standard IDoc interfaces as well as custom ones.

Configuration

In this section, I will show you in detail how to perform configuration steps required to test IDoc interfaces. The main step in the process is to create a Configuration (Automation) Object which is a
base object that stores all the rules for a single application interface to be tested.

We can divide IDoc interfaces into two groups depending on their directions:

The configuration looks very similar for both types. In this article, I will create a Configuration Object for an Inbound IDoc interface (IDoc ORDERS05).

Steps:

1. Navigate to Int4 IFTT Mass changes of configuration (tcode /int4/iftt_conf_mass) and click on the New Entries button. Enter object definition ID and description.

2. Provide IDoc details in the Service Interface Name column. Name of an IDoc interface should be a combination of IDoc message type, basic type and extension separated by a dot (.). You can find those details in the IDoc’s control record:

Therefore, in the above case you should enter ORDERS.ORDERS05 in the Service Interface

Name column, as below:

3. Navigate to the Variables section and define suitable variables. For our IDoc we need to define a variable for a Purchase Order number. Add new entry and provide Variable Name and Description and save your data:

4. Next, select the line with the variable you have just defined and go to the Variable processing section. In this step we need to define how the variable should be processed by Int4 IFTT.

To find more details about Variable processing please follow the article of my colleague, Konstantinos Tsakalos – Int4 IFTT variables explained.

In our scenario, we define two actions for PO variable:

5. Our next step is to define Database Comparision rules. In INT4 IFTT you validate the actual posted data in the SAP database tables (or even custom ones) by comparing its database entries. You can find more details about Database Comparision rules in our recent Int4 Blog, here: Database comparison rule explained.

As we are testing ORDERS05 IDoc, our goal is to compare the final document which will be posted at the end of the process – a Sales Order. Therefore, we need to compare tables connected to Sales Orders (for example VBAK, VBAP). Add tables which data you wish to compare. The tables are processed in sequence based on Step number.

6. After populating the table names with the additional parameters, save your entries, select the table you want to configure and double click on Selection Criteria. In our example, we want to fetch the data from table VBAK based on BSTNK (PO Number) field. We will use PO variable which will contain the actual test case PO number (that is the variable we defined in Step 3.).

Define Selection Criteria for the rest of your tables. For VBAP table we need to fetch the data based on the actual database values of the parent step. We will reference to the VBELN field of the Parent Table (VBAK). In this case, the criteria should be set as follows:

7. Select table from DB Comparison rule section and navigate to Comparison details. Now you define table fields which should be compared during test execution. You can define a Rule which would be applied when compared data is different or empty. Sample data for VBAK table:

8. Our last step is a definition of the Number range used in Step 4 – as we used option to Generate value from number range. Enter the Number range name (we used PO1), specify a meaningful prefix and define low and high values. Save your data.

After completion of the above steps we are ready to test our IDoc interface. It is possible to define additional steps like Matching Criteria/Data scrambling rules and few more – you can find information about these options in our blogs.

Test Case creation

To test an Interface, we need to create a test case. Go to the Int4 IFTT Cockpit (tcode/int4/iftt_tcockpit) and switch to Edit mode. Navigate to the desired folder and add new test case.

Fill in Test Case details: description, Interface Type (6 for Inbound IDoc and 7 for Outbound IDoc) and enter the Configuration Object name you have created in the previous section. At last, we need
to specify an IDOC number of the original IDoc which was already successfully processed and posted in Backend:

Save and execute your test case. An execution report will be displayed:

You can display detailed execution report by clicking on the Test Case name. SAP Backend Document validation will be displayed with the database entries comparison (for the original IDoc and the newly created one during Int4 IFTT test):

Summary

I hope with the help of this blog, you will be able to test your IDoc interfaces quickly and effectively. Since Int4 IFTT tests is based on comparing entries in the database, we can easily add custom tables to the configuration or even test a completely custom IDoc processing. Do not forget to check out the rest of our Int4 blogs 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.

The post Int4 IFTT – IDoc interfaces appeared first on INT4.

In this article you will learn:

Reading time: 8 minutes

Introduction

On my previous blog “Int4 IFTT Database Comparison Rules”, I am mentioning Int4 IFTT variables. 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.

What are the Int4 IFTT variables?

They are nothing more than simple configurable variables, which are used during the test case creation, execution, and validation.
Variables 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.

In which regression testing scenarios do we use Int4 IFTT variables?

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.

How Int4 IFTT variables process

You can define multiple variables for each Int4 IFTT Configuration Object. 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, a Variable Procedure, and a Processing Parameter.
Let’s get into some details of each Int4 IFTT variable processing configuration element.

Action 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.

There are four predefined actions to choose from, in order to fulfill your requirements:

• Populate variable before execution:
  This action is triggered before test case execution. It is used to load to the variable container the reference value.
• Generate value for a new message:
  This 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.
  Action 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.
• Populate variable after execution:
  This 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.
• Locate new message using variable value:
  This 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.
  The 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
  

Variable Procedure 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 action, there are different procedures available that allow us to accomplish various scenarios.
Please find below the list with the available variable procedures for each action.

Action – Populate variable before execution:

• Read variable from the saved message (XPath):
  Populate 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).
  Apart from loading value, the place in the message will be marked and used by the next action “Generate value for the new message” to substitute reference value with a new one.
  The 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.
• Read variable from the previous case:
  This 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.
• Read the user-defined value from the cockpit:
  The 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.

Action – Generate value for a new message

• Replace value with constant:
  The current value will contain the constant passed in processing parameter. The constant should be provided as is without any brackets.
• Generate GUID:
  Generate random value in a GUID format.
• Generate number from number range:
  generate 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 that was created for the particular variable.
• Generate random value:
  generates 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
• add prefix:
  use 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.
• add suffix:
  use 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.
• Read variable from the previous case:
  This 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.

Action – Populate value for a new message

• Read variable from DB res (XPath):
  Populates variables with data obtained from the Data Base.  As a prerequisite, the configuration object must contain database comparison rules 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.
  if 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.
• Read variable from eCATT log (XPath):
  If test type is eCATT a variable can be populated from the eCATT execution log. The value is obtained from the log using the XPath expression. see details here.
• Read variable from outbound msg (XPath):
  Applicable 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.

Action – Locate new message using a variable value

• Find using XPath:
  This 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.
  The value will be checked in the field specified by XPath or flat-file expression and passed as a parameter.
  The XPath expression, like in other cases, must be ended with text() function.
• XPath value contains Variable:
  Similar to Find using XPath procedure but it will not require the variable value to be equal to the value extracted by XPath expression.
  It will check if the value extracted by the expression contains the variable value.
• The variable contains XPath value:
  Similar to the previous procedure, however in this case the variable needs to contain the value extracted by the expression.

Processing Parameter is an input string with instruction that is consumed by the variable procedure.
As pointed in the variable procedure explanation points most of the time for processing the parameter you need to provide an XPath or flat-file expression.

<h3id=”4″>Example Int4 IFTT variables configuration

Let me provide you with an actual use case scenario.
We 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

Confirmation document generated and send back (IDOC: ORDERS05, message type: ORDRSP).
We want to test this scenario end to end, that means, we are going to validate:

• The inbound Sales Order actually posted IDOC
• The outbound Sales Order Confirmation the actual outbound message from PO

In order to validate those two types of documents, we will need two Int4 IFTT Automation Objects.
One 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.

The Int4 IFTT variables configuration is under the Int4 IFTT Automation Objects.
Go to transaction /int4/iftt_conf_mass and create a new Int4 IFTT Automation Object.

Select the Automation Object that you want to configure and double click on Variables.

New Int4 IFTT Automation Object VARIABLES_SALESORDER

Create a new variable.

Select it and double click on Variable Processing.

New Variable DOCNUM for Automation Object VARIABLES_SALESORDER

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.

So, the first Action that we need is “Read variable before execution” and we choose the variable processing “Read variable from the saved message (XPath)”. For processing parameters, we need to provide the actual XPath expression. In our case:
//E1EDK02[QUALF=”001″]/BELNR/text()

In order to create a new document number, I will use another interesting feature of Int4 IFTT, the Number Ranges. I created a proper Number Range for this scenario named NR_DOCNUM.

Now, we need the “Generate Value for new message” Action and “Generate value from number range” as variable processing. For processing parameters just provide the Number range name.

Variable Processing Configuration for variable DOCNUM

The first Int4 IFTT Automation Object is ready. Now, let’s configure the second one.

Again, create a new Automation object and create a new Variable for it.

New Variable DOCNUM for Automation Object VARIABLES_SALESORDERCONF

The first variable processing action for this Object will be again “Read variable before execution”. But now as a variable process, we choose “Read variable from previous test case” and 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.

The last action that we need is “Locate new message using the variable value” and the procedure “Find using XPath”. The last thing is to provide the correct XPath expression in the Processing Parameter.

Variable Processing Configuration for variable DOCNUM

That way you can create sequential test cases to any document type of this kind.
You can read more about testing end-to-end business processes, with a great complete testing example, in the blog “Testing business processes with Int4 IFTT” by Krzysztof Łuka.

Summary

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.

Do not forget to check out the rest of our Int4 blogs 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.

Read also

1. Int4 IFTT Integration with SAP Solution Manager Test Suite

2. SAP PI/PO migration with Int4 IFTT ? Pharmaceutical company Business Case

The post Int4 IFTT variables explained appeared first on INT4.