part v of vi documentation and naming - sap · topic abstraction 1 2 definition term 3 4...

Topic

Abstraction

11

22

Definition

Term

33

44

„Building“

Semantics

Scoping &Understanding

enterprise SOA Object & Service Operation Design

Part V of VI Documentation and Naming Guideline Version 2.7 February 27th, 2009

I Documentation and Naming

Authors:

Michael Seubert

Thilo Krähmer

Authors

Name Role

Seubert, Michael Author

Krähmer, Thilo Author


© 2009 SAP AG Dietmar-Hopp-Allee 16, D-69190 Walldorf

Part V of VI: Documentation and Naming Version 2.7 Date: February 27th, 2009 Authors: Michael Seubert, Thilo Krähmer

of 113

Intellectual Property Rights and Copyrights protected

Table of Contents

I Documentation and Naming ............................................................ 1

Guide to Readers................................................................................................ 7

1 Introduction.................................................................................................. 9

2 Definition .................................................................................................... 13

2.1 Standards for Definition....................................................................................... 13

2.2 Aspects of a Definition......................................................................................... 14 2.2.1 Definition................................................................................................................. 14 2.2.2 Comment ................................................................................................................ 15 2.2.3 Structure ................................................................................................................. 15 2.2.4 Use ......................................................................................................................... 15 2.2.5 Integrity Condition................................................................................................... 15 2.2.6 Constraint ............................................................................................................... 16 2.2.7 Restriction............................................................................................................... 16 2.2.8 Example.................................................................................................................. 16 2.2.9 Note ........................................................................................................................ 16 2.3 Overview of SAP Modeling Entities and their used Aspects ........................... 17

2.4 Definition Pattern for SAP Modeling Entities .................................................... 17

3 Term............................................................................................................ 19

3.1 Standards for Term .............................................................................................. 19 3.1.1 Scope...................................................................................................................... 19 3.1.2 Authority.................................................................................................................. 19 3.1.3 Semantic Rules ...................................................................................................... 20 3.1.4 Syntactic Rules....................................................................................................... 21 3.1.5 Lexical Rules .......................................................................................................... 21 3.1.6 Uniqueness Rules .................................................................................................. 22 3.2 Clarification of Terms........................................................................................... 23 3.2.1 The Semantic Triangle ........................................................................................... 24 3.2.1.1 Synonyms.......................................................................................................... 25 3.2.1.2 Homonyms ........................................................................................................ 25 3.2.1.3 Equipollence ...................................................................................................... 26 3.2.1.4 Vagueness......................................................................................................... 27 3.2.1.5 Imprecise Usage................................................................................................ 28 3.2.2 Reconstructing Terms ............................................................................................ 29 3.2.2.1 Establishing Terms............................................................................................ 29 3.2.2.2 Linkage of Terms............................................................................................... 31 3.2.2.3 Aggregation of Terms........................................................................................ 31 3.2.2.4 Generalization of Terms .................................................................................... 32


of 113 Intellectual Property Rights and Copyrights protected


© 2009 SAP AGDietmar-Hopp-Allee 16,

D-69190 Walldorf

3.2.2.5 Eliminating Linguistic Defects............................................................................32 3.3 Pattern....................................................................................................................33 3.3.1 Terminological Patterns ..........................................................................................34 3.3.1.1 Grouping Together and Dividing Up ..................................................................34 3.3.1.2 Version and Variant ...........................................................................................38 3.3.1.3 Catalogue ..........................................................................................................39 3.3.2 Structure Patterns...................................................................................................40 3.3.2.1 Hierarchy and Net Relationship.........................................................................40 3.3.2.2 Item....................................................................................................................41 3.3.2.3 Assignment ........................................................................................................42 3.3.2.4 Determination ....................................................................................................43 3.3.3 Business Patterns...................................................................................................44 3.3.3.1 Business Transaction Documents .....................................................................44

4 Naming Rules for Model Entities ..............................................................47

4.1 Naming Rule Notation ..........................................................................................47

4.2 Semantic Name and Technical Name .................................................................48

4.3 Object.....................................................................................................................49 4.3.1 Object Template......................................................................................................49 4.4 Object Node...........................................................................................................50 4.4.1 Specialization Node ................................................................................................50 4.4.2 Grouped Object Node.............................................................................................52 4.4.3 Dependent Object Inclusion Node..........................................................................52 4.4.4 Transformation Node ..............................................................................................53 4.5 Relationship ..........................................................................................................54 4.5.1 Composition ............................................................................................................56 4.5.2 Aggregation / Association .......................................................................................56 4.5.3 Association for Navigation ......................................................................................57 4.5.4 Filtered Association for Navigation .........................................................................57 4.5.5 Structure Relationships...........................................................................................58 4.5.5.1 Hierarchy Relationship – Without Attributes......................................................58 4.5.5.2 Hierarchy Relationship – With Attributes ...........................................................58 4.5.5.3 Net Relationship – With or Without Attributes ...................................................60 4.5.5.4 Cross References within Same Level................................................................61 4.6 Data Type...............................................................................................................62 4.6.1 Node Data Type......................................................................................................62 4.6.2 Intermediate Data Type ..........................................................................................62 4.6.3 Filter Data Type ......................................................................................................63 4.6.4 Key Data Type ........................................................................................................64 4.6.5 IDT replacing a GDT Including Keys instead of IDs ...............................................65 4.6.6 Action Data Type ....................................................................................................65 4.6.7 Query Data Type.....................................................................................................66 4.6.8 Query Intermediate Data Type ...............................................................................66 4.6.9 Extension Data Type ..............................................................................................68 4.7 Data Type Element................................................................................................70




of 113


4.7.1 Elements of a Node Data Type .............................................................................. 71 4.7.2 Aggregated Status Element.................................................................................... 71 4.7.3 Element Typed by Key ........................................................................................... 72 4.7.4 Elements of a Key Data Type................................................................................. 73 4.7.5 Action Data Type Element...................................................................................... 75 4.7.6 Query Data Type Element ...................................................................................... 75 4.8 Core Service Operation........................................................................................ 77 4.8.1 Action...................................................................................................................... 77 4.8.2 Query ...................................................................................................................... 77 4.9 Compound Service Operation............................................................................. 78 4.9.1 Service View........................................................................................................... 78 4.9.2 Service Interface..................................................................................................... 80 4.9.3 Service Operation (Asynchronous) ........................................................................ 80 4.9.4 Service Operation (Synchronous) .......................................................................... 81 4.9.5 Service Operation (A2X)......................................................................................... 82 4.9.6 Message Type ........................................................................................................ 83 4.9.7 Message Data Type ............................................................................................... 84 4.9.7.1 Message Intermediate Data Type / Element within a Message Data Type ...... 85 4.9.8 Response View....................................................................................................... 86 4.9.9 Query / Response - Service Operation .................................................................. 88 4.9.10 Query / Response - Message Type........................................................................ 88 4.9.11 Query / Response - Message Data Type ............................................................... 89 4.9.12 Mass Messages...................................................................................................... 90 4.9.13 Reconciliation Messages........................................................................................ 92 4.9.14 Form and Interactive Form ..................................................................................... 93 4.9.15 Create With Reference (A2X)................................................................................. 94

5 SAP Abbreviation Rules............................................................................ 95

5.1 SAP Abbreviations – Guiding Principles ........................................................... 96

5.2 General Abbreviation Rules ................................................................................ 96

5.3 Abbreviations in ARIS - Names and Length Restrictions ................................ 97

5.4 ARIS Name - Abbreviation Rules ........................................................................ 97

5.5 ARIS Technical Name - Length Restrictions Overview .................................... 98

5.6 ARIS Technical Name: Abbreviation Rules ....................................................... 98

5.7 ESR Name Adopted from ARIS Technical Name............................................. 103

6 SAP Object Model - Documentation....................................................... 105

6.1 Target Group Specific Pattern-Based Documentation ................................... 107

6.2 Hints for Object Definition................................................................................. 108 6.2.1 Paragraph „Structure“........................................................................................... 108 6.3 Hints for Object Node Definition....................................................................... 109 6.3.1 Object Root Node ................................................................................................. 110





D-69190 Walldorf

6.4 Hints for Object Node Element Definition ........................................................110

7 Index..........................................................................................................111

8 Change History.........................................................................................113




of 113


Guide to Readers This part describes how a real-world entity, in particular an object of the SAP object model, is to be found and documented.

This covers the abstraction of “real world”-concepts, rules for its definition and the finding of a term for its corresponding model entity.

It is shown what kinds of problems may occur and how to solve them.

Naming patterns are described and hints for defining and naming of dedicated entities are given. Naming rules for the respective model entities are specified as well as abbreviation rules needed to fulfill length restrictions of the modeling tool and implementation environment.

The underlying concepts are not contained within this document. Nevertheless their understanding is a prerequisite for understanding this document. Regarding the concepts refer to the corresponding guidelines.




of 113


1 Introduction Object-orientation reflects the general human thinking:

To understand a topic in the real world, each perception is classified or categorized. This step is called abstraction. The abstract concept needs a definition reflecting its semantics. From this definition, a commonly understandable term is derived. This term has to represent the definition.

Topic

Abstraction

11

22

Definition

Term

33

44

„Building“

Semantics


Figure 1: Understanding the world

The goal of this document is to enable the reader to create a business-oriented, comprehensive documentation of entities such as business objects.

That is:

One document for different target groups with different granularity





D-69190 Walldorf

Why?

• Its all about business

• Clear definition of business concepts

• Transparent business semantics … for everybody

For whom?

• Developers

• Partners

• Consultants

• Independent Software Vendors

• Customers

How to achieve this?

Differentiated Terms - Clear Definition is Key

“The language we use to some extent determines the way in which we view and think about the world around us”

(Sapir-Whorf Hypothesis)

For example, Eskimos have more than 50 terms for “snow” - well defined and clearly separated from each other. That means their language is much more differentiated in that area then for example the German language.

That means clear definition of business concepts is the basis to a

• Clear understanding of the real world

• Clear differentiation between objects




of 113


Examples for business terms

• Activity

• Opportunity

• Lead

• Purchase Requirement

• Purchase Request

• Purchase Order

• Sales Order

But what is their semantics…?

How to find and define an object?

• Get a clear understanding: selective, precise, specific, detailed …

• Define the capsule: That is, find the border

o Inside / outside of the object

o What does belong to the object, what does not …? (the car ?; the tree ?, the house?, the window?)

• Distinction and separation from other objects

This is the basis for the definition.




of 113


2 Definition

2.1 Standards for Definition

SAP Definitions follow the ISO 11179 rules and guidelines

ISO 11179 specifies (amongst others) „requirements and recommendations for constructing definitions for data and metadata. …semantic aspects of definitions are addressed.“

For details see ISO/IEC 11179-4 (Formulation of data definitions)

ISO 11179-4 contains the following requirements and recommendations for a definition:

Requirements:

A data definition shall:

a) be stated in the singular

b) state what the concept is, not only what it is not

c) be stated as a descriptive phrase or sentence(s)

d) contain only commonly understood abbreviations

e) be expressed without embedding definitions of other data or underlying concepts

Recommendations:

A data definition should:

a) state the essential meaning of the concept

b) be precise and unambiguous

c) be concise

d) be able to stand alone

e) be expressed without embedding rationale, functional usage, domain information, or proce-dural information

f) avoid circular reasoning

g) use the same terminology and consistent logical structure for related definitions

h) be appropriate for the type of metadata item being defined

These requirements and recommendations are detailed in the following aspects of a definition.

http://standards.iso.org/ittf/PubliclyAvailableStandards/c035346_ISO_IEC_11179-4_2004(E).zip�





D-69190 Walldorf

2.2 Aspects of a Definition

There are different types of information for the description of an object / entity. These aspects are de-scribed in the following paragraphs. For the development of a definition it is useful to clearly separate these aspects. In ARIS they are separated by using an individual ARIS attribute for each aspect.

2.2.1 Definition

Definition is a description of the particular set of business-related facts that is delimited in an object.

A definition fulfils the following criteria:

Semantics The object is described from a semantical, business-oriented point of view. („An object is …“ ). The definition covers the target scope; restrictions are specified separately.

Use business terms only; avoid technical / modeling terms such as “node”.

Sufficient All differentiating description elements are contained and the relation between them is clear

Abstract / Con-crete

As concrete as possible, abstract where necessary

Necessary No additional information is contained, such as examples, comments, paraphrases etc.

Differentiating The unique selling point of SAP becomes apparent, if such exists.

Outside-In The terminology corresponds to the language and terms used in books or stan-dards of the corresponding area of expertise, including the semantics specified by them. „Not contradictory, only supplementary / more restrictive.“

Integrity For a term used in a definition a definition has to be available. It can be defined in the object model, be commonly understandable or be defined in the comment sec-tion. The relation between the individual terms must be clear.

For example use term “Bidder” if you mean the Party Role “Bidder”. Do not create homonyms.

