This is a test message to test the length of the message box.
Login
BTP On-Premise (OData)
Created by Software-Heroes

BTP - Connect On-Premise (Consumption Model v2)

452

In this article we want to provide another update on the connection of on-premise systems and how this is done with a communication arrangement.

In an older article we described connecting an on-premise OData via the Consumption Model. In this article we will look at the new Consumption Model v2, which has changed with Release 2311 and we will make the connection via the Communication Arrangement instead of using the Destination Service.

 

Introduction

With the last release on the ABAP Environment (2311), adjustments were made to the generated consumption model for OData integrations. We would like to take a closer look at these changes in this article. Before that, however, we want to take a look at connecting the on-premise system via a communication arrangement.

 

Consumption Model v2

The new version of the Consumption Model now supports the generation of v2 and v4 Consumption Models on the ABAP Environment. This allows various definitions of OData services to be loaded, especially as the selection of v4 services continues to increase. The wizard now generates far fewer artifacts. Previously, in addition to the consumption model, an abstract CDS entity was generated for each entity, which led to many additional objects depending on the number of entities. Now just create a class that defines the individual entities as types. In addition, various constant structures are available that combine the entities and functions and make them reusable for calling.

 

Communication

The next special feature compared to the destination is the generation of various objects for communication with the backend. The objects are required for configuration.

 

Outbound Service

The outbound service determines the communication protocol and the objects require an appropriate ending in the name, so HTTP services must end with _REST.

 

The generated object does not have many setting options and no longer needs to be generated.

 

Communcation Scenario

Next we need a communication scenario that we will use later when setting up the connection. In ADT you can search for the "Communication Scenario" object in the investment dialog, and we will give it a name and description accordingly.

 

The object has some setting options, but we don't have to change them. In the lower part you will find various tabs for storing the permissions and the various services.

 

We now switch to the “Outbound” tab because we want to access the on-premise system from within the system. This is an outbound communication (from the perspective of the ABAP Environment). We store the outbound service we have just generated, the authentication mechanisms Basic (user and password) and X.509 (principal propagation) are already activated and thus allow these two types of communication.

 

Hint: Finally, the “Publish Locally” button must be pressed so that the scenario appears in the “Communication Arrangement” app. Otherwise the scenario cannot be configured later.

 

Connection

In the last article on this topic we used the Destination Service to access the on-premise system. However, this is now considered obsolete for ABAP scenarios and you should primarily rely on communication arrangements. The following two applications are required for configuration:

 

Communication Systems

The communication system is configured in the app of the same name and represents something like the connection, comparable to the SM59. In this case we use the activated destination service to establish the connection. In the Communication System scenario, this communication can continue to be used, especially if you also need the destinations for connections with CAP or BAS, saving you the double configuration.

 

Communication Arrangements

Using the app, we create a new entry using “New” and search for our created communication scenario. We can assign the name freely, if we only have one communication with this scenario, the same name is recommended.

 

We then store the “Communication System” in the settings in order to establish the connection to the on-premise system via the scenario.

 

Create model

Now we're going to create the consumption model. To do this, we'll need the metadata from the on-premise service again. You can find out how to get this in the old article about the connection. After starting the wizard, we specify the name and description of the consumption model:

 

In the next step we specify the path to the metadata; here you can use the search help if you have not copied the path. Here you also enter the name of the class that is being created.

 

You can confirm the next two steps; the entities and types are listed here, as well as possible objects that cannot be taken over from the service. After the generation is complete, you will receive the usual image of the consumption model: the link to the class, the list of entities and a code wizard with example codes for quickly implementing a test example.

 

The respective types (structure and table) are now available in the class, and there is also a constant structure GCS_ENTITY_SET, which can be used to address the individual entities.

TYPES:
  BEGIN OF tys_company_names_type,
    company_name        TYPE c LENGTH 60,
    branch              TYPE c LENGTH 50,
    company_description TYPE c LENGTH 255,
  END OF tys_company_names_type,
  tyt_company_names_type TYPE STANDARD TABLE OF tys_company_names_type WITH DEFAULT KEY.

