Web service

A Web service is an independent, modular, self-describing application function or service. Based on XML
and other standards, this application function can be described, made available, located or called using
internet protocols. Each Web service therefore encapsulates a piece of functionality that can be used, for
example, to forward a price query to a provider, check the availability of an item in an enterprise resource
planning system, or locate a telephone number.

Providing a Web Service

The provider of a Web service is generally called a service provider. The service provider will
have a corresponding XML-based description of the Web service in the Web Service
Description Language (a WSDL document). In principle, any programming language can be
used to implement this service. Based on the HTTP transport protocol, Simple Object Access
Protocol (SOAP) is now established as the quasi-standard access protocol.

Publishing a Web Service

When publishing a Web service, the service provider transmits information about itself and a
description of the service it is offering and transfers this to the services registry. A services
registry can be described as a type of Yellow Pages for Web services. In addition to other
data, it also provides information on calling the Web service, for example. The services
registry therefore provides a description of the Web service only. This description forms an
abstraction layer and is therefore not dependent on the corresponding implementation.
The standard register used is the UDDI services registry (Universal Description, Discovery
and Integration). SAP provides a public UDDI server at http://uddi.sap.com, and any ABAP
client can be set up as a services registry.

Consuming a Web service

The user of a Web service is called a service consumer. In most cases, the service consumer is an
application that accesses the Web service. The application obtains the necessary information for this from
the service description, which is, for example, stored in the services registry.

ABAP Web Services

SAP NetWeaver Application Server for ABAP provides a standardized architecture and a set
of tools for creating Web services and related objects. Existing BAPIs or remote-enabled
function modules can be used for setting up Web services or you can develop new Web
services in the Object Navigator of SAP NetWeaver AS for ABAP. There are predefined
settings for securing Web services or the transports being used. ABAP Web services can be
used for communication between SAP systems and between SAP and non-SAP systems.

Developing Web Services

You can use the ABAP Workbench to create ABAP Web services in the following ways:

Web service providers

You can create a Web service provider from existing RFC modules or from WSDL
documents. Or you can model them in the Enterprise Services Repository or directly in
the ABAP backend.
For more information, see Web Service Providers
Web service consumers

You can create a service consumer for your Web service provider.
For more information, see Web Service Consumers
Integration Scenario Definitions
An integration scenario definition is a development objects that groups interactions on a
logical level. First, semantic contracts are created that describe interactions between
communication partners. For every such interaction, you can build one or more
definitions that are binding for both partners and form the basis for their
implementations. There are no separate provider and consumer models that can evolve
independently.
For more information, see Integration Scenario Definitions

ABAP Proxies
ABAP proxies correspond to different entities of Web services, such as port types, messages, and
schema types. Technically, ABAP proxies consist of two parts:

classic ABAP objects: such as interfaces, classes, and DDIC types,

metadata (SPRX objects)

These two parts are always edited and transported together.

ABAP proxies can be displayed using different browsers

Enterprise Service Browser : Handles all ABAP proxies.

Enterprise Services Repository Browser : Handles objects that were modeled in ESR.

Enterprise Service Browser

The Enterprise Service Browser provides a view on all Web service objects that are available in the ABAP
back-end. Using the Enterprise Service Browser, you can quickly locate objects as they are organized
according to different entry points in tree structures.
ESB lets you browse proxies for all object types that are used for ABAP Web services. Display the
Enterprise Service Browser using transaction code SPROXY.

You can also start the ABAP Workbench using transaction code SE80 and choose Enterprise Service
Browser. If this option is not available, choose Utilities Workbench (General) and
select Enterprise Service Browser.

Enterprise Services Repository Browser

Enterprise Services Repository Browser (ES Repository Browser) is located in the ABAP back-end
system, and provides a view on the data in the Enterprise Services Repository. The ES Repository
Browser lets you create, change, check, activate, and delete proxies for all object types that have been
modeled in the Enterprise Services Repository. For example, service interfaces.
Starting the Enterprise Services Repository Browser
1.
Call the Object Navigator (transaction code SE80).
2.
Choose Enterprise Services Browser.
The software component versions are displayed.

Note
If the Enterprise Services Repository Browser button is not displayed, choose Utilities
Settings Workbench (General) and select Enterprise Services Repository Browser.

Features of ESRB:

The ES Repository Browser displays the structure of the objects in the Enterprise
Services Repository

The top-level nodes of the tree represent the software component versions. When you expand a
software component version, the namespaces available for that software component version are
displayed.

You can expand a namespace to display the objects available for that namespace.

Objects of each type are displayed in a separate node. For example, message types, or data
types. Expand a node to display all the objects of that type.

When an object is displayed, you can perform the following proxy-specific operations:
Check

Checks the consistency of a proxy

Regenerate

Regenerates a proxy
This function will only be available if the proxy has already been generated.

Activate

Activates a generated proxy

Use the Proxy menu to perform the above operations.

The ESR Browser offers the following navigation functions:
Integration Builder

Open the SAP NetWeaver Exchange Infrastructure

Connection Test

Tests the connection to the Enterprise Services Repository

Display WSDL Document

Displays the WSDL representation of the currently selected proxy

Use the Goto menu to perform the above functions.

The ES Repository Browser offers the following display functions:
Refresh

Refreshes the browser; the objects displayed in the tree are reloaded

Exchange Infrastructure

Open the SAP NetWeaver Exchange Infrastructure

Filter

Allows you to specify filter criteria to restrict the objects displayed in the tree
Note that the filter settings will be stored for each user.

Search

Search the tree to locate specific objects

Use the ES Repository Browser toolbar (above the object tree) to perform the above
functions.

Constraints
The ES Repository Browser allows you to change some object attributes. Choose Display <->
Change.
To create objects, work with the Integration Builder.

Object States
The functions available depends on the state of an object. For example, if an object does not have a
proxy, only two functions will be possible: Create Proxy and Display WSDL.

Objects can have the following states:

The proxy object is up-to-date. SAP objects in customer systems are always up-to-date.
The proxy object is orphaned: no corresponding object is available in the Enterprise Service Repository.
Note that this icon is not displayed in the Enterprise Services Browser as orphaned objects are collected
in a separate node.
No proxy exists for this object

Context Menu
You can perform operations on proxies by using the context menu. To display the context menu, right-click
over an object in the ES Repository Browser.
Double-Click
You can double-click an object to perform an operation on it. The operation triggered depends on the
object's state: If a proxy has already been generated for an object, double-clicking the object displays the
proxy. If no proxy exists for an object, when you double-click, you are prompted to create a proxy.