Syntax Start every definition with the super ordinate term to which it belongs.

Use an article at the start of the definition.

Example sales order: „A request from a customer to a seller to deliver materials and provide the relevant services at a specific time.“




of 113


In the daily work of defining entities, the following difficulties or problems may occur.

The Definition Enemies

• Different definitions (and different terms) for the same business concept in the real world (Redundancy)

• Different terms for identical information / content / definition (Synonyms)

• Identical terms for different information / content / definition (Homonyms)

See also the description of linguistic defects and their clarification in section 3.2, page 23.

2.2.2 Comment

Comment is the reference to the environment of a term, as well as the definitions of terms used in the definition that are not in common use, and which are not already defined by other business objects.

2.2.3 Structure

Structure is a general description of the entity types grouped by the defined object. It describes the business-related environment of the object.

The general description can also be accompanied by a specific example (if necessary, with weighting) if a complete description cannot be provided.

In case of a business object it explains the meaning of its major nodes, from a business perspective.

2.2.4 Use

Use is a specification of possible usages of the entity (context).

2.2.5 Integrity Condition

Integrity condition is the condition that ensures the consistency and completeness of an entity from a business point of view.

The condition incorporates the entity, its subordinate entities and its relationships to other entities and describes their dependencies to each other.

For example only one of the relationships A and B may exist.





D-69190 Walldorf

2.2.6 Constraint

Constraint is the limitation of an entity from a business point of view.

For example data type elements typed by a code-GDT where only some code values are allowed.

2.2.7 Restriction

Restriction is the limitation of the planned scope of an entity specified in its definition. In distinction to constraint this limitation is only valid at the moment; the full scope specified will be available in future.

This is necessary because the documentation is legally binding.

Examples:

• A business object does not provide the full defined scope at the moment. The current limita-tions are specified in this section.

• An operation does not support the full structure of a message type. The structures and fields of the message type that are not (yet) covered by the operation are specified in this section. This can be the case especially for older message types.

2.2.8 Example

Example is an instance of the entity. It should cover the full complexity of the entity.

If there are different kinds of instances, provide an instance for each kind.

2.2.9 Note

Note is a description of special properties of the entity. They cover information that is not business-related but useful from a technical point of view.

For example, for a GDT the reference to its corresponding R/3 data type may be specified.




of 113


2.3 Overview of SAP Modeling Entities and their used Aspects

The following table lists for several AP model entities the used definition aspects.

Name / DefinitionAspect

BO

BO

Nod

e

Nod

e D

ata

type

Nod

e D

ata

Type

Ele

men

t

Key

Dat

a Ty

pe

Key

Dat

a Ty

pe E

lem

ent

Gen

eral

izat

ion

Type

Com

posi

tion

Agg

rega

tion

Ass

ocia

tion

Filte

r Dat

a Ty

pe

Filte

r Dat

a Ty

pe E

lem

ent

Act

ion

Act

ion

Dat

a Ty

pe

Act

ion

Dat

a Ty

pe E

lem

ent

Que

ry

Que

ry D

ata

Type

Que

ry D

ata

Type

Ele

men

t

GD

T

Attr

ibut

e

GD

T El

emen

t

Cod

e Li

st

Cod

e

Qua

lifie

r Lis

t

Qua

lifie

r

Name m m m m m m m m m m m m m m m m m m m m m m m m m

Definition m m m m m m m o m o m o m m m m mComment o o o o o o o o o o o o o o oStructure mUse o o o m o

Integrity Condition o o o o o o o o m o

Constraint oRestriction oNote o o m o

Example o o m

Global Data Type (GDT)Object / Node Relationship Core Service

Figure 2: Definition Aspects used by Model Entities

Legend:

m mandatory

o optional

2.4 Definition Pattern for SAP Modeling Entities

To ensure a common form of SAP modelling entity definitions, patterns are defined for each of them.

You can find the definition pattern on the Wiki page of of AP KM Standards & Guidelines (S&G):

https://wiki.wdf.sap.corp/pages/viewpage.action?pageId=1476716

(S&G for Terminology and Glossary Definitions)

https://wiki.wdf.sap.corp/pages/viewpage.action?pageId=1476716�




of 113


3 Term

3.1 Standards for Term

SAP terms are built according to ISO 11179-5.

According to ISO 11179-5 the following aspects are to be prescribed:

• The scope of the naming convention, e.g. an industry

• The authority that establishes the naming conventions

• Semantic rules governing the source and content of the terms used in a name, e.g. terms de-rived from data models, terms commonly used in the discipline, etc.

• Syntactic rules covering required term order

• Lexical rules covering controlled term lists, name length, character set, language

• A rule establishing whether or not names must be unique

For details see ISO/IEC 11179-5 (Naming and identification principles for data elements).

The term conventions valid for all entities of the SAP object model are specified in the following sec-tions.

The term conventions that are specific for an entity are described in the respective naming rule section for this entity.

3.1.1 Scope

The scope covers all entities of the SAP object model including the entities

• Object (BO, TecO ...)

• Object node (TN, RTN…)

• Relationship (composition, aggregation…)

• Service (action, query, service interface, service operation…)

• Data type (GDT, IDT…)

• Data type element (NDT-element, status-element…)

3.1.2 Authority

The term conventions are established by the corresponding PIC Coaching Teams in cooperation with the Business Object Task Force (BOT) and the Service Definition Methodology Council (SDMC).

http://standards.iso.org/ittf/PubliclyAvailableStandards/c035347_ISO_IEC_11179-5_2005(E).zip�





D-69190 Walldorf

3.1.3 Semantic Rules

The semantic rules follow the ebXML CCTS, which is based on ISO/IEC 11179-5.

PropertyPropertyQualifier Representation Representation QualifierObjectObjectClassClassQualifier PropertyPropertyQualifier PropertyPropertyPropertyPropertyQualifier Representation Representation Qualifier Representation Representation Representation Representation Qualifier

ObjectObjectClassClassQualifier ObjectObjectClassClass

ObjectObjectClas Class Qualifier

Figure 3: Naming Parts of an Entity Name according to ISO/IEC 11179-5

A term is made up of three parts:

• The “object class”: A set of concepts, abstractions or things in the real world which can be identi-fied within clear boundaries and meanings, and whose characteristics and behavior follow the same rules (examples: automobile, person, household, order ...).

• The “property”: A characteristic feature shared by all the instances of an object class (examples: color, age, income, address ...).

• The “representation”: Describes how the data is represented, meaning the data type and its value range (examples: a date can be represented with xsd:date or xsd:datetime).

Each of these three name components can be semantically restricted by one or several qualifiers. The order of the qualifier is not significant. Qualifiers are needed to make a term unique within a specified context.




of 113


3.1.4 Syntactic Rules

a) Object class terms shall occupy the first (leftmost) position in the name.

b) Qualifier terms shall precede the part qualified. The order of qualifiers shall not be used to dif-ferentiate terms. If the qualifier is an established term of its own and contains the semantics of the term qualified, the qualified term is omitted. Example: Qualifier Approver describes an object Employee in more detail. As approver is an established term and an approver is always an employee the resulting name is Approver (and not “Ap-prover Employee”)

c) The property term shall occupy the next position.

d) The representation term shall occupy the last position. If the representation term is redundant with the latter part of the property term, one occurrence will be deleted.

3.1.5 Lexical Rules

a) Terms are in singular form only, except the entity itself is plural.

b) Terms are in Title Case. Exceptions:

Data Types, Data Type Elements, Codes and Code lists are in UpperCamel-Case. See chapter 4.2, page 48.

Attributes are in lowerCamelCase. See chapter 4.2, page 48.

A Data Type can have a variable as prefix followed by an underscore such as “SHORT_”, “MEDIUM_” and “LONG_“. The variable contains upper case let-ters only.

c) Abbreviations, acronyms, and initialisms are allowed only when used normally within business terms (for this, see Oxford Dictionary). Exceptions:

UUID - Universally Unique Identifier

URI - Unified Resource Identifier

PO Box – Post Office Box

SAP - Systems Applications and Products in Data Processing

IT Control - Information Technology Control”

RFI - Request for Information

Abbreviations for countries contained in the code list of GDT CountryCode (restricted use for country specific objects and extensions)

d) Words contain letters only. Exceptions:

An template-object contains an underscore that separates the suffix “Tem-plate”

Country specific objects and extensions contain underscore behind the coun-try code.

A GDT can contain an underscore to separate a “variable” as prefix.

For versioning an underscore is used to separate the version as suffix

e) The technical name for a term is in UpperCamelCase. See chapter 4.2, page 48.





D-69190 Walldorf

3.1.6 Uniqueness Rules

The context in which a term has to be unique depends on the entity that is named by the term.

Figure 4 shows an overview about the uniqueness rules for the respective model entities.

Entity Uniqueness Context

Object SAP wide

Object Node Object the node belongs to

Composition Source node

Inbound Aggregation, Inbound Association Target node

Obj

ect /

Nod

e /

Rel

atio

nshi

p

Association for Navigation Source node

Action, Query Node the action / query belongs to

Service Interface SAP wide

Service Operation Service interface

Serv

ice

Message Type SAP wide

Data Type SAP wide

Supplementary Component (SC) Data type the SC belongs to

Data Type Element Data type the element belongs to

Code List SAP wide

Code Code list the code belongs to

Dat

a Ty

pe

Qualifier Data type the qualifier belongs to

Figure 4: Uniqueness Rules for Model Entities

The required uniqueness of a term is, as a rule, ensured by the specific naming conventions for the respective entity.




of 113


3.2 Clarification of Terms

To allow communication about a set of facts (here models), terms must be used in a uniform manner. Therefore, as a first step in modelling, an understanding must be reached concerning the terms to be used.

Figure 5: Discussion of Terms

The terms obtained from a survey are analyzed and synonyms and homonyms are eliminated.





D-69190 Walldorf

3.2.1 The Semantic Triangle

For the definition of a term, the semantic triangle - a schema borrowed from linguistics - is used. In this triangle, the definition of a term is established by means of an extension, an intension and a sign.

Figure 6: The Semantic Triangle

A term is clearly and uniquely defined when the sign, the intension and the extension are in concor-dance.

Sign: Name of a term

Intension: Meaning of a term, described by its characteristics

Extension: Scope of meaning of a term, semantic field / business area.

Description of the field / business area or object to which a term relates.

Example:

In the field of business administration the term “Supplier” is defined in the following way:

“A business partner who offers or provides materials or services.”

Sign, intension and extension are in concordance - the term is clearly and uniquely defined.




of 113


3.2.1.1 Synonyms

In the case of synonyms, the same object or the same phenomenon is designated by different terms.

Figure 7: Synonyms

Definition: - Different sign

- Same intension - Same extension

Example: Telecopier, fax machine

Action: If possible, do not use different signs, otherwise reference by means of "alias".

3.2.1.2 Homonyms

In the case of homonyms, different phenomena are designated by the same term.

Figure 8: Homonyms





D-69190 Walldorf

Definition: - Same sign - Different intension - Different extension

Example: Order: customer order, vendor order Table: numerical table, kitchen table

Action: The signs must be assigned in such a manner that they can be differentiated.

3.2.1.3 Equipollence

A phenomenon occurs in different roles and is given different names.

Figure 9: Equipollence

Definition: - Different sign - Different intension - Same extension

Example: Vendor, customer

Action: The different intension must be made clear using different features.




of 113


3.2.1.4 Vagueness

Different names suggest the same meaning of a phenomenon.

Figure 10: Vagueness

Definition: - Different signs, however suggesting the same intension - Vague intension - Unclear extension

Example: Branch, branch office

Action: The meaning of the terms must be clarified on the basis of their features. The range of meaning must be clarified.





D-69190 Walldorf

3.2.1.5 Imprecise Usage

Figure 11: Imprecise Usage

Definition: - Sign that suggests a differing intension - Same intension - Same extension

Example: working storage Core memory (meaning main memory)

Originally the term described another object, but it continues to be used as a matter of tradition.

Action: A suitable term must be found.




of 113


In the table below, all the defects presented above are shown in summarized form.

Sign Intension Extension

Synonym ≠ = =

Homonym = ≠ ≠

Equipollence ≠ ≠ =

Vagueness ≠ = not clear

Imprecise Usage = suggests ≠

=

Table 1: Linguistic Defects

It is important to avoid linguistic defects when establishing terms: They have to be clarified!

3.2.2 Reconstructing Terms

3.2.2.1 Establishing Terms

To find a term the following sequence applies:

Semantics Definition Term

1. Get an understanding of the object. Describe the business semantics.

2. Write a definition according to the business understanding

3. Find the term according to the definition

o Use the commonly used business term, if exists

o Otherwise, determine the term by putting together the main terms that make up the semantics

For objects with common features, a term is searched for or confirmed as correct.





D-69190 Walldorf

Terms are differentiated according to whether they are classifying terms or characterizing terms.

