Service Operations

Service Operations

SAP AG 2004, Service Operations, Michael Seubert / 2

Table of Content

Business Content Governance

Business Object Model

Service Operations Definition & Understanding Service Operation Signature: Derivation by Hierarchization Service Operation Signature: Derivation by Hierarchization –

Detailed Steps Service Operation Definition Framework

Business Object Documentation

Global Data Types (GDT)

Service Operation

Definition & Understanding


Service Operation: View Concept

View

A service operation represents

a semantical view onto an object

to perform a business functionality

The view defines the operation signature

Ser

vice

Op

erat

ion


From Outbound to Inbound: One Single View

e.g. PurchaseOrder e.g. SalesOrder

Inte

rfac

e O

UT

Inte

rfac

e IN

OP

1

OP

2

HugoRequest

Object emulates view

Hugo

The same view is used in inbound operation, message type, and outbound operation

Defining Object


Compound Service Operation

Operation defined at BO level

Implemented via BO core service operations

From PIL Taxonomy:

compound serviceA service that is designed from a process point of view. It is not necessarily bound to a specific part of a business object and wraps multiple elementary services.

In Business Process Platform, compound services for business objects are implemented by invoking several core services or reuse service components.

In the application platform, compound services are implemented by process agents that invoke several core services or reuse service components.


Core Service Operation

Operation defined at BO node level

Offers access to and manipulation of a single BO node

Different kinds of operations (Create, Update, Delete, Query, RetrieveByAssociation, …)

From PIL Taxonomy:

core serviceA service of a business object node according to a standardized set of interface patterns. The set of all core services of a business object node completely encapsulates and controls the state and behavior of all node instances.

ExamplesCreate, update, delete, or query services for sales order item or sales order header

Service Operations

Service Operation Signature: Derivation by Hierarchization


Different Operations: How to Achieve Consistency ?

Cross - operation consistency ?


Consistent Business Documents derived from Object Model

Environment„Leading Business Object“

Object Model

BusinessDocument

~ Object

Component Component

Implementation Object


One Single View Based on a Central Object Model

BusinessDocument

~ Object

Component Component23

Source Object TargetObject

Outbound Operation Inbound Operation

„Defining Business Object of central Object Model

Document based Integration


Business Document Variants derived from Object Model

Object Model

Environment

„Leading Object“

Business Document

Object


Business Object – Business Documents - Messages

Business Object Model

B3

BusinessDocument Objects

Not overlapping Net structure

overlapping hierarchical

BusinessDocument

Message:

Message Header:

Attachment:

BusinessDocument-Object:

BusDocMsg-Header: MessageID


Hierarchization: Business Document Object 2

A

C

B

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

1 : 1

Directed relationships

1 : 1

1 : 1

Case 1: The whole

object A is of relevance

Case 2: In C the reverse path

from C2 to C1 is of relevance

Case 3: The composite B3 of

object B and the dependent

composite B4 is of relevance.

The composite B1 is not of relevance in this case.

1 : 1

Different cases for involvingreferenced business objects


Business Document Object: dependency level

Arrangement according to the degree of the dependency level

3

A

C

B

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

1 : 1


1 : 1

1 : 1

Level 1 2 3 4 5


Hierarchization: the resulting Business Document Object 4

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X


Level 1 2 3 4 5

<X1>

<A1>

<A2>

</A2>

<A3>

</A3>

</A1>

<X2>

<X3>

<C2>

<C1>

</C1>

</C2>

</X3>

</X2>

<X4>

<B3>

<B4>

</B4>

</B3>

</X4>

</X1>

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X


Level 1 2 3 4 5 1 2 3 4 5

XML SchemaBusiness Document Object

Service Operations

Service Operation Signature: Derivation by Hierarchization – Detailed Steps


(i) Selection of leading object

Selection of leading object Specify the leading BO The leading object can be

the source object, the target object, or a third one.

Selection of relevant nodes Determine the parts of the BO required for the view. The parts must be connected to the root node via a valid path along the

hierarchy

Selection of more independent objects Determine more independent objects (object parts, respectively) referenced

by the leading object which are the relevant for the service. A relationship must exist between the leading object and the more

independent objects.

Environment„Leading

Business Object“

Object Model

BusinessDocument

~ Object

Component Component

ImplementationObject

Environment„Leading

Business Object“

Object Model

BusinessDocument

~ Object

Component Component

ImplementationObject


(ii) Hierarchization – Adoption

Adoption of object nodes Adopt the relevant nodes of the leading

object structurally identical to the message type structure.

Adoption of nodes from more independent objects Invert the relationships to the relevant more independent objects or

object parts, respectively.


(ii) Hierarchization – Adjustment

A

C

B

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

1 : 1


1 : 1

1 : 1

Case 1: The whole








1 : 1

A

C

B

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

1 : 1


1 : 1

1 : 1

Case 1: The whole








1 : 1

Derived Business Document Object: Leading Object with Previously “Referenced” Objects

Linearization A BO node containing certain TypeCodes is represented in the MT structure

by explicit entities (an entity for each value of the TypeCode). These entities contain the name of the TypeCode as prefix.

