Product Standard Compliance (T0167) - CCPM

SAP Custom Development
Product Standards Compliance
Instructions:
The purpose of this document is to record the compliance with SAP's product standards of your project.
Please check the following wiki page for details of the
Product Standards Process and Exception Handling Process @CD

Custom Development Projects
Product Standard Compliance Sheet
<Project Name>
for Non-Standard Components/Custom Development
For < Type delivery type, e.g., Initial, Interim, Final, etc. >Version: <Version> < Organization Name>
Initial creation on: <Type date of initial checklist creation>, Created by: <Name of Author>
Product Standards Compliance

Released on (date)
by (name)
Additional project information:

Component ID (Java Component ID/
Add-On ID/others)
Responsible Project Manager
Solution Architect
Quality Manager
Production Project Lead
Project Type
Additional technical information: Choose: Details and Version

Specify the basic characteristics of ABAP Transports
your development
In which runtime environment/system SAP WebAS ABAP/SAP System
does your development takes place?
© Copyright 2006 SAP AG. Last Update: 06/05/2024

2 of 111
All rights reserved. Classification: Internal
Product Standard - Accessibility
Further https://wiki.wdf.sap.corp/wiki/display/Acc/SAP+Accessibility+Standard
Details:
Req.-ID Requirement Text
If the Accessibility Standard is applicable an Accessibility

ACC-251 Status Document (ASD) for customers has to be
provided.
A sufficient accessibility test must be performed for each

ACC-252
product.
All data input elements, data output elements and

grouped information/grouped elements (e.g. tables) are
ACC-253
labeled clearly and accurately. Information on required
entries and input is provided for the user.
Every page (screen) has a visible title, which describes

ACC-254
the topic or purpose of the screen.
All important non-text contents (for example, graphics,

ACC-255
videos) have a text alternative.
Information conveyed through sensory means is provided

ACC-256 using distinguishable sensory characteristics (color and
shape/position, rarely sound) and described in text form.
The target and purpose of a reference (including links
and menu buttons) are described in text form, or the
ACC-257
reference text within the application context makes it
clear to the user what the target and purpose are.
UI elements that have the same appearance and same
ACC-258 function are consistently labeled and used throughout
the product.
If the application uses technologies (for example, Adobe
Flex) or components (such as diagrams, interactive
ACC-259 graphics), which exclude specific user groups, then an
accessible alternative must be provided, which offers the
same content and functionality.
Text can be magnified to 200% of the minimum font size

ACC-260 without assistive technologies and without loss of either
content or usability and function.
Text, images of text, and boxes around control elements

(such as buttons) are displayed using a contrast ratio of
at least 4.5:1 between the foreground color and the
ACC-261 background color. Applications that can be used under a
wide range of light conditions (such as mobile
applications) should have the greatest possible contrast
ratio (and no less than 4.5:1).
The application applies the display settings of the

ACC-262 operating system or provides the user with a selection of
color and contrast settings (HCB, HCW, colors).
Information, structures, and relationships conveyed by

ACC-263 the presentation (such as tables) can be identified by
assistive technologies.
a) The name and type (properties, states, and values) of

all UI elements can be identified using assistive
technologies. b) States, properties, and values that can
ACC-264 be set by the user can also be set using assistive
technologies. c) Assistive technologies are informed
whenever properties, states, and values of UI elements
are changed.
Within a page, language atttributes are used to indicate
ACC-265 text content correctly and the language is identified by
assistive technologies.
If markup language is used, it has to be used in a

ACC-266 syntactically correct way, so that assistive technologies
can read and analyze the content correctly.
Within the application, repeated navigation areas are

ACC-267
arranged in the same place and in the same order.
The application offers more than one method of finding

ACC-268
screens and content.
ACC-269 Groups or repeated elements can be bypassed.
All functions of the content can be accessed and used

ACC-270
from the keyboard or other input devices.
ACC-271 The keyboard focus is always visible.
Logically related UI elements receive keyboard and

ACC-272 reading focus in an order that preserves semantics and
usability.
Focusing UI elements or changing their state does not
produce a context change automatically if there is no
ACC-273
conscious interaction with the user (such as choosing
Enter or the tab key).
The product allows the user to check, correct, or cancel

ACC-274
input.
In case of input errors, the location of the error has to be
indicated, a description of the error has to be provided
ACC-275
and suggestions for correcting the error have to be
provided.
If the user of the product requires a further application

(embedded or external) on the end user device to be
ACC-277 able to use the full scope of the product, the new
application must be accessible or an accessible
alternative must be selectable.
The user is informed about time limits and time limits can
ACC-278 be switched off, delayed, or extended before the time
limit expires.
Automatic animations and audio streams can be paused,

ACC-279
stopped, or hidden.
The product should not contain UI elements that flash

ACC-280
more than twice a second.
Link to Wiki page with all CD product standard experts
Description
The Accessibility Status Document is the only way the accessibility status of an SAP product
can be communicated towards a customer. In the ASD statements are given related to
underlying guidelines or regulations. The ASD is an important prerequisite for selling SAP
products to the Public Sector as well as to large enterprises. At the moment, three ASDs are
offered: VPAT for the US market: related to US Section508 (Act) BITV for the German market
related to Geman BITV 2.0 (Act) WCAG for the entire markets related to WCAG 2.0
(Guideline)
Prerequisite for Applicability: Either data input elements and data output elements are
available or grouped information/grouped elements are available. Explanation: The aim of
this requirement is to ensure that all UI elements for data input, data output and grouped
information (like tables, areas dealing with one topic) are clearly labeled. The topic or purpose
of the field must be clearly indicated by the label. Instructions for user inputs (e.g. input field
contains initial text that shows the correct date format if typing a date is required) supports the
user in entering data correctly.
Prerequisite for Applicability: The application has at least one screen. Explanation: The title
text should indicate what the screen is intended for. Screen titles help all user groups to find
their way around the application. Titles help users to quickly and easily decide whether the
content of a particular screen is relevant for them. Assistive technology makes the title
accessible to the user. Note: Title does not mean the "title" attribute.
Prerequisite for Applicability: Non-text content is available and the non-text content is
important in the application#s context. Explanation: The purpose of this requirement is to
ensure that every important piece of non-text content is also available as text. The advantage
of text is that it has a neutral representation. This means it can be output in visual, auditory or
tactile format - or in any combination of these. Therefore any information created as
electronic text can be represented in the most appropriate way for the user. Non-text
contents include icons, graphics, video streams, audio streams. Note: The following cases are
excluded: - A control element or control, which accepts user input and which has a label that
describes the purpose of the element. - Test or exercises that must be presented in a non-
text format: If tests or exercises are invalid if presented in text, then text alternatives at least
provide descriptive identification of the non-text content. - Specific sensory experiences are
required and text alternatives containing at least one description of the non-text content are
available. - CAPTCHAs: If the purpose of non-text content is to confirm that content is being
accessed by a person rather than a computer, then text alternatives that identify and describe
the purpose of the non-text content are provided, and alternative forms of CAPTCHA using
output modes for different types of sensory perception are provided to accommodate different
disabilities. - Purely decorative elements, or elements only used for visual layout purposes or
where the non-text content is not visible for the user. These elements can be configured so
that they are ignored by assistive technologies.
Prerequisite for Applicability: Information is available that is conveyed using visual

characteristics. Explanation: The purpose of the requirement is to ensure that information
conveyed through sensory means has distinguishable sensory characteristics and is also
described in text form. For example, if information is only conveyed using sensory
characteristics (such as color, size, shape, rarely sound) and the information does not contain
any textual description, then this information cannot be conveyed to a blind user. The
descriptive text should not only refer to visual characteristics such as color or shape. For
example, if information is conveyed using the same shapes and can only be distinguished by
color, then a color-blind user might not be able to identify the information.
Prerequisite for Applicability: There is at least one reference. Explanation The purpose of this
requirement is to ensure that a reference is clearly described and that the user knows what
the reference links to.
Prerequisite for Applicability: There are elements with the same functions on multiple screens.
Explanation: If an application contains multiple screens with the same functions, it is important
that these elements (such as menu items, toolbar buttons) are consistently labeled and used.
Prerequisite for Applicability: The application uses technologies or components, which exclude
specific user groups. Explanation: Certain technologies and components can exclude specific
user groups in the application. Charts or flash-based content can often cause problems. If
specific user groups are excluded, the application developers must find a way to provide an
accessible solution with the same content and functionality in the application.
Prerequisite for Applicability: Text content/images of text exists. Explanation: Partially sighted
users who do not use assistive technologies must be able to magnify text by up to 200% of
the minimum font size (see Minimum Fonts Size Concept). Here, the screen layout must be
scaled so that there is no loss of either content or usability and function (for example, no texts
must be truncated). This includes also images of text.
Prerequisite for Applicability: Texts and images of texts exist. Explanation: A minimum
contrast improves legibility for partially sighted users (for example, users with low visual
acuity or color vision deficiencies) and makes content easier to use. In the case of mobile
applications, for example, changing light conditions could have a negative impact on the
legibility of the content and a contrast ratio of 4.5:1 might not be enough. This means that
developers of applications used under changing light conditions need to strive for the widest
possible contrast ratio (at least 7:1 if possible). No minimum contrast is required for texts and
images of texts that are # part of an inactive component of the user interface # purely
decorative # incidental to the main focus of an image or video.
Prerequisite for Applicability: User Interface exists. Explanation: Users with restricted visual
acuity need to be able to adjust the screen display to their individual requirements. For
example, raising the contrast can improve legibility at the onset of presbyopia. Users with a
high level of sensitivity to light, on the other hand, need to reduce the brightness of the
screen. Once a user makes individual screen display settings at the operating system level
(such as selecting a color and design theme, contrast, brightness, or fonts), it is important
that they are applied to the application so that the user only needs top make them once. If
the application itself provides color and contrast setting options, a) the following themes must
be available: high contrast black (7:1) high contrast white b) colors must be available for the
foreground color and background color.
Prerequisite for Applicability: Information and relationships exist that are conveyed using
visual presentation. Explanation: Users perceive the structure and relationships of information
by the different ways it is presented. For example, headers are often in a larger (bold) font;
tables are elements organized in groups sharing row and column names and the
relationships of these rows and columns are vital for understanding the table content;
background colors can be used to indicate that certain content is related. The aim of this
requirement is to ensure that information and relationships conveyed using visual (and
auditory) formatting is preserved when the presentation format is changed. This means it is
important that these structures and relationships are determined technically in the program or
conveyed using text. One way in which the presentation format can be changed is, for
example, when a screen reader is used or when the user replaces the style sheet with his or
her own style sheet or deactivates the style sheet altogether.
Prerequisite for Applicability: User interface elements exist. Explanation: The application
must be programmed using the appropriate rules for assistive technologies that access the
application. It must be possible to identify correctly the name and type (properties, states, and
values) of all UI elements. This is because assistive technologies access these elements,
interact with them, and conveys them accordingly.
Prerequisite for Applicability: Text content exists. Explanation: The aim of this requirement is
to ensure that language attributes are made available to programs so that they can convey
the text content in the correct language. Using these attributes, for example, screen readers
can convey content using the correct accent, media players can show subtitles in the correct
language, and mailboxes can pronounce names properly. Furthermore, users with
impairments can better understand the screen content.
Prerequisite for Applicability: A markup language (such as HTML, Open OfficeXML, or Open
Document) is used, for example in a Web-based application. Explanation: The aim of this
requirement is to ensure that programs accessing the application (mostly assistive
technologies) can read and analyze the content correctly. This can happen only if the markup
language is used in a syntactically correct way. If the content cannot be resolved as a data
structure, it may be the case that different programs present the content in different ways (or
cannot present it at all).
Prerequisite for Applicability: The same navigation areas are repeated across multiple
screens. Explanation: The consistent presentation and arrangement of navigation areas
across multiple screens helps users to navigate quickly and efficiently when using the
application repeatedly. Users who, for example, work with screen magnifiers can only see a
small section of the active screen at a time. They can work more efficiently if the navigation
areas they are used to finding at the top left of the application are in this position across all
screens.
Prerequisite for Applicability: Information objects exist. The user has the option of visiting the
information objects. Explanation: Users must be able to find content in a way that best
matches their needs. It is important that an application offers several options for finding
content directly. Users with visual impairments often find it easier to navigate using "Search"
rather than selecting links.
Prerequisite for Applicability: Repeated elements appear. Explanation: The aim of this
requirement is to ensure that all users can work efficiently with an application. A user must be
able to locate the focus of a page as quickly as possible without, for example, having to
traverse identical content after changing screens. It must also be possible to skip grouped
information, such as tables. Keyboard user must not be subjected to excessive amounts of
tabbing.
Prerequisite for Applicability: Always applicable. Explanation: If all functionality can be
achieved using the keyboard, it can be accomplished by keyboard users, by speech input
(which creates keyboard input), by mouse (using on-screen keyboards), and by a wide variety
of assistive technologies that create simulated keystrokes as their output. No other input form
has this flexibility or is universally supported and operable by people with different disabilities,
as long as the keyboard input is not time-dependent. Note that providing universal keyboard
input does not mean that other types of input should not be supported. Optimized speech
input, optimized mouse/pointer input, etc., are also good. The key is to provide keyboard
input and control as well.
Prerequisite for Applicability: Interactive UI elements exist. Explanation: Users of an
application require a visible keyboard focus to identify which element has the focus.
Prerequisite for Applicability: Logically related interactive elements exist. Explanation: In
applications where the navigation order is important for the user's understanding of the
model, the keyboard focus must also follow this order.
Prerequisite for Applicability Interactive UI elements exist. Explanation: When navigating
through an application, actions must be predictable for the user. When an element is focused
or its state changed, the context must not be changed unless there is further interaction with
the user.
Prerequisite for Applicability: The input of the user is a legal obligation, a financial transaction,
or can cause data to be lost or modified in data repository systems. Explanation: If the input
of a user implies legal obligations or a financial transaction or can cause data to be lost or
modified in data repository systems, the application must ensure that the user can check,
correct, or cancel his or her actions.
Prerequisite for Applicability: Data input elements exist and the application checks user input
for errors automatically. Explanation: If data input is required in the application context, the
user must be informed about any input errors, where they occurred, and be provided with a
text description of the error.
Context-specific suggestions for corrections help groups of users to identify and correct errors
quickly. In an accessibility context, this requirement supports users with impaired vision by
providing them with more specific information about the nature of the input error. The
suggestion contains a precise description of the error.
Prerequisite for Applicability Additional software is required to be able to use the full scope of
the application. Explanation: Many applications uses embedded or external further
applications (e.g. showing pay statements via pdf). If this additional application is not
accessible, a user may not be able to use full scope of an application. This requirement has
three parts: 1. Is there a link to the required software? 2. Does the required software meet
SAP Product Standard Accessibility? 3. Is it possible to change the link to select accessible
software?
Prerequisite for Applicability: Time limits exist that are not part of a real-time event or that are
shorter than 20 hours or that are not required by an activity. Explanation: User with varying
levels of impairment or varying expertise may need more time to complete a task than
specified by the application. If reasonable in the context, it must be possible to switch off or
modify time limits.
Prerequisite for Applicability: There is automatically played content lasting longer than five
seconds (in the case of video content) or three seconds (in the case of audio content) and the
content is presented at the same time as other content and is not related to the activity of the
user. Explanation: Animations and audio streams are designed to attract the attention of the
user. E.g., users of screen readers find it difficult to listen to speech output if other audio files
are played automatically at the same time. Users with hearing impairments are also distracted
by content played automatically. The user must therefore be able to pause, stop, or hide
automatic audio or video content or change the volume independently of the system volume.
Prerequisite for Applicability: Flickering or flashing content exists. Explanation: Groups of