A classifying term groups together objects of the real world whose main features are identical. An en-tity type is established for it.

Figure 12: Establishing Terms: Classification

A characterizing term describes a characteristic or a feature of an object of the real world. An attribute is established for it.

Example: last name, first name, birthday

Figure 13: Establishing terms: characterization




of 113


3.2.2.2 Linkage of Terms

Figure 14: Creating terms: linkage of terms

For ranges of meaning that result from the combination of sub terms to form a complex whole, a term is searched for or confirmed as correct.

Example:

Marriage = relationship between man and woman

Plant material = relationship between plant and material

3.2.2.3 Aggregation of Terms

Figure 15: Aggregation of Terms

For a uniform whole that is composed of identical or different objects, a term is searched for or con-firmed as correct.

Example:

Car = motor + tires + body + steering wheel + ...

Machine group = machine 1 + machine 2 + …





D-69190 Walldorf

3.2.2.4 Generalization of Terms

Figure 16: Generalization of Terms

For classifying terms, a generic term is searched for or confirmed as correct. The reconstruction is initiated by the possible inclusion of one or several terms in another term.

Example:

Vehicle = car, truck, .....

Means of transport = airplane, bus, car, ship, bicycle, .....

3.2.2.5 Eliminating Linguistic Defects

Entity types are representations of sets of similar objects (sets of similar entities) of the real world. They are named by a term. To name an entity type properly, a special importance is attached to estab-lishing the term and eliminating linguistic defects (homonyms, synonyms, and so on).

In object modelling the name of an entity type is of high importance.

The term has to be established properly without any linguistic defects, that is, synonyms, homonyms etc.




of 113


3.3 Pattern A pattern is an abstraction that describes the structure of a problem solution for a subject matter by specifying its essential elements. The pattern represents reusable know-how that can be applied to analogous subject matters.

Patterns therefore ensure that similar facts are uniquely described and, by this, simplify the complexity of the whole system. The use of Patterns in description thus supports analysis, structuring and com-prehension.

Patterns are classified into the following categories

• Terminological Patterns - Used for the definition of terms

• Structure Patterns - Used for structural interrelations

• Business Patterns - Used for business-related facts





D-69190 Walldorf

3.3.1 Terminological Patterns

Similar semantic concepts are shown explicitly. This is achieved by attaching a standardized prefix or suffix to the name of entities that represent a similar set of facts, and by providing the definitions of such sets of facts with the same structure.

3.3.1.1 Grouping Together and Dividing Up

Figure 17 shows some selected partial aspects for which standardized names have been agreed. The terms class, type, group, category, kind and grouping are classified according to their nature and on the basis of the criteria assigned to them.

Figure 17: Terminological Patterns

Class, type and group have a "grouping-together" and, as a rule, "generative" effect on their depend-ent entity types, whereas category, kind and grouping "divide up" and "reference" their dependent entity types but do not "generate" them.




of 113


Grouping together / determination of the nature of entities by a type or a group

The terms group, type and class are used to describe the grouping together (not the dividing up!) of entities, or their essential nature.

To define the terms, the following model definitions are used:

Class:

A class is a grouping together (classification) of any entities that have the same features. The grouping together is independent of the object or the intended pur-pose and thus objectively related to attributes of the entities.

Model definition: A ... class is a grouping together (classification) of ... (entities) according to ... (es-sential criteria).

Example of definition: A work center class is a grouping together (classification) of work centers according to accounting requirements.

Type:

A type characterizes the essential nature or totality of an entity (in contrast to the kind, this essential nature cannot be defined in terms of individual features). An entity is assigned to a type (a kind divides up entities according to certain criteria). Since a type represents the abstracted (ideal) idea of an entity, a transition to a higher abstraction level (meta-level) is always connected with this idea.

Model definition: A ... type describes the essential nature of ... (entity types), according to ... (characteristics of this es-sential nature).

Example of a definition: A work center type describes the essential nature of work centers according to their characteristic equipment.

Example: assembly line work center.





D-69190 Walldorf

Group:

A group is the grouping together (classification) of entities according to a subjective viewpoint, that is, a group designates a set of entities that are grouped together on the basis of a subjective criterion.

Model definition: A ... group is a grouping together (classification) of ... (entities) according to ... (viewpoints).

Example of a definition: A work center group is a grouping together (classification) of work centers according to their spatial arrangement.

Example: Work centers in sales and distribution.

Dividing up of entity types by category, kind or grouping:

Category and grouping always describe the dividing up (classification) of entities according to certain criteria. A kind is understood to describe the dividing up (classification) of entities on the basis of cer-tain nature-determining features.

The crucial point is that the terms category, kind and grouping only designate a grid by which enti-ties are divided up. They do not designate the set of entities resulting from the division. For example, the entity type customer grouping designates a dividing up (classification) of customers according to different viewpoints and does not designate the set of customers resulting from the division.

To define the terms, the following model definitions are used:

Category:

A category is a dividing up (classification) of entities according to objective criteria.

Model definition: A ... category is a dividing up (classification) of ... (entities) according to ... (objective criteria).

Example of a definition: A work center category is a dividing up (classification) of work centers according to statutory safety regulations.

Example: Work centers protected against radiation.




of 113


Kind:

A kind is a dividing up (classification) of entities according to characteristic, not neces-sarily objective criteria. It it thus used to divide up entities according to certain view-points.

Model definition: A ... kind is a dividing up (classification) of ... (entities) according to ... (criteria = several identical char-acteristics).

Example of a definition: A kind of work center is a dividing up (classification) of work centers according to the level of training required for the person occupying the work center.

For example: system developer.

Grouping:

A grouping is a dividing up of entities according to subjective criteria. The criteria are subjective in the sense that, with the criterion for the division, reference is made to fea-tures that do not need to be attributes of the entity.

A ... grouping is a dividing up (classification) of ... (entities) according to ... (subjective criteria).

Example of a definition: A work center grouping is a dividing up (classification) of work centers according to the risk of accident associated with them.

Example: hazardous work centers.





D-69190 Walldorf

3.3.1.2 Version and Variant

Version and variant are used as further standard constructs to describe the time-dependent or paral-lel use of entities of an entity type.

To define entity types as variants and versions, the following model definition is used.

3.3.1.2.1 Version

A version is a differentiation of entities of an entity type at different points in time. As an extension of this, the differentiation of entities of an entity type at different points in time is also named a version when instances of entity types differ not only with regard to their features but also with regard to feature assignments of secon-dary importance.

Model definition: A ... version is a (dividing up) ... (entity) that can occur in several different instances at different points in time.

Example of a definition: An accounting transaction figure version is a dividing up (classification) of accounting transaction fig-ures on the basis of common assumptions, common reporting purposes, or a common level of knowl-edge, that makes it possible for an accounting transaction figure to adopt different values at different points in time.

3.3.1.2.2 Variant

The term variant designates the differentiation of entities of an entity type at a point in time. As an extension of this, the differentiation of entities of an entity type is also named a variant when instances of entity types differ not only with regard to their features but also with regard to feature assignments of secondary importance.

Model definition: A ... variant is a (dividing up) ... (entity) that can occur in several different instances at the same point in time.

Example of a definition: A currency exchange rate type variant is a dividing up of currency exchange rate type - consolidation according to certain criteria, such that this can occur in several different instances at the same point in time.




of 113


3.3.1.3 Catalogue

A catalog is a list of entities that is systematically arranged. The crucial point is that the catalog describes an association of general validity in a very large context.

Model definition: A ... catalog is a systematically arranged list of ... (entities).

Example of a definition: A bank catalog is a country-specific, systematically arranged list of banks.





D-69190 Walldorf

3.3.2 Structure Patterns

Sets of facts that are structurally identical are represented by Structure Patterns. A Structure Pattern has an established internal structure that reproduces the interrelationships between the entity types and the relationship types involved.

In the following such structural patterns are described.

3.3.2.1 Hierarchy and Net Relationship

Entities of an entity type can be arranged in a hierarchy or net by means of directed (ancestor-successor) relationships.

The position of an entity relative to a focus entity is expressed using a standardized term as name prefix. These standardized terms are shown in Figure 18.

However, if an established term exists for the special business meaning this is to be used instead.

Focus EntityParent

Top

Leaf

Child

Superordinate

Subordinate

Figure 18: Standardized Terms Expressing the Position of an Entity within a Hierarchy or Net

Meaning of standardized prefix:

Parent: Direct ancestor of focus entity

Child: Direct successor of focus entity

Superordinate: Direct or indirect ancestor of focus entity

Subordinate: Direct or indirect successor of focus entity

Top: Direct or indirect ancestor of focus entity that has no parent

Leaf: Direct or indirect successor of focus entity that has no child




of 113


Use:

These terms are used for naming of elements, relationships, actions and queries.

Examples:

• Element: ParentCommunicationArrangementUUID Element of root node of BO Communication Arrangement that specifies the UUID of its directly superordinate arrangement

• Association: Top Organizational Centre Association to the top organizational centre within a hierarchy of organizational centres

3.3.2.2 Item

An item describes features of an entity type that can be grouped together to form their own entity type because a common meaning of their own underlies them (for example, the entity type purchase order with the features for the individual purchase order items that are grouped together in an entity type purchase order item).

Between an entity type and its item there is always a hierarchical or quasi-hierarchical relationship. The cardinality of the relationship can be 1 : n as well as 1 : cn.

In the case of the entity type chart of accounts, there is a hierarchical relationship of the cardinality 1 : n with the entity type chart of accounts item, since a chart of accounts has at least one item in all cases. By way of contrast, between the entity types order - sales and order - sales - item there is a hierarchical relationship of the cardinality 1 : cn, since at first an order can only consist of an order header without items.

Items can be defined on the basis of the superordinate entity type. However, the definition of the su-perordinate entity type must be comprehensible without the definition of its item. The item is existen-tially dependent upon its superordinate entity type and not the reverse.

Example of a definition: A chart of accounts item is a category of values or value flows that can be recorded or represented in amounts of money in accounting.

A chart of accounts is a superordinate list of categories of values or value flows that is defined in ac-counting ....





D-69190 Walldorf

3.3.2.3 Assignment

Assignment is the most general standardized term. It describes the aggregation of several different entity types. The name assignment is only used when this relationship structure cannot be described more exactly or if it cannot be assigned to any other standardized structure.

Figure 19: Structure Pattern: Venn Diagram of an Assignment

Assignments can only be differentiated through the kind (cardinality) of relationships by which they are formed. For the definition and the use of the term assignment, it is specified that the second entity type is assigned to the first.

Figure 20: Structure Pattern: Assignment

Example of a definition: An item of equipment - bill of material assembly - assignment assigns to an item of equipment, by means of a bill of material assembly, a bill of material that describes its composition.

The definition of the assignment relationship must also clearly state which entity type is assigned to which other entity type. Where relationships between entity types are of the assignment relationship type, reference is made in the description of the relationship type to the entity type participating in the assignment




of 113


3.3.2.4 Determination

The standardized term determination is used when, by means of the aggregating relationships be-tween several entity types, an entity is "found". Between this entity type and the aggregated entity type (with the term determination) there is a referential relationship.

A determination is formed through the aggregation of several entity types. It references the entity type to be found.

A distinction is made between entity types that semantically characterize the determination and entity types that differentiate it.

Taking the entity type business area determination as an example, a business area is found through the aggregation of plant and division. The plant semantically characterizes the determination whereas the division is used for differentiation.

Figure 21: Structure Pattern: Determination

Example of a definition: A business area determination assigns a business area to a plant in dependence upon the division.





D-69190 Walldorf

3.3.3 Business Patterns

A business pattern is a structure pattern whose use can be extended to analogous business-related facts and their relationships. As a result, structural analogies become apparent. These help the user to gain a deeper understanding of complex facts and their interrelationships.

3.3.3.1 Business Transaction Documents

A business transaction document (BTD) is a document which represents a business transaction. It is defined with respect to a specific point in time.

Comment: A business transaction is a self-contained, logically connected, commercial transaction that re-sults in a value change and/or quantity change.

The basic structure of a BTD follows a pattern (see Figure 21). With each level a certain understand-ing is associated.

• “Who”: Involved party

• “What”: Subject of the business transaction

• “When / How much”: Consideration of quantity and time

BTD „Item“ „Sched.Line“

Root

Object

“Who” “What” “When / How much”

BTD „Item“ „Sched.Line“

Root

Object

“Who” “What” “When / How much” Figure 22: Basic Structure of Business Transaction Document




of 113


This basic structure of a BTD is reflected in the following five categories. They are used as building blocks for the definition of a BTD:

• Activity / Character: The definition always starts with a term specifying the activity or character of the represented business transaction such as “request” and “confirmation”.

• Involved Parties (Who): This is followed by the parties involved in the business transaction such as “customer” and “seller”.

• Subject Matter (What): The third part contains the subject of the business transaction such as “delivery of products” and “paying of invoices”.

