Skip to content

Latest commit



187 lines (132 loc) · 6.45 KB


File metadata and controls

187 lines (132 loc) · 6.45 KB

This documentation follows the arc42 template for architecture documentation (

1 Introduction and Goals

1.1 Requirements Overview

  • Extract model information from a SAP system to be analyzed with Moose and Moose2Model.

  • Provides where used informations over multiple levels.

  • Provides informations what is used (Downsearch).

1.2 Quality Goals

  • Easy to install

  • Easy to upgrade

  • Does not extract code (Potentially sensitive information shall not be extracted)

  • Does not write into the system (Does not destabilize the system)

  • Extracts an application that contains of about a view 1000 elements in a few minutes

  • Is not able to handle an inconsistent Where Used Index of the extracted SAP system

1.3 Stakeholders

Table 1. Stake Holders
Role/Name Expectations

SAP Developer

Get an overview of the coding elements, there dependences and links to simplify opening them in an editor

Software Architect

Get an overwiew of the coding elements. Have the opportunity to display dependencies on class and package level.

System Owner

Protect coding. Prevent the system from activities that might destabilize it.

2 Architecture Constraints

  • Has to be easy to install in the analyzed system. A single report with texts should suffice.

  • Does not write any information in the analyzed system.

  • Uses only a file import to extract informations. Web Calls and other techniques are not allowed.

3 System Scope and Context

Components of SAP2Moose. Contains also components to maintain, test and documentate (including images used to documentate).

SAP2Moose Components
Table 2. Explanation
Component Explanation

SAP2Moose (Global classes and report templates

To simplify the development, SAP2Moose is developed using global classes

Report to convert global to local classes to make a simple ABAP report

This is the coding that converts global classes to local classes of the report that runs in the analyzed SAP system


This contains sub components to explain better how texts and images of the documentation are maintained

png file

The information how the png file is build is part of the image file. This is an option when it is exported from Open the file with to be able to edit it and include a copy of the diagram when you export it.

4 Solution Strategy

Table 3. Solution Strategy
Challenge Solution

Install logic as a single report without making the development more complex

Develop with global classes. Convert the coding to local classes of a single report before installation.

The extractor shall run in older SAP releases

Do not use modern ABAP statements in the main logic. Use modern in unit tests and supporting code as these are not part of the single report that runs in the analyzed system

The extractor shall be fast and reliable

Do not use SAP method and functions to read code components and where used information. Reading the database tables is faster and more robust.

5 Building Block View

The following diagram visualizes the main components that are called when an extraction is done.

The diagrams in this chapter show the global classes and the report template Z2MSE_MOOSE_EXTRACTOR2 that are used during development. The report that is used for the extraction can have any arbitrarily name. The classes are then local classes with a slightly different name.

Block diagram level 1

6 Design Decisions

6.1 Read system informations

Table 4. Decision Strategy reading


Performant, stable, independend from SAP releases


1. Read database tables directly. 2. Access SAP functions or methods (preferrable API)


1. Reading database tables directly fullfills all criteria

6.2 Determine dynamic usages

Table 5. Decision Strategy dynamic usages


Independend from the SAP2 Moose extractor, shall be able to use application specific logic, shall be able to reflect tables that specify dynamic calls.


1. Provide an application specific class that can be used by SAP2Moose during extraction. 2. Store informations about dynamic usages in Moose2Model


1. The possibility to implement an application specific class that can be used by SAP2Moose fullfills all criteria.

7 Risks and Technical Debts

7.1 Documentation insufficient

The documentation is sometimes confusing. There may be old informations. The installation is not completely explained. Users may experience problems when they install the development coding in some cases. This is not explained in the documentation.

7.2 No proper communication about the benefits and need for the tool

Due to a failure to communicate the benefits and need for the tool, there is no community big enough to maintain and support the project in the long range.

7.3 Release dependency

Using SAP2Moose to extract SAP systems with very different releases is currently not well supported in the project. There is only a single branch that focuses on the most recent SAP releases.

7.4 Error handling

Errors that could be deteckted during extraction are not reported to the user.

7.5 Completeness

It is not fully transparen what is extracted and what is not extracted. This is especially problematic in case of down search.

7.6 No dumps

Especially the down search is currently quite unstable. Dumps occur often when the down search is done over many levels.

7.7 Runtime

The extraction takes for typical projects often minutes. The down search is generally slower than the up search.

8 Glossary

Table 6. Glossary
Term Explanation

Down Search

Search for what an element is using. This is currently not supported in the Where Used function of SAP.

Up Search

This is similar to the Where Used function of SAP. Not all is found as in Where Used. On the other hand interfaces, redefinitions and dynamic usages may be found in an Up Search of SAP2Moose