users who are sensitive to light (such as users with epilepsy) can have seizures if the
#general flash# or #red flash# thresholds are exceeded or if the content flickers. It is therefore
important that software does not have content that # Flashes more than twice a second (time-
related content) # Exceeds the #general flash# and #red flash# threshold (space and time-
related content). As it is a pre-requisite for both red flash threshold and general flash
threshold, that there is content, that flashes more than three times a second, the requirement
is fulfilled if there is no content that flashes more than twice a second.
Category On premise On demand On device Compliance
Quality-Always X X X
Quality-Always X X x
Comment
Open
Fulfilled (by
Automated
Tests)
Fulfilled (by
Infrastructur
e)
Fulfilled (by
Manual
Tests)
Planned
Not
Applicable
Not Fulfilled
Product Standard - Business Solution Configuration
Technology
Req.-ID Category Req. Text Req.-Description ABAP
BSC-86 Architecture- All business configuration content of a Only Solution Manager and IMG are x
Always solution/application belonging to SAP allowed means to configure business
Business Suite shall be implemented scenarios, business processes and
by SAP Solution Manager and IMG business process steps in the context
only. Business configuration content of SAP Business Suite.
shall not be part of business function
screens.
BSC-97 Quality- A solution/application belonging to BC Sets are used mainly for: - the x
Specific SAP Business Suite shall support BC- synchronisation of configuration via
sets for automation purposes. SCDT_Mapping between different
implementations of business
processes - automation of tests -
delivery of packaged solutions/Rapid
Deployment Solutions - automation
of configuration process
BSC-104 Quality- A solution/application belonging to The modeling guidelines can be found x

Specific SAP Business Suite shall be modeled here:
in SAP Solution Manager: - In case of https://wiki.wdf.sap.corp/wiki/display/P
applications, model content shall SBSC/Solution+Manager+guidelines.
consist of business processes and
business process steps, with
configuration content assigned where
necessary. Every application shall
have all supported business process
models assigned. - In case of
solutions, model content shall consist
of configuration structures and
business scenarios, with configuration
content assigned where necessary.
Every solution shall have at lease one
business scenario model assigned.
Technology Valid for CDP Size
Java others XL L M S Compliance Comments
x x x x x x CCPM configuration has been

implemented by SIMGH -
transaction /CCPM/customizing
Fulfilled (by Infrastructure)
x x x x Standard functionality of S4/HANA

supports BC-Set
x x x x x CCPM solution is a tool only and

doesn't contain predefined processes
Not Applicable
Open
Fulfilled (by
Automated
Tests)
Fulfilled (by
Infrastructur
e)
Fulfilled (by
Manual
Planned
Tests)
Not
Applicable
Not Fulfilled
Product Standard - Functional Correctness Link to Wiki page with all CD product standard experts
Req.-ID Category Req. Text Req.-Description
CDP-FC-1 Corporate Software code shall be developed Each program shall describe a minimum set
according to the mandatory coding of coding rules for the produced software.
rules. These coding rules shall be derived from
rules defined SAP wide for a programming
language (if applicable). To ensure
compliance with the defined rules static
code checks shall be implemented. There
shall be no open violations of coding rules
of priority very high or high.
CDP-FC-2 Corporate Each new functionality shall be The implementation of new functionality in a
tested successfully. product shall be verified successfully in
accordance with the chosen test strategy.
It shall be possible to show, which new
functionality was tested with which test
cases and that these test cases have been
executed successfully (in this context we
use the term "traceability")
CDP-FC-3 Quality- All regression tests of previously tested The regression test shall ensure that defects
Always functionality shall be executed have not been introduced or uncovered in
successfully in accordance with the unchanged areas of the software, as a
chosen test strategy.
result of changes made. It is performed
when the software or its environment is
changed. Ensure traceability from
regression test objects (per default business
scenarios in TOR) to associated tests (per
default in TWB).Depending on the test
strategy for example (a) the regression test
of takt 2 includes the functionality
previously tested in takt 1 and (b) the
regression test includes the functionality
(e.g. scenarios, processes, requirements,
use cases, etc.) previously tested and
shipped in a former release. It has to be
defined and agreed during planning phase
for this product standard how the fulfillment
of the requirement will be proven.
CDP-FC-8 Quality- In case of open incidents an exception

Always
All test incidents with priority "very
high" and "high" shall be solved in procedure shall be followed including a
accordance to the agreed Maximum qualitative assessment of these issues in
Processing Times (MPT). relation to customer impact.
duct standard experts
CD-specific Info Compliance
Static check tools are for example Code

Inspector, CheckMan, JLin or ATC (ABAP
Testcockpit).
Fulfilled (by Automated

Tests)
It is necessary to ensure a traceability

from test cases to requirements. Normally
for CDPs the system GTP is used for test
coordination and CSN for error reporting.

Tests)
For those CDPs, where we ship the first

release, there is no activity necessary to
fulfill this requirement.

Tests)
Normally incidents for CDPs are logged

using the CSN system.
Fulfilled (by Manual Tests)

Comment
ATC is used
Set of the requirements forms Show&Tell Session. Content of

Show&Tell Session is documented as Scenario. Each scenario
is covered by Selenium automated tests.
All Selenium automated tests will be used for regression

test before delivery of 2nd release
All test incidents are prioritized and processed according

its priority
Open
Fulfilled (by
Automated
Tests)
Fulfilled (by
Infrastructur
e)
Fulfilled (by
Manual
Tests)
Planned
Not
Applicable
Not Fulfilled
Product Standard - Globalization
Req.-ID Req. Text
GLOB-94 The product shall be fully Unicode

enabled which includes the ability to
transact and store all Unicode
characters.
GLOB-146 The product shall work with all

languages with the same quality and
functionality and similar performance.
GLOB-7 Data in XML format shall be persisted
and transmitted in UTF-8 only.
GLOB-17 Text data shall be sorted following

locale-specific (country- and language-
specific) rules and conventions.
GLOB-24 The following settings shall be

personalizable to user specific settings:
date-, time- and number format as well
as time zone.
GLOB-23 User Settings that include time zone,

date, time and number formats, and
language shall be retrieved from a
single centralised user-management
module.
GLOB-104 The Japanese Emperor Calendar shall

be supported in the UI and in date
input.
GLOB-105 A customizable Islamic Hijri Calendar
shall be supported in the UI and in date
input.
GLOB-42 Different paper sizes shall be

supported.
GLOB-56 Text resource files shall use formats

that are supported by SAP translation
tools. In a non-ABAP environment
translation-relevant strings (resources)
need to be provided in one of the
following formats: XLIFF (including
SAP specific meta data), SLIM, S2X,
INFO or BDL. In an ABAP
environment, this requirement is
fulfilled automatically. User assistance
(documentation, in-app help with Web
Assistant) needs to be provided in
DITA XML and stored in the IXIASOFT
content management system to enable
the integrated translation process.
GLOB-61 For each text to translate, context

information (meta data) to translator
shall be supplied.
GLOB-65 Translations shall be traceable back to

the original element so that errors
reported can easily be fixed by the
translation team.
GLOB-57 If a text is not available in the user

language it shall be ensured a
language fallback or supplementation
to another language.
GLOB-64 The product shall ensure that all

language dependent customer data is
translatable.
GLOB-178 Architecture shall allow delivery of new

languages independently of the
delivery of software components.
GLOB-70 Support of currency reforms (e.g. Euro
conversion) shall be ensured
GLOB-71 Parallel usage of two currencies in the

same country shall be supported
GLOB-74 Address formats shall be made

adjustable to different country formats.
GLOB-75 Multiple address versions that allow the

same address to be maintained in a
non-latin and a latin script respectively
shall be supported.
GLOB-81 Functional localization shall be

encapsulated per country in a way that
it can be shipped and maintained
independently of other country
versions.
GLOB-82 The user interface shall provide the
capability to display/hide country
specific content.
GLOB-127 Development language shall be

English
GLOB-179 The product shall support a right-to-left
layout and bidirectional (bidi) text in
input, display and printing.
GLOB-181 Development tools delivered by SAP

shall support the creation of
internationalized applications.
GLOB-182 Legal compliance for the target

