Glossary

Industry Solutions are an integral part of Business Function Sets that are activated by means of the SAP Switch Framework. For this purpose, the Industry Solutions were structured as business function sets consisting of one or more business functions. You can activate a Business Function Set or selected business functions according to your requirements.

Enterprise Services support industry solutions via a Business Context called Industry Classification. The Business Context is a new approach that can be used to tailor service interfaces by classifying elements of the business information interfaces. A message type of an SAP service interface comprises both the elements used across all industries, and the elements relevant for certain industries only. Which elements are used in specific industries only, and in which industries, is indicated using the elements’ Business Context: SAP assigns an industry classification to these elements (for instance Oil&Gas, Pharmaceuticals, etc.).

This industry classification ensures that industry-specific elements are only visible in application systems in which the industry solution concerned is active (in the service WSDLs retrieved from the application systems, to be precise). To use the industry business context in an application system, activating corresponding Business Functions may not be sufficient. The industry has to be activated in addition in the application system using the following IMG activity:

SAP Customizing Implementation Guide-> Cross-Application Components ->Processes and Tools for Enterprise Applications -> Enterprise Services -> General Settings for Enterprise Services ->  Activate Industries for Enterprise Services.

In the SAP ERP enhancement packages, SAP delivers global data types (GDTs) that can contain industry-specific fields. The industry classification assigned to these fields determines that the fields are only displayed in systems of the respective industries.

If you want to use Enterprise Services for industries, you must activate the corresponding industry in Customizing for Cross Application Components .

To do so, log on to the system in English and go to the SV_INDUSTRY view by calling transaction SM30. By activating an industry view, you cause the system to display industry-specific fields at runtime.You must activate the industry view for each system and each client.

An Aggregated Global Data Type (AGDT) always contains elements and may have attributes. An AGDT is derived from Basic Global Data Types (BGDT) and Core Data Types (CDT) .
An AGDT represents a complex business-related subject matter.

A software building block within an application that enables a set of department-oriented business processes or cross-functional business processes.

Application components can offer services to support these business processes. Application components are not implemented in a stand-alone manner.

This is the application component to be used when submitting a customer message for this operation in the SAP Online Service System (OSS).

A BAPI (Business Application Programming Interface) is a standardized programming interface that facilitates external access to business processes and data in the SAP System through methods for the BOR Object types. Together with the BOR Object types, BAPIs define and document the interface standard at the business level.

BAPIs are defined as methods for the BOR Object types and offer an object-oriented view of business components in the SAP system. These object-oriented interfaces allow other components to directly access the application layer of an SAP system without having to know the specific implementation details.

A BAPI Method represents a specific functionality available for a BOR Object type. The BOR Object can be accessed through defined methods.

The following statuses are available for BAPIs:

- released

The BAPI has been implemented and released by SAP and is available for consumption. Check the service documentation and SAP Notes for any limitations or prerequisites relating to the consumption of this BAPI.

Note: BAPIs in the SAP system with the Release Status “obsolete” or “not released” are not displayed on this web page.

Basic Global Data Types (BGDT) are derived directly from Core Data Types (CDT) or from another Basic Global Data Type. Hence, each BGDT is derived - at least indirect - from a CDT. A BGDT may contain Supplementary Components, but will not include elements.
A BGDT represents a simple business-related subject matter.

The object-oriented structure of the SAP system is based on BOR Object types which are listed in the Business Object Repository (BOR). A BOR Object type is the representation of a business entity, like an employee or a sales order, in an SAP System. It encompasses both the functions (in the form of methods) and the data (in the form of attributes) of this entity. In the process, the implementation details of the BOR Objects are hidden from the end user. BOR Objects can be accessed through defined functions (methods/BAPIs).

BOR Object types form the point of entry to the data and the functions of an SAP System. At BOR Object level, non-SAP systems can communicate with an SAP System, and the various SAP business components can communicate with each other.

