Web Services as a Basis for SOA

A service-oriented architecture is based on the use of Web services and therefore also the corresponding paradigms. The following graphic illustrates the Web service paradigm:

  • Creation of services in the context of service provisioning
  • Creation of a reference to the service in a services registry (optional)
  • Consumption of services in applications (service consuming/consumption)

WSDL documents describe Web services that can be stored in Web service directories. Web service providers can describe and publish their services. Users of Web services search for and use these documents.

The following list describes the interaction between Web service users and Web service providers:

  • Providing WSDLThe provider makes a WSDL description file available for its existing services, usually in a UDDI directory.
  • Using WSDLThe user searches for a Web service in the UDDI directory and downloads the corresponding WSDL file. By means of proxy generation, the user creates a function from the WSDL file, which can be called locally. The function to start with (proxy module) can carry out the creation of the XML document and the delivery via SOAP.


  • Web Service RuntimeWhen a function to start with (the proxy function) is called, a SOAP request is created on the user side and sent to the Web service. The Web service processes the request and generally returns a result. The result is then made available to the caller in a local reply.

bpm1.JPG

Web Service Support in SAP NetWeaver Application Server

With SAP NetWeaver Application Server (as of Basis Release 6.40), SAP provides a separate infrastructure for the development, publication, and use of Web services.

Components of the Web Service Framework in SAP NetWeaver Application Server are:

  • A distributed and interoperable SOAP runtime (Web AS ABAP or Java)
  • Development environment of Web AS ABAPIn the Object Navigator (SE80), Web services can be created or included.
  • Development environment of Web AS Java, the SAP NetWeaver Developer Studio
  • Tools to support UDDI registration

From a technical perspective, Enterprise Services are Web services and applications that use Enterprise Services as consumer applications.

bpm2.JPG

Definition and delivery of Enterprise Services

SAP not only provides a platform on which services can be developed (provisioning) and used in applications (consuming). SAP adds an additional aspect to the SOA concept and supplies Business Content in the form of executable Enterprise Services. Of course, SAP uses the tools of its own platform in this context.

The business functions from SAP applications are behind the Enterprise Services. The SAP applications therefore make the services available to their own applications; the implementation code of the functions is in the back end of the application and is supplied in Enhancement Packages.

Therefore, SAP delivers both an SOA infrastructure and a ready-to-run Service Oriented Architecture.

The existence of Enterprise Services provides the flexibility to respond to requirements in existing business processes (outsourcing, including new requirements) or to build new applications that comprise enterprises services from SAP, but can also use non-SAP services.

To facilitate a structured search of Enterprise Services, SAP has developed process components as logical umbrellas for business objects and Enterprise Services. There are process components for ERP, CRM, SRM, SCM and Financials.

Customers and partners can use these process components to identify and analyze existing enterprise services.

What is SAP’s definition of an enterprise service?

SAP uses the following criteria to define an enterprise service:

Criteria of an Enterprise Service


  • Modeled according to a model (use of business objects, process components, interface patterns and global data types).
  • Published in the Enterprise Services Repository (metadata).
  • Documented, stable behavior.
  • Based on open standards (WSDL, XML, SOAP, and so on).


Enterprise services process business objects and use global data types (GDTs) in their interfaces.Global Data Types are SAP’s response to a demand for semantically integrated data, which represents one of the great challenges associated with a service-oriented architecture. It is one thing to have services with defined interfaces, but it is another thing entirely for fields within the interfaces to have a mutual understanding of each other.SAP’s global data types are based on the international standards ISO 15000-5 and UN/CEFACT CCTS.An enterprise service provides a context-oriented business process logic, and business processes utilize business objects. Therefore, enterprise services belong to business objects and represent business object functions.Examples of individual services may include:


  • Check the financial status of the customer
  • Send a confirmation to the customer
  • Check material stock
  • Read customer data
  • Display sales order

Enterprise Service Workplace

You can search for services in the Enterprise Services Workplace (ES Workplace), which you will find in the SAP Developer Network at www.sdn.sap.com in the Service Oriented Architecture section.

If you, as a customer, do not find one of the services you require, you can request it from the SOA network, or you can implement the service yourself. SAP fully collaborates with customers and partners, and has initiated an SOA Community. For more information, refer to the SAP NetWeaver Developer Network at http://scn.sap.com/welcome.

bpm3.JPG

Delivery by Enhancement Package

The services are delivered in enhancement packages for SAP ERP 6.0.

bpm4.JPG


Enhancement Packages are new software developments for SAP Business Systems, which are optional to install and to activate. They follow a cumulating principle, that is, each package also includes the contents of preceding packages.Enhancement Packages are not Support Packages but rather designed to achieve the following:

  • They allow you to install functional enhancements at significantly reduced effort. Install what you need rather than everything you can.
  • Activate exactly the functions that you want to use
  • You can plan the costs of enhancements more precisely than in the past
  • You can use the test cases provided by SAP to speed up your projects and make them more efficient.

Components of SOA, created and used by SAP

As already mentioned, SAP applications use SAP’s own infrastructure for creating their own Enterprise Services.

A service-oriented architecture is a software architecture that supports the design, creation, classification, and use of standardized services. The following are key components of such an architecture:


Key Components of a Service-Oriented Architecture

  • Tools for creating services
  • Tools for storing metadata and managing enterprise services (repository/registry)
  • An infrastructure for distributing messages
  • Tools for consuming services
  • Tools in business process management


SAP NetWeaver Process Integration has two approaches in this context:


SAP Process Integration as Middleware for SOA


  1. Design timeThe metadata for Enterprise Services is saved in the Enterprise Services Repository (ESR).
  2. RuntimeThe runtime components of SAP NetWeaver Process Integration are used to call Enterprise Services.

