Inside-Out Development Approach
You can develop Web Services using two different approaches:
- Outside-In (see next lesson)
With the Inside-Out approach, independent function modules that were implemented as RFC-enabled 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 (for example, HTTP and SOAP) and can easily be added to any development environment.
For developing Web Service providers and Web Service clients, the ABAP Workbench (SE80) provides a wizard that guides you quickly to your goal in just a few steps. The Web Service Wizard enables you to 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.
Creating a Web Service Provider in 3 Steps
First of all, you need an ABAP implementation, for example, function module or BAPI. In our case, we use the function module: Z_IFP_ORDER_GETDETAIL. This function module has a method signature, with import and export interfaces, and possibly tables and changing parameters. These interfaces must be used in order to use the domain-oriented functions. To use these ABAP-specific structures, you must generate input and output interfaces from them.
The Web Service Wizard enables you to create a service definition in a few steps. You assign features that pertain, for example, to security or transport guarantees using configuration profiles. Using this wizard, a WSDL description of the function module will be created. That means a generator will transfer ABAP to XML. Within this WSDL, you will find the description of the business data in the typesarea. Input and Output Interfaces are also defined in this WSDL.
This generated WSDL is a so called, abstract WSDL, which only describes the structure of the business data, the messages, and the interfaces.
Configuration with SOAMANAGER
Using the SOAMANAGER, the necessary configurations such as the endpoint, authorization, and authentication will be added as policies into the abstract WSDL. Technically, you create a concrete WSDL, where the endpoint is entered in the service tree of transaction: SICF. With this endpoint, the service can be called.
Modifying a Service Definition
After you have created the service definition using the wizard, you can edit it subsequently in the proxy editor. Call Transaction:
SE80, and choose your package. In the package, you will find your created Web Services. Choose the Web Service you want to modify. In the application toolbar, choose Display/Change .
To modify a service definition, the following tabs are displayed:
External View / Internal View / Types
The following are further explanations:
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
Choose the operation whose name you want to change. Specify the desired name for the operation in the Operation field.
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.
Choose 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. 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.
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.
In this tab, all the objects belonging to the service provider are listed. The ABAP names can be changed.
For more information, refer to the section: Changing the Service Definition Configuration.
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.
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.
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
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.
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.
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.
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:
(Non-changeable) Properties of Operations
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/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.
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 transactional connection is not passed to the server side.
|Reliable Message Exchange|
With Web Services Reliable Messaging, the following is possible:
|RT Intrinsic Feature|
Type of Message Exchange