The BOR Object ID is the internal technical key of a BOR Object type in the Business Object Repository (BOR). Business object types are identified both by their BOR Object Name (for example, SalesOrder) and by an internal, technical key BOR Object ID (for example, BUS2032). Both identifiers are unique among all BOR Object types.

BOR Object types are often addressed from external applications using the BOR Object Name, whereas within the BOR Objects are usually identified using the internal BOR Object ID.

The BOR Object Name is the descriptive, English ID of a BOR Object type in the Business Object Repository (BOR). BOR Object types are identified both by their BOR Object Name (for example, SalesOrder) and by an internal, technical key BOR Object ID (for example, BUS2032). Both identifiers are unique among all BOR Object types.

BOR Object types are often addressed from external applications using the BOR Object Name, whereas within the BOR Objects are usually identified using the internal BOR Object ID.

Use

Business functions enable you to selectively introduce individual functional enhancements or specific business processes into your system. Business functions are shipped with enhancement packages and have to be explicitly activated in the back-end system (transaction SFW5).

Most business functions are irreversible and as such they cannot be deactivated once they have been activated in a system. Please note that technical dependencies between the activation of some business functions may exist.

If an enterprise service has been delivered as part of an enhancement package, you must activate the relevant business functions in the Switch Framework to make the enterprise service available in your system.

More Information

• For more information about business functions, see the documentation on SAP Help Portal at http://help.sap.com . The business functions are described in the SAP Library documentation for the respective SAP application (for example, SAP ERP) under Business Functions ( SAP Enhancement Package ... ) .
• For more information about the technical prerequisites for business functions and the relevant technical usages, see the Master Guide for the respective SAP enhancement package release on SAP Service Marketplace at http://service.sap.com/instguides .

Business maps help companies focus on the core processes and functions that can increase their ability to compete, strengthen their relationships with partners, and help their companies become closely oriented to the markets and customers that they serve.

There are two kinds of business maps, each providing a different perspective of the processes that support a successful e-business:

• SAP Solution Maps provide a consistent, multi-level blueprint showing processes for an organization within a particular industry or cross-industry. The SAP Solution Maps also show how various processes are covered, including the processes that SAP and its partners support. This content is available for about 50 industry segments and 10 cross-industry areas.

• SAP Business Scenario Maps provide a detailed graphical view of the end-to-end processes of a key industry-specific or cross-industry business scenario. They define the activities, roles, system interfaces, and even the business documents required for collaboration.

Business maps are available for cross-industry (e.g., SAP ERP), industry-specific (e.g., SAP for Banking), and infrastructure and services/technology (e.g., SAP NetWeaver) offerings.

Business objects describe the data of a well-defined and outlined business area. Business objects are defined free of business functionality redundancies and therefore serve as the central point and basis for modeling and defining services at SAP. Business Objects represent a set of entities with common characteristics and common behaviors which in turn represent well-defined business semantics. Business Objects are generally accepted in the business world.

For example, the business object Purchase Order is a request from a purchaser to an external supplier to deliver a specified quantity of goods, or perform a specified service, at a specified price within a specified time.

The Change/Update Behavior  field defines how this operation changes the business object data in the back-end system. There are three possible update types:

• Type 1
  Data transferred by request messages completely overwrites corresponding objects in the back-end system database. The back-end system expects a value for all elements that are found in the structure of the message type. This also applies to elements that are designated as optional in the message structure.

See also: Change / Update Behavior Type 1

• Type 2
  Data transferred by request messages only overwrites objects in the back-end system database that are filled in the message structure, with the exception of list-type elements.

See also: Change / Update Behaviour Type 2  

• Type 3
  The operation updates the database fields for a business object only if the corresponding elements are explicitly contained in the incoming request.

See also: Change / Update Behaviour Type 3