• Time / Quantity (When / How much) This is followed by the specification of the schedule line and quantities for the subject of the business transaction.

• Additional Information The last part contains additional information about the object that is of “technical” nature and needed for its understanding

The building of a BTD definition according to these categories is shown in Figure 23.

a requirementa requisitiona requestan ordera confirmation

A(n) <BTD> is

an organizationa buyera creditor

Additionally it contains the results of the resolution, as well as the expenses incurred.

at certain points in timewithin a period of timeregularly

a specified quantity

Activity / Character Who What When / How much Additional Info

procurement of goods and servicesdeliver materialsperform a specified serviceremunerations to be paidcollect a debt

Figure 23: Definition Pattern for Business Transaction Document





D-69190 Walldorf

Figure 24 shows standardized terms for the Activity / Character used for the definition of a BTD.

Activity / Character Semantics

Requirement A statement that expresses a demand required in advance. Usually a requirement is derived from a forecast is

Requisition An inquiry to a party to fulfil a demand. Usually this inquiry is company internal and triggers the creation of an order

Request

An inquiry with obligation to a party to do something. That can be the execution of an activity which involves the change of a state or subject matter. A request incorporates an obligation.

Order A stated intention to engage in a business transaction for specific products.

Confirmation An assurance with obligation about the fulfilment of a request.

Figure 24: Standardized Terms Used for Activity / Character

Examples:

• Purchase Order A request from a buyer to a seller to deliver a specified quantity of material, or perform a specified service, at a specified price within a specified time.

• Internal Request A request from an employee of a company for the procurement of goods or services for own or company use.

• Service Request A request from a customer to a service provider to solve an issue that the customer has with regard to a product. In addition to the description and the categorization of the issue, the Ser-vice Request contains the documentation and the results of the resolution, as well as the ex-penses incurred.




of 113


Topic

Abstraction

11

22

Definition

Term

33

44

„Building“

Semantics


4 Naming Rules for Model Entities

4.1 Naming Rule Notation

A naming rule specifies how the name of an entity is composed from individual terms.

The composition is defined by an expression using the following notation.

• x - x is fixed term (terminal) • <x> - x is variable term according to a specified rule (nonterminal) • * (star) - The previous item occurs zero, one or many times • + (plus) - The previous item occurs one or many times • ? (question mark) - The previous item is optional (occurs zero or one times) • | (pipe) - Either the previous or the successive item occurs • (expression) - Round brackets group the expression between them

A naming rule is given by an expression for the name and the definition of the individual terms within the expression.

If possible specify natural-language rules and controlled vocabulary for the individual terms. Provide an example that covers the full complexity of the syntax.

Example for the naming rule for Node Data Types:

The name of a node data type is composed of the business object name, followed (if the node is not the root node) by the node name, followed by the fixed term “Elements”.

Naming Rule

Syntax: <object><node>?Elements

<object>: Name of object; in case of template without “_Template”

<node>: Name of node; omitted in case of root node

Example: Name of NDT for node Item within BO Customer Invoice is CustomerInvoiceItemElements.





D-69190 Walldorf

4.2 Semantic Name and Technical Name

The naming rules describe how to build the semantic name of an object in conceptional modeling. Therefore no length restrictions arise. However, depending on the technical representation in the modeling tool or implementation environment length restrictions may occur. For detailed rules con-cerning abbreviation refer to chapter 5, page 95.

In addition to the naming rules the style of capitalization has to be decided.

Conceptional Modeling (no tool restrictions)

Technical Representation(ESR)

BO

Node-Elements

BO

Node-Elements

Semantic Name Title Case Technical Name UpperCamelCase

Figure 25: Capitalization of Semantic Name and Technical Name

Semantic names of model entities are in Title Case.

Technical Names of model entities are in UpperCamelCase.

Note: The semantic name of a Data Type, Element, Code and Code List is in UpperCamelCase. The semantic and technical name of an Attribute is in lowerCamelCase.

Title Case:

Words of a name are separated by spaces. The first letter of each word is capitalized, except the fol-lowing

• Coordinating conjunctions (and, but, for, nor, or) • Prepositions of four or fewer letters (at, for, per, to, with) • Articles (a, an, the, some) unless the article is the first or last word in the title • The word “to” in an infinitive phrase

Detailed Title Case Rules

Upper Camel Case:

Words of a name are capitalized and there are no spaces between them.

Lower Camel Case:

Same as Upper Camel Case with the first letter in lower case.

http://aiokeh.wdf.sap.corp:1080/SAPIKS2/contentShow.sap?_SCLASS=IWB_STRUCT&_SLOIO=FD9E273C3F2B3C7CE10000000A11402F&TMP_IWB_TASK=PREVIEW2&RELEASE=620&LANGUAGE=EN&_SEQNUM=30&_LOIO=63737C36614A2F45A565BA2D5D7D41B2&_CLASS=IWB_EXTHLP�




of 113


4.3 Object

Syntax: <qualifier>*<object>?

<qualifier>: Term describing a subtype or view of the <object>

<object>: Term for self-contained real world (business) concept

If the <qualifier> is a unique term of its own and already contains the meaning of <object> the <object> is omitted.

Examples: • Payment Register

(qualifier: Payment, object term: Register) • Customer Business Partner

(qualifier Customer is unique term of its own, therefore term Business Partner is omitted)

4.3.1 Object Template

Syntax: <generalized term>_Template

<generalized term>: Term expressing common semantics of projected objects

Examples: • Business Partner _Template • Procurement Document _Template





D-69190 Walldorf

4.4 Object Node

Syntax: <path>?<qualifier>*<main node semantics>?

<path>: Hierarchical path with first level omitted

<qualifier>: Term expressing the semantic restriction of the <main node semantics>

<main node semantics>: Term expressing the main semantics of the node in the context of the path

If the <qualifier> is a unique term of its own and already contains the meaning of <main node seman-tics>, the <main node semantics> is omitted.

The name of root node is identical to the object name.

Exceptions: See section 4.4.1 and 4.4.2.

Examples: • Party (party in BO below root node) • Item Schedule Line (schedule line in BO below node Item) • Purchase Order (root node of BO Purchase Order) • Address_Template (root node of template object Address_Template)

4.4.1 Specialization Node

Case: Specialization of node not taken over from aggregating node:

Syntax: <qualifier>+<generalization node>?

<qualifier>: Term expressing the specialization of the <generalization node>

<generalization node>: Name of generalization node, omitted if <qualifier> is unique term of its own

Example:

Node “Item Party” is specialized according to the role “Buyer Party”.

The name of the specialization node is “Buyer Item Party” (not “Item Buyer Party”)




of 113


Case: Specialization taken over from aggregating node

Syntax: <path><qualifier>+<generalization node without path>?

<path>: Hierarchical path that is part of the generalization node name with first level omitted

<qualifier>: Term expressing the specialization of the generalization node

<generalization node without path>: Name of node that is generalization omitting the path

If the <qualifier> is a unique term of its own, <generalization node> is omitted

Example:

Node “Item Business Transaction Document Reference” is specialized according to the referenced object “Purchase Order”.

The name of the specialization is “Item Purchase Order Reference”.





D-69190 Walldorf

4.4.2 Grouped Object Node

Syntax: <path without parent node><grouped object>

<path without parent node>: Hierarchical path with both first level and parent node of grouped object omitted

<grouped object>: Name of the grouped object represented by the node

Examples:

• Grouping Object at root node level: Product Categories are grouped by an Product Category Hierarchy. The name PCH is not part of the name of the node representing the Product Category. As the root node is never repeated in nodes below root node this has only a consequence in the naming of relationships from Product Category to nodes of another object.

ProductCategoryHierarchy

ProductCategory

Grouping Object

Product Category Hierarchy

Grouped Object Figure 26: Example for Grouping Object at Root Node Level

• Grouping Object at non-root node level: Objects X are grouped by node “X Group” below Item node. The name “X Group” is not part of the name of the node representing the object X. Therefore the node is named “Item X” (and not “Item X Group X”).

Item XItemX Group

ItemHeader

Grouping Object

Grouped Object Figure 27: Example for Grouping Object at Non-Root Node Level

4.4.3 Dependent Object Inclusion Node

Syntax: <path><qualifier>*<DO>




of 113


<path>: Hierarchical path with first level omitted

<qualifier>: Term expressing a special role of the DO within its host object

<DO>: Name of dependent object

Example:

Hosting object Sales Order, node Item contains the DO Attachment Folder in the role „Receipt“. Corresponding name of DO inclusion node: ”Item Receipt Attachment Folder”

4.4.4 Transformation Node

The naming of a transformation node follows the common naming rules for object nodes.





D-69190 Walldorf

4.5 Relationship

Syntax for Basic Pattern:

<qualifier>*<object>?<node>?<object>?<node>?

<qualifier>: Term expressing the meaning of the relationship or the role of the source/target node for the relationship; needed to distinguish several relationships with same source and target node

<object>: Name of source/target object

<node>: Name of source/target node

<object> and <node> can be replaced by its subtypes.

Figure 28 shows which naming parts are omitted for each relationship type.

<q><BO><node><BO><node>

Direction?

Relationship NR Decision Tree

Inbound(Ass, Aggr)

Outbound(Comp, Nav Ass)

source target


source target


source target

Intra BO?

No Yes

<q><BO><node>

source

<q><BO><node>

source

Intra BO?

No Yes

<q><BO><node>

target

<q><BO><node>

target

Figure 28: Naming Rule Decision Tree

If a naming conflict (homonym) occurs, do not omit <BO> in intra-BO relationship name.

For a relationship name, the given context is omitted from the basic pattern.

source node target node




of 113


The following table shows for each relationship type which naming parts may occur in the relationship name (indicated by “+”) and which parts do not occur (indicated by “-“).

Source Target

Quali-fier

<object> <Node> <object> <Node>

Aggregation / Association (intra object)

+ +* + - -

Inbo

und

Aggregation / Association (inter object)

+ + + - -

Composition (intra object only)

- - - - +

Association for Navigation (intra object)

+ - - +* +

Out

boun

d

Association for Navigation (inter object)

+ - - + +

Table 2: Summary of Relationship Name Syntax

* Omitted if no naming conflict occurs

Naming Conflict

ItemItem

Location

BTD

Location

BTD

Location Location

<q>BTDLocation<q>Location

Do not omit <BO> fromrelationship name

Figure 29: Naming Conflict and Resolution

Naming conflicts are situations where two different relationships have, according to the naming rules, the same name (homonyms).

They may occur when a node has the same name as another (existing or upcoming) BO. In that case it is not possible to determine the source (inbound) or target (outbound) node from the relationship name.

Resolution of naming conflict

To resolve a naming conflict the BO-context is not omitted in the relationship name.





D-69190 Walldorf

Naming examples for different cases are shown in the following picture.

XX Y

A B BC

ABCD

BG

E

Focus: Node

VV W

XY

VW

BG

BCH

X

E

Legend:

FF

BCH

BCD

Structural relationships

Association for Navigation Figure 30: Naming examples for different relationship types

The naming rules for the individual relationship types are explained in the following sections. For self reflexive relationships see section 4.5.5, Structure Relationships.

4.5.1 Composition

Syntax: <target node>

<target node>: Name of target node of the composition

Example: Name of composition from node Item to node Item Schedule Line is Item Schedule Line.

Note: The naming rule for filtered compositions is identical.

4.5.2 Aggregation / Association

Syntax: <qualifier>*<source object>?<source node>?

<qualifier>: Term expressing the meaning of the relationship or the role of the source node for the relationship; needed to distinguish several relationships with same source and target node

<source object>: Name of source object, omitted in case of intra-BO relationship and if no naming conflict with an inter-BO relationship occurs in current or future scope

<source node>: Name of source node; omitted for inter-BO relationship in case of root node

Example: Name of Inbound association from root node of BO Identity with role “creation” is Creation Identity.




of 113


4.5.3 Association for Navigation

Syntax: <qualifier>*<target object>?<target node>?

<qualifier>: Term expressing the meaning of the relationship or the role of the target node for the relationship; needed to distinguish several relationships with same source and target node

<target object>: Name of target object, omitted in case of intra-BO relationship and if no naming conflict with an inter-BO relationship occurs in current or future scope

<target node>: Name of target node, omitted for inter-BO relationship in case of root node

Example:

• Name of Association for Navigation from root node of DO Address to node Telephone (intra BO) with role “default” is Default Telephone

• Name of Association for Navigation from node Execution of MDRO Production Order Release Run to root node of BO Application Log is Application Log

4.5.4 Filtered Association for Navigation

Syntax: <qualifier>+<target object>?<target node>?

<qualifier>: Name expressing the filter semantics

<target object>: Name of target object, omitted in case of intra-BO relationship and if no naming conflict with an inter-BO relationship occurs in current or future scope

<target node>: Name of target node, omitted for inter-BO relationship in case of root node