ABAP Proxy Editor

You can display and edit ABAP proxy objects in the proxy editor. You can browse Web service
objects using theEnterprise Services Browser (transaction code SPROXY) and double-click on
an object to open it in the proxy editor.
Below is a summary of the information displayed for an ABAP proxy. Depending on the proxy
object, some of the tabs may not be available.
Tab

Information Displayed

Properties

An overview of attributes that identify the proxy object. These attributes include: type, name,
namespace, the ABAP name, and the user who created the proxy.

Name
conflicts

Here, you can correct names that were truncated during generation, or names that are causing a
conflict.
This tab is only displayed if name conflicts occurred when the proxy was generated.

Used
objects

An overview of the objects generated for a proxy. These objects include data elements, classes,
structures, and interfaces.
Double-click a row to display the components of an object.

Internal
view

Shows the hierarchy of the objects generated. Similar to theUsed Objects tab. Here, the objects
are displayed hierarchically in the context they are used. Click on an object in the tree on the left
hand-side to display details on the right hand-side.

External
view

Shows the object as it is seen by the outside world. The external names of the objects are
displayed as seen externally as well as in the ES Repository.

Warnings

Even if a proxy was generated successfully, there are situations when an object type created in
the Integration Builder does not correspond exactly to a particular object type in the SAP system.
ABAP data types and schema types can differ in parts. Therefore, sometimes ABAP data types
must be used that do not match the schema data type, which can lead to difficulties at runtime.
If such situations occur during proxy generation, they are recorded with their appropriate level of
severity and displayed in the Warnings tab.

Configurati Displays the properties for the proxy's runtime environment.

on
WSDL

Displays the WSDL/schema for the service provider, service consumer, and the data types.

ABAP Proxy Generation - General Procedure

Use
This section outlines the general procedure for generating, regenerating, and deleting ABAP
proxies with generation source ESR or external WSDL. Additional information for generating
specific proxy types is provided in separate sections.
The procedure to generate ABAP proxies is essentially the same for each different type of
proxy. There are two main steps:

Select the objects to be called or implemented.

Generate and activate the proxies.

Prerequisites
To work with ABAP proxies, you need the SAP_XI_DEVELOPER_ABAP role, which is included in the
composite role SAP_XI_DEVELOPER. Use the profile generator (transaction PFCG) to assign roles.
Depending on the proxy type, the following tasks must be done before you generate a proxy:

All objects must be modeled in the ES Repository - or be made available as external

WSDL descriptions.
Some objects in the ESR are combinations of other objects. For example, a service
interface contains data types and message types. Therefore, a proxy (a Web service
provider or a Web service consumer) can only be generated when all referenced types
are generated as well. When a proxy that is modeled in the ES Repository is generated for
an object that references another object in the same namespace, the proxy for the
referenced object will be generated automatically. For example, a proxy could be
generated for a service interface that references a specific data type. If a referenced
object is in a different namespace, you need to generate the proxy for the referenced
object separately.

When a proxy is generated from an external WSDL document, all of its objects are
generated.

The package structure in the ABAP back-end system must be defined.

The package structure defines where the proxies will be created, where the service
provider will be, and how the packages will fit into the overall application structure. Note
that for proxies from external WSDLs, the package is part of the external name and
objects that reference other objects use the external names for these references. If the
package of some of these objects is changed after proxy generation, these references get
lost. Therefore, the package should not be changed after proxy generation.

Prefixes for the ABAP objects can be defined.

When generating proxies, many different objects are created. All external objects have a
rather long qualified name consisting of name and namespace. The ABAP objects only
have a 30-character ABAP name. The ABAP name is derived from the external name
(without namespace) and, if a prefix is set, it is set in front. Therefore, it is recommended
that you define prefixes as they allow you to ensure that ABAP objects in the back-end
system are assigned unique and consistent names and name collisions are avoided. In
many ABAP projects, you need to use an ABAP namespace. You can define this using a
prefix. Because of the reduction to 30 characters, it is possible that generated names are
not descriptive. It is therefore recommended to check all generated names manually and
adapt them accordingly.

Generating a Proxy
Proxies are generated in the ABAP back-end system, in which the object will subsequently be provided.
1.

Start the Enterprise Service Browser.

Use transaction code SPROXY.

2.

Select an object. In the Enterprise Service Browser, you can locate an object
according to different criteria, such as the generation source, the package, or the object
type.

3.

To generate the proxy, open the context menu and choose Create proxy.

4.

Specify a package and a prefix, and choose Enter.

Valid ABAP names are proposed. You can change the proposed names as required.

The prefix you specified is displayed as part of the ABAP name in the Properties tab and
also in theStructure tab.
5.

Activate the proxy.

The ABAP objects, such as DDIC types, classes, and interfaces, are created or changed
only when the proxies are activated. When generating, regenerating, and editing, or
saving the proxies, the ABAP objects are not touched. When saving a proxy, an inactive
version of the metadata is created. To change the ABAP objects that are used at runtime,
an active version is necessary.

6.

Release the transport request.

Note that the proxy (SPRX object) and the generates (CLAS, INTF, TAB, DTEL) are
transported together.

7.

Create a runtime configuration for the proxies.

In the system that consumes the Web service, create a logical port for the Web service
consumer. In the provider system, create an endpoint for the service definition. For more
information, see Configuring Web Services in SOA Manager.

Generating Proxies with Industry-Specific Enhancements

To activate industry classifications, you need to select an industry when you generate proxies for Web
services delivered with an Enhancement Package. Perform the following steps:
1.

Log on to the back-end system in English.

2.

Start transaction SM30.

3.

Choose the SVW_INDUSTRY view.

4.

Select your industries.

5. Regenerating a Proxy
6. If an object is changed in the Enterprise Services Repository (ES Repository) after it has been
generated, the changes will not automatically be reflected in the proxy in the ABAP back-end
system. If an object in the ES Repository is changed, you will need to regenerate the
corresponding proxy manually.
7. Note
8. In the ES Repository Browser as well as in the Enterprise Service Browser, an icon
with a red triangle indicates a version of an ES Repository entity that is different from
its proxy version in the ABAP back-end system.

1.