A Core Data Type (CDT) is defined in the UN/CEFACT CCTS standard as the smallest building block in the data modeling hierarchy. CDTs are based on W3C data types and do not represent any business semantics. CDTs represent the unambiguous atomic business information components that are used as the basis to build from primitive data types (binary, date, decimal, integer, string) to more detailed simple and complex data elements, up to and including a complete business document. CDTs are limited to a single business meaning, such as - amount, binary object, code, date time, identifier, indicator, name, measure, text. In data modeling terms, CDTs define the value domain for CCTS Basic Core Components (BCC). They can be used without restrictions (unqualified) or further restricted (qualified) to refine the value domain for contextualized Basic Business Information Entities (BBIE).
For more information see the article How to Solve the Business Standards Dilemma - The CCTS based Core Data Types  on SDN.

A deployment unit groups process components that interact with each other and which are to be installed together on a system. The deployment units show the type of interactions required between the process components within the deployment unit. The process components can be operated and installed separately.

The direction of an operation can be either inbound or outbound .

An inbound operation in an application system can be called by a consuming application.
An outbound operation is triggered in the application system and sends a response to a consuming application.

Enterprise Services Bundles (ES Bundles) document the comprehensive portfolio of business scenario descriptions that are SOA-enabled by solutions and enterprise services shipped by SAP. ES Bundles describe the impact of SOA on business processes provided in SAPs business solutions. Each ES Bundle refers to a set of enterprise services that support a particular business process and are made available as part of the SAP Business Suite solutions.

The documentation of an ES Bundle provides:

• exemplary use cases of how enterprise services help implement certain business process steps
• documentation of how to extend and reconfigure processes in a business scenario
• explanations of the relevant business scenario, processes, and roles involved
• guidance on which enterprise services to invoke
• supports with the design of composite applications using SAP NetWeaver's enterprise services development and modelling tools

An ES Bundle is a logical grouping of a collection of enterprise services describing different use cases within a specific business scenario. However the ES Bundle itself is neither a pre-packaged installation, nor an installable entity nor can an ES Bundle be configured or activated. The Enterprise Services documented in an ES Bundle are implemented in (and shipped within) the software components you install on your system and as such they are already available in your backend after an enhancement package installation. Please note that some enterprise services are only available after their respective Business Functions have been activated in the system.

This is the SAP R/3 release with which the BAPI Method was first shipped. The BAPI is available in this release and all higher versions.

Note:  The documentation of the BAPI displayed here applies to the BAPI version shipped with the latest Business Suite 7 Version. The functionality of this BAPI may differ in previously shipped releases. If you plan to use an older version of this BAPI from an earlier release, please refer to the documentation for the respective release to check the release state and whether the features you require are supported.

This is the Software Component Version with which the operation was first shipped. The operation is available in this software component and all higher versions. A software component version is a shipment unit for design objects in the Enterprise Services Repository.
The Software Component Version is shipped as a component of a Product Version. A software component version can be used in different product versions.

Note: The documentation of the operation displayed here applies to the operation version shipped with the latest Software Component Version. The functionality of the operation may differ in previously released Software Component Versions. If you plan to use an older version of this operation from an earlier release, please refer to the documentation for the respective release to check the release state and whether the features you require are supported.

Forward Error Handling

Forward Error Handling (FEH) is a concept that enables errors, detected during the execution of asynchronous services to be processed on the provider side. This concept is implemented using the Error and Conflict Handler (ECH).

Motivation

Asynchronous communication implies that the service consumer cannot react immediately to error messages returned by the provider. Delegating error removal back to the consumer is often inefficient or inappropriate.

• If the service is uni-directional (inbound notification and information services), no response message is foreseen in the consumer-provider interaction.
• If the service is bi-directional (request-confirmation or query-response pattern) it often makes sense for the provider to resolve errors and conflicts on the provider side, without returning an error message to the consumer.

Examples :

The error is temporary and would disappear automatically if the message were to be processed again at a later point in time. For example, the object to be changed is temporarily locked by another user, or another message needs to be processed first.

If a product is not available, the service provider might want to respond with an alternative offer in order to retain the customer.

