In this article you will learn:

Reading time: 5 minutes

Introduction

Testing of interfaces can be a challenging task, especially in complex environments. Very often the ambition is to test interfaces end-to-end, which is understandable but can bring more risks and delays to a project or even a single change request. An alternative to this approach, can be to focus on testing of the interface in the environment where the changes are implemented. This can speed up things significantly but requires tools to do this properly.

Manual vs automatic testing

When we are discussing the testing strategy with companies, we often hear that they perform their testing manually. Sometimes they have tools for test automation, but the integration area is rarely covered there. The reason for this is the complexity of the topic. If the ambition is to test interfaces always end-to-end then the usual choices are:

Manual testing can be a tedious and prone for error process. On the other hand, to be able to test automatically end-to-end, you need to invest (time and money) in a tool and its setup.

But maybe the real question is if we should always strive for testing end-to-end? My suggestion is to do this only when really needed, for example during UAT phase of a project. But on many occasions, testing of only the environment affected by change, for example whole SAP landscape, should be enough. That though, can be secured if you are equipped with the right tool, for example Int4 IFTT.

Decoupling SAP environment

Implementing SAP solution tends to be a big step for companies. SAP environments can be quite complexed, and they also need to be integrated with the remaining parts of the company (legacy) and with the external world. It is usually the case that these parts remain the same or are changed/replaced only partially.

If the main changes, as a result of a project, are happening inside of SAP environment, then you should put most of your focus and resources on testing that part. This applies also to testing interfaces. Yes, you still need to test end-to-end at some point, but for most of the project, testing SAP should be enough.
Instead of spending time on executing the necessary steps in legacy environment, where no changes were implemented, you can focus on the part that really needs to be tested.

Using Int4 IFTT you can secure that your new or changed SAP environment will work properly for messages arriving from outside (legacy or external) and will produce correct messages when sending them outside.

Int4 IFTT Virtualization

With Int4 IFTT you can virtualize all the systems which are integrated with your SAP environment. For your interface scenarios this means the following:

You can either do the virtualization of all systems (legacy applications, EDI providers, etc.) on the SAP middleware level (what you can see on the Figure below on the left hand side) or even virtualize the SAP middleware itself (along with all of the systems connected to it) in case you’d like to run very isolated testing – see the right hand side of the Figure below.

Figure 1 – Int4 IFTT virtualization and test automation

In both scenarios, you can perform mass testing as well. That gives you the ability to verify various alternatives and ensure that you covered all of them. For example, for inbound interfaces you can use messages that you pulled from your productive landscape and store them as test cases in Int4 IFTT. Then you can run them, which will send the messages, virtualizing the sender, into your development or test environment. Finally, Int4 IFTT can automatically verify the outcome of those messages. The automatic verification can be done for both the middleware platform (e.g. SAP PO, SAP CPI, Dell Boomi) and the application system (e.g. SAP S/4).

Summary

There are many benefits of using Int4 IFTT and the service virtualization that it provides. You can benefit from decoupling of your SAP environment from legacy and external systems and test it independently. You can put more focus on the changes implemented in SAP, and still make sure that your changes will not affect the other systems. By using the real messages exchanged with the “rest of the world” you can secure that your solution can process the incoming messages properly and produce correct messages that are sent outside. Thanks to the mass testing ability you gain confidence by verifying hundreds or thousands of possible alternatives, instead of only testing a few as it would be the case in end-to-end testing.

You can check out the rest of the Int4 Blogs in order to read about Int4 IFTT and other interesting SAP-related topics. If you want to find out more about the Int4 IFTT features, just book a session with the product demo or contact us.

Read also:

1. Testing SAP PI/PO Splitter with Int4 IFTT

2. Get advantage of the Int4 IFTT IDoc Message Selector during Test Case creation

The post How to virtualize non-SAP systems for SAP projects using Int4 IFTT to speed up testing appeared first on INT4.

Introduction

