Introduction

We all experience a constantly increasing number and impact of various applications and IT solutions aimed at solving our everyday problems and making our lives easier. Usually, from a user point of view, our interaction with these apps ends as soon as we click a button and complete a task or obtain information we were interested in, and we are not aware of what actually happened behind the scenes at the time.

But it’s worth realizing that the solutions we use are typically only a piece of a larger puzzle of various IT systems integrated with each other. These integrations can be made through Application Programming Interfaces (APIs), thus they can be considered as fuel that drives innovations. However, fuel is only part of the success, so you also should use the right vehicle which in the solution described in the first article of this blog series is the API Management (APIM) capability of SAP Integration Suite on which I will shed some more light in this text.

API Management – overview

In the context of dynamically increasing number of interfaces, APIM plays the role of a central point which allows you to keep everything under control. Thanks to such functionalities like creation, maintenance and monitoring of APIs you should be able to ensure business continuity of your services and ultimately monetize solutions exposed to your partners. What’s important – all of this can be done via configuration instead of coding, which simplifies and speeds up the process from API creation to its publication to the outside world.

SAP API Management provides secure and scalable access to different assets, which in general may be divided into two parts:

•       implementation and configuration done in the API Portal,
•       exposure and consumption operated in the Developer Portal.

Based on this, we can say that APIM aggregates two basic perspectives – on the one hand we have a platform where admins can create and manage their APIs, and on the other a place that enables developers, customers and partners to consume and use them.

Usage in a practical scenario

To demonstrate the usage of API Management in real life, let’s take a closer look at the scenario presented in the blog mentioned at the beginning of this article, where the general concept of the solution is described. In this example, APIM plays the role of an intermediary that exposes the whole solution implemented using the SAP BTP technologies to the outside world.

From a technical point of view, the API exposed via API Management is connected to the SAP Cloud Application Programming (CAP) model app and thus HANA cloud database, which makes the data available to anyone who wants to use our API.

Figure 1. Architecture overview of API Management

Being more precise, the connection to the SAP CAP app is configured in the API Provider that is then used inside API Proxy, which is an object that can be considered as the “heart” of APIM as it contains the logic and most of the API settings. And due to the fact that in today’s digital world security should always be a priority, some additional policies have been applied to the exposed services, namely the unique key for executing the API, which limits the access to the resources in a simple and effective way. But please bear in mind that there are many more possible safety rules that can be implemented, both at the level of API request and data received in the API response.

The next important object is the Product, which is the unit of API exposure in the Developer Portal, so that it can be visible to the outside world. And this is a point where you can actually make money out of the API based on different business models, e.g. based on a fixed monthly fee for API subscription or a rate depending on the number of API calls. But regardless of the rate plan you choose, please note that API Management provides a built-in engine that generates billing.

Last but not least, we should not forget about the monitoring features available in APIM, which allows supervising the entire solution and its use by the partners and customers. In our scenario it means that, among others, we can get info on the number of sales orders created or deleted via exposed APIs, as well as keep an eye on many other helpful statistics.

Summary

Application Programming Interfaces play a key role in modern business as they allow simple and scalable exposure of IT solutions and the use of SAP API Management can boost it to a higher level. I’m aware that in this article its capabilities have been captured from a helicopter view, but we’d be more than happy to come down from this perspective and see how our solution can help your business as well!

Read also:

1. Expose your data in a fast and reliable way in real time with SAP BTP

2. How to simplify your day-to-day operations with SAP Event Mesh

The post How SAP API Management can benefit your business? appeared first on INT4.

In this article you will learn:

Reading time: 4 minutes

Introduction

Test-Driven Development is a development approach relying on software requirements being converted to test cases before the software implementation. It is based on a simple idea, where you first create a test to verify the code which will be implemented afterwards and then do refactoring of the development (this cycle is presented in Figure 1.). Such a methodology has many advantages. Already at the beginning of creating a new functionality you know what conditions must be fulfilled to consider its implementation as correct. Despite this, it is still a rarely used practice, especially in SAP projects. Even though there are tools that allow its enablement, such as ABAP Unit Test Framework available in ABAP Development Tools or when it comes to the SAP integration area – Int4 IFTT.

Figure 1. Test-driven development life cycle

Enablement of Test-Driven Development for SAP APIs

