Michael Seubert, Axel Kühl, Dirk Richtsteiger (Coaching Team)

1. enterprise SOA Object & Service Operation DesignPart IProcess Integration Content (PIC) Governance Michael Seubert, Axel Kühl,Dirk Richtsteiger (Coaching Team) Nicole Leuchter (AP Operations)

2. Table of Content – PIC Governance Process Integration Content (PIC) Governance • Introduction • PIC Governance Process: Roles and Tasks • Governance for Business Objects & Service Operations • Additional Governance Rules • Governance for Alignment of B2B / Level 3 Services • Milestones and Deliverables for BOs • PIC Governance for GDTs • Milestones and Deliverables for GDTs • Coaching Procedure Model (CPM) • ARIS User Access Rights Business Object Modeling Service Operation Design Global Data Type (GDT) Design

3. Introduction

4. Governance Process for Business Content:Business Objects, Operations and Data Types Guidance for identification, design and maintenance of Business Objects, Operations and Data Types according to • defined roles, tasks, milestones and design rules with the objective to define high quality Business Contentwhich is • generally accepted & well known in the business world (outside-in) • consistent and redundancy free „Who does what when how“

5. Governance Process: PIC 0 and PIC 1,2,3 IntegrationScenarioStructure ESA EntityIdentification& Cut ServiceOrchestration PIC 01 PIC 02 PIC 03 Identification of BO’s,PC’s, DU’s(Name and Semantics) Identification of PC’s and PCinteractions within Integration Scenario(Name and Semantics) Identification and cut of Service Operations andInterfaces within PC interaction(Name and Semantics) ChangeRequests PIC 03approval of PCIM’s (Interfaces and Serv.Operations) requiredto start PIC 3 PIC 01approval Required tostart PIC 1 NodeStructure Actions, Queries, Interfaces Elements PIC 1 PIC 2 PIC 3 GDT’s Assignment GDT’s to BOnodes Definition of Actions, Queries, compoundservices GDT PIC Definition of Node Structure of BO Detailed Definition of Global Data Types

6. Goals of the Governance Process for Business Objects (BOs) consistency of semantics across development units reuse wherever possible similar treatment of similar objects (customer invoice – supplier invoice) identical modeling and documentation rules high quality content for Business Process Platform Process Integration Content (PIC) Governance Governance Coaching, Steering, Approval Implementation Scoping, Identification Definition • Business Objects • Interfaces / Operations • Global Data Types (GDTs) PIC 0 PIC 1 PIC 1,5 PIC 2 PIC 3 Identification Structure GDTs Elements Service Operation PIC Council Approval

7. PIC Governance Process: Roles and Tasks

8. Governance & Guidance by Coaching Team Approval by Process Integration Content Council (PIC) Business Objects / Nodes / Operations Data Types Methodology Business Objects / Nodes / Operations Data Types PIC Governance Process and Roles for Business Objects D Methodology Council: Methodology, Design Rules, Procedure Model A B C Development by Project Integration Experts / Content Owner Organizational structure with roles and tasks (A – D)

9. PIC Governance: Roles and Tasks (1) A Integration Experts (in Development Business Units) • Detailed definition of business objects nodes, associations, and data types according to guidelines • Specification of needed service interfaces and operations • Central contact person for BO and operation owners in business unit (“multiplier”) • Work with central team on Governance & Methodology • Responsible for preparation of PIC Approval with all relevant documents in close cooperation with the coaching team Content Creation Teams • Decentralized (Content Owners in Dev. or SM) • Create Content • Responsible for Content

10. PIC Governance: Roles and Tasks (2) B Coaching Team • Governance and coaching of the local integration experts • Ensure unified design process of business objects, service interfaces and data types • Ensure consistent design of the object model and service interfaces • Lean approval of BO if they are based on well known concepts • Responsible for Methodology & Guidelines • Responsible for Content Inventory • Responsible for implementation of Governance Process / Improvement / Scalability /