countries shall be ensured.
GLOB-183 Data or file transfer between systems

or system components (e.g. a separate
printserver) shall always be done with
the necessary code page conversion to
ensure data integrity.
GLOB-184 Search algorithms shall support

language specific characteristics to
avoid inaccurate or incomplete search
results.
GLOB-185 Currencies shall not be hard-coded

and shall meet international standards.
GLOB-186 The product shall work correctly across
different time zones and during the
daylight saving time switch.
GLOB-187 The product shall be translatable.
GLOB-188 Translations to all supported languages

and functional localizations for all
supported countries shall be provided
as outlined in the Country and
Language Strategy.
Techn. 1 Techn. 2 Techn. 3

Req.-Description
Unicode compatilbility is the best way to implement the ability to accept user
input in different scripts (ex. Latin, Cyrillic, Asian scripts, etc) and a
prerequisite towards making your software translatable and saleable in all
major markets. Note that Unicode support might still be destroyed by careless
programming, and extra effort needs to be taken to ensure Unicode
compliance. For example: When using Windows APIs, Unicode versions
should be used in spite of the availability of non- Unicode APIs. -
Automatically enforced by NetWeaver ABAP - Supported by NetWeaver
Java, .NET and JRE Additionally, the following tools help you with ensuring
Unicode compliance: - The ccQ Unicode check for your C-code - The jlin
check 'Internationalization' for your Java-code
The product shall be able to display and function in languages such as Arabic
or Japanese in the same way as in English or French.
UTF-8 is the platform independent Unicode encoding that is also a standard

for persisting and transacting XML data. [This can be tested by persisting
non-English special characters in the XML file, for example: Ä Ü ß, etc]
Text sorting shall be done so that the result corresponds to the users’
expectations. For example words with special characters might be sorted
differently depending on the language context in which they are used.
For Asian languages a proper sorting algorithm is more critical than for other
languages.
The locale-specific ordering of text is specified, for example in the Unicode
collation algorithm.
If a date, time, or number is displayed, the display format shall meet the user's
expectations and avoid misinterpretation. supported in NW ABAP (enforced,
if date, time, and number formatting is left to the framework) supported by
Web Dynpro (Java as well as ABAP), ensure an appropriate personalization
screen is available, ensure correct typing of fields
This requirement ensures that centralised user management is adopted

instead of each application developing its own user settings management tool.
Netweaver ABAP and Java supply a User management engine (UME) module
for the same, and runtime frameworks like Portal or WebDynpro can interface
with this UME module. The application should not override the format
information that is maintained and supplied by framework that works with the
UME.
The Japanese Emperor Calendar is mandatory for software sold to public
sector institutions in Japan. Different from the Gregorian calendar used in
most Western countries, the years are counted based on the era of the
current emperor dynasty. For example, the year 2012 is Heisei 24 in the
Japanese Emperor Calendar. For the sake of improved usability, it is
recommended to support a date-picker control for the Japanese Emperor
Calendar. If the product contains further calendar controls, these shall also
support the Japanese Emperor Calendar.
The Islamic Hijri Calendar is based on the moon, and needs to be customized
as different Islamic countries follow versions that may vary in the actual date
by a few days. For sake of improved usability, it is recommended to support a
date-picker control for the Islamic Hijri Calendar. If the product contains
further calendar controls, these shall support the Islamic Hijri Calendar as
well. In ABAP based products this is provided by the technology, if date
formatting is left to the framework.. Please see the link for calendar support
information in further technologies and backend-frontend scenarios. supported
in ABAP Dynpro, Web Dynpro ABAP supported in Web Dynpro Java since
7.20 (not DatePicker, only when connected to an ABAP System) supported in
double stack scenarios with NW Java 7.20 and higher
Formats such as, for example, 'US Letter' in the USA or 'DIN A4' in Germany
must be supported.
This is automatically enforced in SAP spool, ABAP list, SAPscript and
Smartforms. For further information, check section Input, Display and Printing
of the Internationalization (I18n) Guide.
Translation-relevant strings (resources) need to be provided in one of the

formats supported by SAP's production and translation infrastructures which
includes the industry standard XLIFF 1.2. In the context of new repositories,
build infrastructures etc. preference should be given to XLIFF, since SLIM,
S2X, INFO and BDL should only be used in legacy contexts.
- meta data: e.g. maximum length, domain, target group, string category
(button, label), comment/description - do translators easily see the
relationships between related UI strings (e.g. all entries in a menu)? -
translated strings of a dashboard visible in realtime at the final screen location
This requirement aims to ensure that the traceability information is
automatically available to the translator without the need for him / her to
contact development in event of a bug in translation. When a defective text is
found on the display, a tool or framework supported way to find the
corresponding text element in the database or within the resource bundle files
is very helpful.
If, for some reason, a specific text is not or not yet translated, it should be
displayed in another language. As all texts of SAP Software must be available
at least in English, it is recommended to switch to English text display if the
desired language cannot be selected. This does not refer to a complete
translation, but to special output texts from functions that might not be
translated (e.g. reused components).
Language dependent customer data is for example: product description,
invoice templates, freight accompanying documents, safety instructions for
dangerous goods and other kinds of content. Textual data that is not needed
in other languages does not need to be translatable.
In ABAP systems, customers can use transaction se63 to translate their 'own'
data.
This requirement aims to ensure that resources and languages are packaged
and shipped independently of the software logic / components. There needs
to be a capability to deliver new languages without needing to rebuild and
repackage the entire product or parts thereof, and without needing to wait for
the next support package. When compliant, adding a language will not be like
an upgrade project for the customer. For SAP, compliance will reduce risk
otherwise caused by the complexities in delivering a complete installation
package / service pack.
Products should be prepared to support any currency change/conversion (e.g.
from local currency to EURO). The full support of currency reforms can be very
complex especially (but not exclusively) for the Financials area. For example,
SAP Business Suite customers typically need to run a specific project for
countries where the currency is changed.
Currency reforms are a complex topic, but different products are affected to
different degrees. So the main question you should ask yourself is how the
effects of changing the currency during a currency reform would affect your
customers and their data. How would you enable the customer to change the
currency of business transactions, support a possible dual currency phase or
help convert historic records to the new currency? The answers to these
questions should help you judge to what extent the requirement is (in)-
applicable or where you need to think ahead and develop a concept for
supporting future currency reforms. The examples below are meant to help
understand these different aspects better.
In the Financials area for example, parallel currencies are required for
International companies operating in multiple countries. Those corporations
typically define one enterprise wide currency e.g. for reporting purposes. This
currency is used in parallel to the local currency which is common and legally
required in the countries of the subsidiaries. This requirement is not restricted
to Financials and sometimes can be relevant for other products, in particular if
they contain valuation amounts or prices. For example, if a system contains
material prices (standard price / moving average) or product costing values.
If applications handle address data and/or names, specific local requirements

must be fulfilled.The most obvious example is the address written on a letter
(e.g compare German/US/UK/Japan addresses). For example, a Japanese
address in Japanese starts with the largest unit and becomes more and more
specific. First the postal code, then the state/prefecture, then
municipality/district/town/village, “block” number, building name, and finally the
house/ room number. Street names are seldom used in Japanese postal
addresses. This means that the application must be capable to store multiple
address elements (like e.g. country/street/house
number/municipality/county/state/postal code/post office box /city/postal code
… and many others) in a flexible manner (do not hard-code).The application
must also be capable to store and present person’s name in a flexible manner,
so that sequence of given name / family name can be adjusted to suite
requirements in east Asian countries like Japan and China.
In China for example, addresses are often maintained simultaneously in

Chinese and in English. This is also true for Russia. In Japan even three
scripts are used: Katakana, Kanji, and Latin (translilteration), which is legally
required in the public sector.
This decoupling will allow us to ship localized versions for different markets
without one version affecting a market it wasn't intended for.
Note: Country specific fields shall only be displayed (or edited) in the relevant
countries. The relevant country needs to be determined according to
underlying business object. There may be cases, where more complex
information needs to be brought to the UI (additional tabs, subscreens, tables,
or even entire new country specific screens).
English is the source language for translation into many languages. Hence,
development should integrate text resources in English (and not in German) to
facilitate good translation.
In languages such as Hebrew or Arabic, the main direction of reading flows
from right to left and the starting point of the screen is in the top right corner.
Bidirectional text can contain text in both text directionalities, right-to-left (RTL)
and left-to-right (LTR). It generally involves text containing different types of
alphabets. Direction dependent icons and images need to be mirrored. Charts
(for example, stock charts) and geographical maps are not mirrored. Bidi
support is also needed for document printing (for example for reports or forms)
from the application.
If your product is or contains a development tool, it shall support the creation of
applications that fulfill the requirements of the product standard globalization.
This includes especially Unicode support and translatability. External
developers using SAP's development tools should also have the possibility to
write applications with text resources in a language of their choice. Internal
developers must follow requirement GLOB-127 and develop in English.
Country-specific legal and best practices requirements such as accounting

rules (including asset accounting and valuation), invoicing, taxation (product,
service, withholding and income tax), statutory reporting, forms, personnel
management, payments and regional holidays / festivity days (via a
customizable calendar) shall be supported. A document containing a list of
affected features shall be provided to enable the customer to easily see where
the product has been adapted or needs customizing to comply with legal
regulations imposed in a particular country
In file transfer between Unicode products, UTF-8 shall be used as an
encoding. If a non-Unicode system is involved, appropriate non-Unicode
encodings shall also be supported. When interfacing with third party products,
data shall be transferred using the necessary code page conversion. In some
countries, it is a legal requirement that documents are supplied in a specific
code page.
The search algorithm must be able to deal with special characters such as
German umlauts, accented letters or some Asian characters that may be
represented as unique Unicode codepoints or as a combination of two or more
codepoints. Consider Unicode character normalization when searching, as this
is one method to resolve different codepoint representations in an
unambiguous way.
A good search algorithm for Asian languages can be very complex due to the
fact that e.g. in some Asian languages, there is no end of word delimiter like
‘space’ in European languages and the average word length can be
significantly shorter.
Your product shall consider the following main aspects:

- All currencies currently used in the world shall be supported.
- Currencies shall be adaptable to customer and/or country specific needs.
The options for configurability shall include the possibility to set the number of
figures behind the decimal point.
- Data storage and display shall be big enough to accommodate the additional
decimal digits or large amounts for high inflation currencies.
- Currency conversion ( conversion from currency X to currency Y ) using a
proper exchange rate shall be supported
- It is recommended that currencies are represented using currency codes
defined by international standards such as the ISO 4217 standard. For
external interfaces, a mapping to the ISO standard is required.
The following aspects need to be considered:
- User, client and server are located in different time zones.
- Users from different time zones work simultaneously and interact.
- The product can run during the daylight saving time switch and time
dependent data (especially input) is processed correctly.
- Time duration calculations shall also work with daylight saving time changes.
- Time information shall be stored in a way that the nature of time (global time,
local time or time zone independent data) is unambiguous.
Translatability means that texts are Unicode compliant and that no hardcoded
texts shall be used, among other things. All texts in an SAP product shown to a
user during normal processing (including common error messages) shall be
translated. A translation is not required for technical texts (e.g. texts that if
translated, might break the program), runtime errors or log entries for technical
logs (application logs may require translation, depending on the business
scenario). The development environment system shall be connected to the
SAP translation system. If this is not the case, you shall create and agree
upon a translation technology roadmap with SAP Language Services.
Language dependencies must be maintained in the Product & Production

Management System (PPMS). Note that even if you are not planning any
translations at present, your product should be designed following
internationalization (I18N) guidelines to avoid excessive development costs
when the translation is required later.
Techn. 4 Techn. 5
Compliance Comments
Fulfilled (by
Infrastructure)
check development language. Product language - RU

Planned only. EN is needed for international support only.
XML is not stored