Example: Party nodes, BTD Reference nodes, Product node

Reduction of structure Check all 1:1 cardinalities existing in the MT structure. Combine entities if

They are semantically equivalent or One of the entities carries no elements or

An entity solely results from an n:m assignment in the BO


(ii) Hierarchization – Resulting BDO

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X


Level 1 2 3 4 5

<X1><A1>

<A2></A2><A3></A3>

</A1><X2>

<X3><C2>

<C1></C1>

</C2></X3>

</X2><X4>

<B3><B4></B4>

</B3></X4>

</X1>

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X


Level 1 2 3 4 5 1 2 3 4 5


C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X


Level 1 2 3 4 5

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X


Level 1 2 3 4 5

<X1><A1>

<A2></A2><A3></A3>

</A1><X2>

<X3><C2>

<C1></C1>

</C2></X3>

</X2><X4>

<B3><B4></B4>

</B3></X4>

</X1>

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X


Level 1 2 3 4 5

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X


Level 1 2 3 4 5 1 2 3 4 5


Business Document Object with Its Parts (Arranged According to Dependency Level) and Corresponding Representation in the XML Structure

Object Model

Environment


Business Document

Object

Object Model

Environment


Business Document

Object

Object Model and Derived Business Document Object (Multiple Overlapping Views)


(iii) Completion / Wrapping

Add information regarding the transmission of the BDO CompleteTransmissionIndicator, ActionCodes, message category

Message Header Add the standardized message header to the MT structure

Typing Type the MT structure with data types.

(1) Elements are typed by GDTs according to the business objects.

(2) Aggregated levels are typed with message type specific data types (Intermediate Data Types). Their name is built according to the path in the message type structure.

(3) The whole message type structure is typed by an MDT. Its name is built according to the root entity with suffix „Message“.


(iii) Completion / Wrapping

Message Category Specify the suited message category for the message type. according to the suited transaction communication pattern.

Sender Recipient

Query

Response

Request

Confirmation

Notification

InformationPattern 1

Pattern 2

Pattern 3

Pattern 4

Sender Recipient

Query

Response

Request

Confirmation

Notification


Pattern 2

Pattern 3

Pattern 4


Result: Business Document

More details on the derivation rules can be found here:

ServiceSignatureDerivation_by_Hierarchization_EN.doc ServiceSignatureDerivation_by_Hierarchization_DE.doc

Corporate Portal > Application Platform > Engineering > Cont.Gov. > Guidelines & Documents

BusDocMsgIDBusDocCreationDateTime

Business Document(Payload):

. . . .

Message

Message-Header

TechnicalMessageID

Attachment

Invoice No

Sender

Invoice Date

Recipient

Message NoMessage Date

Invoice

Business Document

„MessageType“ type „MsgDatatype“

BusDocObject

BusDocMessageHeader

structures

Message Envelope(technical)

character-izes

Instance Level Type Level Analogy

BusDocObjID



. . . .

Message

Message-Header

TechnicalMessageID

Attachment


. . . .

Message

Message-Header

TechnicalMessageID

Attachment

Invoice No

Sender

Invoice Date

Recipient


Invoice

Business Document


BusDocObject

BusDocMessageHeader

structures


character-izes


BusDocObjID



. . . .

Message

Message-Header

TechnicalMessageID

Attachment

Invoice No

Sender

Invoice Date

Recipient


Invoice

Business Document


BusDocObject

BusDocMessageHeader

structures


character-izes


BusDocObjID



. . . .

Message

Message-Header

TechnicalMessageID

Attachment


. . . .

Message

Message-Header

TechnicalMessageID

Attachment

Invoice No

Sender

Invoice Date

Recipient


Invoice

Business Document


BusDocObject

BusDocMessageHeader

structures


character-izes


BusDocObjID


MessageDataType: Data Model

Service Operation

Service Operation Definition Framework


The Service Operation Definition Framework (SODF)

All operations are built according to the SODF, which is based on the interface paradigm*.

The Business Document

Interface Type Categories

Message Type Categories

Operation Templates and Packages

Data Types

Naming Rules

Documentation template

Integrity based on Business Object Model

*see Corporate Portal Application Platform Engineering Cont.Gov. Guidelines & Documents


Interface Paradigm

Interfaces & Operations (and Messages)

Correspond to business-related documents

Are built according to international standards and norms

Are driven outside-in

Have a uniform structure via templates

Have uniform typing throughout SAP via normed data types


Outside–In: eBusiness Standards

RosettaNet,

xCBL,

HR-XML,

PIDX (Petroleum Industry Data Exchange),

CIDX (Chemical Industry Data Exchange),

UCCnet (Retail),

PapiNet (Paper Industry),

Odette (Automotive Industry)

Organisations and Initiatives UN/CEFACT ebXML und UBL

SAP (“inside”) speaks the language of the Business World (“outside”).


Interface Category: SAP B2B Interface

Focus: compatibility with international standardized interfaces

represent business-related documents. designed in accordance with the rules of international standards contain exclusively business-related information