11. PIC Governance: Roles and Tasks (3) C BO Process Integration Content Council (BO PIC Council) • Approval of Business objects, node structure and assigned data type design • All methodical issues have to be addressed to and solved by the methodology council • Staffed with representatives (10 – 12) from • AP Operations • Platform areas (10 - 20 % FTE) • Development Business Units • Netweaver • Coaching Team (interface, process and business object experts) • Responsible for high quality of Process Integration Content

12. PIC Governance: Roles and Tasks (4) D Methodology Council • Works with Coaching & Governance Team on methodology issues and methodology development • Proposal and Review of general concepts, guidelines, templates, patterns, methodological issus • Approval of the overall design approach • Responsible for a consistent methodological approach

13. Governance for Business Objects and Operations

14. PIC 0-3 review steps PIC 0: Business Objects and Operations Identification • It is recommended for new BOs to pass each PIC 1-3 review step seperately • No restriction on number and combination of PIC 1-3 review steps • deliverables for each PIC step must be fulfilled (details, see following slides) • Allowed steps / combinations are: PIC1, PIC2, PIC3, PIC1-2, PIC2-3, PIC1-3 • No overlapp of different PIC review phases of the same BO • Preparation phase may overlapp PIC 1: Node-Structure for Business Objects PIC 2: Node Data Types for nodes PIC 3: Final definition for Business Objects and Service Interfaces / Operations

15. Detailed PIC 0-3 Process for Business Objects Identification + Definition of Key Entities by PIC0 IE PIC 0 Creation/Change of BO in Aris (english) according to guidelines Color Legend: Coaching by IE + KM BO Owner Suited for Review? Check by IE Integration Experts (IE) + KM Representative • AP Ops starts review: • Q&A-, SignOff-Excel • Inform: owner + experts Name + Definition OK? Coaching Team AP OPS • secure copy in word • After change before review Offline Review by IE + KM + Coach BO-Coach contacts PIC0 coach 1 ) BOT: staffed with architects of development areas Escalation Inform SVP Critical Issue? Check by owner 2 ) Clearing House: staffed with PIC0-Coach, Applicationexpert, PIC1-3 Coach, Integrationexpert, Object Owner, KM Representative Name + Definition OK? Clarification in Clearing House 2 Business Object Taskforce (BOT) 1 New generic concept Online Review OK with changes ConsolidationOpen Issues PIC Scheduling PIC Meeting Open Issues Owner corrects open topics + informs coach Sign-Off Phase Not OK Coach checks + set status in ARIS OK Creation of BO in ESR by Owner Save all review documents SAP wide Review (only PIC 1 + 3) Document Accepted? Check by AP OPS Change Request IE informs AP Ops about Change Request BO finally approved

16. BOT Governance Process for New Generic Concepts PIC Governance Process BOT Governance Process Creation/Change of BO in Aris (english) according to guidelines Topic Owner PIC Reviewer:New generic concepts Integration Expert:Critical methodological topics Request for BOT New generic concept BOT (Methodology Council) eSOA Guideline Further occurrencesof new concept First occurrenceof new concept Online Review Offline Review by IE + KM + Coach PIC Scheduling PIC Meeting Open Issues BO finally approved

17. Alignment in AP and between AP and BS AP Stefan Kaetker Michael Seubert Günter Pecht-Seibert Info about Topics with Modeling Impact Process Modeling, PIC 0 BOT / BOWPIC 1-3,GDT ANT Info Highlights, Escalation path Stefan Kaetker (sponsor) Klaus Enders (operational lead) SAP aligned (AP + BS) Alignment, if SAP relevance Alignment, if SAP relevance SDMC Business Suite Horst Schnörer Bernhard Drittler PIC 0,1-3 Enterprise SOA Architecture Team

