solution documentation for custom development

SAP® Standard: Solution Documentation for Custom Development

Version: 2.0

March 2009

Solution Documentation for Custom Development

Whitepaper

Active Global Support SAP AG

© 2008 SAP AG

Solution Documentation for Custom DevelopmentVersion: 2.0

of 52

SAP® Standard Solution Documentation for Custom Development Change history:

Version Date Changes

1.0 August 2008 Original version

2.0 March 2009 Updated version referencing new features for docu-mentation of custom code available with SAP Solution Manager 7.0 EHP1

© 2008 SAP AG

Solution Documentation for Custom Development Version: 2.0

of 52

SAP® Standard Solution Documentation for Custom Development

1 MANAGEMENT SUMMARY .................................................................... 4

2 SAP STANDARDS FOR E2E SOLUTION OPERATIONS....................... 5

3 TECHNICAL REQUIREMENTS OF PROVIDING DOCUMENTATION.... 8 3.1 Location and Format of Documentation Content .......................................................... 8 3.2 Documentation Language .................................................................................................... 8

4 REQUIREMENTS FOR MINIMUM DOCUMENTATION CONTENT ........ 9 4.1 Create Project in Solution Manager................................................................................... 9 4.2 System and Application Landscape................................................................................ 11

4.2.1 Documenting usage of 3rd-party software ................................................................... 12 4.3 Physical System Landscape ............................................................................................. 13 4.4 Solution Definition ............................................................................................................... 14 4.5 Business Scenario and Business Process Documentation...................................... 15

4.5.1 Starting with an SAP delivered business scenario .................................................... 16 4.5.2 Define missing business scenarios, processes and steps ....................................... 17

4.6 Application Components.................................................................................................... 20

4.7 Interface Documentation .................................................................................................... 21

4.8 Documentation of Background Jobs .............................................................................. 25

4.9 Transactions and User Entry Points ............................................................................... 28

4.10 Performance and Volume KPIs ......................................................................................... 29

4.11 Development object list for Custom Development or Customizing Objects ........ 30

4.12 Functional Documentation / Business Background ................................................... 31

4.13 Integration and Volume Test Plan Documentation...................................................... 32

4.14 Application Operations Guide........................................................................................... 33

5 APPENDIX.............................................................................................. 34 5.1 Template: Functional Documentation............................................................................. 34 5.2 Template: Test Plan Documentation ............................................................................... 37 5.3 Template: Application Operations Guide....................................................................... 49

© 2008 SAP AG


of 52


1 Management Summary With the increasing number of systems and technologies, the complexity of IT solutions is rising. The key to successful landscape planning and operation is an accurate and complete description of the solution landscape itself with all business processes. All reporting is based on this fundamental information. As part of SAP’s standards for End-to-End Solution Opera-tions, the standard for Solution Documentation describes in general how customers achieve the required transparency of their SAP solution.

On one hand, minimum documentation as described in this document lays the ground for leveraging many operation support functions offered via SAP Solution Manager (e.g. identifi-cation of affected custom business process by requested software or customizing change requests). On the other hand, it is important to get the documentation in a standardized loca-tion and format in order to ensure the optimal delivery of SAP support services.

Especially in order to enable SAP to deliver services for custom projects, a minimum amount of documentation is required regarding these custom projects. This document describes the required content of this documentation as well as the tools and formats to be used to deliver the documentation.

This paper starts with a brief overview of the end-to-end solution operations standards. Then it describes the general motivation and basic requirements regarding solution documentation for custom developments in chapter 3. Content of chapter 4 of this document is an explana-tion of what has to be documented and where to store the information. Finally, the appendix (chapter 5) displays templates which can be utilized for solution documentation of custom developments.

© 2008 SAP AG


of 52


2 SAP Standards for E2E Solution Operations Mission-critical operations is a challenge. While the flexibility of SAP-centric solutions rises, customers have to manage complexity, risks, costs, as well as skills and resources efficiently. Customers have to run and incrementally improve the IT solution to ensure stable operation of the solution landscape. This includes the management of availability, performance, proc-ess and data transparency, data consistency, IT process compliance, and other tasks.

Typically, multiple teams in the customer organization are involved in the fulfillment of these requirements (see Figure 2.1). They belong to the key organizational areas Business Unit and IT. While the names of the organizations may differ from company to company, their function is roughly the same. They run their activities in accordance with the corporate strat-egy, corporate policies (for example, corporate governance, compliance and security), and the goals of their organizations.

Figure 2.1: Organizational model for end-to-end solution operations

The different teams specialize in the execution of certain tasks: On the business side, end users use the implemented functionality to run their daily business. Key users provide first-level support for their colleagues. Business process champions define how business proc-esses are to be executed. A program management office communicates these require-ments to the IT organization, decides on the financing of development and operations, and ensures that the requirements are implemented.

On the technical side, the application management team is in direct contact with the busi-ness units. It is responsible for implementing the business requirements and providing sup-

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development port for end users. Business process operations covers the monitoring and support of the business applications, their integration, and the automation of jobs. Custom development takes care of adjusting the solution to customer-specific requirements and developments. SAP technical operations is responsible for the general administration of systems and de-tailed system diagnostics. And the IT infrastructure organization provides the underlying IT infrastructure (network, databases …). Further specialization is possible within these organi-zations as well. For example, there may be individual experts for different applications within SAP technical operations.

Efficient collaboration between these teams is required to optimize the operation of SAP-centric solutions. This becomes even more important if customers engage service providers to execute some of the tasks or even complete processes. Customers have to closely inte-grate the providers of out-tasking and out-sourcing services into the operation of their solu-tions.

Key prerequisite for efficient collaboration of the involved groups is the clear definition of processes, responsibilities, service level agreements (SLAs), and key performance indicators (KPIs) to measure the fulfillment of the service levels. Based on the experiences gained by SAP Active Global Support while serving more than 40,000 customers, SAP has defined process standards and best practices, which help customers to set up and run End-to-End (E2E) Solution Operations for their SAP-centric solutions. This covers not only applications from SAP but also applications from independent software vendors (ISVs), original equipment manufacturers (OEMs), and custom code applications integrated into the customer solution.

SAP provides the following standards for solution operations:

• Incident Management describes the process of incident resolution

• Exception Handling explains how to define a model and procedures to manage ex-ceptions and error situations during daily business operations

• Data Integrity avoids data inconsistencies in end-to-end solution landscapes

• Change Request Management enables efficient and punctual implementation of changes with minimal risks

• Upgrade guides customers and technology partners through upgrade projects

• eSOA Readiness covers both technical and organizational readiness for enterprise service-oriented architectures (eSOA)

• Root Cause Analysis defines how to perform root cause analysis end-to-end across different support levels and different technologies

• Change Control Management covers the deployment and the analysis of changes

• Solution Documentation and Solution Documentation for Custom Development define the required documentation and reporting regarding the customer solution

• Remote Supportability contains five basic requirements that have to be met to op-timize the supportability of customer solutions

• Business Process and Interface Monitoring describes the monitoring and supervi-sion of the mission critical business processes

© 2008 SAP AG


of 52


• Data Volume Management defines how to manage data growth

• Job Scheduling Management explains how to manage the planning, scheduling, and monitoring of background jobs

• Transactional Consistency safeguards data synchronization across applications in distributed system landscapes

• System Administration describes how to administer SAP technology in order to run a customer solution efficiently

• System Monitoring covers monitoring and reporting of the technical status of IT so-lutions

• Test Management describes the test management methodology and approach for functional, scenario, integration and technical system tests of SAP-centric Solutions.

