Approach for this blog
In this blog you will get an overview of:
- the options offered by the Landscape Transformation Validation Framework (LTVF) tool to reduce your testing efforts on various projects, including conversions and migrations to SAP S/4HANA.
- The opportunities to reduce the overall downtime during golive by automating validation/testing time.
Summary
In the context of your transformation projects, the testing and validation of results is often an important effort driver:
For example, if you have many organisational units (e.g. company codes, plants) and/or different and complex accounting structures to validate, a purely manual approach to these activities is both costly and error-prone.
Furthermore, if this process is not automated, it can add unacceptable time to the actual downtime in the cutover phase.
In this blog, I would like to provide an overview of the LTVF Landscape Transformation Validation Framework that helps overcome the above challenges.
This blog is based on a presentation and further information material I received from the architect and developer of this tool, Mikhail Isupov. Thank you, Mikhail, for the valuable information you have provided!
Structure of this blog
I will explain the concept of LTVF along the following topics:
- Business Value of LTVF
- Overview of projects, where LTVF can be used
- Which validations can be automated?
- Architecture of LTVF
- How is a validation project organised?
- Further topics to consider for an LTVF project
- Key Learnings for the use of LTVF
Business Value of LTVF
LTVF automates your tests and validations, it:
- reduces the overall testing-effort and validation costs of a project.
- reduces the overall system downtime during the Golive-Weekend.
During a Golive weekend, some final tests need to be performed before you can put a changed system back into productive use.
These tests, if only done manually, can take more hours than are actually available during the downtime. If all testing is done manually, there is also a risk that some detailed testing will be sacrificed to save a few hours or simply out of time pressure.
The testing effort is an essential part of any project. The atomisation that LTVF offers for testing will therefore significantly reduce the overall project effort.
Where can the automatic validation framework be used?
The automatic validation framework can be used in all projects where you need to compare a large number of values before and after a transformation.
Typical examples of such projects are:
The basic idea for the validation automation is as follows:
Part of the validation is always to prove the correctness of important figures, e.g. balances, stock values, etc... These figures are available e.g. in ALV reports, tables, text reports or files.
The LTVF tool extracts these data before and after transformation and compares them automatically. If transformation rules have been applied, they can of course be integrated into the LTVF tool so that the tool can also compare "oranges" with "apples". For a large part of the standard reports, there are already pre-configured solutions in the LTVF tool available, which only need to be configured with the organisational units to be tested/validated. For those areas where there are no preconfigured solutions yet, the SAP LTVF tool provides an effective framework to create new validation reports with little additional effort.
Which validations can be automated?
LTVF supports the automatic comparison and validation of the following items:
- Reports with ALV output
- Reports with text output and Files
- Tables
Post-processing logic can be applied to all these comparisons, allowing the comparison of different tables or reports. Transformation logic used in a migration or conversion project can be integrated into LTVF.
A few more functions are also available:
- Filters can be applied to focus on relevant data.
- tolerances can be set, e.g. if rounding differences are expected.
- for merge scenarios a conditional merge including aggregation and replacement functionality is available.
Not all available functions are listed here - with the LTFV functionality not only master and transaction data but also configuration data can be checked and automatically validated.
With the help of filters, it is seamlessly possible to limit the evaluation not to all data, but only to the last years.
The LTVF framework does not support the evaluation of interactive reports unless they have a background-compatible execution mode.
.
Architecture of LTVF
LTVF is deployed in a central SAP Netweaver system. In migration projects LTVF is often installed on the same server, that is as well used for the migration. The minimum release is 7.0 but 7.4 is recommended. It must be connected via rfc to all systems involved in the validation, the source and target systems, including the sandbox test systems.
The LTVF system is the central point to trigger the relevant validation activities, such as extracting the data from the source and target systems before and after conversion/migration
LTVF provides a versioning and history mechanism, thus comparisons of the results between different test-cycles can easily be performed.
Technical requirements:
Technically, it is possible to run an LTVF project with very limited technical resources, but this will increase the runtime to an unacceptable level.
We recommend guaranteeing at least 50 background processes for LTVF to perform extractions on the remote systems and 30 processes on the central system for evaluation. The exact planning depends on both the scope of the validation and the size of the system under test.
How is a validation project organised?
The Business Data Validation (BDV) team and the client jointly define the validation scope in a scoping workshop.
Based on the validation scope, the BDV team adjusts configuration and if required develops additional functionalities in the LTVF to cover the full scope of the project.
This is done in parallel with the preparations for the first test cycle of the migration (or conversion) project.
Immediately prior to the first migration/conversion, the BDV team takes a data snapshot of all report outputs and table contents that are eligible for validation prior to migration (conversion/migration) to capture the as-is status of the data. This status is stored in a compressed, non-readable format and can only be retrieved via transaction LTVF.
In the following step, the migration or conversion is carried out.
Then, based on the migrated or converted data, another data snapshot is created.
These two data snapshots are compared using the LTVF functionality.
The comparison of these extractions will show all types of results:
- Results with equal records in the source and target systems (as expected).
- Expected Records with the same key fields but different attributes, i.e. due to conversions and mappings.
- Data sets that are only present in the source and therefore missing in the target system or data that is not expected in the target system.
- Data with expected rounding differences
Last but not least, it is possible to filter irrelevant data from the results list. Sometimes we can’t apply filter criteria for the snapshot creation, but LTVF has an option to apply additional filter on any key or attribute so records will appear in a special out-of-scope category instead.
Since there are usually several test cycles, you can fine-tune these filters as the project progresses so that your testers can quickly see the relevant results.
It is important to mention that the test environment should be static during the time period when the first and second extractions are performed. If there are other activities besides the transformation between the extractions from the source and target systems, the differences created by these activities will obscure the results of the LTVF.
Key Learnings for the use of LTVF
From our LTVF projects we want to share the following key-learnings:
As in any project, preparation is key - i.e. especially if you intend to use LTVF in a project, this decision should be made at the beginning of the project and the LTVF team should be involved in the project from the beginning.
Similar to other projects, there are several test cycles and the quality and results will improve with each test cycle. It is not an option to involve the LTVF in a project only two months before Golive.
Testers need to be trained on how to use the LTVF interface for their tests - it is quite simple, yet a good introduction / training can avoid misunderstandings and save some time.
Last but not least, a piece of advice that has always applied and will always apply - no matter how many agile project method evangelists overestimate the possibilities of agile project methods:
Minimise scope changes between test cycles and aim for a clear scope of your project.
If you want advice or support within you SAP S/4HANA Hana migration project you may also reach out to the following email:
mailto:sap_dmlt_gce@sap.com.
