1 / 44

Service Operations

Service Operations. 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

floyd
Download Presentation

Service Operations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Service Operations

  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)

  3. Service Operation Definition & Understanding

  4. Service Operation: View Concept Service Operation View • A service operation represents • a semantical view onto an object • to perform a business functionality • The view defines the operation signature

  5. From Outbound to Inbound: One Single View The same view is used in inbound operation, message type, and outbound operation Object emulates view Defining Object HugoRequest Interface OUT OP2 OP1 Interface IN e.g. PurchaseOrder e.g. SalesOrder

  6. 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.

  7. 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

  8. Service Operations Service Operation Signature: Derivation by Hierarchization

  9. Different Operations: How to Achieve Consistency ? Cross - operation consistency ?

  10. Object Model „Leading Business Object“ Environment Component Component Business Document Implementation Object ~ Object Consistent Business Documents derived from Object Model

  11. One Single View Based on a Central Object Model Document based Integration „Defining Business Object of central Object Model Component Component 2 Business Document 3 ~ Object Source Object TargetObject Inbound Operation Outbound Operation

  12. Environment „Leading Object“ Object Model Business Document Object Business Document Variants derived from Object Model

  13. Message: Message Header: BusinessDocument BusDocMsg-Header: MessageID BusinessDocument-Object: Attachment: B3 Business Object – Business Documents - Messages • Not overlapping • Net structure Business Object Model BusinessDocument Objects • overlapping • hierarchical

  14. Hierarchization: Business Document Object 2 Different cases for involving referenced business objects 1 : 1 A1 A2 Case 1: The whole object A is of relevance A A3 1 : 1 1 : 1 Case 2: In C the reverse path from C2 to C1 is of relevance X1 X2 X3 C2 C1 C X X4 B3 B4 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 B Directed relationships

  15. Level 1 3 2 4 5 1 : 1 A1 A2 A A3 1 : 1 X1 X2 X3 C2 C1 C X X4 B3 B4 B 1 : 1 Directed relationships Business Document Object: dependency level 3 Arrangement according to the degree of the dependency level

  16. Business Document Object XML Schema 1 2 3 4 5 Level Level 1 1 3 3 2 2 4 4 5 5 <X1> <A1> <A2> </A2> <A3> </A3> </A1> <X2> <X3> <C2> <C1> </C1> </C2> </X3> </X2> <X4> <B3> <B4> </B4> </B3> </X4> </X1> A1 A1 A2 A2 A3 A3 X1 X1 X2 X2 X3 X3 C2 C2 C1 C1 X X X4 X4 B3 B3 B4 B4 Directed relationships Directed relationships Hierarchization: the resulting Business Document Object 4

  17. Service Operations Service Operation Signature: Derivation by Hierarchization – Detailed Steps

  18. (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.

  19. (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.

  20. (ii) Hierarchization – Adjustment 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

  21. (ii) Hierarchization – Resulting BDO Business Document Object with Its Parts (Arranged According to Dependency Level) and Corresponding Representation in the XML Structure Object Model and Derived Business Document Object (Multiple Overlapping Views)

  22. (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“.

  23. (iii) Completion / Wrapping • Message Category • Specify the suited message category for the message type. • according to the suited transaction communication pattern.

  24. Result: Business Document • More details on the derivation rules can be found here: • ServiceSignatureDerivation_by_Hierarchization_EN.docServiceSignatureDerivation_by_Hierarchization_DE.doc • Corporate Portal > Application Platform > Engineering > Cont.Gov. > Guidelines & Documents

  25. MessageDataType: Data Model

  26. Service Operation Service Operation Definition Framework

  27. 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

  28. 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

  29. 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”).

  30. 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 standardRosettaNet, 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 bindinge.g. stored in ebXML Registry / Repository or SAP Collaboration Directory • are used mainly in business processes between enterprises

  31. Interface Category: SAP A2A Interface • Focus: complete usage of the functionality of the application • represent business-related documents • designed in accordance with the rules of international standards • contain exclusively business-related information • Can contain additional informationnot (yet) covered by B2B standards.This information is motivated by SAP applications(Content is transparent, not SAP-specifically encoded) • allow complete usage of the SAP application functionalityfrom a purely business-related point of view • Rules for optimal coupling and usage of the applications are agreed bilaterally according to need • 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

  32. 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.

  33. 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 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.

  34. 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

  35. 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.

  36. Uniform Building Blocks:Packages The packages group semantically associated information Order ... Party BuyerParty Seller Party ManufacturerParty ... ..... ...

  37. Top-Down: Identical build-up structure for all operation signatures The simple usage of the interfaces results from their uniform composition Uniform Structure via Operation Templates

  38. MessageDataType: Data Model

  39. SAP Business Objects and Service Operationsbased on GDTs and CCTS Core Data Types Business Object B2B / A2A – Interface / Service Operation n 1 1 n • PurchaseOrdering_In • PurchaseOrdering_Out • PurchaseOrder Semantic Structure Message Type Business Object Node • PurchaseOrderParty • PurchaseOrderDeliveryTerms n 1 1 1 • PurchaseOrderRequest • PurchaseOrderChangeRequest Data Typing Node Data Type B2B / A2A – Message Data Type n n • PurchaseOrderPartyElements • PurchaseOrderDeliveryTermsElements • PurchaseOrderMessage • InvoiceMessage Usage specific global • Deliery Terms • Address • ProductID Business Semantics Global Data Type n 1 no Business Semantics • Amount • Binary Object • Code • DateTime • Identifier • Indicator • Measure • Numeric • Quantity • Text CCTS Core Data Type n 1 • float • string W3C Data Type

  40. Bottom-up:uniform typing A Message Interface is a hierarchical structure. The leaves of the tree are Generic Data Types SAP-wide Uniform Typing via Normed Data Types The same subject matter is always described by the same data type

  41. 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 >

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

  43. Object Class Property Qualifier Qualifier Representation Qualifier Value Domain Datatype Naming Rules According to ISO 11179

  44. MessageDataType: Data Model and Element Structure

More Related