Out of this list, this white paper describes the standard Solution Documentation for Cus-tom Development.

© 2008 SAP AG


of 52


3 Technical Requirements of Providing Documenta-tion

The functionality delivered by standard applications does not always match completely with the requirements of a customer. Therefore, some projects may include the development of additional functionality or the change of existing functionality. These custom developments may be done by customers themselves, by third-party companies, or by SAP Custom Devel-opment. This chapter describes the preconditions for providing the required documentation. This includes the expected location and format as well as the language of required documen-tation.

3.1 Location and Format of Documentation Content

The minimum documentation required for custom development projects shall be stored within the project documentation tools provided in SAP Solution Manager 7.0 located in the cus-tomer solution environment. In case of multiple SAP Solution Managers in the customer land-scape it is expected that the complete set of minimum documentation is located within the SAP Solution Manager that is also used for managing operations and maintenance tasks for the involved system landscape. It is possible to start a project within one SAP Solution Man-ager during the development phase and later on transfer it to another Solution Manager.

The full documentation capabilities for ABAP-centric developments are available within Solu-tion Manager 7.0 with enhancement package 1. For SAP composite applications, the full documentation capabilities are planned to be available in the next enhancement package of SAP Solution Manager.

Certain parts of the documentation are required to be stored in structured format – for those parts the Solution Manager project documentation offers dedicated screens and structuring elements that shall be used. For unstructured type of information (textual descriptions), there are special documents provided with a predefined internal structure that you should use to provide this information. Which information is expected in which format is explained in chap-ter 4 (Requirements for Minimum Documentation Content). In case you already have docu-mentation available containing the same information, you may also upload your existing ones to SAP Solution Manager.

3.2 Documentation Language

It is required that all documentation requested within this document is provided in English. In case where SAP services shall cover this project, it is important that SAP support engineers are able to read it. Without additional translation effort, this can only be guaranteed if it is available in English. Otherwise, the delivery of support may be delayed and SAP might not be able to provide the service level guaranteed in the SAP Enterprise Support engagement.

© 2008 SAP AG


of 52


4 Requirements for Minimum Documentation Con-tent

Documentation can be extensive. To keep your focus on the information that is required most importantly, this chapter describes the key documentation for custom developments. You learn how to maintain this documentation within SAP Solution Manager 7.0 Enhancement Package 1.

4.1 Create Project in Solution Manager

Use transaction SOLAR_PROJECT_ADMIN in SAP Solution Manager (Project Administra-tion from menu). You will use this transaction for all documentation tasks described in section 4.1 through 4.4). In case that your development is part of a larger implementation project, it is also fine to use the existing project and add the documentation requested within this docu-ment under this more generic project.

The project documentation tools available in SAP Solution Manager are quite powerful and allow many aspects of a project to be documented. Only a subset of this information is impor-tant to support such a project according to standard support processes. In order to focus on the minimum documentation that is required for providing various support tasks, there is an option to remove all tabs that are not relevant for this minimum set of information. You can activate this reduced view via the menu item ‘Edit Proposed Value for Min. Documentation’ (see Figure 4.1). This is just an optional simplification for the later usage. It will not be appli-cable when you document your custom development as part of a larger project.

Figure 4.1: Set Minimum Documentation Defaults

Select a project type. There are multiple project types. The type ‘Implementation Project’ works fine for documentation of custom code. The corresponding solution may not be existing or known at the early project phases. The Solution information shall be entered as soon as it is known. The Information shall be available and up-to-date at the delivery of the ‘Modification Justification Check’ service. If you have a high level project description you should upload this into the project description (optional).

Minimal required information (see Figure 4.2):

© 2008 SAP AG


of 52


Figure 4.2: Project Administration - Header Data Screen

1. Provide a meaningful title to the project. Latest when a project is moving from the im-plementation phase to the productive phase, it shall be linked to a Solution that should consist of all business scenarios that are running together in a common sys-tem landscape. If the Solution is not yet defined when the project is started, you need to leave this field initially blank and fill it later as soon as the Solution is defined. After the project is finalized, you should also copy the project into the Solution.

2. In the Project Management section, select whether the project is led by your organi-zation (customer), by SAP or by a consulting partner (resp. VAR/CBS). Also add a responsible person for this project within your organization (customer) and if the pro-ject is not led by your organization also the responsible person for this project within

© 2008 SAP AG


of 52


the leading organization. Note that the persons you enter here are supposed to exist as users within the Solution Manager system and you enter their system user ids.

3. Enter the current project status. It is important to distinguish between finished pro-jects and still ongoing projects.

4. Enter the planned and (if available) actual start and end dates as well as the antici-pated and actual amount of required person days (PD). This information is optional but helps to understand the project scope at a very high level. In case you use an al-ready existing implementation project, this information is not urgently required as it just documents the complete project effort.

4.2 System and Application Landscape

The application landscape contains the list of software product versions involved in this pro-ject. The system landscape contains the list of logical components (placeholder for a real physical system independent of its role of development, quality assurance or production) involved in this project. For understanding the realized business processes, it is essential to have the logical components defined. You have to list them under the ‘System Landscape’ tab. Logical components may be defined without reference to a real physical system by just referring to the underlying product versions (see Figure 4.3). After the real systems are known, you need to add them also in the System Landscape tab according to their role (see also section 4.3 Physical System Landscape).

The creation of logical components can be triggered out of the value help for the logical com-ponent or via the system landscape management application (Solution Manager work center: ‘System Landscape Management’). You can also use existing logical components that have been defined earlier (e.g. during the definition of a solution). When defining a logical compo-nent, you have to provide the product version as well as the so-called main instance within that product. A main instance is a separately installable software part. Note that if you are using the SAP Business Process Repository as a basis for attaching your custom specifics, you will get a list of logical components required in the related SAP standard processes. If the custom developments are located within the same components, there is no need to manually create additional ones.

Via the product version information value help in the logical component creation dialog, you get all available product versions for SAP sold software as well as all certified products from independent software vendors (ISVs) that have been certified after 2007. This information is regularly updated via content updates in your SAP Solution Manager.

If your project requires multiple product components running on the same application server (ABAP add-ons or SAP J2EE deployed components), you should document this by using the possibility to add further product references to a logical component.

If you are using other 3rd-party or own software, you need to define it as described in the fol-lowing sub-section 4.2.1 (Documenting usage of 3 -party softwarerd ).

© 2008 SAP AG


of 52


Figure 4.3: Project Administration - System Landscape Screen

4.2.1 Documenting usage of 3rd-party software

As explained before you should first verify that the 3rd-party software you want to document is not known to the SAP Solution Manager yet.

If you are using 3rd party software that is not yet known to Solution Manager or own software running outside any SAP system, you need to define a custom product version in order to be able to specify it as part of your system landscape. Also a logical component needs to be defined for each non-SAP system. Since the complete picture of all systems involved within your project is required, it is expected that you create custom product version entries for all such systems (see Figure 4.4). The product key shall be defined in the customer namespace. If the product uses an own database system, this shall be flagged in the components tab as well as the ‘Technical Instance’ flag if this product does not provide any business logic but only technical functionality (e.g. a pure UI renderer).

Figure 4.4: System Landscape - Create Custom Product Screen

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development If your custom product is built using multiple independent software components, you shall enter these as separate ‘Main Instances’ (see Figure 4.5). You can use these instances later to define business process steps to be executed on them.

Figure 4.5: System Landscape - Maintain Custom Software Components