In the Enterprise Services Repository Browser, locate the object whose proxy you
want to regenerate.
2.
Open the context menu and choose Regenerate proxy
This function will only be available if a proxy has already been generated.
Only the proxy interfaces, datatypes, and classes will be overwritten. ABAP names and
types will remain intact if possible. If, for example, a datatype has been changed in a way
that its ABAP type is no longer valid, it is adapted.
3.
Reactivate the proxy.
From the context menu, choose Activate Proxy.
You can choose between the options Activate, Activate Main, and Activate All, depending
on wheter you want the underlying objects to be activated as well.
Deleting a Proxy
1.
In the ES Repository Browser, select an object.
2.
From the menu, choose Proxy Delete .

Note
The implementing class will not be deleted, but you will have to delete it manually. Only
the generated data will be deleted.

Result
When proxy objects are activated, one or more of the following ABAP objects are created:

ABAP Dictionary types

ABAP Dictionary types represent the global data types in the ES Repository. The system
also generates the data types that will be used as method parameters.
ABAP interface

An ABAP interface comprises interface types and constants.

A template of an ABAP class (proxy class or implementing class) for provider or
consumer proxies, if not already existent
You have to manually adapt and activate ths template. If you want to create a new one,
you have to delete the implementing class or change its name.
The ABAP class of a service provider contains the implementation of the service provider
methods, and uses an ABAP interface. A service provider class has one method for each
operation modeled in the ES Repository. For a proxy to be used by an application, the
methods will need to be filled with application coding.

Example:1
Concept:
1. Every Web service is generated with a Web Service Definition Language (WSDL).
2. We will use the WSDL to create a Client Proxy.

Example: Suppose we have two systems System-1 & System-2. We have created a web service in
System-1 & we want to consume that Web service in System-2. For this we have to create a Client Proxy
in System-2 with the help of WSDL that is generated with the web service which is made in System-1.
Settings: To call the web service of system1 in system2 the following settings must be done.
1. Go to T-code SICF and press execute.
2. Go to Client->Proxy Settings.
3. The following screen appears.
4. Go to HTTP Log and Provide the Host name and port of system-1. (System in which web service
exists)

Steps for Creating a Client Proxy:

1. Go to T-code Se80.
2. Go to Edit Object ->Enterprise Services->Client Proxy (Radio Button).

Click on the create button.

3. The following screen appears.

Select the radio button URL/HTTP Destination and click on the continue button.
4. The following screen appears.

In the URL provide the Web service definition language (WSDL) of the web service.

Click on the continue button.

4. The following screen appears.

Provide the prefix and stored it in a package or in a local request.

The following screen appears.

Click on the complete button.

6. After clicking on the complete button the following pop-up appears asking for filling the user id and
password.

This user id and password is of that system in which web service exists. (Permission to use the web
service of another system).
Provide the user name and the password and Click on the OK button.
7. The following screen appears and the proxy is created.

Save and activate the proxy. This Proxy is nothing but a class which exists in SE24.
The name of the proxy is always like this: Consumer Proxy Prefix + CO + Name of the Web Service.
When we open the class in SE24 it looks like this.

Where ZWS_FM is our RFC FM for which we have created a client proxy.
8. Go to T-Code SOAMANAGER and give the name of the Client Proxy which you have created. (In the
search by drop down select Consumer proxy).

9. Apply Selection and go to configuration tab to create the Logical Port.

Provide the logical port name and its description.

URL for WSDL Access: WSDL of the web service
Provide the user name and the Password of the system in which web service exists and click on apply
settings.
10. The Following Screen Appears.

Click on save button. The binding for the web service activated.

11. Now Create an Executable program and write the following code to call the RFC FM.
a) Create an object of the proxy class and provide the name of the Logical Port.
b) Then call the RFC function module with the help of that object.
DATA:
CREATE OBJECT lo_object
EXPORTING logical_port_name = 'ZPORT_LDS'.
TRY.
CALL METHOD lo_object->zws_fm
EXPORTING

lo_object TYPE REF TO ZPROXY_CO_ZWS_SUM

input = ls_input
IMPORTING
output = ls_output .
CATCH cx_ai_system_fault .
CATCH cx_ai_application_fault .
ENDTRY.
This client Proxy object calls the RFC FM (The RFC Function Module which is made in SYSTEM-1) .The
Output of the Method can be used for further processing.

Example : 2
Creating a Web Service
In the function library (SE37), display the function module.
Open the function Module

: ME_GET_CURRENT_USER_ID

Choose Utilities -> More Utilities -> Creating a Web Service -> From Function Module.

In the Web Service Creation Wizard, choose Continue.

Enter the name of the Web Service Definition

In the following screen, enter the required data and select the checkbox Name Mapping. If the checkbox Name
Mapping is ticked, the wizard accepts the existing names for the end point.

Choose Continue.

In the following screen, enter the required data and select the checkbox Release Service for runtime.

Choose Continue.

Choose Complete.

Save as local object.

Testing a Web Service.
Prerequisites
Open the transaction WSADMIN.

Select the Web service definition you have created under SOAP Application for RFC-Compliant FMs
Select and expand the ZWEB_GET_CURRENT_USER and select the Web Service as shown in
screen.

You have entered the address of the application server on which the J2EE Engine is running in
transaction WSADMIN under Goto -> Administration Settings.

Check the J2EE Server and check in your server.

Choose Web Service Homepage (Execute Button ).

Select the Document Style under Style definition in WSDL.

The Web service requires authentication.

Enter the user and password

Click on the Test.

Select the Operations.

Fill in values for the method parameters underneath the heading Request if required. Choose Send.

The required values are displayed under the Response heading. The Web service has not been tested
successfully.

Example 3 :
Description: Creating ABAP based Web services and consuming in report. In this example we will be using
wizard provided by SAP.

Go to SE37. Enter the name of the function module already created.

Menu->utilities->more utilities->create web service->from function module:

Enter the Service Definition Name followed by short text as shown below

Select the end point, as of now the following options are available

Function module

Function Group

BAPI

Message interface (from XI)

Select the function module created earlier

Since we are using basic Authorizations, select the option as shown

Make sure we select the check box release Service for Runtime
If this is not selected we need to go to TCode: WSCONFIG & release it
This is the final screen for wizard before completion.

Click on Complete and save it in package.

Go to TCode wsconfig to check whether the wsd created has been released for soap runtime

Click on Display button

Click on ICF Details button

The web service is created in sicf transaction as shown

Go back

Yes the green icon shows the wsd is released successfully for soap runtime.
Generating the wsdl from wsd
Go to transaction code wsadmin as shown