CONSTANTS:
  BEGIN OF gcs_entity_set,
    company_names TYPE /iwbep/if_cp_runtime_types=>ty_entity_set_name VALUE 'COMPANY_NAMES',
  END OF gcs_entity_set.

 

Hint: Once generated, the types and structures can be renamed to accommodate possible naming conventions.

 

Test

In order to test the call, we implement the example coding from the Consumption Model. We adapted and prepared the coding accordingly:

DATA lt_business_data TYPE TABLE OF zcl_bs_demo_rap_onprem_newv2=>tys_company_names_type.

DATA(lo_destination) = cl_http_destination_provider=>create_by_comm_arrangement( comm_scenario = 'ZBS_DEMO_COMM_SCENARIO' ).
DATA(lo_http_client) = cl_web_http_client_manager=>create_by_http_destination( lo_destination ).

DATA(lo_client_proxy) = /iwbep/cl_cp_factory_remote=>create_v2_remote_proxy(
    is_proxy_model_key       = VALUE #( repository_id       = 'DEFAULT'
                                        proxy_model_id      = 'ZBS_DEMO_RAP_ONPREM_NEWV2'
                                        proxy_model_version = '0001' )
    io_http_client           = lo_http_client
    iv_relative_service_root = '/sap/opu/odata/sap/ZBS_API_COMPANY_NAME_O2/' ).

DATA(lo_request) = lo_client_proxy->create_resource_for_entity_set(
    zcl_bs_demo_rap_onprem_newv2=>gcs_entity_set-company_names )->create_request_for_read( ).

lo_request->set_top( 50 )->set_skip( 0 ).

DATA(lo_response) = lo_request->execute( ).
lo_response->get_business_data( IMPORTING et_business_data = lt_business_data ).

 

In the first step, we create a destination using the configured communication arrangement; the communication scenario for creating the destination is a mandatory field. If the data record is not unique, for example because more services have been assigned, additional information must be provided:

  • Communication System - Information about the system that was created in the “Communication Systems” app and is assigned to the scenario.
  • Service ID - Name of the outbound service that is used.
DATA(lo_destination) = cl_http_destination_provider=>create_by_comm_arrangement(
    comm_scenario = 'ZBS_DEMO_COMM_SCENARIO'
    comm_system_id = '<Comm System Id>'
    service_id     = '<Service Id>' ).

 

To define the types we can use the types from the class:

DATA lt_business_data TYPE TABLE OF zcl_bs_demo_rap_onprem_newv2=>tys_company_names_type.

 

Likewise for passing the entity name to the query:

DATA(lo_request) = lo_client_proxy->create_resource_for_entity_set(
    zcl_bs_demo_rap_onprem_newv2=>gcs_entity_set-company_names )->create_request_for_read( ).

 

Conclusion

The new consumption model offers many advantages over the old model, but is not yet perfect in its current status. Next year there will be further updates to make workarounds for calling actions and functions unnecessary and to integrate them into the standard.

 

More informations:
SAP Blog - Service Consumption Model 2 for OData Client Proxy


Included topics:
BTPRAPABAP EnvironmentOn-PremiseOData
Comments (2)



And further ...

Are you satisfied with the content of the article? We post new content in the ABAP area every Friday and irregularly in all other areas. Take a look at our tools and apps, we provide them free of charge.


RAP - Deep Action in OData v4

Category - ABAP

In this article we will look at actions with deep structures, how we can create them and pass data to an API endpoint.

05/24/2024

BTP - Business Configuration (Adaptation)

Category - ABAP

What do adjustments to the RAP business object actually look like in the context of the business configuration? More information in this article.

05/17/2024

BTP - Business Configuration (without Transport)

Category - ABAP

How do you actually use the Business Configuration without the transport recording? In this article we clarify whether it is possible.

05/07/2024

BTP - Business Configuration (Usage)

Category - ABAP

Today it's about using the various apps and transporting the business configuration in the ABAP environment.

05/03/2024

BTP - Business Configuration (Creation)

Category - ABAP

This article is about creating maintenance views in the ABAP environment to maintain data and later transport the settings.

04/26/2024