In case your custom developed solution has inter-company interfaces, you also need to de-fine a logical component for the external endpoint of the interface. For such cases, just define any product name that represents the external endpoint (e.g. EXTERNAL VENDOR).

4.3 Physical System Landscape

As soon as real physical systems exist on that the solution is running, you need to enter those into the system landscape as shown above. This will usually be development systems in the early project phases, while in later stages the productive systems shall be added as well. The system list in the system landscape tab offers several system roles. Before you can map physical systems to logical components, the physical systems need to be known to the Solution Manager. The most comfortable and recommended way to make systems know to Solution Manager is via a System Landscape Directory (SLD). Each system shall be regis-tered at an SLD and the SLD connected to Solution Manager (if multiple SLDs are used, they can be consolidated into one central SLD that is connected to SAP Solution Manager). Each system known to the Solution Manager connected SLD is known in SAP Solution Manager. It can be selected via the value help if the system has to be entered.

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development If you enter a system for an already defined logical component, you will only get a selection of systems that match to the product version defined for the logical component.

If you have not setup an SLD for providing the system information automatically, you may also create systems definitions manually via the creation wizard out of the system landscape management transaction (SMSY Landscape Components right mouse click on Systems

Create New System with Assistant).

Figure 4.6: System Landscape Maintenance - System Creation Wizard

Non-SAP systems have to be defined manually – the system ID can be chosen freely but needs to be unique in your system landscape. If an installation number does not exist, you can enter any number. .

4.4 Solution Definition

For managing the operational tasks to keep the business processes running smoothly, you have to define a so-called Solution within SAP Solution Manager. If you have defined a solu-tion already, this section is optional for the minimum documentation of a development project.

A solution contains the physical system landscapes as well as the business process defini-tions to be supported by it. A solution may thus include business processes from multiple projects. A new project may also fit into an already existing solution. In this case, you should enter the solution name into the project header (see Figure 4.7).

© 2008 SAP AG


of 52


Figure 4.7: Project Header Data - Mapping to a Solution

You can create a new solution in the Solutions view of the SAP Solution Manager Administra-tion work center. Select New and enter the required data (see Figure 4.8).

Figure 4.8: Solution Manager Wizard for Solution Creation

4.5 Business Scenario and Business Process Documentation

It is important that the custom development is documented within the context of the business processes where it is included. Business processes that belong to the same business scope shall be grouped into so-called business scenarios. Each business process is always as-signed to a business scenario. All business processes of one project can be assigned to the same business scenario.

SAP has already documented all business processes delivered within the SAP standard port-folio in the so-called Business Process Repository (BPR). Whenever your custom develop-ment project is modifying SAP standard code, you may either define business scenarios and processes completely by yourself or start with a scenario/process delivered by SAP. You can skip section 4.5.1 if you define the complete business scenario and business processes from scratch by yourself.

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development 4.5.1 Starting with an SAP delivered business scenario

Many custom developments either extend or modify business processes that are delivered with the SAP standard portfolio. For all SAP standard business scenarios and business proc-esses SAP delivers already a pattern and documentation inside the SAP business process repository (BPR). For each business process that is involved within your project, you should try to find the closest SAP delivered business process pattern in BPR and copy it into your project documentation. This can be done either in the ‘Business Blueprint’ or in the ‘Configu-ration’ structure of your project (see Figure 4.9 and Figure 4.10 as an example). The SAP solution maps found under SAP Solution Maps at www.sap.com help you to navigate to the suiting business scenarios.

Figure 4.9: Business Process Repository - Selection of Business Scenarios / Processes

After you have selected the matching business scenario(s) and saved them, you get the com-plete list of associated SAP standard business process and have to delete those that you do not touch within this project.

For each business process, you need to adjust the list of business process steps as well as the association to your logical systems in order to match the business processes that your development project will realize. For each additional logical business step that you realize via own custom software, you shall add an additional business process step in the step list and give it a name that briefly explains the business activity executed within this step.

© 2008 SAP AG


of 52

http://www.sap.com/industries/lifesciences/midsize/solutions/business_tools/index.epx?tab=tab1


Figure 4.10: Structured Documentation of Business Scenarios / Processes in Project

4.5.2 Define missing business scenarios, processes and steps

Whether you have started using an SAP scenario or not – you may need to add further busi-ness scenarios, business process and business process steps to completely describe your project.

It is important that this business process documentation is understandable by somebody from outside who has good knowledge on the SAP business applications but has no knowledge about the specific company internals (e.g. SAP support engineers in case this project shall be handled within SAP standard support services),

See Figure 4.1 as a generic guideline for defining business scenarios, processes and steps. Besides this, it is important that each software activity that is executed on a separate logical component is also modeled as a separate business process step. Steps that are performed externally but important for understanding the whole business process shall be modeled and assigned to a specific external logical component as well. The same is valid for steps that are not executed by software but important for the process (e.g. a printed document has to be sent via post mail). You can also check out the SAP delivered standard business processes within the SAP business process repository for many examples showing you the expected documentation granularity.

© 2008 SAP AG


of 52


Figure 4.11: Scenario, process, step, transaction

Adding a new business scenario can be simply done by adding a reasonable name into the Structure tab at the Business Scenarios node of the project tree and save it. This will create a new sub-tree under Business Scenarios which you will use for adding business processes.

To add a business process, you first select the Business Processes sub-node for the sce-nario where this process belongs to and add a reasonable name into the Structure tab and save it, this will create a new sub-node under the Business Processes node with the chosen name.

For adding a business process step, you need to enter a reasonable name into the Step Name column at the Structure tab of the business process. A process step always needs also a logical component to be assigned. You need to have the logical components defined be-forehand as explained in section 4.2. If your business processes get data from an external system you should also define this external system as a separate logical component and define a business process step on it. The scope of a business process step shall be the activ-ity that executes a single logical step within the business logic. It is not necessarily the execu-tion of a piece of software but may also be the manual execution of some task (e.g. copy a file from a CD shipped via post mail into a special folder for further processing).

Each business process step has to be classified into one of the following categories by set-ting the matching values in the attributes tab of the business process step. The attributes are maintained via the structure tab of the respective business process (see Figure 4.12). See Table 1 for the meaning of each category. A process step may belong to multiple categories (if it contains multiple coding parts falling into different categories).

© 2008 SAP AG


of 52


Figure 4.12: Classify Business Process Step via Attribute

You shall change the step classification from ‘SAP standard’ to ‘SAP with enhancement’’ whenever you modify the behavior of an SAP business process significantly via implementing a standard enhancement hook (e.g. business add-in)..

For modifications of SAP business process steps via real modification of original SAP code, you shall change the step classification from ‘SAP standard’ to ‘SAP with modification’. If the main business activity originally performed by this step has also changed, this shall be re-flected in a corresponding adjustment of the step name.

In cases where you do not find a well matching original SAP business processes within the BPR, you need to create a completely new business scenario resp. business processes from scratch. Typically, these business processes will also be integrated with the SAP standard. The minimum information required is at least the documentation of that part of the business processes that are realized by the custom code or by SAP modifications as well as all busi-ness process steps that are directly linked via standard SAP interfaces. Ideally, you should document the whole business processes where the custom development is integrated. As you will enter both types (customer and SAP steps) manually in this case, it is important to

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development change the step class from ‘Custom’ to ‘SAP’ (resp. ‘SAP with extension’ or ‘SAP with modifi-cation’) for those that are original SAP.

Attribute name / Category Meaning

SAP standard Business step is fully realized with SAP stan-dard code. Used also in SAP standard busi-ness processes.