Select the wsd for which the wsdl has to be generated.

Make sure the administrative settings has been configured

Click on generate function after selecting the respective wsd

Save the wsdl file on to the local pc for further use

Testing the web service

Click on submit button

Copy the wsdl as shown

WSDL:
http://yhsapx09.yashsap.com:8003/sap/bc/srt/rfc/sap/Z_ESA_GETCARRIERS_WSD?sapclient=100&wsdl=1.1

Click on test button to test the functionality of web

service
Click on the parameters

Enter the input parameters and click on submit

Comments: The web service has been tested successfully and is ready to use.
Create any client application for consuming it.
Generating the proxy object-Consuming in ABAP
Login to SAP system.

Go to SE80 create proxy object,

Path: create-> enterprise web service->proxy object

Select the option local File and select the wsdl saved on local pc in earlier step.
Specify the package & prefix (z) save it.

Creating RFC destination for Yhsapi01.

Create RFC destination of type H

If needed configure the proxy settings

For configuring proxy settings click on Global Configuration

Save the settings

Creating Logical port

Go to lpconfig

Creating Client Application-> report

*&---------------------------------------------------------------------*
*& Report ZXI3

*& AUTHOR: chandra dasari

*&---------------------------------------------------------------------*
REPORT ZXI3.
*&----------------------------------------------------------------*&
*& Data Declaration
*&----------------------------------------------------------------*&
tables : spfli.
DATA: proxy TYPE REF TO zco_zgetflightdet19_wsd,
OUTPUT type ZZGETSFLIGHTDETRESPONSE ,
INPUT type ZZGETSFLIGHTDET .
Data : sys_fault type ref to cx_ai_system_fault,
app_fault type ref to cx_ai_application_fault.
Data : itab type spfli.
*&----------------------------------------------------------------*&
*& UI Declaration
*&----------------------------------------------------------------*&
parameters : p_carrid type spfli-carrid,
p_connid type spfli-connid.
*&----------------------------------------------------------------*&
*& Application logic
*&----------------------------------------------------------------*&
start-of-selection.
TRY.
CREATE OBJECT proxy
exporting
LOGICAL_PORT_NAME = 'ZCO_ZGETFLIGHTDET19_WSD'
.
CATCH cx_ai_system_fault .
create object sys_fault.
write :/ 'error at level 1', sys_fault->errortext.
exit.
ENDTRY.
TRY.
input-carrid = p_carrid.
input-connid = p_connid.
CALL METHOD proxy->zgetsflightdet
EXPORTING
input = input
IMPORTING
OUTPUT = output
.
CATCH CX_AI_SYSTEM_FAULT .
create object sys_fault.
write :/ 'error at level 2', sys_fault->errortext.
exit.
CATCH ZCX_EXCEPTION00 .
CATCH CX_AI_APPLICATION_FAULT .
write : 'error 3'.
exit.
ENDTRY.
write : / 'TEST RESULTS OF CLIENT APPLICATION RUNNING ON YHSAPX05'.
WRITE : / 'THE CLIENT APPLICATION CALLS THE WEBSERVICE LOCATED ON YHSAPI01
SYSTEM'.
SKIP.
write :/ output-carrid,
/ output-connid,
/ output-currency,
/ output-planetype,

/ output-price,
/ output-seatsmax,
/ output-seatsocc.
Performing test from client application.
Execute the application.
Input screen:

Output:

Generating an ESR-Based Provider Proxy

Prerequisites
To generate a provider proxy, the following objects must already have been designed in the
Enterprise Services Repository:

Data types

Message types

Service interface and its operations

Context
You work with the Enterprise Service Browser in the ABAP back-end system and follow the
general procedure for generating proxies.
More information: ABAP Proxy Generation - General Procedure

Procedure
1.
2.

Generate a provider proxy for an inbound service interface.

Activate the provider proxy.
When the provider proxy is activated, all the underlying data types and message types
will also be activated.

3.

Implement the provider proxy.

To implement a provider proxy, you need to add application coding.
An active provider proxy now exists in the ABAP back-end system, in which the service
will be provided.

4.

To be able to call a Web service, you have to create a runtime configuration. To do

this, use the SAP NetWeaver Administrator. Start this tool from the SOA Manager
(transaction code SOAMANAGER).

Results

An endpoint exists that can be used to call the Web service.

The provider proxy comprises the following:

An ABAP proxy interface

An implementing class that implements the proxy interface

The implementing class contains the operations that were modeled in the Enterprise
Services Repository as methods.
A template for the implementing class is created during proxy generation. A developer must
add the appropriate application code to the implementing class. The ABAP proxy interface is
generated and cannot be changed.

Example
Below is an example of an implementation of a method that returns an echo of imported
data:

METHOD ZMY_II_SYNCHRON_INBOUND_INTERF~EXECUTE_SYNCHRONOUS.
**** INSERT IMPLEMENTATION HERE ****
OUTPUT-RESPONSE_MESSAGE_TYPE-SIMPLE = INPUT-REQUEST_MESSAGE_TYPE-SIMPLE.

ENDMETHOD.

Generating a Consumer Proxy

Use
You can generate consumer proxies from objects modeled in the Enterprise Services
Repository or from a WSDL document. The resulting objects are in different generating
applications. For more information on generating application, see the system documentation
that you can access using the Tips and Tricks icon in transactionSPROXY.
ABAP consumer proxies are used in an application to call (consume) a Web service.
Consumer proxies need only to be generated and can then be used by an application. If the
objects for a consumer proxy are modeled in the ES Repository, the corresponding ES
Repository object is an outbound service interface.

Prerequisites
A consumer proxy can be generated if any of the following prerequisites are met:

The outbound service interface, which will be used to generate the consumer

proxy, is available in the ES Repository.

A WSDL document that describes the Web service to be called is available. Note that
there are some limitations to the WSDl content that is supported by ABAP proxy
generation. See the 944029
.

Procedure
Generating a Consumer Proxy Using the Web Service Creation Wizard
1.
Start the Repository Browser (transaction code SE80).

2.
3.

Open the package for which you want to generate the consumer proxy.
From the context menu for the package, choose Create Enterprise Service .
The Web Service creation wizard is started.
4.
When you are prompted, select Service Consumer as the object type.
5.
Continue.
6.
Select the source of the WSDL document.
You can select the following sources:

Enterprise Services Repository