Application Interfaces are most usually part of a larger business process. They tend to play a significant role in these scenarios and being able to test them properly is important to ensure the entire process is correct.

As you know, with Int4 IFTT you can test not only the integration platform layer like SAP PO or SAP CPI (transport API testing) but also the backend applications like SAP ECC or S/4HANA (functional API testing). This article is a more detailed version of a Case Study that is also available on our website.

Reading time: 5 minutes

The challenge

In such scenarios, it is sometimes challenging to test an application interface as a standalone solution. For example, to be able to test an inbound interface that creates a purchasing invoice, you need a fresh set of the purchase order and inbound delivery. That means every time you want to re-test the invoice, you also need to create the preceding documents. Whether the preceding documents are created via interfaces, or they are created manually, in both cases you can include those steps as test cases in your Int4 IFTT test scenario.

Alternatively, if you need to test your sales process end-to-end, you need to cover a lot of steps, which might involve manual operations (e.g. picking, goods issue, etc.) or several inbound and outbound interfaces, which are all crucial pieces of the complete scenario. And all of them can also be part of your Int4 IFTT test scenario.

These testing capabilities are ensured by three Int4 IFTT functionalities:

The following example will present these features and explain how this is achieved.

Testing sales process end-to-end

In this example, we will have a look at an end-to-end order-to-cash scenario, configured by our Int4 Labs. This scenario starts with an inbound sales order message arriving from a customer and ends with a sales invoice being sent out to the customer. In between, there are also important steps of delivery creation, goods issue, and invoice posting in the backend system. All steps are executed automatically by Int4 IFTT.

The entire scenario is presented in Figure 1.

Figure 1 End-to-end sales process configured in Int4 IFTT

During the execution of this scenario in Int4 IFTT, the following steps are performed.

1. Sales order inbound

An inbound IDoc of type ORDERS.ORDERS05 is sent into the SAP S/4HANA. As a result, a new sales order document is created. The IDoc is created based on live data from the production environment or the SAP ECC that is going to be replaced by SAP S/4HANA.

The newly created document is validated by Int4 IFTT.

The validation is done on the field by field level. Each field of the new document is compared to the reference sales order document, which was originally created by original IDoc, and which is now the basis of our new test case.

Figure 2 Sales order document validation in Int4 IFTT

2. Sales Order confirmation

Sales order confirmation IDoc is sent from the newly created sales order. The outbound IDoc of type ORDRSP.ORDERS05 is validated by Int4 IFTT, where each field of the outbound IDoc is compared to the original outbound IDoc (same source as above).

Figure 3 Outbound IDoc validation in Int4 IFTT

3. Create delivery

In this manual step, an SAP eCATT script is executed in the backend system that will create an outbound delivery document. To create the new delivery, the number of the newly created sales order in step 1 is used as a reference.

The number of the delivery document is stored by Int4 IFTT for further use.

• Validate delivery

In this sub-step, the newly created delivery document is validated to confirm if it is correct.

Just to let you know, the recording and playback for testing the manual steps might be also done in other testing tools like Worksoft Certify or Tricentis Tosca and integrated with Int4 IFTT API validation.

4. Send ASN

Outbound IDoc of type DESADV.DELVRY07 is sent back to the customer and the complete message is validated. The delivery IDoc is validated automatically against the original IDoc.

5. PGI

Another eCATT script is executed, where the number of newly created delivery is used to perform pickling and post goods issues.

6. Create invoice

After successful PGI, the newly created delivery can be used to create an invoice document. Thanks to SAP eCATT integration, this is again a step performed automatically by Int4 IFTT.

• Validate invoice

The new invoice document is validated.

7. Send invoice

Outbound IDoc of type INVOIC.INVOIC02 is sent out to the customer and the entire message is, again, validated by Int4 IFTT.

All the above steps are performed automatically by Int4 IFTT and the test is available directly from the test cockpit. The tester only needs to select the scenario and execute it, and then wait for the results, which will be presented once the steps are finished. In the above example, the testing takes around 20-25 seconds.

