Part 2 of Blog Series – An in depth look at enterprise SOA
This blog will help you understand service modeling and service definition capabilities in the Enterprise Service Repository. Modeling capabilities empower enterprise service architects to have a holistic view of the analysis, design and architecture of service oriented assets. Enterprise service architects can now use service modeling disciplines to provide strategic and tactical solutions to enterprise problems. Through modeling, architects focus on design, ensuring reusability, naming conventions, and scalable interaction and integration scenarios.
In this blog and narrated recording I will focus in describing step-by-step how to model process components and define service interfaces in the ESR. This blog does not cover any in-depth material in Service Modeling Methodology please refer to TechEd sessions (SOA-223) to understand what modeling principles and approach should be consider before service modeling.
Service interfaces defined in this blog will be provisioned and consumed in ABAP and Java in later blogs of this series.
Let me start by introducing a simple scenario that will set requirements for all process components to be modeled.
Every time a new contract is signed between a vendor and a company, personnel from the Contracts department need to execute the following tasks:
- Search for vendor records to validate contract
- Enter new vendor information if no record is available
Contracts and Partners are the two business units involved yet neither have the process components, business objects, or service interfaces needed to complete the task. An enterprise service architect will need to model inbound operations to process vendor information such as search or create. Outbound operations from contracts must also be created to notify that a new partner needs to be created (Vendor Create) or to check if a Partner exists (Search Vendor). Using the ESR a Process Component Interaction Model will be created. Interaction models show interactions between two processes components.
Here is summary of the two process components that will be modeled:
Process Component: Contracts Processing
- Business Object: Contracts
- Service Interface: ManageContractsApproval – Outbound
- Operation: Notify New Contract Partner – Asynchronous. . Notifies back-end systems that a new Partner contract is approved and sends Partner information. In this scenario partner data sent to back-end systems is the same as create vendor.
- Operation: Check Contract Partner – Synchronous. Checks if the existing partner is already in the system by sending a Vendor Number and Country Code.
Process Component: Vendor Processing
- Business Object: Vendor
- Service Interface: ManageVendor – Inbound
- Operation: Create Vendor – Asynchronous. Creates a new vendor in the back-end system.
- Operation: Search Vendor – Synchronous. Performs a search in the back-end system and returns all vendor information.
Three message types are used, all with the same signatures as the operations.
The following narrated recording contains the necessary steps to implement a Process Component Interaction Model “EndToEndInteractionModel”
In a real scenario a company will already have process components that can be leveraged from their SAP or non-SAP systems. For Example a company might find an Interaction Model delivered by SAP. This interaction model might show interaction between Contracts Management and Vendor Management. Process components such us Vendor Processing and Contracts Processing might already be available with various Service Interfaces containing various operations. The only task remaining in this real scenario will be to create an additional operation in the appropriate process component and service interface.
As mentioned before, this blog does not cover any in-depth material in Service Modeling Methodology but I do define some modeling terms used in the recording.
A process component represents a modular independent and reusable piece of functionality.
Every process component contains at least at one Business Object. A Business Object is a logical object of significance to the business. It represents a class of entities with common characteristics and common behavior describing well defined business semantics.
A Service Interface represents the service during design time. A service is semantically described by an interface. At the end of modeling the structure defined by a WSDL file is the Service Interface.
A service interface contains one or more Operations. An Operation is the callable activity and data of the service interface
To send messages back and forth, Messages Types are assigned to service operations. A Message Type is created from Global Data Types and is basically the signature of an operation.