Using the standard messaging channel to communicate errors back to the sender and ask for clarification would take too long – it would be more helpful to use the phone or another synchronous medium.

ECH Framework

The ECH Framework is available in the SAP back-end system.

Errors that are handed over to the ECH Framework typically occur during data conversion or business logic processing. ECH enables administrators or even business users on the provider side to follow up on error messages. In SAP Business Suite 7, you can use transaction ECH_MONI_SEL to search for and access error cases. You can also access this transaction from the SAP Easy Access menu by choosing Cross-Application Components --> Error and Conflict Handler .

The resolution process depends on the type of error. An error may be resolved automatically, resolved manually, or rejected and delegated back to the consumer.

• Automatic Resolution : The system retries processing or automatically rejects the request .
• Manual Resolution : An administrator or business user corrects the error (for example, by correcting the request, correcting Customizing settings, or entering transaction data), and restarts processing. If an error cannot be resolved by the provider, the user can call the sender and ask for the request to be corrected.

The ECH Framework classifies errors into error categories. Examples include:

• Conflict, restart not possible
• Authorization error; manual restart possible
• Lock request error; automatic or manual restart possible
• Value error; manual restart possible
• Internal term error; manual restart possible

You can define a resolution strategy individually for each error category.

To make use of the ECH capabilities, you must first activate and configure the ECH Framework in Customizing:

SAP Reference Implementation Guide -> Cross-Application Components -> Processes and Tools for Enterprise Applications -> Enterprise Services -> Error and Conflict Handling .

The Function Module is the implementation of the BAPI method. You can access the Function Module in the Function Builder, Transaction SE37, of the SAP System.

The SAP GDT Catalog is the complete documentation of all Core Data Types (CDT) and Global Data Types (GDT) defined by SAP. See the complete  SAP GDT Catalog available on SDN.

A SAP Global Data Type (GDT) is a SAP-wide unified data type representing business-related content built according to the UN/CEFACT CCTS standard. The ISO 15000-5 CCTS (Core Components Technical Specification) developed by both the UN/CEFACT and ISO provides a methodology for semantic data modeling that achieves a common understanding of data structures and message types on a syntax independent level. SAP supports ISO 15000-5 CCTS for defining the SAP Global Data Types (GDT) as a basis for Business Objects and Enterprise Services in order to provide the highest level of semantic interoperability between SAP and non-SAP applications.

See also  Core Data Types (CDT) and GDT Catalog  in this glossary.

For more information visit the SAP Global Data Types (GDTs) Wiki .

Features

This function is available with SAP NetWeaver 2004s SP09 and ECC-SE 600 SP03.

In business scenarios, reliable message transfer is required. It must be guaranteed that a message sent to the receiver to modify an object state is processed exactly once (EO). For example, if a new purchase order is to be created via a service invocation it is not acceptable to either have no purchase order created, or to have one or more duplicates created. In the case of asynchronous services, the XI 3.0 protocol guarantees reliability. However, in synchronous communication there is no intrinsic mechanism to guarantee that a sent message arrives at the recipient, or that a request is processed exactly once by the recipient. A message may be lost, or may arrive several times, due to network problems. Even if a request reaches the provider, the response may be lost during network transport, in which case the consumer might assume that its request did not arrive and would resend it.

To avoid inconsistencies in the provider or consumer system, the relevant SAP Enterprise Services are implemented as idempotent. If an idempotent service receives exactly the same request message multiple times within a limited time frame, it will process it only once and return the original response. The restriction to a limited time frame is necessary to avoid overloading the database, as the system must store the original response message within the specified time frame.

Prerequisites

There are two prerequisites for employing services as idempotent services:

1. Service consumers must use the MessageHeader element and its sub-element UUID in the services’ request messages.
   The UUID values must be globally recognizable and satisfy the format that is specified in IETF RFC 4122 ( http://www.ietf.org/rfc/rfc4122.txt ). If you do not use the element when you call the services, the services do not behave in an idempotent manner. When developing consumers using Java, UUIDs can easily be generated using the class java.util.UUID. When developing consumers in ABAP, use function module GUID_CREATE followed by the method call CL_GDT_CONVERSION=>GUID_OUTBOUND. Note: The GUIDs used internally in ABAP systems do not satisfy the UUID format.
   
2. Before calling the idempotent services, the underlying framework has to be configured, including the time frame for which the system keeps responses for already processed service calls.
   See Cross-Application Components -> Processes and Tools for Enterprise Applications -> Enterprise Services -> General Settings for Enterprise Services -> Define Settings for Idempotent Services in the SAP Reference IMG.

If these prerequisites are met, a consumer can safely re-send request messages.

Note

It is important that this resend decision is incorporated in the consumer application's logic, using the appropriate consumer application code and model (or, if resend is already supported by the underlying framework, by using appropriate parameterization of the call to the framework when issuing the first service call). The decision should not be left to the consumer application’s end user. Consider the result if the end user waits for too long or decides not to retry, but the first request was executed by the service provider and only the response was lost: returning to the UI (or process) step that triggered the sending of the original request, thereby allowing an end user to manually re-trigger the communication, is not an appropriate approach. Such a re-triggering must lead to a new request, with a new request message UUID.

  

An Integration Scenario Model is defined in the Enterprise Service Repository and shows the graphical representation of the deployment units and process components involved in a cross-component business process, as well as the connections between the process components in an end-to-end scenario.

The global data type (GDT) Log contains the sequence of log messages, such as error messages, that result when an application executes a task. Almost all SAP response messages and confirmation messages include a Log element of this type.  Information contained in the Log element can be evaluated by the consumer of the service.

The value of the BusinessDocumentProcessingResultCode sub-element of a Log indicates whether a requested modification to a business document was successful or not. This tells the consumer of the service whether or not the message request was successful and if the requested modification to the service provider’s object state was performed.

Note: Exceptions are not handled by the Log but are instead handled by a fault message type.

More Information

Fault Message   

A data type that describes the structure of the message used by a particular operation. A message data type adheres to one of the following communication patterns: information, notification, query-response, or request-confirmation.

A Message Data Type (MDT) is a grouping of all elements of a message type and provides the typing for the elements.

The message header is an element in all asynchronous service interfaces and the synchronous service interfaces that implement the notification, information, or request-confirmation pattern. The underlying global data type, apart from a few exceptions, is either BasicBusinessDocumentMessageHeader or BusinessDocumentMessageHeader.
BasicBusinessDocumentMessageHeader contains information about the identification of the message. BusinessDocumentMessageHeader can also contain additional administrative data, such as the date and time at which the message was sent, the sender, and the recipient party.  

A Message Intermediate Data Type (MIDT) is a node for a group of message data elements that have a strong semantic relationship. The elements have been specifically grouped for a node and this node is not reused. MIDTs cannot be extended using the SAP Enterprise Service Enhancement Concept.

There are two principal architectures for Web service interfaces: synchronous Web services and asynchronous Web services.
These two architectures are distinguished by their request-response handling.

With synchronous services , clients invoke a request on a service and then suspend their processing while they wait for a response from the provider. The client cannot perform another task until a response or confirmation is received from the provider.

With asynchronous services , clients initiate a request to a service and then resume their processing without waiting for a response. The service handles the client request in the provider system and returns a response at some later point, at which time the client can retrieve the response and proceed with its processing.

This is the namespace in which the enterprise service has been defined in the Enterprise Services Repository (ESR). The namespace groups a set of operations within a software component version in the ES Repository.

Namespaces are used to avoid naming conflicts within object types in the ES Repository. When using design objects, the respective tools require that a design object can be defined uniquely by its Technical Name and Namespace (at least within one system).

If point-to-point communication has been enabled, you can trigger enterprise services through the Web services protocol without using a mediator (such as SAP NetWeaver Process Integration). In other words, you can configure direct communication between the consumer and provider.

To set up a point-to-point communication for asynchronous services you need to make additional settings in the SAP back-end system:

• You must activate the business function FND_SOA_REUSE_1.
• In Customizing for SAP Business Suite , choose Cross-Application Components -> Processes and Tools for Enterprise Applications -> Enterprise Services -> Point-to-Point Enablement for Asynchronous Enterprise Services.
• You use the SOA Manager application (transaction soamanger )   to set up endpoints and logical ports.

More Information

For more information about the SOA Manager application, see SAP Library for SAP NetWeaver on SAP Help Portal at http://help.sap.com/netweaver -> SAP NetWeaver 7.0 (2004s) -> SAP NetWeaver 7.0 including Enhancement Package 2. Search for Working with the SOA Manager.

Process components are the building blocks of service-enabled solutions. A Process Component is a modular, context independent, reusable pieces of software that exposes its functionalities as services. A process component contains at least one Business Object and is unique within a Deployment Unit. Process Components are designed to represent a technical grouping of business-semantically related business objects. Semantically, Process Components interact with other Process Components using enterprise services.

For example, the process component Purchase Order Processing handles purchase requests from a purchaser to an external supplier.

Use

The release state of a service is defined at service operation level in the Enterprise Services Repository. SAP uses this status to inform service consumers about the lifecycle state of an enterprise service. The following release statuses are possible:

• Released

The service has been implemented and released by SAP and is available for consumption. Check the service documentation and SAP Notes for any limitations or prerequisites relating to the consumption of this service.

• Released with Restrictions

The service is released and supported by SAP for restricted consumption only. Before consuming this enterprise service, you must check the enterprise service documentation, the SAP Release Information Note, and SAP Notes for the corresponding application version to see if restrictions and/or limitations apply to the enterprise service. SAP can change the status “Released with Restrictions” to “Released” or “Revoked”. The service itself might be changed incompatibly in one of the future support packages for the related application.

• Deprecated

A new version of this enterprise service that covers the same or enhanced functionality is available in the same software component, or in a different software component for the same product. The new version is available when the release status of the enterprise service is set to “Deprecated” in the Enterprise Services Repository (ESR).

The status of an “original” service can only be changed to “Deprecated" within a new Enhancement Package, Support Package (in the case of corrections), or product version. The deprecated enterprise service is still available and supported in the new Enhancement Package, Support Package, or product version. The functionality of the deprecated enterprise service corresponds to the functionality of the same enterprise service in the previous version. After a minimum of one full main release cycle, the ESR status of the enterprise service can be changed to „Revoked“. This means that the "outdated" and the "new" service versions are available in parallel for at least one full main release.

The link to the successor service is provided in the service documentation and in a Composite SAP Note. Any adjustments or potential migration efforts are described in the Composite SAP Note.  

• Revoked

The enterprise service implementation is still in place, but the service is no longer supported by SAP.

If an enterprise service is flagged as “Deprecated”, the ESR Release Status can be changed to “Revoked” after a minimum timeframe of one whole main release.

Note : The definition of the service operation may still be available in Enterprise Services Repository (ESR), in the ABAP proxy objects, and in the Web service. However, SAP no longer supports the usage of this enterprise service and strongly recommends that you replace it with the successor service. 

More Information

For more information about the release state of an enterprise service, see the documentation on SAP Help Portal at http://help.sap.com . The release states are described in the SAP Library documentation for SAP NetWeaver Process Integration 7.1.

Definition

In the United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT ) Core Component Technical Specification (CCTS), the identification context of an identifier or a code is defined by supplementary components. The supplementary components may also be referred to as the attributes of an object ID or code. Identifier and code values are unique with respect to such a scheme. The values of these attributes are filled at configuration time or runtime.