Not Applicable
Fulfilled (by
Infrastructure)
NW ABAP
Fulfilled (by
Infrastructure)
ABAP
Not Applicable
Not Applicable
Not Applicable
Fulfilled (by
Infrastructure)
ABAP
Not Applicable
translation is not needed

Not Applicable
UI5 technical language

Fulfilled (by
Infrastructure)
ABAP
Not Applicable
translation is not needed
Not Applicable
Fulfilled (by
Infrastructure)
Fulfilled (by
Infrastructure)
Fulfilled (by
Infrastructure)
NW ABAP Addresses functionality is used
Fulfilled (by
Infrastructure)
NW ABAP Addresses functionality is used
Fulfilled (by
Infrastructure)
Fulfilled (by
Infrastructure)
there is no country specific
Not Applicable
should be checked
Planned
Fulfilled (by
Infrastructure)
Not Applicable
there is no country specific
Not Applicable
unicode only products are used

Fulfilled (by
Infrastructure)
ABAP and HANA search possibilities are used
Fulfilled (by
Infrastructure)
ATC-check for hard code

Tests)
Fulfilled (by
Infrastructure)
Fulfilled (by
Infrastructure)
Russian language is only supported
Not Applicable
Open
Fulfilled (by
Automated
Tests)
Fulfilled (by
Infrastructur
e)
Fulfilled (by
Manual
Tests)
Planned
Not
Applicable
Not Fulfilled
Information Lifecycle Management
For all data adequate means shall be taken to prevent problems

DA-11
due to data growth.
Destruction of data from object <please specify> shall only be

performed in full accordance with valid legal retention policies
from audit area <please specify>. Therefore, it is necessary to
DA-8
provide at least a data destruction only solution or an archiving
solution (includes destruction) to additionally allow the retention of
data beyond the system lifetime.
Archiving object <please specify> shall support search using the

DA-5
following criteria: <please specify> ...
Data archived with archiving object <please specify> shall be

DA-6 displayable, e.g. via the following transaction or report: <please
specify display solution(s)> ...
Relationship between the following pairs of business objects (BO)
DA-7 shall be kept after archiving: <please specify BO> vs.
<please specify BO> ... ...
Whenever possible, destruction shall be realized through a

DA-9
connection to Information Retention Manager (IRM).
Destruction of data shall be possible regardless of whether it

DA-10
resides in the database or in the archive.
Each object to be archived or destroyed shall have clearly defined

DA-2
business semantics.
Archived data shall be accessible also after data conversion

DA-4
measures.
DA-12 Tenant Export functionality shall be available
DA-13 Tenant Destroy functionality shall be available

Product Standard Owner: Iwona Luter
Product Standard Co-Owner: Helmut Stefani
Link to Wiki for further information https://wiki.wdf.sap.corp/wiki/display/ILMSAP/Home
Description Category On premise

Fast growing data volumes in the SAP system can slow
down system performance, increase times for
upgrades, backup and recovery, and lead to higher
hardware costs (disc, CPU, memory). Therefore, it is
very important that we provide our customers with data
Architecture-Always X
management functions to help them avoid problems
related to data growth. Note: In case indexing or
partitioning of the data is not sufficient to allow
scalability with the expected data volume, means to
delete data from a live system have to be provided.
The destruction of data in an application is very critical
as this may lead to an irrecoverable loss of the
information contained therein. This may cause legal
compliance problems, for example, in the case of a tax
audit. It is therefore mandatory to check the
destructibility of the data prior to its destruction. Note:
By specifying the audit area you define the reason why
Quality-Specific X
the data needs to be retained. As audit area select Tax,
Product Liability, HR, or Others (please specify). The
concept of data destruction only allows the data to be
destroyed w/o a prior archiving run. An archiving
solution additionally includes the archiving and
snapshot functionality (for mass data handling and
retention of data beyond the system lifetime).
Every archiving object must be able to support access to
individual business objects in the archive using
attributes as search criteria (e.g. order number for a
sales order). To accomplish this, the archiving object
Quality-Specific X
must be integrated into the Archive Information System.
(For XML-based archiving only a property index can be
created and used. The use of the Archive Information
System is not supported.)
The purpose of data archiving is not only to archive data
but also to make this data available to the user (in read-
only mode), if the need arises. Therefore, every
archiving object must provide methods to display the
Quality-Specific X
entire data that it archives. These methods must be
available from within the application where the data
originates, and also be included in the relevant user
roles.
Most business objects that are created in an application
are part of a more complex business process, which is
usually made up of several business objects. Therefore,
virtually every business object is connected to other
business objects from the same or from a different
business process. These object relationships form the Quality-Specific X
basis of the underlying business process. Although
desirable, business processes are not archived as a
whole. To be able to display a business process after
some of its business objects have been archived, the
object relationships need to be intact.
In the ILM solution from SAP, IRM is the central tool for
managing retention policies for business information.
These policies govern the retention periods that define
Architecture-Specific X
when data can or must be destroyed. Whenever a data
destruction program is developed it must be ensured
that destruction does not bypass IRM.
If, according to the retention policies, data can or must

be destroyed it must be possible that the destruction is
performed for the data in the database as well as for the
data that resides in the archive.
In order for an individual data instance to be identified
during archiving or destruction, the object type it is
associated with must be well defined semantically. For
example, as a business object or an archiving object.
Access to archived business objects must be possible
even after the data has been converted using an XPRA
program (in an ABAP environment). Another
requirement is that archived data must remain Architecture-Specific X
accessible even after the operating system or the code
page (for example, due to Unicode implementation) on
a system have changed.
Only applicable for on-demand solutions The tenant
(customer) may request the export of his own data (e.g.
transactional, master, configuration data) to an
appropriate media and in an appropriate data format.
Optionally, delta data export shall be supported. Architecture-Specific
Examples: 1. The tenant requests a local copy (backup)
of his data. 2. The tenant is changing the service
provider. 3. The tenant wants to stop the usage of the
service for a certain period of time.
Only applicable for on-demand solutions At some point
in time the tenant (customer) may want to terminate the
contract with the service provider ("off-boarding")
Architecture-Specific
requesting the hand-over of his complete data. The off-
boarding includes the destruction of all the relevant
data in the SAP system.
ay/ILMSAP/Home
On demand On device Compliance Comments
Data Aging Archive Concept is

X X Planned planned to used but not
implemented yet.
Data deletion is not required and is

X X Not Applicable not possible according solution
specification
Fulfilled (by
X X Supported by Data Aging
Infrastructure)
Fulfilled (by
Infrastructure)
Fulfilled (by
Infrastructure)

specification

specification
Supported by Data Aging (for

Fulfilled (by
X X archiving); for desturction - Not
Infrastructure)
Applicable
Fulfilled (by
Infrastructure)
X Not Applicable
X Not Applicable
Open
Fulfilled (by
Automated
Fulfilled
Tests) (by
Infrastructure)
Fulfilled (by
Manual Tests)
Planned
Not Applicable
Not Fulfilled
Operations and Support
Chapter Req.-ID Requirement Text

The information to operate the components and
Phase 1 ITSAM-1
scenarios of the application shall be documented.
Phase 1 ITSAM-44 The component shall provide version information.
The component shall provide a concept for online
Phase 1 ITSAM-29
backup and consistent recovery.
The component shall be instrumented to monitor
Phase 1 ITSAM-54 performance indicators and consumption metrics of own
managed resources.
For applications that store any data: For all data,
Phase 1 ITSAM-57 adequate means shall be taken to prevent problems due
to data growth.
The product shall be protected by a proper state-of-the-
Phase 1 ITSAM-68
art License Key technology.
The component shall report its version to a central
Phase 2 ITSAM-55
landscape management tool.
The component shall report the following aspects to a
central monitoring tool: # Availability (#Heartbeat#) #
Critical error situations ("Exception") # Performance
Phase 2 ITSAM-11
indicators and consumption metrics of own managed
resources All monitoring features shall be installed and
enabled automatically.
The component shall provide its technical configuration
Phase 2 ITSAM-46
in SAP standardized repositories / interfaces.
Phase 2 ITSAM-17 The component shall write its logs and traces.
The application shall provide remote and safe access for
Phase 2 ITSAM-51
provisioning support services.
The component shall support monitoring, error handling,
Phase 2 ITSAM-41
restart and recovery for all asynchronous interfaces.
The component shall provide functions for clean-up of
Phase 2 ITSAM-31
outdated technical data.
The component shall provide a license measurement
Phase 2 ITSAM-52
function.
The application shall provide a user interface to create a
support message (incident), and shall automatically
Phase 2 ITSAM-56
populate the support message with all the context
information for its processing.
For applications that store retention relevant data:
Whenever possible, destruction shall be realized
Phase 2 ITSAM-58
through a connection to Information Retention Manager
(IRM).
For applications that store retention relevant data: Each
Phase 2 ITSAM-59 archiving/aging or data destruction object shall have
clearly defined business semantics and content.
For applications that store retention relevant data:
Destruction of data shall only be performed in full
Phase 2 ITSAM-60 accordance with valid legal retention policies from the
corresponding audit areas. Therefore, it is necessary to
provide a data destruction or an archiving object.
For applications that need data archiving to control the
Phase 2 ITSAM-61 data growth in the database: Archiving objects shall
support search using suitable search criteria.
For applications that need data archiving/aging to
control the data growth in the database: Archived/aged
Phase 2 ITSAM-62
data shall be accessible via suitable transactions or
reports.
control the data growth in the database: Relationships
Phase 2 ITSAM-63
between business objects shall be kept after
archiving/aging.
control the data growth in the database: Destruction of
Phase 2 ITSAM-64
data shall be possible, regardless of whether it resides
in the database (hot or cold area) or in the archive.
For applications that provide data conversion measures
and need data archiving/aging to control the data growth
Phase 2 ITSAM-65
in the database: Archived/aged data shall be accessible
also after data conversion measures.
The component shall provide functionality for clean-up
Phase 2 ITSAM-31
of outdated technical data.
The component shall provide a central web-based
Phase 3 ITSAM-33
administration UI.
The component shall support the technical requirements
Phase 3 ITSAM-49 for managing custom development and shall be
integrated into the SAP transport system.
The component shall support the SAP adaptive
Phase 3 ITSAM-37 computing concept for landscape virtualization
management.
The component shall provide and implement a concept
Phase 3 ITSAM-36
to minimize unplanned downtime.
The component shall support the SAP E2E trace

Phase 3 ITSAM-23
concept.
The component shall enable the monitoring of execution

Phase 3 ITSAM-53
of business processes.
The application shall provide functionality to recognize
Phase 3 ITSAM-6
and repair data inconsistency issues.
For On Demand solutions: Export of customer data in
Phase 3 ITSAM-66
cloud environment shall be available.
For On Demand solutions: Destruction functionality for
Phase 3 ITSAM-67
customer data in cloud environment shall be available.
Every SAP product shall provide a usage measurement
Phase 2 ITSAM-69
capability.
Product Standard Owner (for SAP Custom Development): Arthur Sehn
Product Standard Owner (for SAP Products): Michael Kloeffer, Suhaib Mohammed
Product Standard Owner (for acquired products): Andreas Krueckendorf
Product Standard Owner (for partner products): Andreas Graesser
Product Standard Owner (for Information Lifecycle Management): Iwona Luther
Link to Wiki for further information https://wiki.wdf.sap.corp/wiki/display/operationssup
Description On premise
https://wiki.wdf.sap.corp/wiki/display/operationssupport/ITSAM-1 X
https://wiki.wdf.sap.corp/wiki/display/operationssupport/ITSAM-66
https://wiki.wdf.sap.corp/wiki/display/operationssupport/ITSAM-67
oeffer, Suhaib Mohammed
rueckendorf
df.sap.corp/wiki/display/operationssupport/Home
On demand On device Compliance

X X
X X Planned
X X
X

X X

X
Planned
X
Not Applicable
X X
X X
X X
X
X X
X
Not Applicable
X X
Not Applicable
X X
Not Applicable
X X
Not Applicable
X X

X X

X X

X X
X X
X X

X X
X X

