Architecture of the eCATT OData Test Automation

Architecture of the eCATT OData Test Automation: This document describes the technical background of the OData Test automation with eCATT.

If you are rather looking for hands-on information on how to create automatic OData tests, click here.

How Does OData Work at SAP?

As shown in the picture below (click to enlarge), an OData service is delivered by a server, which can be an SAP ABAP system, an SAP HANA system or any other SAP or SAP vendor software system delivering services according to the Open Data Protocol. The client which invokes a service can be anything outside the server, for example a user interface program, a mobile device, a user interface server or another business system. Naturally, also a test program can act as a client against the OData service provider.

In OData, data is made available in data chunks called data entities. One example for an entity is a sales order. The reason to make data available in entities is that they are easier to consume, which is especially important in the mobile area.

Technically, the OData service defines a number of entity sets (table of entities) with their properties (table structure fields) and relations between entities for a specific business. There are operations to act on the entity sets (the CRUD operations create, retrieve, update, delete) and functions which can read or process one or multiple entities.

The definition of the specific business service as OData service can be accessed from a client by retrieving the service metadata document.

The OData protocol relies mainly on the REST principle, on the data transfer via HTTP protocol and on a data format which is either XML-based or JSON.

eCATT OData Test Architecture

The eCATT test support for OData offers the following advantages:

• It accesses the service via HTTP(s) from a test client outside the service provider.
• It provides access to both the data and the functions of the service in an object-based manner; in other words, the test developer won’t operate directly with XML or JSON.
• It integrates the service calls and tests into existing test capabilities and test management systems for integration testing in SAP’s IT infrastructure.

The underlying architecture is as shown in following diagram (click to enlarge), which shows a number of participating objects in two layers:

 

Service Access Layer

The (HTTP) calls to the System Under Test to invoke OData services are processed in the OData library of SAP NetWeaver and encapsulated in a general technical layer.

Client access to business data provided by the service is implemented in ABAP classes, which can be generated by the eCATT OData Assistant tool for each individual OData service. These generated classes will include type definition for business data (entity types) of the service in one super class including support for all entity types and complex types of one entity container. The generation process will build sub-classes, one for each entity set, to include methods for the data access and methods for CRUD operations (create, retrieve, update, delete).

Invoking the public methods of the generated classes can result in:

• access to service metadata as XML stream
• retrieve of entity data in ABAP internal tables
• creation / update / deletion of entities
• invoke of functions of the OData service for specific business

Although the classes generated by the eCATT OData Assistant could be changed and modified by a developer in a development system, you are not encouraged to do so, since future changes in the service metadata model might affect and invalidate the generated classes which then will lead to the need to again use the assistant to regenerate the classes. Re-generation and overwriting of existing OData Service Client classes will be possible only for “untouched” classes.

Selected options and user input of the first generation is currently not persisted, so the user has to provide his or her entry again at the next use of the Assistant. It’s advisable to use the same settings especially the same “name proposal” to generate similar classes, which will match the eventually already existing test classes.

Test Objects Layer

Building a test automation of a test scenario against an OData service from the eCATT perspective means to invoke the service operations in a given logical order using defined test data. This can be achieved by calling the methods of the above described OData service access classes.

The frame to carry the test algorithm can be implemented in any ABAP module or eCATT test script, which will invoke the methods of the generated OData service access classes.

The eCATT OData Assistant provides the option to also generate integration tests in a global ABAP Unit class which builds one set of possible tests. These tests can use test data stored in eCATT test data containers, which are also generated and filled with test data during the Assistant’s test generation process.

Of course, the test developer can modify and enhance the generated test modules according to his or her test projects needs. The generated ABAP Unit tests could be considered as show case how to call the service access classes. You are encouraged to enhance the generated methods, to implement more test methods and even completely new classes calling the service access classes to enrich your test scenarios.

Testing OData Services Automatically

If you want to know how the automatic testing of OData Services functions practically, click here.