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 Development Version: 2.0
Page 1 of 52
SAP Standard Solution Documentation for Custom Development

Change history:
Version 1.0 2.0 Date August 2008 March 2009 Changes Original version Updated version referencing new features for documentation of custom code available with SAP Solution Manager 7.0 EHP1
2008 SAP AG
Page 2 of 52
1 2 3
3.1 3.2
MANAGEMENT SUMMARY .................................................................... 4 SAP STANDARDS FOR E2E SOLUTION OPERATIONS....................... 5 TECHNICAL REQUIREMENTS OF PROVIDING DOCUMENTATION.... 8
Location and Format of Documentation Content .......................................................... 8 Documentation Language.................................................................................................... 8
4
4.1
REQUIREMENTS FOR MINIMUM DOCUMENTATION CONTENT ........ 9

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 4.4 Physical System Landscape ............................................................................................. 13 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 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 Application Components.................................................................................................... 20 Interface Documentation .................................................................................................... 21 Documentation of Background Jobs .............................................................................. 25 Transactions and User Entry Points ............................................................................... 28 Performance and Volume KPIs......................................................................................... 29 Development object list for Custom Development or Customizing Objects ........ 30 Functional Documentation / Business Background ................................................... 31 Integration and Volume Test Plan Documentation...................................................... 32 Application Operations Guide........................................................................................... 33
5
5.1 5.2 5.3
APPENDIX.............................................................................................. 34
Template: Functional Documentation............................................................................. 34 Template: Test Plan Documentation ............................................................................... 37 Template: Application Operations Guide....................................................................... 49 Solution Documentation for Custom Development Version: 2.0 Page 3 of 52
2008 SAP AG

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 SAPs standards for End-to-End Solution Operations, 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. identification 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 location 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 explanation 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
Page 4 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, process 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 strategy, 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 firstlevel support for their colleagues. Business process champions define how business processes are to be executed. A program management office communicates these requirements 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 business units. It is responsible for implementing the business requirements and providing sup 2008 SAP AG Solution Documentation for Custom Development Version: 2.0 Page 5 of 52

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 detailed system diagnostics. And the IT infrastructure organization provides the underlying IT infrastructure (network, databases ). Further specialization is possible within these organizations 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 SAPcentric 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 integrate the providers of out-tasking and out-sourcing services into the operation of their solutions. 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 exceptions 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 optimize the supportability of customer solutions Business Process and Interface Monitoring describes the monitoring and supervision of the mission critical business processes Solution Documentation for Custom Development Version: 2.0 Page 6 of 52
2008 SAP AG

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 solutions 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 Custom Development.
2008 SAP AG
Page 7 of 52
3 Technical Requirements of Providing Documentation

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 Development. This chapter describes the preconditions for providing the required documentation. This includes the expected location and format as well as the language of required documentation.
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 customer solution environment. In case of multiple SAP Solution Managers in the customer landscape 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 Manager during the development phase and later on transfer it to another Solution Manager. The full documentation capabilities for ABAP-centric developments are available within Solution 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 chapter 4 (Requirements for Minimum Documentation Content). In case you already have documentation 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
Page 8 of 52