X
X
X X

X
Not Applicable
X X
Not Applicable
X
Not Applicable
X
Not Applicable
X X
Comments
Documentation is prepared
Only standard indicators and metrics should be

monitored
Data Aging Arhive Concept
There is no component specific alerts
Standard SAP Logging and tracing functionality is used

and tested
SAP PI, SAP qRFC, SAP bgRFC
Fiori
SAP Gateway.
Front-end components running SAP UI5 already have a
built-in mechanism to activate and record client side
traces. It is possible to enable automatic upload of the
traces to SAP Solution Manager if SAP NW servers and
SAP Cloud Platform are involved.
Open
Fulfilled (by
Automated
Fulfilled
Tests) (by
Infrastructure)
Fulfilled (by
Manual Tests)
Planned
Planned
Not Applicable
Not Fulfilled
Product Standard - Licensing
Development shall request and receive the approval for

all use and distribution of Commercial, Open Source
LC-1
and other Third Party Software and Services (e.g.
content, web services, APIs, JSRs) in SAP Products.
Product Standard Expert (for Custom Development) Michael Portner
Product Standard Owner: Janaka Bohr
Product Standard Co-Owner:
Link to Wiki for further information https://wiki.wdf.sap.corp/wiki/display/glwikilc/Product+Standard+
On
Description Category premise
More information on the request/approval process is
provided in the following blog:
Corporate X
https://jam4.sapjam.com/blogs/show/
Xhv1KxBs3BLlRYyRvtDt37
p/wiki/display/glwikilc/Product+Standard+Licensing
On demand On device Compliance Comments
X X Open
Open
Fulfilled (by
Automated
Tests)
Fulfilled (by
Infrastructur
Fulfilled
e) (by
Manual
Planned
Tests)
Not
Applicable
Not Fulfilled
Product Standard - Performance
Req.-ID Req. Text
1. General
1.1. Are performance critical processes part of this CDP?
1.2 Detailed description of performance critical processes
2. Persistence Layer
2.1 Performance-optimized accesses to persistence layer
3. Application Layer
3.1 Parallel processing enabled
3.2 Linear dependency only.
4. Communication
4.1 There shall be no more than 2 synchronous round
trips between front end and application layer per user
interaction step.
4.2 Transferred bytes between frontend and application
layer shall be kept at a minimum
4.3 Average end-to-end dialog response time per

interaction step below 2 seconds
Req.-Description Compliance
Critical processes can be for example:

- immediate response is business critical for the customer (for
example Service Hotline)
- frequently used transactions Planned
- high data volume expected
Detailed description will be basis for the test case / script.

Additionally the test environment has to be described. Planned
This includes:
- Appropriate indexes Fulfilled (by
- Buffers and caches Infrastructure)
- No redundant accesses
Scalable parallel processing and load balancing mechanisms

have been employed in your product. Locks have no impact on Fulfilled (by
parallel processing. Infrastructure)
The CPU and memory required to process a given number of
records depends linearly on the amount of processed data. Fulfilled (by
Please test that there are only linear dependencies. Infrastructure)
Only if product can be used in a WAN environment.

Fulfilled (by
Please report number of round trips per each process. Infrastructure)
Only if product can be used in a WAN environment.
Please report the average amount of transferred bytes between Not Applicable
frontend and application layer.
Only applicable for critical processes with user interaction. avg.
End-to-end response time must be below 2 seconds. Planned
Comments
If answer is "Fulfilled" then next lines need to be processed
Here list of test cases must be filled
HANA database used, BOPF fulfill caches and buffers.

Special performance optimization is not necessary on persistance layer
Load balance is provided by front-end server. Optimistic locks are used.
hardware sizing has been done basing on forecast of HANA DB
usually 1 round trip is used, many requests are combined to Gateway

batch request
LAN environment
must be tested
Open
Fulfilled (by
Automated
Tests)
Fulfilled (by
Infrastructur
Fulfilled (by
e)
Manual
Planned
Tests)
Not
Applicable
Not Fulfilled
761439183.xlsx
X
X Product Standard Security Target Platform on Premise Information Source: SAP Product Standard Security Wiki
X CD Product Standard Experts
X Requirement A B C Applications on NetWeaver

Security Requirement Category Compliance Comments
ID ABAP Platform
X Zero Vulnerabilities
X SEC-102 No data query and manipulation language injection vulnerabilities x Corporate Fulfilled (by Infrastructure) Means provided by platform
X SEC-133 No Cross-Site Scripting vulnerabilities x Corporate Fulfilled (by Infrastructure) Means provided by platform
X SEC-136 No Path Traversal vulnerabilities x Corporate Fulfilled (by Infrastructure) Means provided by platform
X SEC-139 No backdoors x Corporate Fulfilled (by Automated Test) CVA tests and ATC check
X SEC-235 No memory corruption vulnerabilities x Corporate Fulfilled (by Infrastructure)

Compliant by usage of ABAP
code only
X SEC-199
Validate all data in the destination URL when performing URL redirect or
URL forward
x Architecture-specific Fulfilled (by Infrastructure) Means provided by platform
X SEC-220 Protect security sensitive cookies x Architecture-specific Fulfilled (by Infrastructure) Means provided by platform
X SEC-221 Manage security sessions securely x Architecture-specific Fulfilled (by Infrastructure) Means provided by platform
X SEC-223 No Cross-Site Request Forgery vulnerabilities x Architecture-always Fulfilled (by Infrastructure) Means provided by platform
X SEC-225 Validate all data received through component interfaces x Architecture-always

Fulfilled (by Manual Test or
Review)
BOPF validations
X SEC-226 Encode output properly for the component which is meant to process it x Architecture-specific Fulfilled (by Infrastructure) Means provided by platform
X SEC-229 Validate all data that is used to dynamically generate code x Architecture-specific Fulfilled (by Infrastructure) Means provided by platform
X SEC-236 Do not disclose information to unauthorized receivers x Architecture-specific Fulfilled (by Infrastructure)
X SEC-237 Protect against Denial-of-Service attacks x Architecture-specific Fulfilled (by Infrastructure)
X SEC-238 Implement HTTP request and response handling in a secure way x Architecture-specific Fulfilled (by Infrastructure) Generated Smart Templates and ODATA-Services are used
X SEC-243 Load shared libraries and dynamic link libraries (DLLs) safely x Architecture-specific Not Applicable
Not applicable by usage of ABAP
code only
X SEC-263 No operating system command injection vulnerabilities x Architecture-always Fulfilled (by Infrastructure) Means provided by platform
X SEC-264 No clickjacking vulnerabilities x Architecture-specific Fulfilled (by Infrastructure)

Compliant by usage of
WebDynpro ABAP
X SEC-267 Securely process incoming XML documents x Architecture-specific Not Applicable
X Secure Communications
X SEC-218 Provide encrypted communication connections x x Architecture-specific Fulfilled (by Infrastructure) Compliant by platform
X Authentication
X SEC-276 Enforce authentication for all non-public resources x x Quality-always Fulfilled (by Infrastructure) Compliant by platform
X SEC-230
Provide standard identity management, authentication and single sign-on
mechanisms
x Architecture-specific Fulfilled (by Infrastructure) Compliant by platform
X SEC-231 Provide secure User ID / Password authentication x Architecture-specific Fulfilled (by Infrastructure) Compliant by platform
X SEC-232 Provide secure X.509 certificate authentication x Architecture-specific Fulfilled (by Infrastructure) Compliant by platform
X Authorization
SAP Confidential 06/05/2024 Page 67

761439183.xlsx
X SEC-248 Enforce a secure authorization concept x x Quality-specific Fulfilled (by Infrastructure) Means provided by platform
X SEC-250 Provide administration of authorizations based on platform tools x Quality-specific Fulfilled (by Infrastructure) Compliant by platform
X Secure Data at Rest
X SEC-271 Protect sensitive data when stored persistently x x Quality-always Fulfilled (by Infrastructure) Means provided by platform
X SEC-272 Encrypt sensitive data when stored persistently x Architecture-specific Fulfilled (by Infrastructure) Means provided by platform
X Strong Crypto
X SEC-266 Use recommended cryptography only x Architecture-specific Fulfilled (by Infrastructure) Compliant by platform
X Secure Multi-Tenancy to be continued

X Auditing and Logging
X Data Protection & Privacy
X SEC-218 Provide encrypted communication connections x x Architecture-specific Fulfilled (by Infrastructure) See above (Secure Communications) Compliant by platform
X SEC-276 Enforce authentication for all non-public resources x x Quality-always Fulfilled (by Infrastructure) See above (Authentication) Compliant by platform
X SEC-248 Enforce a secure authorization concept x x Quality-specific Fulfilled (by Infrastructure) See above (Authorization) Means provided by platform
X SEC-271 Protect sensitive data when stored persistently x x Quality-always Fulfilled (by Infrastructure) See above (Secure Data at Rest) Means provided by platform
X SEC-224
Capture explicit user consent before collecting any personal data non-
interactively
x Architecture-specific Not Applicable No sensitive personal data processing
X SEC-254 Log read access to sensitive personal data x Quality-specific Not Applicable
X SEC-255
Provide a report or display function which can be used to inform the data
subjects about the personal data stored about them
x Quality-specific Not Applicable
X SEC-256 Erase personal data when all applicable retention periods have expired x Quality-specific Not Applicable
X SEC-265 Log changes to personal data x Quality-specific Not Applicable
X Secure-by-default
X SEC-239 Fail securely x Architecture-always Fulfilled (by Infrastructure)
X SEC-244 Deliver with a secure default configuration x Architecture-always Fulfilled (by Infrastructure)
X SEC-275
Enforce address space layout randomization, executable space protection
and buffer overflow protection
x Architecture-specific Fulfilled (by Infrastructure) Compliant by platform
X Secure-by-design
X Provide a risk-adequate second line of defense against malicious input from intranet only access is planned
SEC-219 x Architecture-specific Not Applicable
the Internet
X SEC-228
Protect upload, download and display functions of untrusted files against
MIME-type sniffing and virus attacks
x Architecture-specific Fulfilled (by Infrastructure) Means provided by platform
X Implement security functions based on a consistent and documented standard concepts are used
SEC-240 x Architecture-always Fulfilled (by Infrastructure)
concept
X
CVA-test
SEC-246 All code delivered shall contribute to documented functionality x Quality-always Fulfilled (by Automated Test)
X Provide a security guide explaining how to securely setup, configure, and Fulfilled (by Manual Test or setup&configuration and user guides are provided
SEC-247 x Quality-always
operate Review)
X SEC-258 Provide separate access to administration functions x Architecture-specific

Review)
administration functions are checked with own authorization checks and
can be combined to special role(s)
X SEC-262
Do not decrease the security level with updates of security settings or
configurations
x Architecture-specific Not Applicable
X SEC-269 Provide basic compliance with Content Security Policy x Architecture-specific

Review)

761439183.xlsx
X SEC-274
Protect authenticity and integrity of all released executable code and
artifacts
x Quality-specific Fulfilled (by Infrastructure)
X SEC-277 Run with minimal privileges required at all layers x Architecture-always Fulfilled (by Infrastructure)
Compliant by platform with
exception
X