Examples

• Standard Identifier/Standard Agency:
  <ProductID schemeID ="GTIN" schemeAgencyID="113">10614141000415</ ProductID>
• Proprietary Identifier/Standard Agency:
  <ProductID schemeID ="householdappliance" schemeAgencyID="310">123</ ProductID>
• Proprietary Identifier/Proprietary Agency:
  <ProductID schemeID ="householdappliance" schemeAgencyID="anyURL.com ">456</ ProductID>

Identifier Supplementary Component Attributes

•  identifies the identification scheme for the identifier.
•  the version of the identification scheme in case of identifier supplementary components.
• 
  

Code Supplementary Components Attributes

• listID identifies the code list of the code.
• listVersionID identifies the version of the code list in case of code supplementary components.
• listAgencyID

The following types of identifiers and codes can be represented by the corresponding AgencyID:

• Standardized scheme or list managed by an agency from the DE 3055 code list (excluding roles).
• Proprietary identifiers or codes whose scheme or code list is managed by an agency that is identified using a standardized ID.
• Proprietary identifiers or codes whose identification schemes or code lists are managed by an agency that is identified by a proprietary identifier.
• Proprietary identifiers or codes whose identification schemes or code lists are managed by an agency that is specified using a role, or by an agency that is not specified at all.
  The role is specified as a prefix in the tag name. schemeID and schemeVersionID can be used as attributes if there is more than one identification scheme; no attributes are required if there is only one identification scheme.