URL/HTTP Destination

Local File

UDDI Registry

Services Registry
7.
8.
9.
10.

Continue.
Search for or specify th WSDL document.
Specify a package, a prefix, and a transport request.
Continue.
The consumer proxy is generated. During generation, proxies for all the related data
types and message types are generated.
The Configuration tab displays the default properties, which are extracted from the WSDL
document. These properties determine the settings of a runtime configuration.
11.
Choose Activate.
The consumer proxy is saved and activated. In addition, the proxy class and the related
structures and methods are automatically created and activated.
Generating a Consumer Proxy From the ES Repository
1.
Start the Enterprise Service Browser (transaction code SPROXY).
2.
3.

Locate the outbound service interface.

Open the context menu and choose Create.
The system prompts you to specify a prefix and a transport request.
4.
Confirm.
The consumer proxy is generated. During generation, all the related data types and
message types in the same namespace are also generated.
The Configuration tab displays the default properties, which are extracted from the WSDL
document. These properties determine the settings of a runtime configuration.
5.
Choose Activate.
The consumer proxy is saved and activated. In addition, the proxy class and the related
structures and methods are automatically created and activated.

Working with Service Variants

Use
Service variants provide views on service interfaces that are modeled or based on a WSDL
document. Instead of using all the parameters in a service interface, a service variant allows
you to use only parameters that are needed for a particular business context.

A service variant is based on a service interface and reuses the implementation of that
service to create the new service. It is not necessary to create a new service
implementation.
A service variant has its own WSDL and service endpoint, and is published to the Service
Registry in the same way as any other standard service.
Service interfaces can often contain many parameters to support several different use cases
and to enable a high degree of reuse of services. For this reason, it can sometimes be
difficult to know which parameters in the service interface are relevant for their specific
business purpose. By using service variants, you can simplify the way a service is consumed,
for example, by hiding fields or assigning fixed values.

Procedure
Creating a Service Variant
Service variants are created in the ABAP back-end system.
1.
Start transaction SVAR.
2.

Choose New.
The Wizard for service variants is started.

Note
Alternatively, you can start the Wizard from the context menu in the root node of the
package. Choose Create Service Provider Service Variant
3.

Specify a name and a namespace suffix for the new service variant.
The namespace is built by concatenating the namespace prefix and the namespace
suffix. The namespace prefix cannot be changed.
4.
In the Base Service Interface box, specify the service interface on which to base the
new service variant, and its namespace.

Note
The service interface you specify must be released. If the service interface is not
released, the system prevents you from continuing.
5.
6.
7.

Choose Continue.
Specify a package and a transport request.
Choose Finish.
The new service variant is now created.
When a service variant is first created, it has the following default field states:
Hidden with fixed value propagation

for all optional fields

Hidden without fixed value propagation

for all optional fields that reference complex types

Visible

for all non-optional fields and for all operations

Note
If the base service is changed, for example, if optional fields or operations are added, the
default state for the new fields and the new operations is Hidden without fixed value
propagation so the service variant does not change its behavior.

Editing a Service Variant

You can change the following properties of a service variant:

Hide or unhide operations from the base service interface

Hide fields from the base service that are not required for the service variant

Set fixed values for fields

Define optional fields as mandatory

You cannot define mandatory fields as optional.
To change a service variant:
1.
Start the proxy editor (transaction code SPROXY).
2.

Locate the service variant that you want to change.

Use transaction code SE80, then choose Edit Object, and search for the service variant.
3.
Go to the External View tab.
4.
Choose Edit.
You can now change the field states.
Below is an overview of the field states:
Visible

The behavior of a Visible field is the same as in the base service interface.

Mandato Only optional fields in the base service interface can be defined as mandatory in the service
ry
variant.
To ensure that the response XML is valid, you should set to mandatory only fields that are
always filled by the base service implementation. If a field in the response structure is not
filled, this may result in an invalid XML response at runtime.

Note
This attribute cannot be used for tables ( maxOccurs > 1).

Hidden

Hidden fields are not included in the payload.

If mandatory fields are set to hidden, a value is required.
If a XSD default value is assigned in the base service interface, this becomes the default field
value.
If a field is hidden in a service variant, the field is not included in the service described by the
variant.
There are two different hidden states.

Hidden without fixed value propagation

This state is possible only for elements that reference a complex type in the original XSD
document. The element must be optional or all subelements must also have the
state Hidden without fixed value propagation.
Hidden with fixed value propagation
This state is possible only for leaf elements or if all subelements or attributes are hidden or
optional.

Note
This option cannot be used for tables (maxOccurs > 1).
All fixed values assigned to the field or to subelements or attributes are passd to the
original service implementation at runtime, unless one of the following conditions is met:
o
The subfield is part of a table
o
There is a field which is Hidden without fixed value propagation in the
chain between the Hidden with fixed value propagation super field and the subfield
with a fixed value,

Enterprise Services Wizard

Use
The Enterprise Services Wizard guides you when you create any of the design time objects
used in the ABAP Web Services framework.
There are several entry points for the wizard, some of which are context-sensitive. If you
start the wizard multiple times in the same session, values for package, prefix, and transport
request are pre-filled from the previous start.

From ABAP Workbench

In ABAP Workbench (transaction code SE80) in Enterprise Services Repository

Browser right-click a package and choose Create and then Enterprise Service.
From Enterprise Services Browser
In Enterprise Services Browser, right-click a node above the object you want to create
and choose Create. Note that the wizard call is context-sensitive, and it will offer you the
appropriate options to choose from. For example, if you open it from the Enterprise
Services node, you can create any proxy object. If you open it from a subnode, only the
proxy objects of this subnode are offered in the wizard.
From the proxy objects entry point
In transaction SPROXY_START, choose the
icon.
Using transaction code SPROXY_WIZ
Start the wizard with all its options by entering the transaction code SPROXY_WIZ.

Creating a Proxy Object

In the wizard, you have to specify the following:

Generation source
You can specify the following generation sources for the respective proxy objects:
Proxy Object

Backe
nd

Enterprise
Services
Repository

External
WSDL/Schema

Data types, message types,

X
data type enhancements, fault
messages, event providers

Service consumers

Service providers

Semantic contracts, contracts

RFC consumers

X (local file of the ABAP

Connector of the function
module)

Existing ABAP
Object (Inside
Out) or Service
Variant