SAP with enhancement Business step is realized with SAP standard code with implemented custom enhancement (e.g. BADI implementation).

SAP with modification Business step is realized with SAP standard code that was modified (i.e. original SAP program code in SAP namespace was changed).

Custom development Business step is realized by custom code within custom namespace.

Table 1: Classification Types of Business Process Steps

It is important to understand which of the business processes are essential for your key busi-nesses to work –these processes are called the core business processes. A good indicator for a core business process is that you immediately would loose business or your logistics or production chain would be broken if this process is not available. A typical non core business process would be one that produces statistical data for reporting. You shall identify your core business processes by setting the attribute ‘Core’ to them. This can be done via the attribute maintenance of the business process (see Figure 4.13).

Figure 4.13: Setting Core Business Process Attribute

4.6 Application Components

Application components are used to identify the application area a specific functionality of the application belongs to. If SAP provided you with dedicated custom specific application com-

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development ponents (usually in the XX-.. namespace), you shall also document the list of these custom application component names. They are used to identify this custom development applica-tion. This identification tag can then be reused when creating an incident message in case these application component names have been assigned by SAP. This allows quicker identi-fication of expert knowledge on SAP support side.

Besides that top level component name which is the minimum requirement, it may be useful for complex projects to define sub-components for logically separated software parts.

The application component hierarchy defined for this custom code shall be documented as an attribute to a business scenario resp. at business process level (see Figure 4.14).

Figure 4.14: Application Component Hierarchy Attribute

4.7 Interface Documentation

The next task is to document the SAP interfaces that are used within the business processes. You shall enter at least all interfaces that are used from custom coding. Interfaces may be grouped logically into so-called Interface Scenarios. Interface scenarios are supposed to be used for grouping together interfaces that logically belong together (typically criteria are com-mon technology or same application unit). You are free in defining interface scenarios for such a logical grouping but at least one interface scenario needs to exist. You define the list of interface scenarios on project level in the ‘Structure’ tab in the ‘Interface Scenarios’ node (see Figure 4.15).

© 2008 SAP AG


of 52


Figure 4.15: Interface Scenario Definition

After you have saved the interface scenario definition(s), you have to add the list of single interfaces per scenario. This is done within the ‘Structure’ tab of the respective interface sce-nario node (see Figure 4.16). You have to define a meaningful name in the ‘Interface’ column and enter sending and receiving logical components (these may also be identical, e.g. if the custom code calls standard functionality by invoking a BAPI on the same logical component), the technology (selected from the values in the drop-down box), as well as the ‘Type’. The ‘Type’ is ‘synchronous’ when the sender waits until the receiver has consumed the sent data or ‘asynchronous’ if the message is just put on a queue for later processing and the sender immediately continues independent of the receivers behavior.

Figure 4.16: Adding an Interface to an Interface Scenario

In addition to that, you shall provide details on each interface using the ‘attributes’ button. Information is required in the ‘Technical Attributes’ tab and the ‘Document Volume’ tab. In the ‘Technical Attributes’ tab at least the ‘Technical object’ name and the business object name are required as they allow to technically identify the interface within the system. See Figure 4.17 as an example.

© 2008 SAP AG


of 52


Figure 4.17: Enter Technical Interface Name

You are encouraged to enter further technical attributes.

For the ‘Data Volume’ tab you shall at least enter estimated average and maximum expected document volumes for one of the offered time frames (hour, day, week, and month). See Figure 4.18 as an example. The more details you are able to provide the better. ‘Required response time’ shall be entered if your business requires that the sender proceeds within a given time frame (only for synchronous interfaces) or that the receiver is able to start proc-essing within a certain time frame. Entering no required response time means that it is suffi-cient if the system can handle the total document volume over time without constantly in-creasing backlog.

© 2008 SAP AG


of 52


Figure 4.18: Enter Interface Document Volume

In order to document the usage of the interfaces within the business processes, you have to assign them to the matching connections between business process steps in the respective business process graphic. Without assigning an interface to the connecting line of two busi-ness process steps, you just define their logical sequence.

For assigning a previously defined interface enter the ‘Graphic’ tab at the respective business process node and right click on the connection line of the two business process steps you want to add the interface to. In case there is no connection defined yet you need to create one first. After selecting ‘Assign Interface’ you get a selection of all interface definitions within your project that potentially match. This means that the source and destination logical sys-tems and the interface type must match (see Figure 4.19 as an example).

© 2008 SAP AG


of 52


Figure 4.19: Assign Interface Connection Line

4.8 Documentation of Background Jobs

Background jobs are typically used to handle mass data processing without direct interaction with users. You shall document all background jobs used in your project. A background job shall be either entered directly at the business process step, which the job realizes; or at the business process level of the business process that the job is part of. Therefore, you enter it in the ‘Transactions’ tab of the respective node by selecting type ‘Job documentation’. In the subsequent popup, you can either create new job documentation or refer to an already exist-ing one (see Figure 4.20).

© 2008 SAP AG


of 52


Figure 4.20: Create New Job Documentation

If you create new job documentation, a browser window for the job documentation UI is opened (see Figure 21). The minimum information that shall be entered is the job name (as it can be found in the job scheduler). If you already know that the scheduler will be Redwood Chronacle or the ABAP job scheduler (BC-XBP), you can choose the corresponding sched-uler. Otherwise, choose BC-XBP as scheduler. You need to define at least one job step via ‘Add’. In the job step details, you have to enter a text description of the executed program, the program type (ABAP report, any external program, shell script, or a command defined in the ABAP external command list SM69) and the technical name of the program it executes (e.g. ABAP report, executable program, shell script name). If a variant is used, enter the name of the job variant as well and select whether the job runs client specific or not.

© 2008 SAP AG


of 52


Figure 21: Adding Job Step Details

In case of a multi-step job, you may add more steps as needed. If possible, also enter sched-uling details, preconditions and limitations (e.g. dependency on other jobs, not in parallel with other jobs), error handling procedures (what to do if the job aborts, what if it did not start, or if it finishes too late) via the respective tabs,.

The detailed description of the business functionality shall be described additionally within the functional documentation document of the business process step where the job is mapped to (see section 4.12 Functional Documentation / Business Background).

In the early phases of the project, you may not have all information ready for the complete background job documentation (e.g. responsible persons for monitoring or error handling may not be defined during the implementation phase). In such cases, you shall add the missing information as soon as they are known.

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development 4.9 Transactions and User Entry Points

Business process steps may be invoked by different means. They may be executed auto-matically by the system as a successor of a previous step (invoked via an interface), they may be executed as a background job on a time schedule, or an end user has to invoke them. The interfaces and background jobs have been documented already. What is missing yet are the end user invocations.

Therefore, you shall document for each business process step, which may be invoked manu-ally by an end user, the software entry points that the end user can use to do so. Such entry points may be ABAP transactions, WebDynpro applications, Business Server Pages, any URLs, programs, etc. The tab named ‘Transactions’ shall be used for entering this informa-tion at business process step level (see Figure 4.22). In cases where there are multiple pos-sibilities to enter this business process step (e.g. multiple transactions that can be used to perform the same business function), you shall enter each of these entry points separately.

Select the matching type of the user entry point, the logical system where it is executed (usu-ally the same that is used for the corresponding business process step) and the technical name of the entry point (i.e. how this can be started on a real physical system). The ‘In Scope’ flag can be used to distinguish if the entry point will be handled within this project or not. It is not used for minimum documentation. SAP recommends documenting only those that are in scope and therefore always mark that checkbox. The ‘Standard’ radio button al-lows identifying one entry point that will be automatically executed when the ‘Execute’ button at the process step in the project tree is clicked. SAP recommends choosing the one that is supposed to be the most heavily used respectively most important one.