The idea behind the TTD practice for SAP Application Programming Interfaces (APIs) is generally the same as in the context of classical software development. Whereas in terms of creating SAP interfaces, a useful thing is that often even before the implementation starts, we already know what input/output messages we expect for the systems involved into the interface to be created. This conclusion is used by one of the new Int4 IFTT functionalities called Int4 IFTT Test Case Loader. Thanks to this functinality you can upload test cases into the testing tool. Thus using the Int4 IFTT you will be able to improve application of the Test-Driven Development key elements while creating SAP APIs, i.e. first of all create test cases and then on their basis validate the implemented scenario, which in turn allows the refactoring and optimization of the solution being created.

Int4 IFTT Test Case Loader

Overview

The Int4 IFTT Test Case Loader is a feature thanks to which you can create test cases by uploading payloads extracted from external middleware (also non-SAP) into Int4 IFTT tool since it can cater for uploading of XML and flat files. It means that this functionality may be particularly useful in e.g. SAP PI/PO migration projects but as well when creating new SAP interfaces from scratch. The Loader feature enables uploading a single test case (consisting of a pair of input and output payloads) or mass upload from a folder using regular expression to match the input/output files. To support execution of test cases in SAP PI/PO, uploaded payloads are wrapped with SOAP XI3.0 envelope before being stored into Int4 IFTT database.

Figure 2. Int4 IFTT Test Case Loader main screen

Usage

To upload and create test case(s) using Int4 IFTT Test Case Loader you need to fill in some data on the main screen visible in Figure 2:

1. Firstly, in the File Selection section, you should choose one of two test case creation modes:

2. In the IFTT Test Case Details section choose the folder from Int4 IFTT Cockpit in which the test case should be saved and also select Int4 IFTT Automation Object for the test case.

3. Next, in the Interface Details section provide the details about the tested scenario.

4. Finally click on the “Execute” button and upon completion of processing the results will be displayed as shown in Figure 3.

Figure 3. Int4 IFTT Test Case Loader result screen

After completing all of the above steps, you can go to Int4 IFTT Cockpit and execute the newly created test cases.

Summary

Test-Driven Development is one of the fundamental techniques of creating various IT solutions. In order to fully benefit from this approach, it is worth to use tools that facilitate its implementation. Of course, some activities cannot be automated and must be done manually but where automation is possible (i.e. in case of creating and executing test cases) it will significantly help to optimize the software development process. And this will allow you to focus on the implementation part of the development cycle and result in creating better IT solutions, which is the main purpose of TDD technique.

This article has only shed some light on how the Test-Driven Development approach can be implemented in the area of SAP integration using Int4 IFTT Test Case Loader. So if you would like to find more about this (or other) Int4 IFTT features, I encourage you to read the detailed documentation available on our Wiki Page.

The post Test-Driven Development with Int4 IFTT appeared first on INT4.

In this article you will learn:

Reading time: 6 minutes

Introduction

Int4 IFTT is a tool that allows testing of different types of SAP interfaces and business scenarios. Many of them use the EDI (Electronic Data Interchange) standard to communicate business objects like sales orders, invoices, etc. between business partners. EDI allows the interchange of data between many partners without modifications or developments of new interfaces for every partner because it provides a generic and standardized definition of business documents. And therefore this type of communication is often used in B2B (Business-to-Business) scenarios, where there is a need to exchange large amounts of data between trading companies. In order to optimize such processes, instead of sending multiple messages separately a more efficient solution may be to transfer one EDI file containing many transaction data which can be divided into individual messages. On the one hand, such a solution may provide benefits through the reduction of transmission costs (because of sending single instead of multiple files), but on the other hand, it may complicate the interface logic. But for this purpose, you can use the Int4 IFTT tool, thanks to which you will be able to test such scenarios. And in case of changes or developments in the interface logic, apply automatic regression testing as well.

EDI Splitter test scenario

This article covers testing of a scenario where several purchase orders are created from one input EDI message after processing in SAP PI/PO (thus a process in relation: single input to multiple outputs). An example of such a B2B integration scenario in which the Splitter adapter is used is presented in Figure 1.

Figure 1. EDI Splitter test scenario diagram.

The presented case consists of two ICOs (Integrated Configurations) in SAP PI, whose basic technical information are as follows:

1. The first ICO receives a collective EDI message from the EDI partner and sends it to the EDISeparator adapter (Outbound Processing tab in Figure 2):

Figure 2. Input ICO’s Outbound Processing configuration.

2. The second ICO receives the collective message via the EDISeparator channel (Inbound Processing tab in Figure 3) and then the message is being separated and filtered by type to single IDOCs:

Figure 3. Output ICO’s Inbound Processing configuration.

Configuration in Int4 IFTT

In order to test SAP PI/PO processing for a scenario using a B2B EDI Splitter we need to connect two types of the Int4 IFTT test cases (of type PI GUID E2E Inbound and PI E2E Outbound). We cannot use the standard PI Unit Test type, because the scenario consists of two separate ICOs.

UNA:+.? '

UNB+UNOA:3+0000000EDI_T:ZZ+0000000ECC:ZZ+20051107:1159+6002'

UNH+000000101+ORDERS:D:96A:UN:EAN008'

BGM+220+DD05847+9'

DTM+137:20051107:102'

NAD+BY+00500100::9'

NAD+SU+4012345000094::9'

LIN+1+1+CE_EXC_100:IB'

QTY+1:10'

LIN+2+1+CE_EXC_300:IB'

QTY+2:10'

LIN+3+1+CE_EXC_CLAMP:IB'

QTY+3:10'

FTX+AFM+1++XPath 2.0 Programmer's Reference'

UNS+S'

CNT+2:4'

UNT+22+SSDD1'

UNH+000000101+ORDERS:D:96A:UN:EAN008'

BGM+220+DD05848+9'

DTM+137:20051107:102'

NAD+BY+00500100::9'

NAD+SU+4012345000094::9'

LIN+1+1+CE_EXC_100:IB'

QTY+1:10'

LIN+2+1+CE_EXC_300:IB'

QTY+2:10'

LIN+3+1+CE_EXC_CLAMP:IB'

QTY+3:10'

FTX+AFM+1++XPath 2.0 Programmer's Reference'

UNS+S'

CNT+2:4'

UNT+22+SSDD1'

UNH+000000101+ORDERS:D:96A:UN:EAN008'

BGM+220+DD05849+9'

DTM+137:20051107:102'

NAD+BY+00500100::9'

NAD+SU+4012345000094::9'

LIN+1+1+CE_EXC_100:IB'

QTY+1:10'

LIN+2+1+CE_EXC_300:IB'

QTY+2:10'

LIN+3+1+CE_EXC_CLAMP:IB'

QTY+3:10'

FTX+AFM+1++XPath 2.0 Programmer's Reference'

UNS+S'

CNT+2:4'

UNT+22+SSDD1'

UNZ+1+6002

As you can see, the incoming EDI message consists of three same messages which in the next step will be divided into single messages. In order to identify each of these messages in the Int4 IFTT automation object you should define a unique variable (in this case purchase order number) which will allow to connect the input and output the Int4 IFTT test cases:

Figure 4. Configuration of the Int4 IFTT automation object for input test case.

Figure 5. Configuration of the Int4 IFTT automation object for output test case.

Testing in Int4 IFTT

After creating the appropriate automation objects configuration, you can go to the Int4 IFTT Cockpit and create test cases for interfaces. In tested scenario there is one input EDI message and three IDOC output messages, therefore you should create one test case of type PI GUID E2E Inbound and three test cases of type PI E2E Outbound:

Figure 6. Created Int4 IFTT test cases.

However, attention should be paid to defining the Parent ID for “child” test cases (marked with a yellow frame in the Figure 6) to correctly link them together.

Finally, select all created Int4 IFTT test cases and execute them. As a result you will receive the Test Execution Report visible in Figure 7.

Figure 7. Int4 IFTT Test Execution Report.

Summary

The EDI splitting is a common approach in B2B integration and it is important to correctly test and prevent errors in such scenarios. Therefore, bear in mind that testing even complex SAP interfaces can be facilitated and automated with the use of Int4 IFTT tool. If you would like to learn more about the testing approach presented in this article, I encourage you to read the detailed documentation available on Int4 IFTT Wiki Page.

And 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. Get advantage of the Int4 IFTT IDoc Message Selector during Test Case creation

2. Int4 IFTT and SAP Test Suite integration – Business Scenarios

The post Testing SAP PI/PO Splitter with Int4 IFTT appeared first on INT4.