Note
The generation source controls the source and scope of proxy objects. You can find
detailed information about the scope of proxy objects in the system documentation. In
transaction SPROXY, choose the
icon to display the documentation. Choose Proxy
Identification.

Name and a namespace for the proxy object

The external name that you define in this step is the one that is exposed to non-ABAP
applications.
An ABAP package, a transport request (optional), and a prefix (recommended).
Either choose a transportable package or select Local Object to assign this object to
the $TMP package. If you enter a transportable package, select a request from your

transport system. Prefixes can be used to distinguish proxy objects from others.
When you finish the wizard, the new unsaved proxy object is opened in the proxy editor.
Setting a Default Prefix
You can configure the wizard to be pre-filled with a specific prefix by specifying the user
parameter PRX_PREFIX in your user profile.
1.
2.

In the menu bar of your ABAP system, choose System User Profile Own Data .
On the Parameters tab, enter PRX_PREFIX as the parameter ID and specify the value

to be used a default prefix in the wizard.

3.
Save.

Modeling Web Service Objects in the Back-End

You can either model Web service objects (data types, message types, fault message types,
inbound service interfaces, outbound service interfaces, event providers, or data type

enhancements) in Enterprise Services Repository (ESR) or directly in the ABAP back-end.

This procedure outlines the general principles of modeling Web service objects using the
proxy editor. The proxy editor and Enterprise Services Wizard are easy-to-use when following
these principles.

Prerequisites

For more information on modeling services in Enterprise Services Repository, see the
documentation in the function-oriented view of the application help for SAP NetWeaver on
the SAP Help Portal athttp://help.sap.com.

You have assigned your namespace to the ABAP back-end as the generating
application in transactionSPXNGENAPPL. For more information, see the chapter
entitled Proxy Identification in the system documentation. To find this documentation,
choose the
[Tips & Tricks] icon in transaction SPROXY.

Procedure
1.

Start the proxy editor, for example by double-clicking a Web service object in
Enterprise Service Browser.
On the Internal View tab, the proxy editor is divided in two parts. On the left hand side,
the object is displayed in a tree. Here, you can use the context menu to add objects or
you can drag and drop objects from Enterprise Service Browser or Enterprise Service
Repository Browser. Also, you always have a powerful field help at your disposal that only
offers objects that are allowed at this particular place.

2.

In case of problems, the proxy editor displays warnings on the bottom of the window
that often have long texts. Read through these long texts for helpful hints and solutions
to these problems.

Web Service Providers

Use
You can provide Web services in the following ways:

Using the Enterprise Services Repository (outside-in)

This approach comprises basically two steps:
o
Development of the service starts in the Enterprise Services Builder (ES

Builder). In contrast to inside-out development (whereby a WSDL document is

generated on the basis of an existing function and then published), the ES Builder
creates the service implicitly as a WSDL document in the Enterprise Service Repository
(ES Repository).
To implement or call a service, developers generate proxies in the relevant

application system for the service from the ES Repository. Developments therefore
begins outside the application system and is then continued in the application system
(hence the term outside-in).
For calling a service, development objects of a service that was described outside of the
system are generated into the respective development system (outside-in) with the help
of a WSDL document.
Modeling in the Back-end

The ABAP back-end supports modeling functions that are similar to those of the Javabased Enterprise Services Repository. It allows you to model data types, message types,
and service interfaces directly in the ABAP development environment.
Based on existing functions (inside-out)

The Web Service technology enables a company to act as a so-called "provider" and to
provide services either within the company or externally. The problem posed by the use
of different programming languages is overcome by encapsulating an existing function in
a system using a Web service. The Web service definition contains the signature for the
function and other information required to call it - such as the address of the server on
which the function can be called. To provide this information to a consumer, you publish
the Web service as a WSDL document. Using this XML standard, consumers of the
services can generate a proxy in their application systems, with which they can then use
the SOAP protocol to call the Web service.
A programming-language-independent description of th interface used to call th function
is provided to the outside for further use. In this case, we refer to "inside-out
development".
RFC-enabled function modules, function groups (that contain RFC-enabled function
modules), and BAPIs can be made available as Web services without any additional
programming. The service is in the system already and can be published externally
(inside-out).
Based on a WSDL document

You can either use a WSDL that is stored locally or retrieve it from a URL or a services
registry. The WSDL document is a description of the Web service and contains all
necessary information.

Note
Instead of "outside-in" and "inside-out", the SOA world commonly uses the following terms
as well: "Contract-First" and "Code-First"; "Top-Down" and "Bottom-Up".
As a general guideline, you would use the inside-out approach if the objects are already
there and you use the Web service for internal purposes only. Otherwise, you would usually
model the objects. When modeling the Web services, the WSDL documents are cleaner and
better to read for the outside world.

Developing a Web Service Using the Enterprise Services

Repository (Outside-In)
Use
You create an outside-in service by performing the following steps:

Modeling in the Enterprise Services Repository

Creating the interface

Implementing the application logic

Configuring the Web Service

We distinguish between the following processing types for methods of Web services:

Synchronous

Asynchronous

More information: Types of Message Transmission.

Prerequisites
The Web service runtime has been configured (refer to Configuring the Web Service
Runtime).
The Web service has been modelled in the Enterprise Services Repository (ESR).
You have activated the Enterprise Services Browser in the ABAP Workbench. You can also call
the browser in transaction SPROXY.

The user is assigned the relevant Authorizations.

Procedure
1.

Generate a provider proxy.

While the service modeling takes place centrally in the ES Repository, the proxy
generation and subsequent service implementation is done in a specific back-end. Before
the corresponding Web service proxy is generated, the developer has to decide in which
system the proxy is to be generated. Afterwards, he or she starts the proxy generation
locally in this system. This transfers the entities from the ES Repository into the local
system. The resulting proxies are stored in the back-end. The proxies can be used
independent of of the ES Repository. The connection to the ES Repository is only required
for generation, re-generation, and for checking the proxies against the ES Repository.
Call transaction SPROXY, select the inbound service interface, and choose Create
Proxy from the context menu. Enter the name of a package. (Refer to Working with ABAP
Proxies).
The service definition is automatically generated during proxy generation.
After generation, the provider proxy contains methods for each service operation.

2.

Fill the operations with the required logic.

In the Properties tab of the service interface, click the name of the provider class, and
then specify the method name in order to get to the editor. You then implement the
provider proxy.

3.

4.