In case you already have a physical system assigned to the logical system, you can choose the technical object name from a value help directly filled from the system. Otherwise, you will get a warning message that the object name cannot be verified.

For URLs, you can use placeholders for hostnames and port numbers if those are not yet known (e.g. http://<host>:<port>/application).

Figure 4.22: Documentation of Transactions / User Entry Points

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development 4.10 Performance and Volume KPIs

Expected volume figures shall be documented for all core business processes. This includes the expected number of executions per time unit, number of documents created and number of concurrent users. It also includes expectations for maximum and average response times for certain business processes or single business process steps.

You shall enter the expected volume figures at least for each core business process. If possi-ble you should provide these figures at business process step level. For documenting this information, you shall use the ‘KPIs’ and ‘Document volume’ attribute tabs for the respective business process steps (in the ‘structure’ tab of the business scenario resp. business proc-ess). In the KPIs tab, you need to select an object that was previously entered in the transac-tion tab as a transaction or user entry point (see section 4.9 above). The action field shall be used to identify the user action within that transaction or user entry point. Try to fill all re-quested fields with your best estimations. In the document volume tab you provide informa-tion about the document type(s) processed in this process/step and the expected number of processed objects per hour and day. ‘New Objects per Month’ shall indicate only the number of newly created objects per month (may be less than totally processed objects). See Figure 4.23 as an example.

Figure 4.23: Enter Performance and Volume KPIs

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development 4.11 Development object list for Custom Development or Cus-

tomizing Objects

All development objects that are newly created or modified within your project shall be docu-mented within the development tab either on business scenario, on business process, or on business process step level (see Figure ). SAP recommends that you create separate devel-opment packages in the customer name space for each logical development. For modified SAP code, you shall enter separate transport requests containing exactly the list of modified SAP objects.

Note that the ‘Development’ tab is available in the ‘Business Blueprint’ project phase only if you have selected the setting ‘Proposed Value for min. Documentation’ in the project admini-stration (see Figure 4.1) or activated the visibility of the tab manually. Otherwise, you need to maintain it in the ‘Configuration’ phase. From the project maintenance transactions (SOLAR01 for business blueprint and SOLAR02 for configuration), you can always switch to the other one via the menu path Environment Business Blueprint / Configuration.

We highly recommend that you specify the packages respectively transport request object lists as closely as possible to the element in the tree where the included development objects really belong to. If certain development objects are generic ones used in various steps of a business process or in all business processes of a business scenario, they should be put into a package resp. transport request on business process resp. business scenario level. The closer you can map development objects to business steps or processes, the more precisely it is possible to tell you which processes or steps may be affected by planned software change.

Similar to documenting the development objects, you shall also document the business cus-tomizing objects. The Configuration tab shall be used for this. The configuration objects should be put into separate BC sets resp. dedicated customizing transport requests. Those BC sets resp. customizing transport requests shall also be added in the Development tab to the related business process or business process step as precisely as possible.

In order to add a software package name, a BC set, or a transport request, you should have a logical system with a physical assignment of the corresponding development system in place. Also, the connectivity from the SAP Solution Manager system to this development system should be set up. This allows you to access the object repositories on the develop-ment systems directly and to put the references into SAP Solution Manager.

We highly recommend that you manage all your transports via a centralized transport man-agement system. This can be set up within the Solution Manager itself or in any other SAP Web Application Server system. If the central transport management system is not part of the solution which is used by your project, then you have to add the logical and physical system into your solution landscape so that you can select the transport requests from there. In case you have no centralized transport management (not recommended) then you can also fetch transport requests from each system within your solution landscape (precondition: the physi-cal systems and the connectivity are defined in SAP Solution Manager).

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development It is very typical that the list of development objects grows during the development phase. If you already have the packages for the logical units at the beginning, you should reuse them to include further developments such that you do not need to change the documentation within the Solution Manager project. It is not required to add all objects into one single re-quest. You can define multiple transport requests in the same development tab.

Figure 4.24: Transport Request Documentation

4.12 Functional Documentation / Business Background

In order to understand the functionality that is realized by the custom code development, it is important that you provide additional textual information explaining the following topics:

• Business background information:

What are the business reasons why this project was initiated? Which gaps of the SAP standard solutions have been identified that shall be closed by this project?

Keep in mind that this documentation shall be understandable not only by the busi-ness persons from your company but also by people not familiar with the organiza-tion of your company.

This information shall be documented on project level.

• Business gaps closed

Which gaps of the SAP standard solutions have been identified that shall be closed by this project?

If internal organizational preconditions at your company are necessary to understand the business requirements, these have to be documented as well.

This information shall be documented either on project level or per business process scenario, process or step.

• Functionality

© 2008 SAP AG


of 52


What are the functions realized.

For steps that contain modifications of SAP code, you shall document at step level why this modification is required, which alternative options without modifications have been investi-gated, and when this modification has been signed off by whom.

For steps that contain extensions of the SAP standard code, you shall explain what the ex-tension functionally does.

All these textual information shall be added in the Project Documentation tab at the structural element where it belongs to (project, business scenario, business process, process step). For this, you can fill out the template document ‘Functional Documentation’ (available in the ap-pendix of this paper and for download in the media library for E2E Solution Operations stan-dards at http://service.sap.com/supportstandards) and upload it by using the ‘Upload File’ method (see Figure ). Note that when you are using template projects in SAP Solution Man-ager, you have to put all uploaded documents into the folder tab named ‘General Documenta-tion’ as they will otherwise not be transported together with the template project.

Figure 4.25: Add textual documentation

4.13 Integration and Volume Test Plan Documentation

It shall be documented within one document on project level how you plan to setup and exe-cute integration and volume tests that cover all business processes and all software compo-nents involved in the project’s business processes. Also, document the solution and system landscape role to be used for the tests – the technical solution shall be maintained within Solution Manager in the system landscape information (typically as test system role). For the volume tests, you should document how these volume tests will be prepared and executed (e.g. test data preparation, real users with scripts or automated user simulation, ramp-up profile). Also, explain how much load you plan to produce during the tests and how this load is distributed on the business processes. Include the volume testing of your background jobs in this documentation as well.

Explain how many of those tests you plan with which time interval in between. Explain how you measure the result (have errors occurred, what was the number of concurrent users and

© 2008 SAP AG


of 52

https://service.sap.com/%7Esapdownload/011000358700000262972009E

SAP® Standard Solution Documentation for Custom Development the corresponding response times, what was the system load over time on each system, how many documents have been processed in which time frame).

This information shall be documented using the ‘Test Plan Documentation’ template (avail-able in the appendix of this document and for download in the media library for E2E Solution Operations standards at http://service.sap.com/supportstandards) via the same method as described in section 4.12.

4.14 Application Operations Guide

The Application Operations Guide has to be provided by the development project team. The guide contains information on how the developed application can be operated. An Operations Handbook shall be derived from the Application Operations Guide. The handbook will be used by the operations team. It describes the operations tasks that need to be performed during the real operation of the solution.

Information to be provided in the Application Operations Guide:

• Monitoring of the application (business process level as well as technical level): How to detect problems resp. avoid critical situations or performance problems. How to monitor data growth.

• Support tools and troubleshooting guidelines for analyzing problem situations: How to find the root cause of problem situations. How to analyze performance problems.

• Consistency checking. How to verify data consistency (if replicated data exists): How to safely repair potential data inconsistencies.

• Management of the application. How to start/stop the complete application: How to change configuration. Administration tools to be used. How to backup and restore the complete solution. Regular tasks to be scheduled and monitored (automated back-ground jobs as well as manual tasks).

• Scalability and high availability: How to scale up the solution for higher user or data volume. How to setup a high availability scenario.

• Transport and change management: How to perform software changes on the com-plete solution and how to integrate all components into the one-transport-order con-cept.

• Remote supportability: How to setup safe remote access to all support relevant tools (e.g. special user roles for read only access permission, URLs to support tools).

This information shall be documented using the template ‘Application Operations Guide’ (available in the attachment of this document and for download in the media library for E2E Solution Operations standards at http://service.sap.com/supportstandards) via the same method as described in section 4.12.

© 2008 SAP AG


of 52


http://service.sap.com/%7Eform/sapnet?_SHORTKEY=01100035870000711194&_SCENARIO=01100035870000000202&


http://service.sap.com/%7Eform/sapnet?_SHORTKEY=01100035870000711194&_SCENARIO=01100035870000000202&


5 Appendix

In the appendix of this document, you can find templates that you can use for documenting specific aspects of your custom development. For using these templates in your project, please download editable versions from SAP Service Marketplace at the media library for E2E Solution Operations standards.

5.1 Template: Functional Documentation About this Template You use this template to document the business background that led to this custom devel-opment. Explain what are the functional business gaps closed by this development. Describe on business process level how this development works logically. The explanation shall refer to the business process and step names that were also used within the business process structures that you have documented within the project in Solution Manager. A description of the functionality is required for all business process steps that are of type ‘Custom development’, ‘SAP with enhancement’, or ‘SAP modification’. For SAP enhancements the implemented SAP enhancement objects (e.g. BADIs) shall be listed. For SAP modifications it shall be explicitly explained which modification free alternatives have been evaluated, why the modification option was chosen in the end and who on customer side has officially signed off the modification. Additionally it has to be documented which preconditions (e.g. certain SAP releases or functionalities) or assumptions are made that have to be met for the developed functionality to work.

1 Glossary

Here you may provide a glossary for the abbreviations that you use within this document or within the business process / step names (e.g. PR = purchase requisition).

Term Definition

2 Business Requirements / Gaps to be Closed

Explain why this custom development was needed. Which functionality was missing in the existing SAP software?

© 2008 SAP AG


of 52



3 Functional Documentation Explain how the functionality is realized by the custom code on a logical level. The documen-tation should be structured by business processes using the same names as in the business process structure within the project in SAP Solution Manager. The process step names from the project documentation should be also used within the functional documentation to have a clear relation. You may also export the business process graphics out of SAP Solution Man-ager and include them as a picture in here.

3.1 Business Process: ‘<name of business process 1>’ Provide the documentation for this business process. Describe step by step for each non-SAP standard step what it does and how it is triggered (user interaction, synchro-nous/asynchronous communication of predecessor step, background job) respectively how it interacts with its successor(s).

3.1.1 SAP enhancements

Only enhancements that are not trivial or perform some unusual business functionality are requested to be separately listed here.

<enhancement 1>

Explain briefly what this enhancement does logically. If you have multiple modifications then copy this section for each of them.

3.1.2 SAP modifications

<modification 1>

As modifications to SAP standard code may have dangerous effects to other areas and may also lead to additional maintenance costs in the future, it is important to have more detailed documentation for them. If you have multiple modifications then copy this section for each of them.

Logical description of the modification:

• Describe what functionality was modified in which logical way.

Alternatives evaluated:

• Explain briefly the alternatives you have taken into account.

Final reason for choosing the modification alternative:

• Why did you finally decide to implement this modification instead of any other alterna-tive?

Responsible person at customer who signed off for this modification:

© 2008 SAP AG


of 52


• Who officially agreed from customer side to implement the modification? This may be also a sign off committee.

3.2 Preconditions / Assumptions

Explain what is required for this development to work (e.g. expected releases or functional-ities of SAP products).

© 2008 SAP AG


of 52


5.2 Template: Test Plan Documentation About this Template You use this template to document how the testing of this project will be organized. The document is organized as a type of questionnaire. This document contains form elements to simplify the data entry but it requires being in pro-tected mode in order to enable the form entry.

Roles and Responsibilities for Testing Action: Please enter information about Test Management roles and responsibilities and

provide the contact details of the persons in these roles.

Example: Role / Area Responsible Company Phone e-Mail

Business Process Owner(s) John Smith; Klaus Mustermann

XYZ GmbH XYZ GmbH

+49(1)777-888 +49(1)888-777

[email protected] [email protected]

Roles Role / Area Responsible Company Phone e-Mail Executive Sponsor Test Project Manager(s) / Test Coordinator(s) Application implementation / operation Technical implementation / operation Business Process Owner(s) Key / Power User(s) Test Case Development

© 2008 SAP AG


of 52

mailto:[email protected]

mailto:[email protected]


Transport Landscape

Please describe the transport landscape of the chosen solution in the tables below.

Action: In this table please enter the information regarding productive systems in the landscape.

Example:

SID1 System role Release PRD R/3 system, Automotive 4.7 SR 2

Productive system

SID System role Release

Action: In this table please enter the information about each system in the transport landscape. This includes the SID of the ‘upstream’ 2- and ‘downstream’ -3 systems for each system in the landscape.

As soon as the table is completed, it describes the whole transport landscape and the trans-port routes in the landscape.

Example: the table below describes the classical 3-systems landscape DEV 4 -> QAS 5 -> PRD 6. Here PRD is a downstream-system for QAS and DEV is upstream-system for QAS:

SID Role in the transport landscape SID of ‘up-stream’ - system

SID of ‘down-stream’ - system

DEV Development system - QAS QAS Quality Assurance system DEV PRD PRD Productive system QAS -

1 SID – System ID. The name for your SAP system which is unique throughout your organization and must consist of exactly three alphanumeric characters where only uppercase letters are allowed and the first character is a letter (not a digit) 2 ‘Upstream’-system means a system where the transports come from 3 ‘Downstream’-system means a system where the transports go to 4 DEV – development system in a transport landscape 5 QAS – quality assurance system in a transport landscape 6 PRD – productive system in a transport landscape

© 2008 SAP AG


of 52


Systems in Transport Landscape

SID Role in the transport landscape SID of ‘up-stream’ - system

SID of ‘down-stream’ - system

Roles, Responsibilities and Workflow Action: Please describe in the column ‘Project, Name and Role’ who is responsible for

each particular step in the change management and the corresponding role. If they are differ-ent for several projects please enter the information for each project in one field using a pro-ject short name as a prefix.

Example: Step / Function Project, Name and Role

Perform functional test in DEV PSAP_R3 - J.Smith, Test Manager; SCM_SAP - S.John, Test Manager

Roles in Change Management Step / Function Project, Name and Role Decision about software projects <Please type in your answer here> Create and assign transport requests to developers

<Please type in your answer here>

Plan functional test in DEV <Please enter your answer here> Perform functional test in DEV <Please enter your answer here> Transport into QAS <Please enter your answer here> Monitor result of import in QAS <Please enter your answer here> Plan test in QAS <Please enter your answer here> Perform test in QAS <Please enter your answer here> Approval of test <Please enter your answer here> Import into PRD <Please enter your answer here> Monitor result of import in PRD <Please enter your answer here>

An exception to the standard transport workflow could be necessary to allow fast reaction to urgent problems in the productive system.

Action: Please answer the question:

© 2008 SAP AG


of 52


Exceptions Questions Answers Is an exception to this workflow allowed (e.g. for emergency transports)?

Yes No

Who can request those emergency transports?

End User Key User Business Process Owner System Owner (Administrator) Development <Other>

Who is responsible for approval of emergency transports?

Key User Business Process Owner System Owner (Administrator) Development Manager <Other>

Change request Action: Please mark the appropriate field if there is any standard change request form

in use in the company and if there is a change request database storing the requests, which are already processed.

Change Request Form and Database Questions Answers

Change request form available? Yes No

Change request database available? Yes No

Current Test Strategy

Activities distribution Action: Please use the tables below for each test type to describe how the test activi-

ties are assigned to organizational units in the company. SAP is interested in the following test types: Unit Test7, User Acceptance Test8, Customer Development Test9, Integration Test10,

7 Unit Test – the lowest level of testing where the program or transaction is tested and evaluated for errors

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development Regression Test 11 and Technical System Test12. For each activity in each table, please mark the appropriate organizational units (one or more) that are responsible for this particular activity. If there are any comments or additions regarding activities distribution please use the field under the table. In each table for each activity mark at least one responsible organiza-tional unit.

Unit Test Who performs an activity?

Activities

Every Business Depart-ment on their own

Central Test or-ganization in each branch

Central Test or-ganization corporate wide

Central IT de-part-ment

Project team

<Other>

to decide what needs to be tested

to create test case descriptions

to organize testing

to execute test

to monitor test

to evaluate test results

Comment to the table: <Please enter your comment here>

8 User Acceptance Test – represents end-to-end testing from the business perspective. The purpose of that is to prove that initial business requirements were implemented exactly and in accordance to speci-fications made before 9 Customer Development Test – mixture of Unit Test and Integration Test with scope limited to the cus-tomer’s own development10 Integration Test – is accomplished through the execution of predefined business flows, or scenarios, that emulate how the system will run your business. Integration Test starts with the testing of the cross-functional integration points and ends with the end-to-end testing of critical business processes 11 Regression Test – test of critical business processes after a change to ensure that a) any problem has been fixed and that no other previously working functionality has been harmed as a result of the changes and/or b) that newly added features working as designed and have not created any unex-pected side effects12 Technical System Test – test aimed to verify the production system environment from a technical standpoint, e.g. to test if the system can be started / stopped properly, if the basis technical infrastruc-ture is working fine and the whole system in conjunction with database and operating system performs well from technical point of view. Among this the following technical tests are usually part of Technical System Test: backup and recovery, system administration, printing and faxing, failure scenarios, disas-ter recovery

© 2008 SAP AG


of 52


Definition of test scope Action: Please use the table below to document how you evaluate which test cases are needed

for specific software changes and software maintenance. In other words, which methods and strategies are in use to help in decision of which test cases should be executed after a change of a specific type?

Test Scope Change type

Possible methods projects regular maintenance

hot fix process

General regression testing of all core business processes

Analysis of changed / new objects and affected application area

Evaluation of customizing settings to identfy which processes are configured and therefore most likely used and potentially affected by changes

Evaluation of load profile (e.g. EWA 13, ST14, RBE 14, etc.) to find the business processes with a high load (meaning that such processes could also be most critical for everyday work)

Only new functionality will be tested, usually no Regression Testing

Others: <Please enter an additional method here if there is any>

13 EWA – Early Watch Alert 14 RBE - Reverse Business Engineer - a tool used for process-oriented analysis and continual optimiza-tion of SAP production systems. Using data from production systems it is possible to analyze how func-tions in the SAP System are used and identify potential for improvement

© 2008 SAP AG


of 52


Development of tests Action: Please use the table below to specify who is responsible for developing test

cases. Please also specify what kind of testing is meant (manual or automated).

Development responsibility Options Man

ual Autom

ated Remarks

Every Business Department on its own <Please enter your comment here>

Specific project team (implementation / upgrade / etc.) <Please enter your comment here>

Central Test Organization in each branch <Please enter your comment here>

Central Test Organization corporate wide <Please enter your comment here>

Central IT department <Please enter your comment here>

<Please put in an additional option here if there is any> <Please enter your comment here>

Customer specific quality targets and criteria

Completeness of any test plays an important role in the total success of the test. A complete test of a complex business scenario very often cannot be created without participation of the people who deal with the scenario in their day-to-day work. As the major goal of any test activity is to get reliable results, a controlling of correctness, completeness and grade of detail is very important.

Action: Please answer the questions below.

Quality targets and criteria Questions Yes No Remark

Is the ‘2-person policy’ in use, i.e. test cases need to be tested twice by 2 different persons? <Please enter your comment here>

Are there any customer-specific quality targets or criteria?

Which? <Please enter your comment here>

Are there special requirements regarding documentation of test cases (paper or electronic)


Are there some legal requirements affecting the test process?


Is there a person controlling the completeness of the tests?

Who is this person? <Please enter your comment here>

Is there a person controlling the correctness of the tests?


© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development Questions Yes No Remark

Is there a person controlling the grade of detail of the tests?


Do you use templates for test case creation? Example? <Please enter your comment here>

Test Case description Action: Please use the table below to specify what information is included in the stan-

dard test case description adopted to use in the company.

Information in Test Case description Information Available Remarks

Test Case ID (unique identfier) <Please enter your comment here>

Name of Project <Please enter your comment here>

Name of Business Process <Please enter your comment here>

Owner of Test Case <Please enter your comment here> Test Type (e.g. Unit, Integration, Regression) <Please enter your comment here> Test System <Please enter your comment here>

Client <Please enter your comment here>

Detailed description of preparation activities <Please enter your comment here>

Detailed description of test procedure <Please enter your comment here>

Check / Expected Test Results <Please enter your comment here>

Only for Integration Testing: dependencies on other test cases (predecessor and successor) <Please enter your comment here>

<Please enter your comment here> <Please enter an additional option here if there is any>

Test result documentation Action: Please answer the questions below.

Handling of Test Results Question Yes No Remark

Do you document the results of the manual testing?

How? <Please enter your comment here>

<Please enter your comment here> Do the currently used tools allow the tester to document the test results (results such as what has been tested by whom, when and with which results)

© 2008 SAP AG


of 52


Action: Please use the table below to specify what information is included in the stan-dard test result documentation adopted to use in the company.

Information in Test Result Documentation Information Availabl

e Remarks

<Please enter your comment here> Name of Tester Master Data <Please enter your comment here>

Transactional Data <Please enter your comment here> Actual Test results <Please enter your comment here>

<Please enter your comment here> Status information Remarks <Please enter your comment here>

Signature <Please enter your comment here> Date of Test <Please enter your comment here>

<Please enter your comment here> <Please put in an additional option here if there is any>

Test KPIs Action: Please mark in the table below what kind of measurements via predefined KPIs

15 you have regarding reliability of the tests.

Test KPIs Possible measurement Yes No Remark

<Please enter your comment here>General Stability

<Please enter your comment here>Availability / unplanned downtime

<Please enter your comment here>Performance

<Please enter your comment here>No. of short dumps

<Please enter your comment here>No. of update-errors

<Please enter your comment here>No. of trouble tickets (per component)

<Please enter your comment here>Interface throughput

<Please enter additional measurementS if there are any> <Please enter your comment here>

15 KPI - key performance indicator - a measurement or metric for evaluating a company's business strat-egy, performance, or technology. KPI express abstract company objectives in financial or physical units for comparative purposes

© 2008 SAP AG


of 52


Test data preparation and management Action: Please describe what methods you use to prepare the data in QA system data-

base before testing.

Test Data Preparation Possible method Yes No Remarks

Refresh via system copy of PRD <Please enter your comment here>

Refresh via client copy from PRD <Please enter your comment here>

Refresh via client copy from a standard client in QAS <Please enter your comment here>

Manual creation of master data <Please enter your comment here>

Automated creation of master data <Please enter your comment here>

Manual creation of transaction data <Please enter your comment here>

Automated creation of transaction data <Please enter your comment here>

<Please enter an additional method if there is any> <Please enter your comment here>

Action: Please describe what methods you use to manage the test data (to create it, to

store it, to update it, etc.) for testing.

Test Data Management Possible method Yes No Remarks

Microsoft Office Excel spreadsheets <Please enter your comment here>

Local or central test data databases What kind of databases? Paper <Please enter your comment here>

Automated Test Tools <Please enter your comment here>

Test data is not managed centrally and is up to a tester <Please enter your comment here>

<Please enter an additional method if there is any> <Please enter your comment here>

© 2008 SAP AG


of 52


Test execution

Execution Action: Please answer the questions below.

Execution: Manual or Automated? Question Yes No Remark

Do you use manual testing in your current test approach? <Please enter your comment here>

Do you use automated testing in your current test approach? How?

<Please enter your comment here>

What part (percentage) of the total testing do you perform manually? <Please enter your comment here>

Monitoring Action: Please answer the questions below.

Monitoring Question Yes No Remark Does the current test approach allow you to have a clear picture of the testing progress at every point of time?

<Please enter your comment here>

Does the current test approach allow you to estimate whether the time schedule is going to be kept? <Please enter your comment here>

Does the current test approach allow you to have an overview of the actual test results? <Please enter your comment here>

Does the current test approach allow you to react as required in case of error? <Please enter your comment here>

© 2008 SAP AG


of 52


Error Tracking Action: Please describe the workflow for error tracking established in the company.

Error Tracking Questions Answers

Who is involved in case of an error during tests in QAS? <Please enter your answer here> Yes No Do you have a defined process in case of test errors (feedback

loop / issue tracking) ?

How does the workflow look like to correct these errors? <Please enter your answer here>

Tools Action: Please answer the questions below.

Tools Question Yes No Remark

Do you use CATT 16 / eCATT 17 for testing? <Please enter your comment here>

Are there any 3rd party tools involved in your current test approach? <Please enter your comment here>

Are there any tools used for assignment of testers? <Please enter your comment here>

Are there any tools used for execution of tests and documentation of results? <Please enter your comment here>

Are there any tools used to follow-up in case of error? <Please enter your comment here>

Are there any tools used to manage test data? <Please enter your comment here>

16 CATT -Computer Aided Test Tool - an SAP tool enabling you to combine and automate business processes as repeatable test procedures 17 eCATT - extended CATT - a successor of SAP CATT which provides more flexibility and functionality. Delivered starting with the basis release 6.20 of the SAP Web AS

© 2008 SAP AG


of 52


5.3 Template: Application Operations Guide About this Template You use this template to document what needs to be known in order to smoothly operate this custom developed component. The major topics to be described are: monitoring, ad-ministration, software change management, high availability and troubleshooting. It de-scribes which tasks to be executed and which tools to be used. This document does not replace the Operations Handbook in which the customer respec-tively the operations organization has documented the concrete tasks, involved parties and interaction procedures. It is rather the basis for defining the Operations Handbook.

1 Monitoring Monitoring is the task of retrieving information on the status of a certain component, business process or process step that is relevant for the smooth functionality of your implemented business processes. This section shall be used to describe all tasks and tools that are re-quired to find out about any critical situation that indicates an existing or arising disturbance or failure of an implemented business process.

1.1 Alert Monitoring Describe here whether integration is available into alert monitoring tools (e.g. SAP CCMS) and which alerts will be propagated. Explain which alerts have to be checked and what is there meaning to the business. Also provide recommendations on thresholds to be defined.

1.2 Error Logs Document which error logs are used by your components to report error situations and how to filter on them (e.g. application log object names or development locations or error mes-sages). You should also provide a list of all critical error messages with typical reasons and corrective measures.

1.3 Workload Monitoring Document how the workload produced by the custom development can be identified and measured. For ABAP based components this may be done via the default ABAP workload monitor by providing the filter information to identify the custom components (e.g. namespace prefixes).

1.4 Interface Monitoring For all interfaces that your custom development components are using document how to monitor it for errors, throughput, delays, queues. If you are using SAP standard interface technologies you just have to explain how to filter for your interfaces within the SAP standard monitors. If possible, explain also if possible how to distinguish the load from your compo-nents from others using the same interface (e.g. user names, destinations used).

© 2008 SAP AG


of 52


1.5 Background Job Monitoring List all background jobs that your application uses and where to find them. Explain how to identify a successful job run and what to do if a job run has failed (e.g. normal restart, restart with different variant, and separate repair activity). Note that this information can be also pro-vided in the background job documentation within SAP Solution Manager.

2 Administration and Management This section shall document the tasks required for an administrator. There are regular tasks like starting/stopping, backup, user creation as well as exceptional tasks like adaptation for additional load.

2.1 Starting and Stopping If your components have to be started separately, explain how to do that and which start and stop sequences have to be followed.

2.2 Technical Configuration Where can the technical configuration be changed? How to activate changes?

2.3 Backup and Restore Which components need to be backed up? Are certain backup sequences or preconditions (e.g. only offline backup) to be met? Explain which components hold business data and what needs to be checked / synched after an incomplete restore.

2.4 Periodic Tasks Which tasks have to be performed periodically and at which frequency? Besides the back-ground jobs of your application this can be also e.g. manual reorganization or archiving tasks.

2.5 User Management Explain which system users with which capabilities (e.g. permissions, password not allowed to be changed) are required and where they are maintained. Explain how end users have to be maintained and which permissions are needed for which business functionality.

2.6 Load Balancing and Scalability Explain how to adapt for higher user or document volume. This includes setting up parallel instances as well as according configuration of the application, interfaces and jobs. For load balancing, describe how users or document processing can be distributed over multiple re-sources (e.g. instances).

2.7 High Availability Explain how to setup the landscape for high availability (i.e. without single point of failures for any core business process step). You may refer to available technical HA solutions for tech-nology components but typically it is also required to setup the technical application configu-ration accordingly.

© 2008 SAP AG


of 52

SAP® Standard Solution Documentation for Custom Development 3 Software Change Management Explain which tools have to be used to deploy software changes for your software compo-nents. Which are the names of the software components within the systems? If there are multiple systems involved you should use the one-transport-order-mechanism for consoli-dated transportation through the landscapes. Describe the dependencies of the components. For SAP application server based components, the SAP transport tools have to be used.

4 Troubleshooting Explain which typical problem types exist and how to troubleshoot them (e.g. via a flow chart). Explain which tools to use for troubleshooting (e.g. error logs, perform and analyze traces). Explain which application component to be used to report problems in which area.

© 2008 SAP AG


of 52


Copyright 2009 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software compo-nents of other software vendors.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos are trademarks or

registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated logos displayed are the trademarks of their re-

spective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only in-tended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. SAP

assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not

limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in

cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does

not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

© 2008 SAP AG


of 52

solution documentation for custom development

Documents