Example: Filtered association for navigation from root node of business partner to node Role with filter based on role category.

Name of association for navigation: Role Category Based Role

Note: The naming rule for filtered compositions is identical to the naming rule for compositions.





D-69190 Walldorf

4.5.5 Structure Relationships

4.5.5.1 Hierarchy Relationship – Without Attributes

<node> from

to

Syntax for inbound association relationship: <qualifier><node>

<qualifier>: Fixed term “Parent” or term expressing the meaning of the parent node instance

<node>: Name of node

Example:

Items of a Sales Order may be arranged hierarchically.

The name of the inbound association relationship is Parent Item

4.5.5.2 Hierarchy Relationship – With Attributes

<Node><Hierarchy

Relationship>

<node>

Syntax for relationship node: <node><hierarchy relationship>


<hierarchy relationship>: Fixed term “Hierarchy Relationship” or term expressing the meaning of the hierarchy relationship

The name of the composition relationship is the same as for the relationship node.




of 113


Syntax for inbound aggregation relationship: <qualifier><node>

<qualifier>: Fixed term “Parent” or term expressing the meaning of the parent node instance


Example:

Items of an Inbound Delivery may be arranged hierarchically; the relationship contains attributes. • Name of relationship node: Item Hierarchy Relationship • Name of composition relationship: Item Hierarchy Relationship • Name of inbound aggregation relationship: Parent Item





D-69190 Walldorf

4.5.5.3 Net Relationship – With or Without Attributes

<Node>

<Node><Net

Relationship>

Syntax for relationship node: <node><net relationship>


<net relationship>: Fixed term “Net Relationship” or term expressing the meaning of the net relationship

The name of the composition relationship is the same as for the relationship node.

Syntax for inbound aggregation relationship: <qualifier><node>

<qualifier>: Fixed term “Parent” or more specific term expressing the meaning of the parent node instance





of 113


4.5.5.4 Cross References within Same Level

<Node>

Syntax for inbound association relationship: <qualifier><node>

<qualifier>: Term expressing the role of the related node instance, such as Predecessor, Suc-cessor


Example:

Predecessor / Successor Relationship between Operation Activities

Operation

Operation Activity

OperationActivityOperationBill of

Operations

The name of the inbound association relationship is Predecessor Operation Activity.





D-69190 Walldorf

4.6 Data Type

4.6.1 Node Data Type

Syntax: <object><node>?Elements

<object>: Name of object the node belongs to; in case of template without “_Template”

<node>: Name of node; omitted in case of root node

Example: The name of NDT for node Item within BO Customer Invoice is CustomerInvoiceItemElements.

4.6.2 Intermediate Data Type

Syntax: <object><node>?<element>

<object>: Name of object; in case of template omit “_Template”; omitted in case of allowed reuse

<node>: Name of node; omitted in case of root node or in case of allowed reuse

<element>: Name of the grouping element that is to be typed by this IDT

Example: Element Status groups all status elements of a Customer Invoice Item The name of the IDT is CustomerInvoiceItemStatus




of 113


4.6.3 Filter Data Type

Syntax: <filter>FilterElements

<filter>: Name of filter. Two cases are distinguished:

• FDT is reusable across several relationships: <filter> expresses the filter semantics, that is, the elements that belong to the FDT

• FDT is relationship specific: <filter> is built according to the following syntax: <source object>?<source node>?<relationship>

<source object>: Name of object the source node belongs to

<source node>: Name of source node of filtered relationship, omitted in case of root node or in case the <relationship> is a composition

<relationship>: Name of filtered relationship (composition, association for navigation)

Examples: • Filter at composition (from BO “Compensation structure” root node to node “Grade”):

CompensationsStructureGradeFilterElements (no reuse)

• Filter at association for navigation (from BO “Business Partner” root node to BO “Position” root node)

BusinessPartnerPositionFilterElements (no reuse)

• Filter not relationship specific: ValidityPeriodFilterElements (reuse)





D-69190 Walldorf

4.6.4 Key Data Type

Syntax: <object><node>?<key qualifier>?Key

<object>: Name of object for which the KDT is defined

<node>: Name of object node for which the KDT is defined, omitted in case of root

<key qualifier>: Semantically qualifier required to differentiate from other keys (according to semantics); not needed for main key of node

Examples:

KDTs for keys of node Sourcing List Item within BO Sourcing List • KDT for main key: SourcingListItemKey • KDT for key consisting of ID elements: SourcingListItemIDKey

Definition Pattern for KDT

“A grouping of elements that uniquely identifies <object><node>? according to <grouping criteria>”

<object>: Name of object for which the KDT is defined

<node>: Name of object node for which the KDT is defined, omitted in case of root

<grouping criteria>: Criteria from a business point of view what elements are grouped to identify uniquely an object, object node




of 113


4.6.5 IDT replacing a GDT Including Keys instead of IDs

For an aggregated GDT that includes IDs it might be necessary to create a data type that is identical to the GDT but uses the corresponding keys instead of the ID. For this an IDT is created following the following naming rule.

Syntax: ObjectNode<name of aggregated GDT>

<name of aggregated GDT>: Name of the aggregated GDT where the ID is replaced by a key

Example:

Element PartyID within GDT LocationAddressReference needs to be replaced by PartyKey.

The name of the corresponding IDT is ObjectNodeLocationAddressReference.

Comment:

When using the IDT for typing an object node element the fixed term “ObjectNode” is replaced by the name of this node. For the element name the object node is truncated. As a consequence the element name is not influenced by the fixed term ObjectNode (after truncation <name of aggregated GDT> remains)

4.6.6 Action Data Type

Syntax: <object>?<node>?<action>ActionElements

<object>: Name of the object the action belongs to, omitted if reused across several objects

<node>: Name of the node the action belongs to, omitted in case of root node or if reused across several nodes

<action>: Name of the action

Examples: • Without reuse:

Name of ADT for action Notify of Invoice Cancellation on node Customer Invoice Request Item is CustomerInvoiceRequestItemNotifyOfInvoiceCancellationActionElements

• With reuse across several objects: Name of ADT for action Check Archivability is CheckArchivabilityActionElements





D-69190 Walldorf

4.6.7 Query Data Type

Syntax: <object>?<node>?<selection criteria view>QueryElements

In case of “content view” the following syntax applies:

<object>?<node>?<response view>By<selection criteria view>QueryElements

<object>: Name of the object the query belongs to, omitted if reused across several objects

<node>: Name of the node the query belongs to, omitted in case of root node or if reused across several nodes

<response view>: Name of content view

<selection criteria view>: Name of selection semantics • Semantically name (e.g. Planning Information) • Sequence of main selection parameters concatenated by “and” • “Elements” for maximal set of selection criteria

Examples: • BusinessPartnerBankDetailsQueryElements

Name of QDT for query “Query By Bank Details” at root node of BO Business Partner • CustomerInvoiceCompanyAndDateQueryElements

Name of QDT for query “Query By Company and Date” at root node of BO Customer Invoice • EmployeeTimeAgreementItemElementsQueryElements

Name of QDT for query “Query By Elements” at item node of BO Employee Time Agreement • LocationTopLocationByIDQueryElements

Name of QDT for query “Query Top Location By ID” with content view “Top Location”

4.6.8 Query Intermediate Data Type

Syntax: QueryElement<object>?<node>?<grouping element>

QueryElement: Unique prefix, omitted from element name

<object>: Name of object the query belongs tot; omitted if reused across several objects

<node>: Name of node the query belongs to; omitted if reused across several nodes

<grouping element>: Name of the semantic subject represented by the grouped elements. The name is the same as the corresponding element in the object model or solely within the query




of 113


Remarks: It depends on the „reuse scope“ whether Query IDT name contains <object> or <node>:

• Specific for single node (no reuse) full name

• Reuse within object, across nodes <node> not part of name

• Reuse across objects <object>, <node> not part of name

Rationale for omitting prefix “QueryElement”: Only an element in a query is typed by a Query IDT. Thus, the common shortening rule applies

Naming Rule for element in core query:

• <object> is always omitted from element name

• <node> is omitted from element name, if query resides at this node (common rule)

Example:

Queries of business object Bank Directory Entry have a solely defined grouping element AddressOr-ganisationName.

The name of the Query IDT is: QueryElementBankDirectoryEntryAddressOrganisationName





D-69190 Walldorf

4.6.9 Extension Data Type

The following rules are valid only for NDTs, QDTs and IDTs within a MDT.

A

B

C

Extension

MT

A B1 0..*

C0..* Extension

BO

Figure 31: Extension of a node data type and its corresponding message intermediate data type

Syntax for DTs of form <X>Elements (with suffix “Elements”):

<X><extension view name>ExtensionElements

<X>Elements: Name of a data type that is to be extended such as Node DT, Query DT

<extension view name>: Name expressing the meaning of the extension; for country specific

extensions “<country code>_”

Examples • Country specific extension of Node DT “EmploymentElements”

Name of extension DT: EmploymentDE_ExtensionElements

• Country specific extension of QDT “BusinessPartnerIdentificationAndAddressQueryElements”

Name of extension DT is BusinessPartnerIdentificationAndAddressQueryUS_ExtensionElements




of 113


Syntax for DTs of form <X> (without suffix “Elements”):

<X><extension view name>Extension

<X>: Name of a data type that is to be extended such as Intermediate DT

<extension view name>: Name expressing the meaning of the extension; for country specific

extensions “<country code>_”

Example

Procurement specific extension of message data type IDT “SourcingListItem”

Name of extension DT: SourcingListItemProcurementExtension





D-69190 Walldorf

4.7 Data Type Element

Syntax: <qualifier>*<element term>

<qualifier>: Term expressing semantic restrictions of the element

<element term>: Term expressing the meaning of the element in the context of the data type

The element must be unique within its aggregated data type (such as Node DT, Action DT, Query DT, Filter DT)

Usually the element name must contain the name of the data type by which it is typed.

For detailed rules regarding shortening and replacement of parts of the data type name within the element name see naming rules for elements of aggregated data types in the GDT guideline.

Examples: • Element “NetAmount”

Qualifier: Net; element term: Amount; typed by GDT Amount

• Element “ID”

Element in the NDT of root node of BO Supplier Invoice Note: The element is typed by GDT BusinessTransactionDocumentID. For the element name the term “BusinessTransactionDocument is omitted because Supplier Invoice is a Business Transaction Document (replacement rule) and the element is located at the root node of the BO Supplier Invoice (shortening).




of 113


4.7.1 Elements of a Node Data Type


<qualifier>: Term expressing semantic restrictions of the element

<element term>: Term expressing the meaning of the element in the context of the object node

The element must be unique within its NDT.

The node data type name and the element name have to be regarded as semantic unit • Redundant and semantically identical parts of element name and node data type name have

to be removed in the element name (truncation rule) • „Elements“ as a suffix is ignored for truncation rule.

For detailed rules regarding shortening and replacement of parts of the data type name within the element name see naming rules for elements of aggregated data types in the GDT guideline.

Note: Element naming of NDTs for Transformation Nodes follows the same rules as for “normal” nodes.

The origin of the information must either be determinable by the element name or by its documen-tation. In case, that the element of the NDT is calculated, this calculation must be described in the element documentation.

Example:

The node data type SupplierInvoiceItemElements contains the following elements: • ID typed by GDT BusinessTransactionDocumentItemID • TotalReleasedQuantity typed by GDT Quanitiy and with first level qualifier “Released”

4.7.2 Aggregated Status Element

Syntax: <node>List<status element>

<node>: Name of the subordinate node containing the status that is to be aggregated

<status element>: Name of the status element that is aggregated

Example:

Node Customer Invoice Request Item contains the element CancellationStatusCode. The aggregated status on root node of Customer Invoice Request has the element name ItemListCancellationStatus-Code.





D-69190 Walldorf

4.7.3 Element Typed by Key

The name of a key element depends on whether the key element is located at the node identified by the key (own key) or whether it is located at a referencing node (foreign key).

Element name in (defining) object node

Syntax: <key qualifier>?Key

<key qualifier>: Term expressing the differentiation of the key from other keys identifying the same node; not needed for main key of node

Note:

Pay attention that for the defining node the KDT naming parts <object> and <object node> are not part of the name of the element typed by the KDT.

Examples:

Keys of node Sourcing List Item within BO Sourcing List • Element name for main key: Key • Element name for key consisting of ID elements: IDKey

Definition Pattern for Element name in defining object node

Same as Definition Pattern for KDT (see 4.6.4, page 64).




of 113


Element name in other (referencing) object node

Syntax: <qualifier>*<key data type>

<qualifier>: Role of relationship; same as corresponding relationship

< key data type >: Name of key data type of the referenced object node

Common shortening rule for name of key element in node applies.

Examples: • Inbound association from node Item of BO Sourcing List

Name of corresponding element is SourcingListItemKey (typed by KDT SourcingListItemKey)