information has been adopted by international committees for this interfaceand is mappable to at least to one e-business standard RosettaNet, xCBL, HR-XML, CIDX, PIDX, UCCnet, PapiNet, Odette

support the core functionality of a component .

usage does not presuppose bilateral agreements between the business partners. Rules for usage are public and binding e.g. stored in ebXML Registry / Repository or SAP Collaboration Directory

are used mainly in business processes between enterprises


Interface Category: SAP A2A Interface

Focus: complete usage of the functionality of the application 1. represent business-related documents2. designed in accordance with the rules of international standards 3. contain exclusively business-related information

4. Can contain additional information not (yet) covered by B2B standards. This information is motivated by SAP applications (Content is transparent, not SAP-specifically encoded)

5. allow complete usage of the SAP application functionalityfrom a purely business-related point of view

6. Rules for optimal coupling and usage of the applications are agreed bilaterally according to need

7. are used mainly for communication between SAP components, and between SAP components and applications from 3rd party suppliers.

Enterprise boundaries do not play a role here


Message Type Categories: Overview

A message type category is a general business-related dividing up of messages according to the criteria

obligation of the message, that is, assurances of the sender connected with sending the message or the sender’s expectations of the recipient

Existence of predecessor messages Expectation of follow-up messages

For the time being, these are the categories “Information”, “Notification”, “Query”, “Response”, “Request”, and “Confirmation”

Communication is always driven by the sender

The meaning of the message categories is specified from the sender’s point of view.


Transaction Communication Pattern

A transaction communication pattern describes an atomic dialog between a sender and a recipient.

In the context of the pattern, the recipient’s reply is optional

four transaction communication patterns are used for SAP messages, with associated message type categories

Sender Recipient

Query

Response

Request

Confirmation

Notification


Pattern 2

Pattern 3

Pattern 4

Sender Recipient

Query

Response

Request

Confirmation

Notification


Pattern 2

Pattern 3

Pattern 4

Note: In a concrete scenario, the pattern can be characterized more precisely.

Example: Dependent on the scenario, a confirmation for a request can be mandatory.


Message Type Categories (1)

Information Information is a message regarding a state or a subject matter.

No reply is expected for information

Notification A notification is a notice or message tailored with respect to a service No reply is expected for a notification

Query A query is an inquiry to which a reply is expected.

By a query the sender does not enter into a commitment. The inquiry is without obligation for the sender.

Response A response is a reply to an inquiry By a response the sender, in general, does not enter into commitment.

The reply, in general, is without obligation for the sender


Message Type Categories (2)

Request A request is a requisition or requirement with obligation.

Confirmation A confirmation is a reply with obligation, which follows a request.


Uniform Building Blocks: Packages

...Order

Seller Party

BuyerParty

...

ManufacturerParty

...

.....

Party

The packages group semantically associated information


Uniform Structure via Operation Templates

Top-Down:

Identical build-up structure for all operation signatures

The simple usage of the interfaces results from their uniform composition

OrderCreate

OrderItemScheduleLine

ScheduleLine

OrderItem

DeliveryInformation

Configuration

Pricing

Product

Attachment

Description

Order

Attachment

Description

PaymentInformation

DeliveryInformation

Administratrive Data

Party

Location

ReferenceReference

Party

Location


MessageDataType: Data Model


SAP Business Objects and Service Operationsbased on GDTs and CCTS Core Data Types

B2B / A2A – Interface / Service Operation

Message Type

B2B / A2A – Message Data TypeNode Data Type

Global Data Type

CCTS Core Data Type

W3C Data Type

• PurchaseOrdering_In• PurchaseOrdering_Out

• PurchaseOrderRequest• PurchaseOrderChangeRequest

• PurchaseOrderMessage• InvoiceMessage

• PurchaseOrderPartyElements• PurchaseOrderDeliveryTermsElements

• Deliery Terms• Address• ProductID

• float• string

BusinessSemantics

n

1

n

1

n

1

n

1

Usagespecific

noBusinessSemantics

global

Business Object Node

Business Object

1

n

1

1

• PurchaseOrderParty• PurchaseOrderDeliveryTerms

• PurchaseOrder

nn

Data

Typing

Semantic Structure

Indicator Measure Numeric Quantity Text

Amount Binary Object Code DateTime Identifier


SAP-wide Uniform Typing via Normed Data Types

Bottom-up: uniform typing

A Message Interface is a hierarchical structure.

The leaves of the tree are Generic Data Types

The same subject matter is always described by the same data type


Global Data Type: Example „Dangerous Goods“ (1)

DangerousGoods are substances or objects that cause danger to public safety, to the life and health of people and animals or to the safety of things

< DangerousGoods ><ClassID>1</ ClassID ><DivisionID >3</DivisionID >

</ DangerousGoods >


Global Data Type: Example „Dangerous Goods“ (2)


Naming Rules According to ISO 11179

DatatypeValue

Domain

PropertyPropertyQualifier Representation Representation QualifierObjectObject ClassClass

Qualifier


MessageDataType: Data Model and Element Structure

Service Operations

Documents

service operationsdate

michael seubert

sap ag

business object node

reuse service components

object modeldate

different operations

business objects