Product Standard - Software Lifecycle Part 1 (Formerly Developme
Source code of SAP products shall be managed

using a centrally provided SAP standard revision
SLC-25
control system that ensures archiving, versioning,
security and tracking of changes.
SAP products shall be developed with a

SLC-26 reproducible, automated, documented and
auditable make/build process
Providers of developer tools must ensure that

developed SAP products can be produced in an
automated way. Every automatic transformation
of development objects that is offered by
SLC-28
development tools must also be provided in a
way that is callable by a program in unattended
mode (for example via API or as a command line
tool).
All SAP product versions which are made

available to customers shall be produced with a
reproducible, automated, documented and
SLC-29
auditable make/build process using a SAP
standard build infrastructure provided by a
central team.
All use of Eclipse for SAP products shall follow
SLC-30 the SAP Release Train for Eclipse and shall be
compliant to the SRTE rules
All SAP software shall support Web Browser

SLC-31 versions according to the SAP Web Browser
platforms standard.
fecycle Part 1 (Formerly Development Environment)
https://wiki.wdf.sap.corp/wiki/display/p
Link to Wiki for further information
Description
Category
SAP needs to ensure that the source code is available for development and maintenance,
that access is restricted to authorized persons, and that SAP knows what was changed in
which version and by whom (named person). Having central control of all source code is
also needed to fulfill source code escrow requirements (source code deposit at external
escrow agents). Access control and change tracking is important for fulfilling auditing
Corporate
requirements or for legal cases. To ensure that these requirements are fulfilled in an
efficient way, only centrally managed source code systems shall be used, that means they
are provided and operated by SAP-wide central teams, e.g. Perforce operated by TIP
Production. The current list of allowed source code management systems is here:
https://wiki.wdf.sap.corp/wiki/display/pssl/SLC-25#SLC-25-allowedscm
This is about the build/make process that creates installable/executable software during
development phase or for SAP internal testing. The build must fulfill a set of requirements
to ensure a reliable and efficient software production and to fulfill auditing requirements.
The most important of these requirements are: Traceability and documentation for auditing
reasons, reliability, ability to reproduce old versions (maintenance, implies
versioning/archiving of the build environment), ability to build the software outside SAP
Architecture-
(source code escrow), and the ability to run code checks for security and quality on sources
Always
and build results. It is furthermore important that the results are created only from official
versions of the source code and with the correct versions of libraries, compilers,
generators etc. All this can be guaranteed in an efficient way by a standardized build
procedure that is operated by an SAP-wide central team. Using a not centrally provided (=
local) build requires compliance with the build process guideline. In case the local build
does not fully comply to the build process guideline, an approved exception is required.
This is required to enable other development teams who use the development technology to
be compliant with requirement SLC-26 and SLC-29 (automated build). An example would
be the automatic generation of a Java application from a model (model driven Architecture-
development). It is not sufficient to offer this generator as an interactive tool for the Specific
developer, but it also needs to be provided as a batch tool that can be integrated into
central automated build.
This is about the build/make process that creates installable/executable software. The build
must fulfill a set of requirements to ensure a reliable and efficient software production and
to fulfill auditing requirements. The most important of these requirements are: Traceability
and documentation for auditing reasons, reliability, ability to reproduce old versions
(maintenance, implies versioning/archiving of the build environment), ability to build the
software outside SAP (source code escrow), and the ability to run code checks for security
and quality on sources and build results. It is furthermore important that the results are
created only from official versions of the source code and with the correct versions of
Corporate
libraries, compilers, generators etc. All this can only be guaranteed in an efficient way by a
standardized build procedure that is operated by an SAP-wide central team. To ensure a
smooth handover of the build process to Central Assembly, a handover plan is required for
P2D which is approved by Central Assembly. The product team has to provide a contact
person for the Central Assembly team who assists in setting up the central assembly build
system. Using a not centrally provided build is a violation of this requirement and requires
an approved exception and certification of the make/build process and infrastructure. The
certification process is described in the Build System Certification Guideline.
Eclipse is SAP's strategic platform for design time user interfaces. Eclipse plugins should be
used for these use cases. Eclipse plugins may be used for other use cases, too. SAP
Release Train for Eclipse (SRTE) participation is mandatory for every use of Eclipse for
SAP products. SRTE compliance means that every use of Eclipse for SAP products shall: -
be backward compatible to all versions in maintenance of their related backend systems
provide versions which are not bundled with an Eclipse into installers (= unbundled) -
Architecture-
support the current and previous version of Eclipse - be installable together with other
Specific
Eclipse tools from SAP on one Eclipse instance Details on how to achive SRTE
compliance are described here:
https://wiki.wdf.sap.corp/wiki/display/Dx/SAP+Release+Train+for+Eclipse In addition to the
SRTE compliant versions, other versions are allowed. Examples are other deployment
options such as Eclipse-based Rich Client Platforms (RCP) or support of Eclipse versions
outside of the SRTE.
The SAP Web browser platform standard defines what Web browser / Operating System /
Quality-Specific
Devices must be supported or not, depending on the product type.
On On demand On device Compliance

premise Comments
ABAP Workbench is used

X X X Fulfilled (by Infrastructure) + customer's Git server for
UI5 is used
Fullfilled if ABAP
X X X Fulfilled (by Infrastructure) Workbench is used
Fullfilled if ABAP
X X Fulfilled (by Infrastructure) Workbench is used
Fullfilled if Add-On
X X X Fulfilled (by Infrastructure) Factory is used or
CDP@Customer
N/a if ABAP workbench is
X Fulfilled (by Infrastructure) used
Standard SAPUI5 controls

X X X Fulfilled (by Infrastructure) are used only
Open
Fulfilled (by Automated Tests)

Planned
Not Applicable
Not Fulfilled
Product Standard - Software Lifecycle Part 2 (formerly TICM)
Notes (please expand):
Req.-ID Req. Text
SLC-1 Applications shall be able to be deployed

and to run in a minimal system landscape
setup (default: single instance
approach).
SLC-2 Applications and content shall be able to

be updated without the need of updating
underlying stacks, platforms, database
systems or other components in parallel.
SLC-3 It shall be possible to update individual
applications/products that are deployed
within the system landscape,
independently of each other (avoid
complete landscape updates).
SLC-4 An upgrade to the latest application

version should always be possible from
any older version (Direct Update Path)
SLC-5 After upgrade the system shall be in a

consistent and well-defined state.
SLC-6 An upgrade shall not remove any
software components, technical functions
or business functions, that were already
delivered to customers ("no upgrade to
less").
SLC-7 The update of an application shall not

force a change of the system landscape
layout.
SLC-8 The installation (deployment) procedure

shall be based on a tool, that is provided
by the underlying platform.
SLC-9 The installation process shall be fully

automated, and not require any manual
steps for technical configuration.
SLC-10 All SAP software shall comply with the

OS/DB platform standard.
SLC-11 Applications shall store all permanent

data (e.g. master data, transactional
data, business configuration) in a
standard persistence: # For server-based
applications (ABAP, JEE, C/C++), the
standard persistence is a relational
database system (RDBMS) # For HANA
based applications, use the SAP HANA
database Persistence Layer # For
applications running on mobile devices,
use the standard persistence, as
provided by the manufacturer.
SLC-13 Applications shall store system- or
landscape related information in an
adaptable way.
SLC-14 Developers shall not modify used

components, for example in underlying
software layers.
SLC-15 Source code of SAP Products shall not

be delivered. This does not apply if the
source code is required by the runtime
environment, if it is only part of the
documentation or if it is only a copy
template.
SLC-16 An update/upgrade upgrade process

shall exclude any risk of data loss. All old
application data, configuration and
customizing must be preserved.
SLC-17 Client and server updates shall be
decoupled.
SLC-18 It shall be possible to deliver and apply

urgent corrections at short notice, and
independently of functional updates..
SLC-19 Software shall be shipped and updated

via SAP defined standard channels and
mechanisms only.
SLC-21 After a software update, a mobile device

shall be instantly and fully operational.
SLC-22 Front-End and Mobile applications shall
support a residue-free uninstall.
SLC-23 Use existing integration technologies for
hybrid scenarios (involving on premise as
well as cloud and/or mobile parts.)
SLC-32 An update of cloud based applications

and services shall not lead to downtime
for end users.
SLC-33 Cloud based systems shall support a

rollback of services to an earlier
consistent state.
SLC-34 An update of cloud based applications

and services shall not lead to downtime
for end users.
SLC-35 Up- and downwards compatibility of
services and APIs shall be ensured.
SLC-36 New innovation / functionality shall be

delivered in an inactive mode.
cycle Part 2 (formerly TICM) Link to Wiki page with all CD product standa
Req.-Description Category CDP@Cust
New applications shall be able to run within an existing customer landscape, without the Quality- X
obligatory necessity to add additional technical systems, databases or other landscape Specific
resources. This will help keeping the complexity to run and operate new applications in
system landscapes manageable for customers and therefore ease the adoption of new
innovation. Hence applications shall be able to run in a minimal system landscape
setup at least for demo, test and evaluation purpose. All components mandatorily
required by an application shall be able to be deployed in the minimal system
landscape setup. The default minimal system landscape setup shall consist of at most
the following landscape resources: - a single system respectively a single platform
instance - a single database instance - a single server machine (host) - a common
operating system (e.g. Linux). None of the mentioned landscape resources shall be
technically used exclusively by the application, meaning the landscape resource could
be technically shared with other applications. No mutual software conflicts shall arise
when e.g. different applications run on a common server or in a common system.
An application shall be able to be updated as easy as possible in order to motivate Quality- X

customers to keep the application up to date. And thus concentrates on compatibility Specific
and interoperability. Hence it shall be possible to update applications (bug or security
fixes, corrections, new features) independently from underlying stacks, platforms,
database systems or other components (this includes all required landscape resources
as defined in the minimal system landscape). For example, application or content
updates shall be strictly decoupled from updates of the underlying technology. Make
sure that the updated version of the application does not require any parallel software
changes of the other components and still runs with the unchanged ("older") version of
these components. If the update offers new features (not corrections or fixes), the
active usage of these new features might require also new features (meaning software
updates) of other components like the underlying platform or landscape resources.
However, it must be ensured that this should only be the case, if the new feature of the
application can not be provided with the existing set of capabilities of other components
(e.g. if a new technology capability is going to be adopted by the application).
Furthermore as long as the new features are not used after updating the application,
existing scenarios shall still run like before with the current version of the other
components. Hence the update of other components can be decoupled and are only
required for the time, if and when the new features are going to be used. This
requirement especially applies to applications or content that are deployed on central
systems or central landscape resources, that are shared within a system landscape
across different applications. Otherwise customers will face additional downtime, as
well as high efforts for regression tests.
Customer landscapes typically contain not only one but multiple different applications Quality- X
(e.g. SAP ERP HCM, SAP NetWeaver Portal, Sybase Unwired Platform, Productivity Always
Mobile Apps) that are used in parallel and that interact with each other. Those
applications might run on-premise or on-demand (or a mixture of both), some of them
might even run on-device. Typically those different applications belong to different
individual products and thus have different innovation speeds (leading to different
update cycles). A simultaneous update (implementing bug or security fixes,
corrections, or new features) of the entire system landscape is not manageable for
customers, and would result in an unacceptable overall downtime. In addition updating
the complete landscape would require to run regression tests for the complete
landscape and not only for the single application to be updated, thus leading to
significant additional effort. That is why version dependencies between different
applications must be avoided. Different applications that can be deployed and used
separately, but can interact with each other, shall be able to be updated independently
from each other. It shall be possible to use different combinations of versions for those
applications, when been used together. The update of one application shall not force the
update of another application. If the update of an application offers new features (not
corrections or fixes), the active usage (adoption) of these new features by other
applications might require an update of those applications as well. However, both
updates shall be able to be performed decoupled, meaning existing cross-scenarios
between different applications still run after updating one of the applications (at least
with the old functionality). Any update of centrally used landscape resources or
central servers shall not force customers to update other connected servers or
applications and vice versa. For example, it shall be possible to update a central hub
like SAP NetWeaver PI, SAP NetWeaver Portal, or Sybase Unwired Platform without
updating other hubs or application backend systems like SAP ERP, SAP CRM or SAP
SCM and vice versa. The characteristics regarding updates with new features as
described above are valid as well. This means that central servers must be able to offer
"old" features (for connected consumers that are not updated) and "new" features (for
connected consumers that are already updated) in parallel. In a mobile environment the
requirement means that a mobile application can be updated without updating other
components such as the middleware or backend systems and vice versa. The
requirement also comprises the need for independent software updates between On-
Premise and On- Demand applications that are used together.
Customers shall be able to move their existing application landscape setup to a new Quality- X
application version (e.g. new EhP or new release) in "one step". Any restrictions for the Specific
supported update path or limitations for the selected application landscape setup could
impede the update intent significantly. If customers are forced e.g. to perform a two-step
or multi-step update (e.g. 1.0 => 3.0 => 4.0), the overall downtime increases
significantly, as the first update has to be completed and tested, before the second
update can start. All of the steps in between would result in business downtime. Hence
a complete, consistent & direct update path to the new version of an application must
be available: complete means: An update path from all start releases in maintenance to
the new application version shall exist. consistent means: If different applications are
deployed together in the landscape setup, the update path of one application to the
new version must also be supported by the other applications (e.g. Add-On product
must support all update paths of the underlying product and vice versa). direct
means:The implementation of a certain patch or correction level beforehand as a
prerequisite for the update to the new application version shall not be required.
Applications shall ensure full compatibility with existing customer data and content. Do Quality- X
not introduce any architectural changes that may lead to data inconsistencies. In Always
addition, do not introduce any manual steps during downtime. If such steps are
forgotten or executed in a wrong order, the entire system may become inconsitent, and
hence the upgrade would fail. If application-specific steps have to be included into an
upgrade process, use standard automation procedures such as XPRAS (ABAP) or
Java Migration Controllers.
Be aware that an uncontrolled removal of functions may lead to legal issues, unless the Quality- X
customer contract explicitly allows it. If functions are removed in an uncontrolled maner, Specific
business processes as well as services on customer site can be damaged without
further notice. Also do not remove technical components or services that are consumed
by other components unless they can be easily substituted by other
components/services that provide the same functions.
During software updates (implementing bug or security fixes, corrections, or new Quality- X
features) customers do not expect changes of their system landscape layout that lead Specific
to re-installations, re-configurations or migrations. Changes of the landscape layout are
typically a manual procedure that can not be automated and also cover high risks.
Hence the system landscape setup shall remain stable when applying software updates
for applications. This means that the update shall not force movements (re-
deployments) of software components between different systems, platform instances or
hosts or shall not even require a re-design of the system landscape. If the update
contains new functionality that requires the implementation of additional infrastructure or
landscape resources, then it shall be possible to implement these additional resources
separately and decoupled from the software update process (e.g. adding those
resources to the system landscape before the update takes place).
In order to ensure low TCO on customer side, all SAP products shall be installed with Architecture-
standard tools. This offers the advantage of uniform software lifecycle management, Always
mutual tool integration, as well as entailed compliance with other product standards,
such as Security or Accessibility. The usage of standard tools also helps to reduce
support efforts and costs, as a limited number of well known tools exists and support
colleagues do not have to analyze each problem in a different way.
Technical configuration includes for example: Component initialization, creation of Quality-

users, creation of technical destinations, security settings, content load, and so on. All Always
of these steps have to be automated to the highest possible degree. For mobile
applications, also ensure that the backend connectivity is established automatically.
The SAP platform standard defines what OS/DB platform categories must be supported Quality-
as a whole (or not, depending on the product type) to ensure low TCO on customer Specific
side. For a detailed information, see the platform standard definition in the Portal
(/go/pssl). This definition also includes standards for on-demand applications. HANA
based applications only need to support the operating systems supported by HANA.
Permanent data is data, that must be preserved during an upgrade or system cloning Architecture- X
process. Do not store such data on file system level or other non-standard locations. Always
Otherwise data may be lost during operation, upgrade or system copy. Storing
permanent data in a standard database system also has many indispensable benefits
such as: # Data consistency in a multi user environment # Recovery from failure and
disaster # Backup and restore process # Security and access control # Isolation
between users # Auditability a) AS ABAP, AS Java NW application server (AS ABAP,
AS Java) supports a large set of OS/DB combinations. In addition, heterogeneous
system copy procedures are supported, which allow an exchange of the underlying
operating system or database (for example, a replacement of Oracle with DB2). In
order to ensure low porting efforts, as well as full data consistency after upgrade and
system copy, all applications based on these platforms have to use database functions
that are understood by all supported databases (Open SQL). Developers have to
strictly avoid database specific functions (such as Oracle stored procedures, or specific
SQL Server sort order functions) that possibly lead to different results on different
databases, and hence to data inconsistency. b) HANA It is a key goal of HANA to
ensure highest possible computing performance, as well as independence from other
database vendors. Both can only be achieved with an optimized soft- and hardware
architecture, without any need to support other databases or hardware in parallel.
Hence, applications running on top of HANA do not have to take care for any specific
porting guidelines. Adhere to the general HANA development guides instead. c) On-
demand Platforms In an on-demand environment, database-specific optimization is also
common practice, to ensure best possible performance, as well as low cost of
operation. However, platform decisions have to be taken with full consideration of the
overall product strategy and resulting consequences and limitations have to be
transparent (e.g. increased porting efforts when the OD solution will later be made
available as an on- premise product). Also, in order to ensure independence from other
database vendors, it is strongly recommended to support an SAP database, such as
HANA or Sybase ASE/IQ.
Do not store such data (e.g. host name, SID, IP address, logical system name, logical Architecture- X
destinations) in a location that is only known by the application. Otherwise, it will be hard Always
to adapt it to a new environment. Use a pointer to the central storage (e.g. the system
profile) instead. For Mobile applications, strictly avoid hard coded IP-Adresses. Use
logical backend destinations instead.
Otherwise, later standard updates may overwrite these changes without further notice. Architecture- X
In a non-ABAP environment, modification means copying the code, changing it, and Always
deploying the changed version. In an ABAP environment, do not use modifying Add-
Ons. Modifying Add-Ons lead have to be delivered with a delay of several weeks, lead
to increased internal costs and prevent a fast delivery of urgent corrections (CRT
process required). Use modification free extensibility or enhancement concepts
instead. For ABAP development, the ABAP enhancement framework shall be used with
the BAdI as the preferred technology.
This requirement excludes the following cases: (1) All cases where the source is Architecture- X
required in the runtime system for execution (ABAP, interpreted code). Here the source Always
code is part of the normal delivery. (2) Source code delivered is used exclusively as
documentation. Intellectual property is with SAP. (3) Code is not part of the
implementation of the SAP product but is only a template, from which the customer
creates a copy that is owned by the customer. It needs to be clear for the customer that
SAP is not responsible for supporting any adjustments of the customer code after new
versions of the template are released. Intellectual property for the template code must
be with SAP. In all other cases the main purpose of the shipping source code is
modification by customers or partners. This is not allowed, mainly because of problems
related to support and maintenance (updates) of a modified application.
Upgrades, or more general #Release Updates#, are very important for SAP to Architecture- X
safeguard our maintenance revenue and to ensure investment in new SAP functions Always
and products. Therefore, the upgrade process shall bear a minimum of efforts and risks
Clients, including mobile applications, shall preserve all user data (e.g. e-mails,
contacts, pictures, videos), as well as user-specific settings (e.g. date, time, language).
The upgrade procedure needs to make sure that cached data which has not beed
stored in the backend yet is either preserved or stored first. Cached data which can be
restored from the backend system can be deleted during the upgrade.
End user clients may be based on desktops, laptops or mobile devices and typically Architecture- X
occur in large number. In contrast to components that are deployed in a local system Always
landscape, the innovation cycle of such clients is out of control. This means that every
end user can individually decide the time of update, what leads to the situation that
different client / app versions have to be supported in parallel. Hence the update of
clients (patches, security fixes, corrections, new features) must be decoupled from the
update of any connected servers like middleware components or application systems.
Especially, it must be ensured that a server update is fully downward compatible to the
old client version. By doing so, clients can be updated successively after the server
update. If the update of the server offers new features (not corrections or fixes), the
active usage of these new features might require an update of the client as well (e.g.
new mobile app version is required to use new features in the application backend). In
such a case the server must be able to manage requests from old clients (using old
functionality) and new clients (using the new functionality) in parallel. Alternative: The
update of the client is downward compatible to the old server version. This strategy
also allows decoupling, but it must be ensured, that all clients are updated before
starting the server update. Sometimes this strategy is easier to achieve than making
the server downwards compatible, but it requires more effort for customers and,
therefore is not the most recommended one. For cloud based scenarios it is highly
important that interoperability in both directions is ensured (up- and downwards
compatibility). Notes At least one of the two presented ways of decoupling updates
shall be provided. This works fine as long as client and server belong to the same
product and have the same innovation speed (e.g. client is only used to access a
certain functionality offered by the server application). If client and server have different
innovation speeds, because the same client is used against different independent
server (applications) or the client itself is shipped as independent application/product
(like mobile apps or many analytical clients), only one way of decoupled updates is
typically not sufficient. Such situations are addressed within requirement SLC-3
[Independence of Product Updates]. Planning Define the appropriate update strategy
for your application in order to support decoupled updates for your client and server
components. If the client application is typically used as independent component (with
an independent innovation speed) consider the update needs as requested in SLC-3 in
addition. More details how to achieve version interoperability is described in this white
paper. Validation Based on the selected update strategy, run test scenarios in an
environment where #the server is updated and #one client is updated as well,
#whereas another client is not updated, but remains on the older version. Alternative:
Run test scenarios in an environment where #the client is updated and #the server is
not updated but remains on the older version.
Keep in mind that SAP customers apply Support Packages as well as major functional Architecture- X
updates (Enhancement Packages, Upgrades) only once in a while, to avoid business Specific
downtime, costs and test efforts. However, it must be possible to fix critical bugs on
short notice. This especially applies for Security fixes that are often very time-critical,
when a security vulnerability is undisclosed. Therefore, a process must be in place that
allows a fast and independent delivery of patches without any side effects on customer
side. Hence, do not combine such urgent patches with functional updates. Otherwise,
additional regression tests on customer side would be required and customers may be
reluctant to apply such patches.
Do not ship productive software using non-standard channels, such as FTP download, Corporate
e-mail attachments or SDN. The standard way is to deliver the software via SAP
Service Marketplace or with a physical DVD shipment. In addition, ensure that
standard delivery formats are met. ABAP: Standard are Add-On Packages and ABAP
Support Packages. Forbidden: Delivery of ABAP functions via transport. Java:
Standard is shipment of SCA files. Forbidden: Shipment of productive Java source
code to customers. For mobile applications use the standard channel of the
corresponding mobile device.
The update process on a mobile device must be completely automated. After update, all Architecture- X
functions of the device must be instantly working, without any need of manual Specific
adjustments.
This requirement is important for applications running on smart phones, as well as for Architecture- X
those on laptops, netbooks and tablet PCs. In this user segment, it is a common Specific
practice to install and uninstall applications, e.g. for evaluation purposes. Therefore,
uninstall must be simple, safe and "residue free", which means that that no parts of the
application software remain on the device. After uninstalling, the device must be in the
same state as before installing the application. For frontend applications (such as
SAPgui or PC-based applications), an uninstall process shall also be available.
When extending existing on-premise solutions with cloud services and/or Mobile Architecture- X
applications, no additional infrastructure should be required in the on-premise system Specific
landscape. By making the integration of cloud (mobile) services simple and cheap, the
adoption of new innovation will be fostered. A mobile application shall not force
customers to introduce additional individual infrastructure or landscape resources (like
systems, server, platform instances or database instances) in order to run the mobile
application with on-premise applications. Ensure that the mobile application can be
directly connected to an on-premise application at least for demo, test, and evaluation
purpose. Ensure that only standardized and sharable middleware components are
used to meet scale-out or security needs in a productive landscape. An on-demand
application shall not force customers to introduce additional individual infrastructure or
landscape resources (like systems, server, platform instances or database instances) in
order to run the on-demand application with on-premise applications. Ensure that only
standardized and sharable middleware components are used to meet scale-out or
security needs in a productive landscape. The introduction of needed functional
integration components providing e.g. an interface in the on-premise application for the
cloud/on-demand integration is still possible and not addressed by this requirement.
Notes For scale-out or security reasons it might be required to add an additional
infrastructure component or landscape resource (e.g. reverse proxy, application
gateway, cloud connector) into the on-premise landscape in order to connect on-device
or on-demand applications in an efficient and secure way. We strongly recommend to
utilize a common and standardized mobile infrastructure to connect on-device based
applications with any on-premise application. Ensure that your on-device application
does not use this mobile infrastructure exclusively, meaning the mobile infrastructure
could be technically shared with other on-device applications and is also able to serve
multiple on-premise applications (e.g. today Sybase Unwired Platform is the
standardized product component to connect mobile applications with on-premise
applications). We strongly recommend to utilize a common and standardized
infrastructure to connect on-demand based applications with any on-premise
application. Ensure that your on-demand application does not use this infrastructure
exclusively, meaning the infrastructure could be technically shared with other on-
demand applications and is also able to serve multiple on-premise applications (e.g.
today a dedicated SAP Cloud Connector is been developed for connecting on-demand
applications running in the SAP Cloud with on- premise applications). Planning Design
a reference landscape setup for connecting your on-device or on-demand application
with on- premise applications based on the mentioned guiding principles and document
this setup in your architectural documents (e.g. ACD). Make sure that #Typical
scenarios to access on-premise applications by the on-device or on-demand application
are described #No additional individual infrastructure components for connecting your
application with an on-premise application are depicted as mandatorily required #For
Public Cloud solutions provide services that are consumed over the Internet across Architecture- X
different time zones and locations. The consumption of services by end-users is not Specific
limited to a specific time slot, and therefore full business continuity (7 x 24) is a must.
This includes the exclusion of unplanned downtime with appropriate failover
mechanisms (part of PS Operations & Support), as well as zero downtime update and
correction capabilities. In private cloud scenarios, customer specific downtime SLAs
have to be fulfilled.
Keep in mind that all updates in a cloud environment have an immediate impact on end Architecture- X
users. In case of an unforeseen event, such as an interrupted update, a previous state Specific
should be restored, which is consistent and can be used without any functional or
technical limitations.
Deprecation is an attribute applied to a cloud service to indicate that it will be removed Architecture- X
or replaced by another service in future. In general it is not allowed to remove Specific
services / functions that are in use by customers, unless the license contract explicitly
allows it. To avoid such a forbidden removal, an ongoing monitoring of consumed
services is highly recommended. In addition, a quarantine / shadow storage of
deprecated services would allow a service reactivation, if required. A common practice
is to replace the deprecated service with another service that provides the same or
more functionality. In such a case, both services must be available in parallel over a
longer period of time to give customers the opportunity to slowly adopt the new
service(s).
In a cloud environment, the end user innovation cycle is out of control (browser Architecture- X
versions, App versions). Therefore, contract violations shall be avoided, and backwards Specific
compatibility of services must be ensured. In case of contract violations, each case
should be communicated to customers properly via agreed channels. Strongly
recommended: No storage of application data on application clients / apps and
minimum of synchronization (resulting in network traffic).
This means that a cloud update does not force customers to use new functions Architecture- X
instantly, especially if the related changes have a direct end user impact. Instead, each Specific
customer should have the possibility to decide on the point in time when the new
functions become active. In general customers prefer to determine the point in time
when new functionality is used. This allows customers to train end users in advance,
plan regression tests and decide on the point in time when business related changes
become effective. In addition, automated tests on customer side may rely on a specific
UI layout, such as a button that appears on a specific position of the screen. In case that
a screen layout is changed without further notice, automated tests may possibly stop
working. A technical solution could be providing customer-specific toggles / switches
that allow customers to activate new functions at a specific point in time. In addition.
customers shall be actively informed what new functions are available (e.g. with a pop-
up or online message).
e with all CD product standard experts
on premise on demand on device Compliance
Fulfilled (by
Infrastructure)
Fulfilled (by
Infrastructure)
X X X
Fulfilled (by
Infrastructure)
X X
Fulfilled (by
Infrastructure)
X X
Fulfilled (by
Infrastructure)
X X X
Fulfilled (by
Infrastructure)
Fulfilled (by
Infrastructure)
X X X
Not Applicable
X X X
Not Applicable
X X
Not Applicable
X X X
Fulfilled (by
Infrastructure)
X X X
Fulfilled (by
Infrastructure)
X X X
Fulfilled (by
Infrastructure)
X X X
Fulfilled (by
Infrastructure)
X X X
Fulfilled (by
Infrastructure)
X X X
Fulfilled (by
Infrastructure)
X X X
Fulfilled (by
Infrastructure)
X X X
Not Applicable
X
Not Applicable
X
Not Applicable
X X
Not Applicable
Not Applicable
Not Applicable
Not Applicable
X
Not Applicable
Not Applicable
Comments
CDP@Customer
CDP@Customer
CDP@Customer
standart objects are not modified
Packages and transport requests for UI and backend are
decoupled
CDP@Customer
CDP@Customer
CDP@Customer
CDP@Customer
On Premise and desktop only