Create a runtime configuration for the provider proxy. In the proxy editor,
choose Start SOA Manager. For more information, refer to Configuring a Service
Provider (from point 5 onwards).
Test your service in the Web Service Navigator.
Select the service definition in the Object Navigator (Transaction SE80) and choose Start
Web Service Navigator. Make sure that a connection to the Web Service Navigator has
been set up (refer to Setting Up the WS Navigator). If the service has not yet been
configured, a standard configuration is created before starting the Web Service Navigator.
In this case, choose the appropriate pushbutton.
More information: Testing a Service.

Result

An endpoint exists that can be used to call the Web service.

The provider proxy comprises the following:

An ABAP proxy interface

An implementing class that implements the proxy interface

The implementing class contains the operations that were modeled in the Enterprise
Services Repository as methods.

A template for the implementing class is created during proxy generation. A developer must
add the appropriate application code to the implementing class. The ABAP proxy interface is
generated and cannot be changed.

Example
Below is an example of an implementation of a method that returns an echo of imported
data:

METHOD ZMY_II_SYNCHRON_INBOUND_INTERF~EXECUTE_SYNCHRONOUS.
**** INSERT IMPLEMENTATION HERE ****
OUTPUT-RESPONSE_MESSAGE_TYPE-SIMPLE = INPUT-REQUEST_MESSAGE_TYPE-SIMPLE.

ENDMETHOD.

Developing a Web Service Provider in the ABAP Back-End

Prerequisites
The Web service runtime has been configured (refer to Configuring the Web Service
Runtime).
The SAP system uses the software component version SAP NetWeaver 7.0 EHP2, Service
Package 08 or higher.
For general information on modeling Web service objects in the back-end, see Modeling Web
Service Objects in the Back-End

Context
You can create a service provider locally in the back-end system using the internal ABAP
modeling functions. For more information, see the documentation on modeling services in
Enterprise Services Repository in the function-oriented view of the application help for SAP
NetWeaver on the SAP Help Portal at http://help.sap.com.

Procedure
1.

Ensure that your namespace is assigned to the back-end.

In transaction SPXNGENAPPL, you can check whether your namespace has been assigned
to the back-end repository. If not, add it to this list and assign it to the generation
source Backend Metadata Repository.

2.

In the Proxy Editor (transaction code SPROXY), in the Enterprise Services

Browser right-click on Object Types and choose Create new object.
3.
Select Service Provider.
4.
Select ABAP back-end as the generation source for the service provider.
5.
Specify a name, a namespace and (optionally) a prefix.
The external name that you define in this step is the one that is exposed to non-ABAP
applications that consume or provide the Web service. Prefixes can be used to distinguish
proxy objects from others. If your namespace has not been assigned to the back-end yet,
you get an error message. Assign the namespace as described in step 1 above.
6.

Specify an ABAP package and a transport request.

Either choose a transportable package or select Local Object to assign this object to
your $TMP package. If you enter a package, select a request from your transport system.

7.

Finish the wizard.

The proxy object is created and opened in the proxy editor. On the Properties tab, an
empty class is displayed that you can implement as soon as the provider is activated.

8.

On the internal or external view tab, add operations to your service provider by rightclicking on the service provider node.
9.
On the internal or external view tab, right-click an operation to add message types.
For an asynchronous operation, set a request message type. For a synchronous operation,
also add a response, and, optionally, one or more fault message types.
You can either add an existing message type or create a new one. Choose the appropriate
action from the context menu of the operation. If you create a new one, the Enterprise

Services Wizard is started and leads you through the creation process. You can also drag
and drop message types from the Repository Browser or from the Enterprise Services
Browser.
10.

On the internal or external view tab add datatypes to the message types by rightclicking a message type.
You can either add existing datatypes or create a new type. Choose the appropriate
action from the context menu. If you create a new type, the enterprise services wizard is
started and guides you through the creation process. You can also drag and drop data
types from the Repository Browser or from the Enterprise Services Browser.

Note
On the internal and external view tab the object a is displayed with the
icon in front of
it as long as it contains inconsistencies. Click on the same icon in the menu bar to carry
out a check. This will display the individual warnings or errors.
11.

Save the service provider and activate it.

Results
The service provider has been created. You can now implement the new implementing class.

Developing a Web Service Based on Existing Functions (InsideOut)

Use
With the inside-out approach, independent function modules that were implemented as RFCenabled function modules, as function groups, or as BAPIs are provided as a Web service.
The Web service can be used across the entire Internet using standard protocols and can
easily be added to any development environment.

Prerequisites
The user has been assigned the appropriate Authorizations.

Features
You provide Web services on the AS ABAP using the service wizard.
The Web service properties are defined in a preset, selectable profile. The values assigned
through a profile can be changed in the Object Navigator of the ABAP Workbench.
You can assign features - such as the authentication level, for example - to the service
definition in abstract form. The technical details of these features are specified in the Web
services configuration.

Procedure

Creating a Service Definition

Editing a Service Definition
Changing the Service Definition Configuration

Creating an Inside-Out Service Definition

Use
The Web Service Wizard enables you to create a service definition in a few steps. You can
create Web services for RFC-enabled function modules, function groups, and BAPIs. You
assign features that pertain, for example, to security or transport guarantees using
configuration profiles.
After you have created the service definition using the wizard, you can edit it subsequently
in the proxy editor by opening it from the Enterprise Services Browser Enterprise
Services Service Definitions (refer to:Editing a Service Definition).

Prerequisites
The user has been assigned the appropriate Authorizations.

Procedure
1.

In the Repository Browser, choose the name of the package in which you want to
create a Web service.
2.
In the context menu, choose Create Enterprise Service Service Provider
Existing ABAP Objects (Inside Out).
For function groups and function modules, you can call the wizard from the Function
Builder (SE37). Choose the required function module, display it, and then choose
Utilities More Utilities Create Web Service From the Function Module or From the
Function Group.
Note that the function group must contain at least one RFC-enabled function module.
Action:

Meaning:

Create Service

Enter a name and short text for the service definition. Choose an end-point type.

Choose End Point

Choose the object that you want to offer as a Web service. For BAPIs, enter the
application.
If the checkbox Name Mapping is marked, the wizard accepts the existing names for the
end point. Initial letters are in uppercase and underscores are removed If this is not
required, create the service definition using the names in the end point.