4 Requirements for Minimum Documentation Content
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 Administration 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 document 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 important 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 applicable 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): Solution Documentation for Custom Development Version: 2.0
2008 SAP AG
Page 9 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 implementation 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 system 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 organization (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 project is not led by your organization also the responsible person for this project within Solution Documentation for Custom Development Version: 2.0
2008 SAP AG
Page 10 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 projects and still ongoing projects. 4. Enter the planned and (if available) actual start and end dates as well as the anticipated 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 already 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 project. 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 component 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 component, 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 following sub-section 4.2.1 (Documenting usage of 3rd-party software).
2008 SAP AG
Page 11 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 Solution Documentation for Custom Development Version: 2.0 Page 12 of 52

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 define 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 registered 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 Solution Documentation for Custom Development Version: 2.0 Page 13 of 52

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 solution 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 definitions 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
Page 14 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 Administration 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 assigned 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 portfolio in the so-called Business Process Repository (BPR). Whenever your custom development 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 Solution Documentation for Custom Development Version: 2.0 Page 15 of 52

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 processes 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 Configuration 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 complete 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
Page 16 of 52
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 business 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
Page 17 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 scenario 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 beforehand 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 activity that executes a single logical step within the business logic. It is not necessarily the execution 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 setting 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
Page 18 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 reflected 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 business 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 Solution Documentation for Custom Development Version: 2.0 Page 19 of 52

change the step class from Custom to SAP (resp. SAP with extension or SAP with modification) for those that are original SAP.
Attribute name / Category SAP standard
Meaning Business step is fully realized with SAP standard code. Used also in SAP standard business processes. Business step is realized with SAP standard code with implemented custom enhancement (e.g. BADI implementation). Business step is realized with SAP standard code that was modified (i.e. original SAP program code in SAP namespace was changed). Business step is realized by custom code within custom namespace.
SAP with enhancement
SAP with modification
Custom development
Table 1: Classification Types of Business Process Steps It is important to understand which of the business processes are essential for your key businesses 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 comSolution Documentation for Custom Development Version: 2.0
2008 SAP AG
Page 20 of 52

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 application. 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 identification 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 common 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
Page 21 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 scenario 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
Page 22 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 processing within a certain time frame. Entering no required response time means that it is sufficient if the system can handle the total document volume over time without constantly increasing backlog.
2008 SAP AG
Page 23 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 business 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 systems and the interface type must match (see Figure 4.19 as an example).
2008 SAP AG
Page 24 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 existing one (see Figure 4.20).
2008 SAP AG
Page 25 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 scheduler. 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
Page 26 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 scheduling 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
Page 27 of 52

4.9 Transactions and User Entry Points
Business process steps may be invoked by different means. They may be executed automatically 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 manually 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 information at business process step level (see Figure 4.22). In cases where there are multiple possibilities 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 (usually 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 allows 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 Solution Documentation for Custom Development Version: 2.0 Page 28 of 52

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 possible 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 process). In the KPIs tab, you need to select an object that was previously entered in the transaction 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 requested fields with your best estimations. In the document volume tab you provide information 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
Page 29 of 52

4.11 Development object list for Custom Development or Customizing Objects
All development objects that are newly created or modified within your project shall be documented 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 development 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 administration (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 customizing 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 development systems directly and to put the references into SAP Solution Manager. We highly recommend that you manage all your transports via a centralized transport management 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 physical systems and the connectivity are defined in SAP Solution Manager).
2008 SAP AG
Page 30 of 52

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 request. 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 business persons from your company but also by people not familiar with the organization 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
Page 31 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 investigated, 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 extension 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 appendix of this paper and for download in the media library for E2E Solution Operations standards 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 Manager, you have to put all uploaded documents into the folder tab named General Documentation 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 execute integration and volume tests that cover all business processes and all software components involved in the projects 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 Solution Documentation for Custom Development Version: 2.0
2008 SAP AG
Page 32 of 52

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 (available 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 background 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 complete solution and how to integrate all components into the one-transport-order concept. 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
Page 33 of 52

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 development. 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.
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
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
Page 34 of 52

3 Functional Documentation
Explain how the functionality is realized by the custom code on a logical level. The documentation 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 Manager 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 nonSAP standard step what it does and how it is triggered (user interaction, synchronous/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 alternative?
Responsible person at customer who signed off for this modification:
2008 SAP AG
Page 35 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 functionalities of SAP products).
2008 SAP AG
Page 36 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 protected 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 XYZ GmbH XYZ GmbH Phone +49(1)777-888 +49(1)888-777 e-Mail john.smith@xyz.com John Smith; Business Process Owner(s) Klaus Mustermann
klaus.mustermann@xyz.com
Roles
Role / Area 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 Responsible Company Phone e-Mail
2008 SAP AG
Page 37 of 52

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:
SID 1 PRD System role R/3 system, Automotive Release 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 transport routes in the landscape. Example: the table below describes the classical 3-systems landscape DEV 4 -> QAS 5 -> 6 PRD . Here PRD is a downstream-system for QAS and DEV is upstream-system for QAS:
SID DEV QAS PRD
Role in the transport landscape Development system Quality Assurance system Productive system
SID of upstream system DEV QAS
SID of downstream system QAS PRD -
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
Page 38 of 52

Systems in Transport Landscape
SID Role in the transport landscape SID of upstream system SID of downstream 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 different for several projects please enter the information for each project in one field using a project short name as a prefix. Example:
Step / Function Perform functional test in DEV Project, Name and Role PSAP_R3 - J.Smith, Test Manager; SCM_SAP - S.John, Test Manager
Roles in Change Management

Step / Function Decision about software projects Create and assign transport requests to developers Plan functional test in DEV Perform functional test in DEV Transport into QAS Monitor result of import in QAS Plan test in QAS Perform test in QAS Approval of test Import into PRD Monitor result of import in PRD Project, Name and Role <Please type in your answer here> <Please type in your answer here> <Please enter your answer here> <Please enter your answer here> <Please enter your answer here> <Please enter your answer here> <Please enter your answer here> <Please enter your answer here> <Please enter your answer here> <Please enter your answer here> <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
Page 39 of 52

Exceptions
Questions Is an exception to this workflow allowed (e.g. for emergency transports)? Answers Yes No
Who can request those emergency transports?
End User Key User Business Process Owner System Owner (Administrator) Development <Other> Key User Business Process Owner System Owner (Administrator) Development Manager <Other>
Who is responsible for approval of emergency transports?
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 Change request form available? Change request database available? Answers Yes No Yes No
Current Test Strategy Activities distribution Action: Please use the tables below for each test type to describe how the test activities are assigned to organizational units in the company. SAP is interested in the following test types: Unit Test 7 , User Acceptance Test 8 , Customer Development Test 9 , Integration Test 10 ,
Unit Test the lowest level of testing where the program or transaction is tested and evaluated for errors
2008 SAP AG
Page 40 of 52

Regression Test
and Technical System Test 12 . 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 organizational unit.
Unit Test Who performs an activity? Every Business Department on their own Central Test organization in each branch Central Test organization corporate wide Central Project IT de- team partment <Other>
11
Activities
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>
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 specifications made before 9 Customer Development Test mixture of Unit Test and Integration Test with scope limited to the customers own development 10 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 crossfunctional 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 unexpected side effects 12 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 infrastructure 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, disaster recovery
2008 SAP AG
Page 41 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>
EWA Early Watch Alert RBE - Reverse Business Engineer - a tool used for process-oriented analysis and continual optimization of SAP production systems. Using data from production systems it is possible to analyze how functions in the SAP System are used and identify potential for improvement
14
13
2008 SAP AG
Page 42 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 Every Business Department on its own Specific project team (implementation / upgrade / etc.) Central Test Organization in each branch Central Test Organization corporate wide Central IT department <Please put in an additional option here if there is any> Man Autom Remarks ual ated <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <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 Is the 2-person policy in use, i.e. test cases need to be tested twice by 2 different persons? Are there any customer-specific quality targets or criteria? 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? Is there a person controlling the correctness of the tests? Yes No Remark <Please enter your comment here> Which? <Please enter your comment here> Which? <Please enter your comment here> Which? <Please enter your comment here> Who is this person? <Please enter your comment here> Who is this person? <Please enter your comment here>
2008 SAP AG
Page 43 of 52

Questions Is there a person controlling the grade of detail of the tests? Do you use templates for test case creation? Yes No Remark Who is this person? <Please enter your comment here> Example? <Please enter your comment here>
Test Case description Action: Please use the table below to specify what information is included in the standard test case description adopted to use in the company. Information in Test Case description
Information Test Case ID (unique identfier) Name of Project Name of Business Process Owner of Test Case Test Type (e.g. Unit, Integration, Regression) Test System Client Detailed description of preparation activities Detailed description of test procedure Check / Expected Test Results Only for Integration Testing: dependencies on other test cases (predecessor and successor) <Please enter an additional option here if there is any> Available Remarks <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here>
Test result documentation Action: Please answer the questions below.

Handling of Test Results
Question Do you document the results of the manual testing? 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) Yes No Remark How? <Please enter your comment here> <Please enter your comment here>
2008 SAP AG
Page 44 of 52

Action: Please use the table below to specify what information is included in the standard test result documentation adopted to use in the company. Information in Test Result Documentation
Information Name of Tester Master Data Transactional Data Actual Test results Status information Remarks Signature Date of Test <Please put in an additional option here if there is any> Availabl e Remarks <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here>
Test KPIs
15
Action: Please mark in the table below what kind of measurements via predefined KPIs you have regarding reliability of the tests.
Test KPIs
Possible measurement General Stability Availability / unplanned downtime Performance No. of short dumps No. of update-errors No. of trouble tickets (per component) Interface throughput <Please enter additional measurementS if there are any> Yes No Remark
<Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here>
15
KPI - key performance indicator - a measurement or metric for evaluating a company's business strategy, performance, or technology. KPI express abstract company objectives in financial or physical units for comparative purposes
2008 SAP AG
Page 45 of 52

Test data preparation and management Action: Please describe what methods you use to prepare the data in QA system database before testing. Test Data Preparation
Possible method Refresh via system copy of PRD Refresh via client copy from PRD Refresh via client copy from a standard client in QAS Manual creation of master data Automated creation of master data Manual creation of transaction data Automated creation of transaction data <Please enter an additional method if there is any> Yes No Remarks <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <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 Microsoft Office Excel spreadsheets Local or central test data databases Paper Automated Test Tools Test data is not managed centrally and is up to a tester <Please enter an additional method if there is any> Yes No Remarks <Please enter your comment here> What kind of databases? <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here>
2008 SAP AG
Page 46 of 52

Test execution Execution Action: Please answer the questions below.
Execution: Manual or Automated?
Question Do you use manual testing in your current test approach? Do you use automated testing in your current test approach? What part (percentage) of the total testing do you perform manually? Yes No Remark <Please enter your comment here> How? <Please enter your comment here> <Please enter your comment here>
Monitoring Action: Please answer the questions below.

Monitoring
Question Does the current test approach allow you to have a clear picture of the testing progress at every point of time? Does the current test approach allow you to estimate whether the time schedule is going to be kept? Does the current test approach allow you to have an overview of the actual test results? Does the current test approach allow you to react as required in case of error? Yes No Remark <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here>
2008 SAP AG
Page 47 of 52

Error Tracking Action: Please describe the workflow for error tracking established in the company.
Error Tracking
Questions Who is involved in case of an error during tests in QAS? 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? Answers <Please enter your answer here> Yes No <Please enter your answer here>
Tools
Action: Please answer the questions below. Tools
Question Do you use CATT
16
Yes / eCATT
17
No Remark <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here> <Please enter your comment here>
for testing?
Are there any 3rd party tools involved in your current test approach? Are there any tools used for assignment of testers? Are there any tools used for execution of tests and documentation of results? Are there any tools used to follow-up in case of error? Are there any tools used to manage test data?
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
Page 48 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, administration, software change management, high availability and troubleshooting. It describes which tasks to be executed and which tools to be used. This document does not replace the Operations Handbook in which the customer respectively the operations organization has documented the concrete tasks, involved parties and interaction procedures. It is rather the basis for defining the Operations Handbook.
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 required 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 messages). 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 components from others using the same interface (e.g. user names, destinations used).
2008 SAP AG
Page 49 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 provided in the background job documentation within SAP Solution Manager.
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 background 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 resources (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 technology components but typically it is also required to setup the technical application configuration accordingly. Solution Documentation for Custom Development Version: 2.0
2008 SAP AG
Page 50 of 52

3 Software Change Management
Explain which tools have to be used to deploy software changes for your software components. 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 consolidated transportation through the landscapes. Describe the dependencies of the components. For SAP application server based components, the SAP transport tools have to be used.
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
Page 51 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 components 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 respective 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 intended 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
Page 52 of 52

Solution Documentation For Custom Development

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Solution Documentation For Custom Development

Uploaded by

Copyright:

Available Formats

SAP Standard: Solution Documentation for Custom Development

Version: 2.0 March 2009

Solution Documentation for Custom Development

Active Global Support SAP AG

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

REQUIREMENTS FOR MINIMUM DOCUMENTATION CONTENT ........ 9

SAP Standard Solution Documentation for Custom Development

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

SAP Standard Solution Documentation for Custom Development

SAP Standard Solution Documentation for Custom Development

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

3 Technical Requirements of Providing Documentation

3.1 Location and Format of Documentation Content

3.2 Documentation Language

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

4.1 Create Project in Solution Manager

SAP Standard Solution Documentation for Custom Development

SAP Standard Solution Documentation for Custom Development

4.2 System and Application Landscape

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

Figure 4.3: Project Administration - System Landscape Screen

4.2.1 Documenting usage of 3rd-party software

SAP Standard Solution Documentation for Custom Development

4.3 Physical System Landscape

SAP Standard Solution Documentation for Custom Development

4.4 Solution Definition

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

Figure 4.8: Solution Manager Wizard for Solution Creation

4.5 Business Scenario and Business Process Documentation

SAP Standard Solution Documentation for Custom Development

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

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

4.5.2 Define missing business scenarios, processes and steps

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

SAP Standard Solution Documentation for Custom Development

Attribute name / Category SAP standard

SAP with enhancement

SAP with modification

Figure 4.13: Setting Core Business Process Attribute

4.6 Application Components

SAP Standard Solution Documentation for Custom Development

Figure 4.14: Application Component Hierarchy Attribute

4.7 Interface Documentation

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development

Solution Documentation for Custom Development Version: 2.0

SAP Standard Solution Documentation for Custom Development