Open
Fulfilled (by
Automated
Tests)
Fulfilled (by
Infrastructur
e)
Product Standard Plan / Report (T0167)
Template Information (to be maintained by the template manager)

R (Responsible):
A (Accountable):
C (Consulted):
I (Informed):
Derived Document(s):
Document Classification:
Version:
Release Date:
Template History
Version 3.0, Feb 08th, 2017
Version 2.9, Jan 10th, 2017
Version 2.8, Sep 21st, 2016
Version 2.7, Jan 5th, 2016
Version 2.6, Dec 8th, 2015
Version 2.5, May 26, 2015
Version 2.4, March 31, 2015
Version 2.3, March 18, 2015
Version 2.2, Dec 20, 2014
Version 2.1 Dec 10, 2014
Version 2.0, Dec 5, 2014
Version 1.16, Nov 28, 2014
Version 1.15, Sept 22, 2014
Version 1.14, June 23, 2014

Version 1.13, June 3, 2014
Version 1.12, May 26th 2014
Version 1.11, May 5th 2014
Version 1.10, Jan 17, 2014
Version 1.9 December 2013
Version 1.8 October 2013
Version 1.7 October 2013
Version 1.6 Sept 2013
Version 1.5 January 2013
Version 1.4, May 2012

Version 1.3, Jan 2012
Version 1.2, Aug 2011

