BTP - Connect On-Premise (Consumption Model v2)
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.
Table of contents
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