Note
Where the defining agency is a standard agency from the DE3055 code list, the supplementary components are filled by SAP. In general, internal identifiers are not defined by SAP.

Services created by SAP are categorized according to the main purpose of the messages being communicated.

The following service categories exist:

Application-to-Application (A2A)
A2A services facilitate the exchange of business information between different applications to connect business processes, within company borders.

Business-to-Business (B2B)
B2B services facilitate the exchange of business documents across company borders.

Application-to-Cross Application (A2X)
A2X services facilitate the exchange of business information between an application and an unspecified client. They are often used to build user interfaces (UIs) based on the back-end, without an intervening communication layer. For this reason, A2X messages contain all the necessary information for understanding the message, such as code names or texts to be displayed on the UI.   

Service interfaces are named groups of operations. A service interface belongs to exactly one process component, whereas a process component can contain multiple service interfaces. Service interfaces specify offered (inbound service interfaces) or used (outbound service interfaces) functionality. The operations and service interfaces are modeled using predefined patterns to ensure that the naming and definition of services are unified. These interface patterns are derived from the access type needed and cover the majority of use cases. Thus, service interfaces, operations, and message types are always modeled in the same
way. Interface patterns define naming rules for operations and service interfaces based on the business object and its node structure, grouping rules for the operations in the service interfaces, naming rules for the message types, and rules for the message choreography of an enterprise service interaction.

For example, the service interface Manage Sales Order In could provide the service operations Create Sales Order, Read Sales Order, Update Sales Order, and Cancel Sales Order.

Service operations are entities that perform specific tasks on a business object, for example, creating, updating, or deleting a business object. The operation is a specification of a function with a set of message types assigned as the signature. An operation is assigned to exactly one business object, whereas a business object can have multiple operations. Depending on the type of access required to the data or business object, the operations can be asynchronous (for A2A or B2B communication) or synchronous (for access from other components of the same application).

For example, the inbound service operation Cancel Sales Order can be used to cancel a real-world instance of a Sales Order business object (that is, a sales order document) in your system.

This is the Software Component Version with which the service was shipped in the latest Product Version. The service was first shipped in the Software Component Version displayed in the field First shipped with: Software Component Version.

The Software Component Version is shipped as a component of a Product Version.

Note: The documentation of the enterprise service displayed here applies to this Software Component Version. The functionality of the service may differ in previously released Software Component Versions. If you plan to use this service from an earlier release, please refer to the documentation for the respective release to check the release state and whether the features you require are supported.

The technical name is the name of the operation according to SAP´s naming conventions for enterprise services. The technical name is used for the operation definition in the Enterprise Services Repository.