Version 1.1, June 2011
Version 1.0, May 2011
Copyright
© 2014
No part of this documentation may be reproduced or transmitted in any form or for any purpose without the expres
permission of SAP AG.
Product Standard Plan / Report (T0167)
nformation (to be maintained by the template manager)

Architect
Project Manager
Quality Manager
Project Team
Product Standard Report is derived from Product Standard Plan
confidential
3.0
February 8th, 2017
Update on Ops & Support

Update on Security: Aligned with SAP Product Standard Security Version 6.0
Update on Globalization Product Standard
Update of Accessibility Tab: Merge of ACC-275 and ACC-276; Added hyperlinks for details on ACC-251 and ACC-252
Alignment with SAP Product Standard Security Version 5.6 and layout improvements of Sec. Sheet, added "Plan" and "Report" column where missing
Updated Open Source with new URLs for Code Center instances
Updated Accessibility
Updated Globalization
Updated Open Source and Third Party
Updated SL Part 2 with on premise, on demand, on device columns
Deleted product standards Usability and Documentation, updated Operations & Support
Alignment with SAP Product Standard Version 5.5 Security and minor improvements, update of PS Functional Correctness
Updated PS Software Lifecycle Part 1 (Dev. Env.) - added 1 requ. and deleted 2 to align w/ standard. Added column w/ pre-defined results in case ABAP w
are used.
Updated PS OS (added link to Black Duck Control Center for CDPs)

Updated PS ILM
Updated PS Performance
Updated PS Usability: Deleted logic to derive compliance on USA-level.
Updated Security: Alignment with SAP Product Standard Security Version 5.4
Updated usability, updaten Ops.&Supp., deleted AII
Updated Archiving/Information Lifecycle Management, Operations & Support, Open Source, 3rd Party
Updated Security: Alignment with SAP Product Standard Security Version 5.3
Updated Software Lifecycle Part 2 (formerly TICM)
Revised Accessibility tab, revised ReadMe sheet
Added 2 missing corporate requirements for product standard Open Source and 1 for 3rd Party, so that document now contains all 8 corporate requiremen
Added header sheet.
Multi Tenancy: removed
Performance: adjusted
3rd Party: requirement text 1.3 adjusted
ITSAM: renamed to Operations & Support
Development Environment and TICM renamed to Software Lifecycle Part 1 and 2 (incl. adjustment of filter for Part 2)
BSC: clean up, focus on three requirements
Globalization: GLOB-106 deleted
AII: changed to guideline
Read me 1st adjusted
Technical Correction
Deleted 2 rquirements from security sheet: A1 - 18 and B1 - 15, as these have been deleted from T239 also.
Initial version
SAP AG. All rights reserved.
this documentation may be reproduced or transmitted in any form or for any purpose without the express
n of SAP AG.
167)
51 and ACC-252
dded "Plan" and "Report" column where missing
nctional Correctness
Added column w/ pre-defined results in case ABAP workbench or AoF
t document now contains all 8 corporate requirements.

ilter for Part 2)
9 also.

Product Standard Compliance (T0167) - CCPM

Uploaded by

Document Information

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

Product Standard Compliance (T0167) - CCPM

Uploaded by

Copyright:

Available Formats

SAP Custom Development

Product Standards Compliance

Please check the following wiki page for details of the

Product Standards Process and Exception Handling Process @CD

Product Standards Compliance

Additional project information:

Additional technical information: Choose: Details and Version

© Copyright 2006 SAP AG. Last Update: 06/05/2024

Req.-ID Requirement Text

If the Accessibility Standard is applicable an Accessibility

A sufficient accessibility test must be performed for each

All data input elements, data output elements and

Every page (screen) has a visible title, which describes

All important non-text contents (for example, graphics,

Information conveyed through sensory means is provided

Text can be magnified to 200% of the minimum font size

Text, images of text, and boxes around control elements

The application applies the display settings of the

Information, structures, and relationships conveyed by

a) The name and type (properties, states, and values) of

If markup language is used, it has to be used in a

Within the application, repeated navigation areas are

The application offers more than one method of finding

ACC-269 Groups or repeated elements can be bypassed.

All functions of the content can be accessed and used

ACC-271 The keyboard focus is always visible.

Logically related UI elements receive keyboard and

The product allows the user to check, correct, or cancel

If the user of the product requires a further application

Automatic animations and audio streams can be paused,

The product should not contain UI elements that flash

Prerequisite for Applicability: Information is available that is conveyed using visual

Prerequisite for Applicability: Flickering or flashing content exists. Explanation: Groups of

Req.-ID Category Req. Text Req.-Description ABAP

BSC-104 Quality- A solution/application belonging to The modeling guidelines can be found x

Technology Valid for CDP Size

Java others XL L M S Compliance Comments

x x x x x x CCPM configuration has been

x x x x Standard functionality of S4/HANA

Fulfilled (by Infrastructure)

x x x x x CCPM solution is a tool only and

Req.-ID Category Req. Text Req.-Description

CDP-FC-8 Quality- In case of open incidents an exception

CD-specific Info Compliance

Static check tools are for example Code

Fulfilled (by Automated

It is necessary to ensure a traceability

Fulfilled (by Automated

For those CDPs, where we ship the first

Fulfilled (by Automated

Normally incidents for CDPs are logged

Fulfilled (by Manual Tests)

Set of the requirements forms Show&Tell Session. Content of

All Selenium automated tests will be used for regression

All test incidents are prioritized and processed according

Req.-ID Req. Text

GLOB-94 The product shall be fully Unicode

GLOB-146 The product shall work with all

GLOB-17 Text data shall be sorted following

GLOB-24 The following settings shall be

GLOB-23 User Settings that include time zone,

GLOB-104 The Japanese Emperor Calendar shall

GLOB-42 Different paper sizes shall be

GLOB-56 Text resource files shall use formats