• Inbound association from root node of BO House Bank Account with the semantic “Desti-nated”: Name of corresponding element is DestinatedHouseBankAccountKey (typed by KDT HouseBankAccountKey, Qualifier: Destinated)

4.7.4 Elements of a Key Data Type

Note that in distinction to an element typed by a KDT the elements here are part of the KDT.

Syntax: <object><node>?<element>

<object>: Name of the object the corresponding element belongs to

<node>: Name of the node the corresponding element belongs to; omitted in case of root node

<element>: Name of element that is used within the KDT to identify the node

KDT elements contain the complete hierarchical path of the used elements.





D-69190 Walldorf

Example:

ItemHugo

ID (GDT: HugoID) ID (GDT: HugoItemID)

Key (KDT: HugoItemKey)- HugoID (GDT: HugoID)- HugoItemID (GDT: HugoItemID)

Figure 32: Example for Key Data Type Elements

The identifier of Node Item of object Hugo is unique only in the context of the object. Therefore it is identified by an alternative key composed of HugoID and HugoItemID.




of 113


4.7.5 Action Data Type Element


<qualifier>: Term expressing semantic restrictions of the element term

<element term>: Term expressing the meaning of the element for the action

Example:

Name of ADT Element Quantity that is qualified as Invoiced is InvoicedQuantity.

(ADT CustomerInvoiceRequestItemNotifyOfInvoiceCancellationActionElements)

4.7.6 Query Data Type Element


<qualifier>: Term expressing semantic restrictions of the element term

<element term>: Term expressing the meaning of the element for the query

The following rules apply: • If the query element corresponds to an element located at the same node as the query, the

name is the same • If the query element corresponds to an element of a different node, the name reflects its se-

mantics o Chose necessary part of the complete path of the element

(The complete path starts at the BO that contains the corresponding element) o Omit duplicates such as AlternativeCurrencyCurrencyCode

• If the query element is not directly matched to a node element, the name reflects its semantics

For typing of an element that groups several elements in the query refer to section 4.6.8, Query Inter-mediate Data Type.

Note: If the meaning of the query element for the query is not trivial, provide a detailed definition. Es-pecially this is the case if the element doesn’t correspond to an element located at the same node.





D-69190 Walldorf

The next figures provide examples for the naming of elements in compound queries and core queries, respectively, following the aforementioned naming rules.

ZZ Y

A B BC

A

BCD

BCEFBCE

ID, ZID

ID, z1

ID, a1

Focus: Object Response View

Query <ResponseView> By <SelectionCriteriaView>

ResponseView Structure:C ……………..

D …E …

F …

Selection Element

SelectionCriteriaView Structure:a1Bb1BCEe1BCEFf1Zz1ZYy1

Figure 33 Compound Query and Response: Element Naming Example

ZZ Y

A B BC

A

BCD

BCEFBCE

ID, ZID

ID, z1

ID, a1

Focus: Node Response View: Node

Selection Element

Query By <SelectionCriteriaView>

Response View Structure:C

SelectionCriteriaView Structure:Aa1ABb1Ee1EFf1Zz1ZYy1

ABCEe1ABCEFf1ABCEe1ABCEFf1

Figure 34 Core Query: Element Naming Example




of 113


4.8 Core Service Operation

4.8.1 Action

Syntax: <action>

<action>: Term expressing the action to be executed

Must not be one of the Access-Core-Services (Create, Read, Update, Delete)

Examples: Accept, Acknowledge, Activate, Approve, Block, Unblock, Calculate, Cancel, Check, Confirm, Exe-cute, Finish Preparation, Generate Forecast, Migrate, Notify, Release, Replicate, Revoke Obsoles-cence, Transmit

4.8.2 Query

Syntax: Query<response view>?By<selection criteria view>

<response view>: Only in case of content view

<selection criteria view>: Semantically name or main selection parameter

Examples: • Query By Bank Details (at root node of BO Business Partner)

Provides all business partners for the given bank details • Query By Company and Date (at root node of BO Customer Invoice)

Provides all customer invoices for the given date and company • Query By Elements (at item node of BO Employee Time Agreement)

Provides all employee time agreements for the given elements • Query Top Location By ID (at root node of BO Location with content view “Top Location”)

Provides for a location the top location in a location hierarchy





D-69190 Walldorf

4.9 Compound Service Operation

e.g. PurchaseOrder e.g. SalesOrder

Inte

rfac

e O

UT

Inte

rfac

e IN

OP1

OP2

Naming Rules

Msg

MT

MT

Service View

Figure 35: Overview of Naming Rules needed for Compound Service Operations

For compound service operations naming rules for interfaces (IF), service operations, message types and message data types are needed.

4.9.1 Service View

The Service View is used in several naming rules and therefore defined centrally in this section.

Syntax: <qualifier>*<object>?<component>?

<qualifier>: Term expressing a semantic restriction of the relevant instances for the service

<object>: Name of object the service view is derived from

<component>: Name of sub-structure of the object

In case of a subtype (or role) for the object the <qualifier> describes the subtype (or role) of the <ob-ject>.

If the <qualifier> is an established term and covers the semantics of <object>, then <object> is omit-ted.

Examples:

Service View is a Subtype: • Location Inventory (with qualifier Location and object Inventory) • Customer (qualifier Customer is established subtype name, object Business Partner is omit-

ted) • Material (qualifier Material is established subtype name, object Product is omitted)




of 113


Service View is a Role of the Object: • Approver (qualifier Approver is established term for the role of object Employee, therefore ob-

ject Employee is omitted)

Service View is a Component: • Purchase Order Delivery Terms (with object PO and component Delivery Terms) • Employee Delivery Address (with object Employee and component Delivery Address)

Service View is a Component of a Subtype: • The view of the object Product needed to control service processes for materials is named

MaterialServiceProcessControl (object Product is omitted as qualifier Material is an established term and covers the seman-tics of Product, component is Service Process Control)





D-69190 Walldorf

4.9.2 Service Interface

Syntax: <interaction activity><direction>

<interaction activity>: Verb or verb phrase in gerund (‘-ing’ form) or, if not possible, in substantive form

<direction>: Fixed term “In” or “Out”

A service interface name is unique within a process component.

Examples: • Request Invoicing Out • Fulfillment In

4.9.3 Service Operation (Asynchronous)

PC2PC1

<IF>Out

Op (out)

<IF>In

Op (In)MT

MDT

Syntax (outbound): <transaction activity><service view>?<action>?

Syntax (inbound): <action><service view>? or

<action><service view>?Based on<qualifier>*<object>

<transaction activity>: Activity of operation. Allowed terms are “Inform of”, “Notify of”, “Query”, “Re-spond”, “Request”, “Confirm”

<service view>: Service View that defines the operation signature; omitted if the name of the service interface covers the semantics of the service view

<action>: Verb that states the action that • is requested by the operation (in outbound case) • is offered by the operation (in inbound case)

<qualifier>: Semantic restriction of the object on which the action is based

<object>: Object on which the action is based




of 113


A service operation name is unique within an interface.

Operation naming rules apply to all categories of service operations (A2X, A2A, B2B).

For operations of reuse service components (RSCs) it is possible that an explicit object is not present. In that case the service view is not based on an object, for example operation Convert Quantitiy.

Examples: • Notify of Invoice

(outbound; with transaction activity “Notify of” and service view “Invoice”) • Inform of Purchase Order Cancel

(outbound; with transaction activity “Inform of”, service view “Purchase Order” and action “Cancel”)

• Maintain Invoice (inbound; with action “Maintain” and service view “Invoice)

• Create Invoice based on Attachment (inbound; with transaction activity “Create”, service view “Invoice” and object “Attachment”)

4.9.4 Service Operation (Synchronous)

PC2PC1

<IF>Out

Op (out)

<IF>In

Op (In)

MT1

MT2

Initiating Operation(follows outbound NR)

Reacting Operation(follows inbound NR)

MDT1

MDT2

For synchronous operations the following rule applies

• The name of the

o “initiating” operation follows the outbound syntax

o “reacting” operation follows the inbound syntax.

• Omit the “message type category” in the <service view> within the operation name (the <service view> of the incoming and outgoing MT differ by their message type category Request/Confirmation or Query/Response)





D-69190 Walldorf

4.9.5 Service Operation (A2X)

PC2

<IF>In

Op (In)

SV1PC2

SV2PC2

MT1

MT2

Reacting Operation(follows inbound NR)

MDT1

MDT2

For example„Manage <BO>“

For A2X operations the NR for inbound operations (asynchronous or synchronous) applies together with the following additional rule:

• Omit the BO in the <service view> name within the operation name (the BO name is already contained in the name of the IF the operation belongs to)

Note: For A2X only the reacting (inbound) operation is of relevance. The other part can for example be an excel for upload

Example: The name of the A2X operation belonging to IF “Manage Email Activity In” for mass mainte-nance of Email activities is:

Maintain Email Activity Maintain Request Bundle (inbound; with action “Maintain”, service view “Email Activity Maintain Request” and mass processing type “Bundle”)

The following rules applied

• Pattern for inbound operations

• “Request” omitted (rule for synchronous operations)

• “Maintain” omitted (Semantics contained in action name)

• “Email Activity” omitted (rule for A2X operations)




of 113


Topic

Abstraction

11

22

Definition

Term

33

44

„Building“

Semantics


Topic

Abstraction

11

22

Definition

Term

33

44

„Building“

Semantics


4.9.6 Message Type

Naming Rule for Message Types

Syntax: <service view><action>?<message type category>

<service view>: Service View contained in the message type, see section 4.9.1

<action>: Verb that states the action which the sender of a message expects to be executed on the service view

<message type category>: Classification of messages. Valid categories are: Information, Notification, Request, Confirmation, Query, and Response

In case the <message type category> (and / or <action>) is reflected in the <service view> (and thus has the same meaning), the corresponding parts of the <service view> name are omitted to obtain the message type name.

For synchronous operations and if the restricted message header is used suffix “_sync” is added to the MT name. For the MDT naming of mass processing messages refer to chapter 4.9.12, page 90.

Examples: • Purchase Order Cancellation Request with service view “PO Cancellation” and

message type category “Request” • Purchase Order Migrate Request with service view “PO Migrate Request”, action “Migrate” and message type category “Request”

Note:

It is essential to distinguish between

• the service view (substantive) providing the structural definition and

• an action (verb) to be executed on the service view

The following examples emphasize the difference between these two aspects:

• Message type PurchaseOrderCancellationRequest <Service View>

request to accept the PurchaseOrderCancellation document contained in the message Cancellation is part of the service view name no action involved

• Message type PurchaseOrderMigrateRequestMigrateRequest <Service View> <Action>

request to migrate the PurchaseOrderMigrateRequest document contained in the message Migrate = action to be executed on PurchaseOrderMigrateRequest





D-69190 Walldorf

4.9.7 Message Data Type

As a general principle the name of the MDT reflects the MT structure, and thus, is determined by the service view.

Syntax: <service view>Message

<service view>: Service View contained in the MT typed by this MDT, see section 4.9.1

For synchronous operations and if the restricted message header is used suffix “_sync” is added to the MDT name. For the MDT naming of mass processing messages refer to chapter 4.9.12, page 90.

Note:

Often the MT structure (service view) reflects the MT category and/or action of the MT. Thus the corresponding parts (suffix) of the structure name are omitted to obtain the MT name. In this case the original full name of the MT structure (service view) must be used to obtain the MDT name, because the category-specific (or action-specific) aspect of the MT structure has to be reflected in the MDT name.

Example: MT Structure = PurchaseOrderConfirmation

MT Category = Confirmation

MT structure reflects category resulting MT name is PurchaseOrderConfirmationConfirmation

MDT Name is PurchaseOrderConfirmationMessage

Examples:

(see also example of corresponding message types) • PurchaseOrderCancellationMessage with service view “PO Cancellation” • PurchaseOrderMigrateRequestMessage with service view “PO Migrate Request”




of 113


4.9.7.1 Message Intermediate Data Type / Element within a Message Data Type

MIDT / element name on Business Document Object (BDO) Level:

The MIDT name on BDO level is the <service view>.

The element name is obtained from the object the MT is derived from. It is the name of the object, the name of a specialization of the object or the name of a service-specific view onto the object.

For a compound query there is a special naming rule for the element on BDO level. For this see sec-tion 4.9.11, page 89.

MIDT / element name below BDO Level

For the name of an MIDT below the BDO level two cases appear:

- the name of the next higher level MIDT concatenated with the element name of the element to be typed (non-reusable MIDT)

- a name chosen according to the generalized semantics of the elements that shall be typed (reusable MIDT)

The element name does not contain the name of the next higher level element.

Example:

MT Purchase Order Cancellation Request is typed by MDT PurchaseOrderCancellationMessage, which is derived from BO Purchase Order. The BDO contains the service view “Purchase Order Can-cellation”.

• The name of the IDT on BDO level is “PurchaseOrderCancellation” The name of the element on BDO level is “PurchaseOrder”