The ESR is a further enhancement of the Integration Repository in SAP NetWeaver Process Integration 7.0.

In the service registry, customers and partners can search for services that they later call in applications (composite applications). In SAP’s service-oriented architecture, the service call can use the messaging infrastructure of SAP NW PI. However, it can also call the service in the corresponding back end directly (point-to-point) from the client application.


The administration of SAP Process Integration takes place using SAP NetWeaver Administrator.

bpm5.JPG

Interaction between SOA and the Business Process Platform

The complete view of SOA still requires the creation of applications that are based on the use of services, like the familiar Composite Applications (xApps). To achieve this, the ABAP and Java stacks provide options for development: Visual Composer, Web Dynpro for ABAP and Java, native Java programming options, programs in SE80.

This entire architecture is represented by the Business Process Platform (BPP). On the one hand, the Business Process Platform comprises SAP’s business suite, in which the applications make their functions available as Enterprise Services. However, the Business Process Platform also includes the SAP NetWeaver components because the business suite uses SAP NetWeaver as its platform. These components deliver a messaging infrastructure (SAP NetWeaver Process Integration) as well as UI-oriented components (SAP NetWeaver Portal), components for Business Intelligence and tools for Business Process Management.


Therefore, to fulfill the requirements of customers and partners, all of the functions and capabilities of the SAP NetWeaver components are available in addition to the enterprise services. Each Enterprise SOA project checks which of the resources available are best suited to resolving queries that arise.


Example: A project that has to integrate other IT systems into merger & acquisition processes essentially accesses the functions of the SAP NetWeaver Process Integration. Another project that wants to provide users with information about customers everywhere and at any time in very specialized customer-specific user interfaces may write a WebDynpro application that consumes those enterprise services that already exist. Finally, a third project that must dynamically adjust processes every second month within a one-year period accesses the orchestration options of enterprise services (business functions) within SAP NetWeaver.


To make the development of composite applications even quicker and more comfortable, SAP provides the Composition Environment, which is a development environment that bundles all the necessary functions and tools in one platform.

Use the Composite Environment for an optimized development process of composite applications.

bpm6.JPG


Composite Applications

From a business perspective composite applications (xApps) are used as an opportunity for bridging function silos of SAP applications or creating customized applications that enable you to respond to changes faster and in a more flexible way or that enable you to set yourself apart from your competitors by offering different functions.

The composite application architecture comprises several layers:

Components of Composite Applications

  • Enterprise services level
  • Localservices level with local persistence
  • User interface level
  • Process modelling level

In the process view, you define which processes are to be executed and thus determine the roles of the relevant users. You also use the process view to define the objects required by the application as well as the possible functions (services) for these objects. The systems you are using indicate where objects and their data are to be found. These are maintained in defined user interfaces.

Depending on requirements, a composite application contains some or all layers. Not every application works with local services, and not every application uses a special process logic. It is entirely possible that “only” one WebDynpro application (layer user interface) uses enterprise services to read data from back-end systems and then displays this data or makes it available to be changed.

In general, you can imagine the development process according to the following graphic.

The starting point is that a new application is to be built, which supports a desired new process flow from the software perspective. It was probably triggered by the departments who are struggling with certain process flows and want to improve them. The business requirements are collected in a specification and then used in an application design that wants to use services.

To do so, IT works with the departments to determine which services are required. If services are missing, they have to be created. SAP recommends creating customer services according to SAP-internal rules. (Modelling phase)

Once the interfaces have been modeled, you create them in the Enterprise Services Repository or generate them there. You can then generate proxies and implement the service. (Implementation phase)

The final step is to build the composite application that can integrate existing services from SAP, services from third parties, and customer services.

bpm7.JPG

Enterprise Services used to enhance SAP Applications in the Business Suite

Enterprise services cannot just be used for customer use by building customer applications. The SAP applications of the Business Suite also use Enterprise Services to enhance their functions.

Before SAP ERP became available, SAP standard software could be adapted to meet customer-specific requirements as follows:

  • Customer-specific Customizing in IMG
  • Programming of user exits or BADIs

With SAP ERP and the Enhancement Packages concept, SAP delivers the Switch Framework.

At first, the Switch Framework was designed to simplify an ABAP-based system landscape by including one or more industry solutions in a standard system.

With the Switch Framework (SFW), you can externally control the visibility of repository objects or their components by using switches. By using the Switch Framework, all industry solutions and a restricted list of repository objects are delivered together with the system in an inactive state. With a few exceptions, you no longer need to install industry solutions. You can activate them as required.

If a package is assigned a switch, you can use the switch to activate or hide the package functionality. Switches can also be activated or deactivated by higher-level switches.

Transaction SFW5 enables you to activate business functions and also to go to the documentation.

bpm8.JPG


Documentation for Business Functions

The documentation for a business function lists the dependencies with other business functions and the software components that are used.

Enterprise Services can also be activated via business functions. The documentation of a business function lists the Enterprise Services that are used.

You can use Enterprise Services in business functions to add additional functions to existing transactions. This applies in the contract account application – submit for collection for transaction FP03E (release item for collection), FP03D (submit item for collection) and FP03 (edit collection items).

Enterprise Services can also enable new transactions. In the same application, this includes FKKCOL_MONI (monitor collection services), FP03I (process collection office information), and FP03P (post receivables for collection).

New transactions (such as transaction FP03I) become visible with the activation of the business function. When called, they terminate with an error message ‘Enterprise Services not activate, function cannot be used’ if the corresponding service has not been activated and set up in the system.

Enhanced transactions (such as FP03E) show their additional scope of functions after configuration in Customizing. They can be called and only return error messages, if a new function that is processed using Enterprise Services is called within the transaction.

bpm9.JPG

To report this post you need to login first.