Explaining the Inside-Out Approach

Objectives

After completing this lesson, you will be able to:

  • Explaining the inside-out approach

Inside-Out Web Services

Inside-Out Development Approach

You can develop Web Services using two different approaches:

  • Inside-Out
  • Outside-In (see next lesson)

Inside-Out Approach

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

  1. ABAP Implementation

    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.

  2. Create Web-Interface

    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.

  3. 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:

  • Properties

  • External View / Internal View / Types

  • Objects Used

  • Configuration

  • WSDL

  • Classification

The following are further explanations:

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

Choose 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.

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.

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 Service Definition 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.

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.

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.

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:

(Non-changeable) Properties of Operations

PropertyMeaning
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 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 Feature

Type of Message Exchange

  • One Way

    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.

Check and Test Existing Function Modules

Business Scenario

You want to create a Web Service Provider based on an existing function module.

Exercise Information

Note

In this exercise, when the values include ##, replace the character with a two-digit number (01–30).

Exercise Options

You can perform this exercise in two ways:

  1. Live Environment: choose Start Exercise, and from the entry page choose Open PDF Document. Follow the steps described in this pdf in your own system landscape.
  2. Simulation: choose Start Exercise, and from the entry page choose Start Tutorial. Watch the step-by-step instructions within the simulation.
Note
We recommend running the simulation first.

Check and Test Existing Function Modules - Part 1

Check and Test Existing Function Modules - Part 2

Log in to track your progress & complete quizzes