18. BO PIC Governance: Focus on PIC1-3 The PIC Governance Process is ARIS based. That means, all PIC relevant content must be modeled in ARIS. Preparation • BO must have PIC0 approval and must be part of the BO Map in ARIS • “Change Request” for changes and for new models must be submitted by the content owner and must be approved by the management. (see guideline://dwdf029/Ap_eng/Content_Governance/10_Business_Object_Governance_&_Coaching/20_Organization/Model_Consistency/Model_Change_Request_Guideline_v1p2.doc) Starting the review • Integration Expert checks whether BO is suited for review and requests the review in the "Workplace" tool(see guideline: //dwdf029/Ap_eng/Content_Governance/10_Business_Object_Governance_&_Coaching/20_Organization/ARIS/Initiating_PIC_reviews_Guideline.doc) • AP Operations sends mail with review information to all persons involved in review BO review • Questions/discussion takes place in Q&A-Excel • All changes are made directly in ARIS and are documented in Q&A-Excel (not in word document!) • Each reviewer can classify his topic according to prio • Prio 1 critical: architecture or concept not clear, immediate clarification required • Prio 2 to be solved: architecture or concept clear, changes have to be done • Prio 3 comments: suggestions, nice to have • Only the reviewer can set the status to “done” Sign Off • Each reviewer must set the sign-off status at due date latest • Overall status derived by AP Operations depending on reviewer sign-off, status will be set in ARIS • Not OK: AP Operations schedules the BO for online PIC (at least one reviewer status “Not OK” sufficient) • OK with changes: BO Owner closes open topics and informs Coach when finished • OK: Freeze of BO in ARIS, AP Operations starts SAP-wide review • Coaching Team checks general integrity and plausibility of discussion • If all open topics are closed by BO Owner, the Coach can set the sign-off status from "OK with changes" to "OK“ if necessary.In addition the Coach added a comment in the sign-off excel: "All topics closed. Status set to "OK" by Coach"

19. PIC Review Documents: Version Handling (1) • ARIS does not support versioning • at start of PIC 1-3 process an initial document for the BO is created (documentation is generated via ARIS Report) • For each review step a “delta” word document between current review version and initial document is created by AP Operations. • This “delta” document contains the marked changes and is basis for the review (see yellow bars in next slide) • After a PIC 3 review took place (complete approval) an new initial document is created and used to create the “delta” word document  Consequence: All changes since the last PIC3 approval are marked in the “delta” document until a new PIC3 approval exixts.

20. PIC Review Documents: Version Handling (2) Initial Document New Initial Document Review Document 1 1+2 1+2+3 Changes: preparation PIC1 Review PIC1 postproc. preparation 1 1 + 1 .. .. PIC 1 preparation PIC2 Review PIC2 postproc. 2 2 + .. PIC 2 .. preparation PIC3 Review PIC3 postproc. SAP wide review 3 3 + PIC 3 .. Q & A Doc .. changes in ARIS changes in ARIS changes in ARIS: To be documented in Q & A time review cycle

21. BO PIC Governance Process Type • Normal: • Standard PIC review process as described • Lean: • Same process as for “Normal”, but only CT as reviewer involved • Used only for small changes due to new or different functionality which are modeled completely according to guidelines • Lean Fast Track: • Same process as for “Lean”, but only 2 days review time • Used only for adding new elements based on existing GDT, no new concepts • coach has veto right, if prerequisites not fulfilled -> change to a normal review possible • Bug Fix: • Same process as “Normal”, but only CT as reviewer involved • Used for errors in the model or in implementation (with impact to model) which are modeled completely according to guidelines

22. Governance for Business Objects and Operations Additional Governance Rules

23. MDRO Governance • MDROs must be approved by PIC 0 (handling should be “as lean as possible”) • no PIC1–3 review any more  the application itself is responsible for modeling according to the MDRO Design patterns (see the following guidelines) • BO Modeling Guideline • MDRO_Documentation_Pattern_EN.doc • Mass, Background, and Parallel Processing (MBP) • New „MDRO Check“ by Coach • The coach only checks that the MDRO corresponds to the MDRO pattern, that is: • Standard structure and standard formulations for • MDRO, Nodes, Elements • Core Service Queries and Actions • Relationships • Data Types MDRO must not contain any new concepts  this is only a check not an approval! • The check result is “MDRO Check o.k.” or “MDRO Check not o.k.” • In case of “MDRO Check not o.k.” an online PIC is scheduled • MDRO Checks are requested like PIC review requests via the BO_PIC_ARIS Excel file • MDRO Check lasts 2 days • Also change requests of existing MDROs are handled via this process

24. Technical Object Governance • Like governance for BOs with the following special rules • Because of the nature of TecOs, terms in the model entities as well as the used GDTs are allowed to be technical • Be aware to use technical terms only when they are needed to express the subject matter of the TecO • Explain terms that are not common known in a comment • Combined review for PIC1 – PIC3 is possible

25. Additional Governance Rules for Message Types All kind of Message Types (B2B, A2A and A2X) are maintained in ARIS and reviewed in the PIC review process.(Except A2X message types which are generated by a tool) • The following documents have to be provided in preparation folder (Link) • MessageType Word document, provided by AP Operations • The document ist generated from ARIS with report “AP_MT_MessageTypeDocumentation” • MessageType Excel document (structure and mapping to involved BOs), provided by Owner • The Message Type structure excel is generated from ARIS with report “AP_MT_ElementStructure” • Naming Pattern of Excel-File: <MT-name>_Vxx_MT_ELStr_YYYY-MM-DD.xlse.g.: PurchaseOrderRequest_V17_MT_ELStr_2008-08-19.xls • The Owner also provides the mapping to involved BOs in the generated excel • use the excel macro Message Type Mapping Macro to copy the already existing mapping from an “old” Message Type Excel into the “new” generated one. • Owner informs Steffen Wolf (D040280) from AP Operations via e-mail that the excel is provided • Starting of PIC Process via leading Business Object

26. Additional Governance Rules for Form Message Types • For a Form-MT the same deliverables and governance rules apply as for non-Form MTs, except that: • Lean PIC Governance Process is used, because a Form-MT bases on existing A2A/B2B MTs. The basic concept are already approved. • Currently all changes to a Form-MT have to be considered as incompatible for the Adobe form rendering engine, therfore: • Before submitting a change request for an existing Form-MT, the integration expert has to present a written acknowledgement by Forms Development (contact: Li, Patrick) that the changes are accepted (mail is obligatory and stored in the review folder, sufficient for a lean review) • For a normal PIC review (for major changes of a Form-MT or a new Form-MT) Forms Development (contact: Li, Patrick) will take part on the reviewIntegration expert informs AP Operations (contact: Wolf, Steffen) via mail, to start review with Forms Development participation • Only Form-MT for “Backend output” are PIC relevant”Backend output” is part of a business process. Only consistent data can be output. The output is automated and tracked in the backend system. The form data is retrieved in outbound process agents. Backend output can only be implemented in AP layer. • Interactive Form-MTs are Form-MTs, so the same deliverables and governance rules as for Form-MT apply. Additionally: • In case of split of an (incoming) interactive form message an additional mapping must be approved as described in the following slides

27. Interactive Form Message Split For example, ProductAvailableToPromiseUpdateNotification Message (Type A) Switch /Split Interactive Form Message Message (Type B) For example, Customer Requirement Fulfillment Confirmation for example, Interactive FormCustomer Requirement Fulfillment Request Message (Type C) For example, Customer Invoice Request Request

28. Fulfillment In Fulfillment Out Customer Requirement Fulfillment Confirmation IForm Customer Requirement Fulfillment Confirmation Customer Invoice Request Request ProductAvailableToPromiseUpdateNotification Example: Form Split in A2A Scenario with Partial Use Sales Order Processing IForm Customer Requirement & Outbound Delivery Processing IForm Customer Requirement Fulfillment Request Switch /Split Sales Order Customer Requirement Out Customer Invoice Processing Request Invoicing in

29. Additional Mapping for Interactive Form Message Split (1) Mappings Message Structure C Message Structure Interactive Form Message Structure A Message Structure B • Mapping to be approved in PIC3 • Mapping defined in Excel of Interactive Form • Mapping • Only projection from interactive form allowed • Only simple transformations allowed, besides “pure” element mapping (to check in review!) • Application that defines from is responsible for consistency

30. Additional Mapping for Interactive Form Message Split (2) No completion/enrichment of split messages with additional information: Split message contains only information from Interactive Form ! CustomerRequirementFulfillmentRequest InteractiveFormCustomerRequirementFulfillmentRequest ProductAvailibilityToPromiseUpdateNotification Submit „ATP Confirmation“ CustomerRequirementFulfillmentConfirmation Submit „Delivery Confirmation“ CustomerInvoiceRequestRequest 

31. Additional Governance Rules for Business Object Extensions ARIS currently does not support Extensions.Therefore Extensions are handled via document based PIC Governance Process, that is: • Word document contains the delta information (see pattern) which has to be provided in preparation folder (Link) by the Owner of the extension • Please inform Steffen Wolf (D040280) from AP Operations via e-mail that you have added the documents. • Consistency of multiple extensions for one BO has to be checked by BO-Owner • Initiation of PIC Process via Excel BO-PIC-ARIS (Link) • Add row • Add name of Extension (column D): <BO name><Extension name>_Extension e.g.: PersonnelChange_Template_CN_Extension • Add “date of entry” and set “Extension” in Request column of excel sheet.

32. Additional Governance Rules for Data Flow Verification (DFV) ARIS currently does not support Data Flow VerificationTherefore DFV is handled via document based PIC Governance Process, that is: • DFV info is part of the excel sheet with Message Type (MT) structure • Special columns and special sheet for Data Flow Verification added to MT Excel by Coaching Team • Owner gets link to the prepared MT excel sheet via email • Attention: please edit the excel on the public folder (from link in email), do not edit local copies • DFV content is filled in prepared MT Excel by Owner • Link to DFV excel has to be provided by owner in preparation folder (Link) • Please inform Steffen Wolf (D040280) from AP Operations via e-mail that you have added the documents. • Starting of PIC Process via Excel BO-PIC-ARIS (Link) • Search DFV Pair in the Excel (all DFV pair start with DFV_) • Add “date of entry” and set “PIC3” in Request column of excel sheet. For further information please refer to the folder (Link)

33. Governance for Business Objects and Operations Governance for Alignment of B2B / Level 3 Services

34. eSOA Cooperation Model Business Suite / AP • Strong cooperation about methodology aspects. • Keep methodology in sync via bi-weekly Methodology Council • Loose coupling for content • Do not block agile projects for content development on both sides • Focus content alignment on PIC 0 level; PIC 1-3 alignment only for BS “Level 3” services (B2B, key A2A services, shared service center integration) Joint Steering Committee(NW, Biz Suite, AP, evtl. B1) Joint PIC 0 Review (to validateLevel 3 Services) Definition of Service Bundles for eSOA by Evolution PIC 0 in Business Suite PIC 1, 3in Business Suite Decision Full scope service enablement for eSOA by Design PIC 0 in AP PIC 1,2,3in AP Alignment For Level 3Services Joint Methodology (Modeling, Service Pattern, Lifecycle Management) Via Service Definition Methodology Council (SDMC)

35. Underlying assumption: AP BO Model represents the future SAP BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible • Approach: Keep Kernel aligned and allow solution specific extensions • For all Level 3 services: Mapping has to be provided (“the 2nd is in charge to def. mapping”) • Currently only very few objects in Kernel; grow over time on demand  manageable effort • Joint Governance of SAP-wide BO Kernel within AP Process Principles: Signature Alignment for Level 3 Services Enterprise Service Repository BS Business Object ModelsSol. spec. Extensions Level 3EnterpriseServicesrealized in BS Other SAP Solutions SAP-wide BO ModelKernel(smallest common denominator) Kernel Kernel copy inBS BO Model Mapping for relevant servicesalong integrationscenarios must beprovided SAP-wide BO ModelKernel(smallest common denominator) Transformation(Projection ++) EnterpriseServicesrealized in AP AP Business Object Models Kernel

36. 100 % down-to-field level identical services not feasible • Approach: Keep Kernel aligned and allow solution specific extensions • For all Level 3 services: Mapping has to be provided (“the 2nd is in charge to def. mapping”) • Currently only very few objects in Kernel; grow over time on demand  manageable effort • Joint Governance of SAP-wide BO Kernel within AP Process PIC 0 in Business Suite Define and align SAP Core PIC 0 in AP PIC 0 Alignment Process PIC 1-3 in Business Suite PIC 1-3 in Business Suite eSOA Cooperation Model with Business Suite Level 3 Services Align BO & PC cut (Coaching Teams only) Validate Level 3 ServicesS.Kätker; B.Drittler; M.Seubert; AP IE; Suite IE SAP wide alignment required and feasible? No Yes SAP Core: Projection based on AP Object Model M.Seubert; B.Drittler; AP IE; Suite IE (PIC 1-3 in AP) B2B Service B.Drittler; M.Seubert; Suite IE; AP IE Extensions required? Yes B2B Service with extensions based on SAP Core B2B Service labeled with suffix B.Drittler; M.Seubert; Suite IE; AP IE

37. Join PIC 0 Review Joint PIC 0 for AP/A1S and Suite in the following cases • B2B Services, • Key A2A Services for • Integration to 3rd party • Shared service center • AP/Suite Adoption Escalation handling if issues in PIC 1-3 occur Bi-weekly, one per month in Rot, one in WDF • IE requests Joint PIC 0 review after successful local PIC 0 • Agenda send out 2 days in advance • Operations to be handled by Michael Ottenstein

38. Governance for Business Objects and Operations Milestones and Deliverables

39. Milestones: Four Step Approach for PIC Council Approval PIC 0: Business Objects and Operations Identification PIC 1: Node-Structure for Business Objects PIC 2: Node Data Types for nodes PIC 3: Final definition for Business Objects and Service Interfaces / Operations Detailed definition containing all elements and integrity constraints How to … … described in guidelines

40. Approval Topics BO • Name • Definition • Nodes and structure • Node elements typed by GDTs • Integrity / Constraints / Business Rules • Interfaces • Compound Operations • Core Service Actions (business semantic) • Core Service Queries GDT • Name • Definition • Structure • Value Ranges PIC 1 PIC 2 PIC 3 PIC 1,5

41. BO Documentation • - Definition • Nodes • Associations • Elements • Integrity • - Actions • Queries • Service Operations BO Elements Structure Deliverables for BO PIC Council Approval A pattern based generation out of the ARIS system of the needed documents is provided (Please see ARIS report AP_BO_BusinessObjectDocumentation) The document generation covers: • BO Structure • Visualisation of BO node structure • BO Documentation • Semantic (Definitions), Structure (node elements) + Integrity, Behavior (operations, actions, queries) • Based on template • BO Node Elements • Detailed structure of BO nodes • Based on Global Data Types • Error free ARIS content • Execute ARIS check report “SAP_CheckFrameworkAdhocCheck” • no errors for submitted content are allowed

42. Milestone 1: BO Structure (PIC 1) PIC Council: Approval for BO Structure („PIC 1”) • Requirements • BO Structure (Graphic) • BO Documentation • Check, acceptance and “Go” by Integration Expert • Activities • Review and sign-off by integration experts and coaching team • Open topics from sign-off: Presentation by integration expert / BO owner in PIC Council: Review and acceptance • Result • Release for SAP-wide Review Generated from ARIS via “Documentation-Report”

43. Requirements PIC1 (Detail): BO Structure • Visualisation of BO structure • Semantic understanding of BO • Uniform representation “SAP Serm/UML Plus” • Contains • Packages • Nodes / Subtypes • Compositions / Aggregation / Associations

44. BO Documentation • - Name • Definition • Process Component • LDU (opt.) • Packages • Nodes / Subtypes • Compositions / Associations • Integrity • - Business Object Environment • Node Element Structure • Interfaces / Operations Requirements PIC1 (Detail): BO Documentation • Business Object • Business Object Name • Business Object Definition • Process Component • Logical Deployment Unit (optional) • Business Object Capsule • Packages • Nodes / Subtypes • Associations • Integrity • Business Object Environment • Association from • Business Configuration Objects (tbd) • Business Foundation Objects • Business Transaction Objects • Node Elements Structure • Interfaces / Operations • Actions • Queries • Compound Services / B2B/A2A, Inbound/Outbound

45. Milestone 2: BO Node Elements (PIC 2) PIC Council: Approval for BO-Node Elements („PIC 2”) • Requirements • PIC1 • BO Node Elements (Assembly of GDTs) • Definition of node elements in BO documentation • GDTs approved by PIC Council or lean approved by coaching team • Check, acceptance and “Go” by Integration Expert • Activities • Review and sign-off by integration experts and coaching team • Open topics from sign-off: Presentation by integration expert / BO owner in PIC Council: Review and acceptance • Result • Approved node structure • SAP-wide availability for use

46. BO Elements Requirements PIC2 (Detail): BO Node Elements • Assembly of node elements • Elements belong to/describe nodes • Structure of Node Elements • Only 1:c or 1:1 • Element Names • Element Definitions • Based On Assigned Global Data Types

47. Milestone 3: BO Service Operations (PIC 3) PIC Council: Approval of Service Operations („PIC 3”) • Requirements • Full business object structure, semantics, integrity (PIC 1 & PIC 2) • Process Components with the Process Interaction Models are well defined • Interfaces / operations identified and named • Complete business object document with service operations • Message type document (for message types derived from this BO) • Check, acceptance and “Go” by Integration Expert • Activities • Review and sign-off by integration experts and coaching team for all operations (without C,R,U,D operations) • Presentation of open topics from sign-off by integration expert / BO owner in PIC Council: Review and acceptance • Result • Release for SAP-wide review

48. Document based integration: Message Type and Operation Signature • The Structure of the Message Type is derived from the „defining BO“ („leading BO“) • Defining Business object of MT can either be source object or target object (or a third one) • The operation signatures of the source and target objectare specified according to this MT structure.

49. Requirements PIC3 (Detail): Service Operation Documentation (1) • Complete business object document (according to pattern) • Compound Service Interfaces • Semantic definition, naming according to naming conventions • Compound Service Operations • Behavior: ( Inbound or outbound specific) Semantic definition of what the operation offers,it‘s effects and integrity / preconditions • Note: Semantic definition of operation and MT are identical except for Inbound / outbound information • Structure:Detailed definition of signature is described (incl. element structure) in message type document • Note: It is based on / linked to the defining object • Mapping of BO node elements and message data type (MDT) elements if BO is not the defining BO of operation • List of Elements of MDT not yet covered by BO

50. Requirements PIC3 (Detail): Service Operation Documentation (2) • Complete business object document (continued) • Core Service Actions • Semantic definition with business focus • Business pre and post conditions • Detailed description of what action does (effect on nodes) • Core Service Queries • Semantic definition • List elements used in query Comment: • Status & Action management (S&AM) will be later included in document. • S&AM is not part of PIC1-3. • Coached by Frank Michael Kraft • Query Response Transformation Nodes (QRTN) are nodes of a BO but their structure is build for and motivated by a core query. Therefore QRTNs are part of PIC3