Figure 4 Complete scenario results

We used IDocs as interfaces in this example for simplification. It could also be any other message format message, like EDIFACT, Enterprise Service, etc. There can be also many more steps in between, to match the business process in your company.

Key advantages

In this scenario you benefit from the following features:

All in all, this speeds up the testing process significantly. I have been to projects where manual testing of such scenarios would take days and would involve different teams and systems to execute and validate it. With Int4 IFTT you get it in seconds and at a very comprehensive level!

The post Testing business processes with Int4 IFTT appeared first on INT4.

Runtime Configuration defines the way in which the interface messages will be processed in SAP AIF.  This setting is usually used for SAP AIF interfaces using XML engine. Understanding the setup is important as it can affect the performance of the interfaces and it can have implications on   systems background jobs and interface queues.

In this blog, I will try to explain details of it, and describe the alternative settings and their effect on the way the messages are processed in SAP AIF.

Runtime Configuration is available at transaction code:

/AIF/PERS_CGR

We can define multiple Runtime Configurations and use them in parallel depending on the requirements. We decide which RC should be used when calling the XML enabler method:

/AIF/CL_ENABLER_XML=>TRANSFER_TO_AIF

In case we want to send multiple messages to AIF at once (packages) we can use the following method:

/AIF/CL_ENABLER_XML=>TRANSFER_TO_AIF_MULT

Both of those methods have parameters:

• IV_QUEUE_NS – namespace of the RC
• IV_QUEUE_NAME – name of the RC

By passing the namespace and name of the RC we are specifying which RC should be used to process the messages.

Main configuration options

Below is the description of the available fields for configuration of RC.

Processing types

“Online” processing

If Runtime Cfg. Active is set to ‘X’ and Run scheduled option is not selected, the messages will be processed in the same work process as the one when they arrive into AIF. For example, if the message arrives to SAP system as proxy message, and from there it is redirected to SAP AIF XML engine interface (using the AIF XML enabler class), then the message will be processed in AIF in the same work process as the one in which it arrived as proxy message.

Hint: In case you need to debug your interface, this is the only mode in Runtime Configuration, that will let you do that.

Background processing

If Runtime Cfg.Active is selected and Run scheduled option is selected, then messages will be processed in background jobs scheduled by SAP AIF Runtime Configuration. In that scenario, the following settings need to be maintained as well:

• Messages per Run – to specify how many messages should be picked for processing with background job for each run
• Messages per Package – only in case also the option Schedule Packages is selected. Then this setting controls how many messages will be picked to each package. Package is always a part of a Run.

Example 1.

With this setting AIF will collect 100 messages and once they are collected in the AIF persistence, AIF will execute a background job to process all 100.

Example 2.

With this setting AIF will collect 100 messages. Once they are collected, or if there are no more messages available in the AIF persistence, AIF will execute 1 main job for the Run and then this job will execute 5 jobs in parallel, 20 messages each) that will process their own package of messages.

The ‘Run Scheduled’ option gives us the possibility to process messages in background jobs, which are running in parallel. That, especially for interfaces that process many messages, can speed up the processing in SAP AIF. It can, though, also have an impact on the number of background jobs available in the system, when a larger batch of messages arrives.

There is one more option available within the Runtime Configuration, which is called ‘delayed’ background processing of messages. In that setup we have also a control on when the messages will be processed, as we are in charge of scheduling the processing job (program /AIF/PERS_RUN_EXECUTE). This mode is enabled when the ‘Run scheduled’ option is checked but the ‘Runtime Cfg Active’ setting is unchecked.

Details of this setup, as well as pros and cons for each scenario, will be described in the second part of this blog – coming soon!

The post Runtime Configuration Options in SAP AIF appeared first on INT4.

New SAP PRESS book

Int4 SAP PRESS books

The post New E-Bite from Int4 on SAP AIF appeared first on INT4.