• The name of the IDT on Item level (directly below BDO) is “PurchaseOrderCancellationItem” The name of the element on Item level is “Item”

PurchaseOrderCancellation Request

PurchaseOrderCancellationMessage

PurchaseOrder

MessageHeader

BusinessDocumentMessageHeader

Item

PurchaseOrderCancellation

PurchaseOrderCancellationItem

MT MDT Element ElementIDT IDT

BDO

Level 1 Level 2

Figure 36: Naming of Intermediate Data Types / Elements within a Message Data Type





D-69190 Walldorf

4.9.8 Response View

The Response View is used in several naming rules for compound Query Response Operations and therefore defined centrally in this section.

Serv

ice

Ope

ratio

n

Selection Criteria View(operation signature)

Response View(operation signature)

Query

Response

Figure 37: “Selection Criteria View” and “Response View” of Compound Query / Response Operations

Syntax: <qualifier>*<object>?<component>?Simple?

<qualifier>: Term expressing a semantic restriction of the object or object component in the response view

<object>: Object the response view is derived from

<component>: Component of the object the response view is derived from

Simple: Fixed term that indicates a simple object response view




of 113


Three kinds of response views are distinguished:

“Simple“ object response

Syntax: <object>Simple

Examples: Purchase Order Simple, Employee Simple

„Complete“ object response

Syntax: <object>

Examples: Purchase Order, Employee

Freely defined object response

Syntax: <qualifier>*<object>?<component>?

The naming for a freely defined response views is identical as for service views.





D-69190 Walldorf

4.9.9 Query / Response - Service Operation

Syntax (outbound): <transaction activity><response view>By<selection criteria view>

Syntax (inbound): <action><response view>By<selection criteria view>

<transaction activity>: Action requested; allowed are Find, Query, Respond.

<action>: Action offered (Find, Query, Respond)

<response view>: Requested response view. See section 4.9.8

<selection criteria view>: Name of selection semantics • Semantical name (e.g. Planning Information) • Sequence of main selection parameters concatenated by “and” • “Elements” for maximal set of selection criteria

Additional Rule for Core Queries

For the naming part <transaction activity> only “Query” is allowed.

The naming part <response view> is only allowed in case of content view.

Examples: • Query Purchase Order By Buyer Party • Respond Purchase Order By Buyer Party

4.9.10 Query / Response - Message Type

Syntax for Query MT: <response view>By<selection criteria view>Query

Syntax for Response MT: <response view>By<selection criteria view>Response

<response view>: See section 4.9.8.

<selection criteria view>: Name of selection semantics • Semantical name (e.g. Planning Information) • Sequence of main selection parameters concatenated by “and” • “Elements” for maximal set of selection criteria

Examples: • Purchase Order By Buyer Party Query • Purchase Order By Buyer Party Respond




of 113


4.9.11 Query / Response - Message Data Type

Syntax for Query MDT: <response view>By<selection criteria view>QueryMessage

Syntax for Response MDT: <response view>By<selection criteria view>ResponseMessage

<response view>: See section 4.9.8.

<selection criteria view>: Name of selection semantics • Semantically name (e.g. Planning Information) • Sequence of main selection parameters concatenated by “and” • “Elements” for maximal set of selection criteria

Examples: • PurchaseOrderByBuyerPartyQueryMessage • PurchaseOrderByBuyerPartyResponseMessage

Special Naming Rule for the Element on BDO level for a Query:

Syntax <response view>SelectionBy<selection criteria view>

For all other IDT and element names see section 4.9.7.1, page 85.

Example:

MT “Customer Invoice By ID Query” is typed by MDT CustomerInvoiceByIDQueryMessage. • The name of the IDT on BDO level is “CustomerInvoiceByIDQuery” • The name of the element on BDO level is “CustomerInvoiceSelectionByID”

Customer Invoice By ID Query

CustomerInvoiceByIDQueryMessage

CustomerInvoiceSelectionByID

MessageHeader

BusinessDocumentMessageHeader

MT MDT Element ElementIDT GDT

BDO

Level 1 Level 2

BusinessTransactionDocumentID

UUID

ID

UUID

CustomerInvoiceByIDQuery

Figure 38: Naming of Intermediate Data Types / Elements within a Query Message Data Type





D-69190 Walldorf

4.9.12 Mass Messages

Operation:

Syntax (outbound): <transaction activity> <service view><mass processing type><action>?

Syntax (inbound) : <action><service view><mass processing type>

For A2X-Operations omit the BO name contained in the <service view>.

Examples (outbound):

1. Request Purchase Order Change Bulk Change (transaction activity=Request, service view=Purchase Order Change, mass processing type=Bulk, action=Change)

2. Request Purchase Order Change Bundle Change (transaction activity=Request, service view= Purchase Order Change, mass processing type=Bundle, action=Change)

3. Notify of Payroll Process Collection (transaction activity=Notify of, service view=Payroll Process, mass processing type=Collection, no action)

Examples (inbound):

1. Change Purchase Order Change Bulk

2. Change Purchase Order Change Bundle

3. Payroll Process Collection

Message Type:

Syntax: <service view><mass processing type><action>?<message type category>

For synchronous operations and shortening rules refer to the basic naming rules for MTs.

Examples:

1. Purchase Order Change Bulk Change Request

2. Purchase Order Change Bundle Change Request

3. Payroll Process Collection Notification




of 113


Message Data Type:

<service view><mass processing type>Message

For synchronous operations and shortening rules refer to the basic naming rules for MTs.

Examples:

1. PurchaseOrderChangeBulkMessage

2. PurchaseOrderChangeBundleMessage

3. PayrollProcessCollectionMessage

<mass processing type>: Fixed term “Bulk”, “Bundle” or “Collection”

<transaction activity>, <service view>, <action> and <message type category> as defined before

Message-IDT:

The name of a Message-IDTs follows the common naming rules described in chapter 4.9.7.1, page 85.

Note:

The Message-IDT on BDO level is, as a rule, reusable for typing of the BDO of a corresponding non-mass message, and thus, its name does not contain the <mass processing type>.





D-69190 Walldorf

4.9.13 Reconciliation Messages

Message Type:

Dedicated reconciliation message types are named as follows:

Syntax: <service view><action>?<message type category>

<service view>: service operation view name consists of “original” view name followed by “Reconciliation”

<action>: same as original (non-“Reconciliation”) message type

<message type category>: same as original (non-“Reconciliation”) message type

Example:

• Production Request Confirmation Reconciliation Notification (service view= Production Request Confirmation Reconciliation, message type category=Notification)




of 113


4.9.14 Form and Interactive Form

Form Message Type

Syntax: Form<A2A/B2B Message Type>

Form: Fixed term

<A2A/B2B Message Type>: Name of corresponding A2A/B2B message type

Interactive Form Message Type

Syntax: InteractiveForm<A2A/B2B Message Type>

InteractiveForm: Fixed term

<A2A/B2B Message Type>: Name of corresponding A2A/B2B message type

Form-Message Type - Intermediate Data Types

Syntax: Form<GDT>

For restricted GDTs <VARIABLE>_<GDT> (see GDT Guideline -> “Restrictions on CDTs / GDTs”) the following syntax applies:

<VARIABLE>_Form<GDT>

Form: Fixed term, omitted in element name

<GDT>: Name of corresponding global data type that is extended to fit the needs of a form MT

<VARIABLE>: A variable is a “special qualifier” for a data type name that gets replaced in element names by an approved qualifier.





D-69190 Walldorf

4.9.15 Create With Reference (A2X)

Syntax for „generic“ create operation:

Message Type: <object>WithReferenceCreateRequest

Operation: Create <object> With Reference

Syntax for „specific“ create operation:

Message Type: <object>WithReferenceTo<RefObject>CreateRequest

Operation: Create <object> With Reference To <RefObject>

<object>: Object to be created

<RefObject> Object that provides information adopted for the creation of <object>




of 113


5 SAP Abbreviation Rules Naming rules for semantic names often result in names that are too long for dedicated name types such as:

• ARIS Name (length restriction 80) • ESR Name (length restriction ≤120)

Examples • Business Object Node (length 88):

Log Section Material Market Price Determination Explanation Derivation Step Output Price • A2X Operation (length 122) AccountingCashLedgerAccountForeignCurrencyRemeasuremen-

tRunActionIn.ExecuteCashLedgerAccountForeignCurrencyRemeasurementRun

Goal • Create SAP wide unique abbreviations of high quality • Outside-In driven

Object Types that need to be abbreviated • Object, Object Node • Relationships • Composition, Aggregation, Association, Association for Navigation • Operations (Compound, Core) • Message Type • Data Type

o Message Data Type o Node Data Type o Query / Action / Filter Data Type o Global Data Type o Intermediate Data Type

• Data Type Element

Abbreviation Rules are applied for name types • ARIS Name • ARIS Technical Name (Length restriction implied by ESR)





D-69190 Walldorf

5.1 SAP Abbreviations – Guiding Principles

• Abbreviations are SAP wide unique

o Guaranteed by using a common Abbreviation List o List contains only PIC approved abbreviations

• Abbreviations available as code list (GDT AbbreviationCode)

• Code list contains

o Abbreviations for Individual terms (e.g. Arrgmt - Arrangement) o Acronyms (e.g. RFQ – Request for Quote) o Abbreviations for Objects (e.g. CoTaxArrgmt - Company Tax Arrangement)

• Code List approved by PIC

• Request new abbreviations as new codes for GDT AbbreviationCode

o Determination supported by KM

• General abbreviation rules describe aspects valid for all abbreviations

• Additional abbreviation rules describe aspects valid for dedicated object types and name types

o Needed to fulfill requirements such as length restriction and readability needs

5.2 General Abbreviation Rules

• Always guarantee understand ability and distinguish ability of resulting abbreviations

• Try not to create abbreviations that are themselves English words

• An abbreviation is associated with only one unabbreviated word

• Do not use abbreviations that will conflict with commonly known abbreviations

• It is best to have an abbreviation begin with the same letter as the word being abbreviated

• Words that are four or less characters in length should not be abbreviated




of 113


5.3 Abbreviations in ARIS - Names and Length Restrictions

ARIS

NameRestricted to 80Title Case as a ruleUpperCamelCase for Data Types and Data Type Elements

Technical NameRestricted to max. 120 depending on object typeUpperCamelCaseMotivated by need to link to ESR

Full NameNo length restrictionTitle CaseFilled only if semantic name longer than 80

80

∞

max 120∞

Conceptional Modeling(no tool restrictions)

Semantic NameName according to naming rulesNo length restriction

Abbreviation rule needed

Identically taken over

(↔ESR)

5.4 ARIS Name - Abbreviation Rules

For all object types the following naming rules are valid for the ARIS Name:

• Abbreviate from left to right, replacing terms by its standard abbreviation, until name length is

less than 80 o Ensures that ARIS name is as understandable as possible o Abbreviated part of name contains no spaces; individual abbreviations start with upper

case • If the limit of 80 cannot be reached, abbreviate individually

(without general rule)

Example for Business Object Node:

Semantic Name: (length 88) Log Section Material Market Price Determination Explanation Derivation Step Output Price

ARIS Name: (length 78) LogSecMatl Market Price Determination Explanation Derivation Step Output Price

ARIS Full Name: (length 88) Log Section Material Market Price Determination Explanation Derivation Step Output Price





D-69190 Walldorf

5.5 ARIS Technical Name - Length Restrictions Overview

Abbreviation Object Type Maximum Length

Never Always As Required

GDT 120 x

Object To be decided x

Object Node To be decided x

Interface 60 x

Operation 60 x

Message Type 100 x

Message Data Type 60 + Version x

Intermediate Data Type 60 + Version x

Node Data Type 60 x

Table 3: Length Restrictions Overview

Abbreviate Semantic Name for Technical Name • Never: Semantic Name must not exceed the maximum length for Technical Name • Always: Semantic Name is always abbreviated • As Required: Abbreviate Semantic Name from left to right until name length fits

5.6 ARIS Technical Name: Abbreviation Rules

For Interfaces, Operations, Node Data Types, Intermediate Data Types the following rules apply:

A Length of Technical Name without namespace should never be longer than 60; abbreviate always

B Applies only for IF / Operation: Leave out duplicate parts of the semantic name Make sure that the name still expresses the right semantics

C Applies only for IF / Operation:

Abbreviate the Process Component by its four letter abbreviation

D Applies only for NDT / IDT:

From the semantic name leave out the path leading to the node

If the result is not unique within the object or MDT add the differentiating part of the path lead-ing to the node




of 113


E Replace terms by its standard abbreviation

Individual abbreviations start with upper case

If needed, request for missing abbreviations via PIC process

F If the limit of 60 cannot be reached abbreviate individually (without general rule)

Note:

Namespaces should be as short as possible. New namespaces should not be longer than 30 letters





D-69190 Walldorf

Examples: A2A Operations