Choose Operations For BAPIs and function groups, choose the operations for which the Web service is to be
created.
With Delete Line you can exclude operations of a BAPI or a function group that should not
be provided in the service definition. At least one operation must be retained.
Configure Services The features that can be assigned here to the Web service relate to questions of security
of data transfer and the type of communication. The selected security level is to be
understood as the minimum requirement for all runtime configurations of the service
definition.
Choose a predefined feature set from the profiles available.

PRF_DT_IF_SEC_HIGH

Authentication using certificates and transport guarantees

PRF_DT_IF_SEC_LOW

Authentication using user ID and password, no transport guarantee

PRF_DT_IF_SEC_LOW

Authentication using user ID and password and transport guarantee

PRF_DT_IF_SEC_NO

No authentication and no transport guarantee

For more information on the features in the profiles, refer to the section Editing a Service
Definition.
Choose Deploy Service to release the service for runtime.
Enter
Enter the name of the package and the transport request number. You do not need a
Package/Transport transport request for local objects.
Request
Finish

The service definition is created.

Result
You have created a Web service.
You can display and edit the service definition in the Object Navigator in the package you
selected under Enterprise Services Service Definitions . For more information, refer to
the section Editing a Service Definition.
Configure the Web service (refer also to Configuring the Service Provider).
Each service that you create in inside-out mode can be called synchronously and
asynchronously.
For more information, refer to the sections Consuming a Web Service and Types of Message
Transmission.

Editing a Service Definition

Prerequisites
You have created a service definition using the service wizard.

Context
You create a service using the default values of the assigned profile. You can change these values for
function modules, BAPIs, and function groups.

Procedure
1.

Double-click the service definition in the subtree Service Definitions in the Repository
Browser of the ABAP Workbench under Enterprise Services.
2.
In the application toolbar, choose Display/Change.The following tabs are
displayed.
Option

Description

Properties

In this tab page you find general information on the service provider

External
View /
Internal
View / Types

Make changes in the External View tab page if the service definition is to be displayed
to the outside in a different form.
Change Names of Operations
Select the operation whose name you want to change. Specify the desired name for
the operation in the Operation field:
Adapt Parameters
Choose the required parameter: You can then make any of the following changes to it:

Change Parameter Name

In the Parameter field, enter the selected name.

Change Parameter Type

You can change the type of a parameter if it is based on a structured type or table
type.
To change the type of parameter, proceed as follows:
Choose the Types tab.
Select the type you want to copy. Choose Copy (from the context menu or
application toolbar).
In the dialog box that appears, enter a name for the copied type. It then appears in
the Copied Types category.
Fields belonging to the type can be deleted by selecting the appropriate function in
the context menu. If the copied type includes other fields that are based on a
structured or table type, the context menu also contains the Change Type option. If
you want to change a type, choose a suitable type in the dialog box that appears.

Option

Description

You will perhaps have copied this previously (see above). Choose the External
View tab in order to assign the new type. Confirm with Return.
Define Default Value
Parameters that are optional in the original interface can also be optional in the
service definition. In this case, the default value of the original interface is used.
Alternatively, you can enter a default value yourself.
Hide Parameters
Uncheck the Exposed checkbox.
If a parameter is hidden, it does not appear in the WSDL document at all. In such
cases, the fixed value or parameter initial value is used.

Objects Used
In this tab, all the objects belonging to the service provider are listed. The ABAP
names can be changed.

Configuration For more information, refer to the section Changing the Configuration.

WSDL
In the case of a WSDL document that is the basis for the service definition, you can
choose either the RPC or Document style.
You can save the WSDL to a file using the corresponding pushbutton or you can copy
the URL to be able to use it during proxy generation.

Classification

You can publish the tModel of a service (this is the technical specification of a service)
in a Services Registry and classify and publish service definitions. tModels of services
(based on a function module, a function group, a BAPI, or a message interface) are
published from the ABAP backend.
tModels of services that were modeled in the Enterprise Services Repository are
published directly from the Enterprise Services Repository. For more information, refer
to Working with a Services Registry.

Option

Description

Prerequisite for the classification and publication is that a connection to the required
registry is set up (refer to Setting Up a Connection to the Services Registry).

Changing the Service Definition Configuration

Procedure
In the Configuration tab, you will find the features that were assigned at interface, security,
and operation level using the service wizard profiles. Make the changes you require. No
changes can be made to service interfaces.
Interface Profile
In the interface profile, choose the required processing type: Stateful or Stateless.
A stateful service retains its status within the framework of a HTTP session throughout
several calls from the same service consumer. The default value for services is stateless. If
you require stateful communication, you can choose this instead.
If you choose the name of the configuration, the ICF ( Internet Communication Framework)
service node of the SOAP runtime is displayed on the right-hand side in the Path Prefix field.
The message identifier has the standard value True. Using the
IF_WSPROTOCOL_MESSAGE_ID protocol, you can query the sent message.
For more information, refer to the section Protocols.
Security Profile
In the security profile, choose the type of authentication for calling the Web service through
a service consumer. You define how transport security (making sure the data transfer is
secure) between the consumer and the provider is to take place.
Operation Profile
The operation profile has the default value Synchronous. If you choose the status stateful in
the interface profile, you can choose also Synchronous Commit and Synchronous
Rollback for all operations except Synchronous.
The assignments of the following (non-changeable) properties of operations can be
displayed.
Property:

Meaning:

Blocking

Calling a proxy (more precisely, transmitting a message to the message infrastructure) causes
the caller to be blocked until the business reply has been received and returned to the caller.

Commit
Handling

Commit/Rollback Control Through the Framework

The Framework is responsible for closing transactions (commit or rollback). The application
signalizes only whether a COMMIT or ROLLBACK is to be executed.

Transaction
Handling

Description of the Transactional Behavior of the Message Infrastructure Transactional processing

means that the messages that are passed to the messaging infrastructure are collected up until
the end of the transaction (LUW). Depending on the type of transaction completion
(commit/rollback), the messages are discarded or stored for subsequent processing. The

Property:

Meaning:
transactional connection is not passed to the server side.

Reliable
Message
Exchange

With Web Services Reliable Messaging, the following is possible:

The sender of a message can determine whether a message was received by the

desired receiver and can then trigger appropriate measures if this is not the case.
The receiver of the message can be sure that he or she receives the message, despite
unforeseen problems with networks or the software.

RT Intrinsic Type of Message Exchange

One Way
Features
Data is transferred from the sender to the receiver without a reply being expected from the
application.

Request Response
The message exchange consists of a query and a reply at application level.
For more information, refer to the section Types of Message Transmission.