Semantic Name (without spaces):

CustomerInvoiceProcessingRequestInvoicingIn.MaintainCustomerInvoiceRequest (74 characters)

After rule C:

CIV_RequestInvoicingIn.MaintainCustomerInvoiceRequest (53 characters)

After rule E:

CIV_ReqInvcgIn.MaintCustInvReq (30 characters)


BalanceOfForeignPaymentManagementForeignReceivablePayableNotificationIn.CreateForeignReceivablePayable (102 characters)

After rule B:

BalanceOfForeignPaymentManagementForeignReceivablePayableNotificationIn.Create (78 charac-ters)

After rule C:

BFP_ForeignReceivablePayableNotificationIn.Create (49 characters)

After rule E:

BFP_ForgnRecvbPaybNotifIn.Create (32 characters)


LogisticsExecutionControlFulfilmentIn.ChangeLogisticsExecutionRequisitionBasedOnDeliveryFulfilme ntConfirmation (110 characters)

After rule B:

LogisticsExecutionControlFulfilmentIn.ChangeRequisitionBasedOnDeliveryFulfilmentConfirmation (92 characters)

After rule C:

LEC_FulfilmentIn.ChangeRequisitionBasedOnDeliveryFulfilmentConfirmation (71 characters)

After rule E:

LEC_FulfilmentIn.ChangeReqiBasedOnDelvFulfConf (46 characters)




of 113


Examples: A2X Operations


CustomerInvoiceProcessingManageCustomerInvoiceRequestIn.CreateCustomerInvoiceRequest (84 characters)

New pattern definition without repeating the object name:

CustomerInvoiceProcessingManageCustomerInvoiceRequestIn.Create (62 characters)

After rule C:

CIV_ManageCustomerInvoiceRequestIn.Create (41 characters)

After rule E:

CIV_ManageCustInvReqIn.Create (29 characters)


AccountingCashLedgerAccountForeignCurrencyRemeasurementRunActionIn.ExecuteCashLedgerAccountForeignCurrencyRemeasurementRun (122 characters)

New pattern definition without repeating the object name:

AccountingCashLedgerAccountForeignCurrencyRemeasurementRunActionIn.Execute (74 characters)

After rule C:

ACC_CashLedgerAccountForeignCurrencyRemeasurementRunActionIn.Execute (68 characters)

After rule E:

ACC_CshLdgrAcctFrgnCrcyRemsmtRnActionIn.Execute (47 characters)

Example: Node Data Type


US_EmployeeTaxArrangementFederalTaxArrangementTaxAuthorityItemPeriodTermsLocalityAdditionalTaxesElements (104 characters)

|--BO----------------------------------|--Node1------------------->|--Node2--------->|-Node3----->|-Node4>|--Node5----->|

After Rule D:





D-69190 Walldorf

US_EmployeeTaxArrangementLocalityAdditionalTaxesElements (56 characters)

After rule E:

US_EmplTxArrgmtLoclAddTxsElmnts (31 characters)

Example: Intermediate Data Type


US_EmployeeTaxArrangementPayrollNotifiactionFederalTaxArrangementTaxAuthorityItemPeriodTermsLocalityAdditionalTaxes (115 characters)

|--MessageType------------------------------------------>|--Node1------------------->|--Node2--------->|-Node3----->|-Node4->|--Node5---->|

After Rule D:

US_EmployeeTaxArrangementPayrollNotifiactionLocalityAdditionalTaxes (67 characters)

After rule E:

US_EmplTxArrgmtPayrlNotifLoclAddTxs (35 characters)




of 113


5.7 ESR Name Adopted from ARIS Technical Name

The ESR name is identically taken over from ARIS Technical Name.

The Length restrictions are in ESR is identical to the length restriction of the ARIS Technical Name.

In case a deviating ESR name already exists and adoption is not feasible anymore, proceed in the following way:

Only in that case:

• Fill ARIS Technical Name with the existing ESR name

• Set ARIS Flag “Keep Technical Name” to avoid overwriting

Reason:

ESR Name has to be identical to ARIS Technical Name to ensure error detection by ESR-ARIS check.




of 113


6 SAP Object Model - Documentation Business Objects are an approach to model real world business content.

A Business Object represents

• a view on a well defined & outlined business content

o Well known in the business world (for example, in an international standard or industry best practice).

• a self-contained (capsule), independent business concept

The objects of the SAP object model are classified in the following way:

• Business Object

o Business Foundation Object

o Business Transaction Object

• Technical Object

• Transformed Object

• Mass Data Run Object

Offered service operations reflect the expected business needs to access or manipulate the object (or parts of it).

ObjectCapsule

<Object>

<Object>Root

<Node 1>

<Node 2>

Root

<Specialisation> <Node 1_2>

<Node 1_1>

<Object>Root

Figure 39: Components and Environment of an Object

Figure 39 shows the model of an object with its components and environment. The object itself is a capsule hiding its internal structure and offering compound service operations.

The internal structure of a business object refines the object into semantic components (nodes, sub-types, elements, relationships) according to the business understanding.





D-69190 Walldorf

For a holistic documentation of an object the following entities are to be described:

• Object

o Object Name

o Object Definition

o Process Component

o Deployment Unit

• Object Capsule

o Nodes / Subtypes

o Compositions / Associations

o Integrity

• Business Object Environment

o Inbound Association

o Inbound Aggregation

• Node Elements Structure

• Interfaces / Operations

o Core Service Operations ( Actions, Queries )

o Compound Service Operation ( B2B / A2A / A2X, Inbound / Outbound )

For the definition of an object and the entities it consist of the rules presented in this guideline apply.

Special hints are presented in the following sub sections.

BO Documentation- Name- Definition- Process Component- DU- Nodes / Subtypes- Compositions / Associations- Integrity- Business Object Environment- Node Element Structure- Interfaces / Operations

BO Documentation- Name- Definition- Process Component- DU- Nodes / Subtypes- Compositions / Associations- Integrity- Business Object Environment- Node Element Structure- Interfaces / Operations




of 113


6.1 Target Group Specific Pattern-Based Documentation To get understandable objects, a holistic semantic documentation of the objects with its services is required. The documentation should be concise but sufficient and adequate for the respective target group. Depending on the target group focus and granularity of object documentation may differ. A way to get a target group specific documentation is to create a common documentation and to gen-erate target group specific documentations using filters. For example business object documents can be generated for the different review types (PIC 1, PIC 2, PIC 3) containing only the granularity of information needed for review but always containing a com-plete holistic documentation of the business object. This documentation describes the objects and services as a whole, as well as defining its substruc-tures. All structure elements are explained by documentation that

• Describes the structure and environment • Specifies integrity conditions and • Refers to the data types used

As the building blocks of the objects and services are the same, its documentation is pattern-based. A document pattern not only specifies the basic document structure but also text blocks or uniform phrases for all object / service documents (analogous for data types).

Figure 40: Pattern Based Documentation of Objects

An object documentation is a • Central self contained document for design / review / roll out • Generated from ARIS • Growing during PIC 1/2/3 process





D-69190 Walldorf

6.2 Hints for Object Definition

The object definition focuses on the main features of the object as a whole from an outside perspec-tive. Because the node structure of the object is hidden from the outside perspective by the object capsule, the definition does not rely on “internal knowledge” of the object.

ObjectCapsule

Figure 41: Object Capsule

Types of mistakes:

• No strict separation of Definition, Comment, Structure, Use and Example • Description of Process instead of Definition

Bad examples:

• An xyz collects information about … • An xyz is the inspection of …

6.2.1 Paragraph „Structure“ Explain the significance of the main subordinate nodes in the context of the object, from a business perspective.

Types of mistakes:

• The paragraph contains no business semantics e.g. The BO xyz is represented by the root node and its associations.

• The paragraph contains no additional information

e.g. The BO xyz contains the following nodes: Node 1, Node 2, Node 3

• Too detailed information: complete listing of all sub-nodes, including their definitions

Good examples:

• A Due Clearing contains: o Information about the time point and execution of an offsetting. o The relation to receivables and payables o As well as the explanation of all deductions

• A project contains o A hierarchical structure of project tasks that have to be fulfilled o Information about the resources that are needed for the fulfilment of the project




of 113


6.3 Hints for Object Node Definition The definition of an object node focuses on its main components. Figure 42 shows the aspects that have to be considered for an object node definition. These are the

• Semantic of the node (1) and its subtypes (2) in the context of the parent node; that includes the semantic of the whole sub-tree as a node represents all its subordinated nodes

• Most important subordinated nodes (3) of the node • Most important relationships (4,5) of the node

Node represents sub-tree

<Business Object>

<Business Object>Root

<Node 1>

<Node 2>

Root


<Node 1_1><Semantik>


<Semantik>

1

234

5

<Business Object>


<Node 1>

<Node 2>

Root


<Node 1_1><Semantik>


<Semantik>

1

234

5

Figure 42: Aspects of an Object Node Definition

Types of mistakes:

• Definitions of object nodes often don‘t clearly state o what one object node is o how different „instances“ of an object node are differentiated

Bad example:

Material Cost Function Material

Figure 43: Example for Object Node Definition

Definition of Material Cost Function: „A Material Cost Function specifies the relation between quantities and costs of the material.“ Questions:

• What does one Material Cost Function represent?

• Why is it necessary to have multiple Cost Functions? How do they differentiate? (Are there separate functions for different times or quantities?)





D-69190 Walldorf

6.3.1 Object Root Node The root node of an object specifies the internal view on the object with details of the object's essential internal structure. Thus the root node definition is not a copy of the BO definition. The business object definition focuses on the external view of the business object as a whole, whereas the root node definition focuses on the internal view. In this sense, it “refines” the BO definition.

Types of mistakes:

• The paragraph contains no business semantics e.g. The root node XYZ is the identifying and administrative header information of object XYZ.

• Redundant information

e.g. copy of object definition Good example: The Supplier Quote is a response to a Request for Quote (RFQ). The response contains detailed in-formation about the offered goods or services, prices, delivery dates, payment terms and conditions of business. The offer may legally bind the supplier company for a certain period of time.

6.4 Hints for Object Node Element Definition An element definition describes the meaning of an element for a node. In case the element is typed by a code GDT, specify constraints for the codes allowed in this context. Types of mistakes:

• The paragraph contains no business semantics e.g. An EmployeeUUID is a unique identifier for an Employee

Good examples:

• EmployeeUUID A unique identifier of the Employee for whom the Parental Leave is valid

• TraficLightColorCode (GDT: ColorCode, Constraint: Only values 1 (red), 2 (green) and 3 (yellow) can be used.)




of 113


7 Index

A

abbreviation rule ........................................................... 96

B

business object ............................................................ 105 business pattern............................................................. 44

C

catalog........................................................................... 39 category......................................................................... 36 characterizing term........................................................ 30 class as key term ........................................................... 35 classifying term............................................................. 30

D

definition aspect ............................................................ 14 comment ................................................................... 15 constraint .................................................................. 16 definition .................................................................. 14 example .................................................................... 16 integrity condition..................................................... 15 note ........................................................................... 16 restriction.................................................................. 16 structure .................................................................... 15 use............................................................................. 15

definition enemy ........................................................... 15

E

equipollence .................................................................. 26

G

group as key term.......................................................... 36 grouping........................................................................ 37

H

homonym ...................................................................... 25

I

imprecise usage..............................................................28 ISO 11179................................................................13, 19

K

kind................................................................................37

L

linguistic defect..............................................................29

N

naming rule....................................................................47

O

object definition...........................................................108 object documentation...................................................107 object node definition ..................................................109 object node element definition.....................................110

S

semantic name ...............................................................48 semantic triangle............................................................24 structure pattern .............................................................40 synonym ........................................................................25

T

technical name ...............................................................48 term..........................................................................19, 24 terminological pattern....................................................34 type as key term.............................................................35

V

vagueness.......................................................................27 variant............................................................................38 version ...........................................................................38




of 113


8 Change History

Version Date Name Changes / Addition

1.0 2007-11-07 Seubert, Michael; Krähmer, Thilo

Published enterprise SOA Object & Service op-eration Design

2.1 2007-11-26 Kühl, Axel New version of complete eSOA guideline hand-book

2.1 2008-02-27 Krähmer, Thilo Reference to S&G-Definition Pattern (2.4) added

2.1 2008-03-04 Thilo Krähmer BO node relationship naming rules adapted

2.1 2008-05-13 Krähmer, Thilo Update Naming of Mass Messages

2.1 2008-05-30 Krähmer, Thilo Added Abbreviation Exceptions (Lexical Rules)

2.5 2008-06-27 Kühl, Axel New version of complete eSOA guideline hand-book

2.5 2008-08-08 Krähmer, Thilo Added allowed abbreviations and acronyms.

Added naming rule for reuse of M-IDT.

2.5 2008-09-30 Krähmer, Thilo Naming Rule for Filter Data Types changed; Ab-breviation sequence rule removed