BTP - Multiple Communication Systems

Table of contents

• Introduction
• Parameters
• Maintenance
• Implementation
• Complete example
• Conclusion

In this article, we will take a closer look at how we can differentiate between the different connections in a communication arrangement and thus address the correct system via the ABAP code.

 

Introduction

In different scenarios, it can happen that we want to use the same communication scenario for different connections. For example, if the user is to access via principal propagation, but the service then requires a technical user via basic authentication in the application job. In such a case, we have to create two variants in the system for the communication scenario, each with its own communication system. Depending on the naming convention, we do not want to hard-code the system in the coding, as it can be different for each stage (DEV, TEST, PROD) and mapping it in the coding makes no sense.

 

Parameters

Before we hard-code the systems and connections in the coding, there is the option of adding additional properties to a communication scenario. On the "Overview" tab, in the "Additional Properties" area, you will find find further features. 

 

You can add new properties using the "Add" button. What you need is your own data element, which does not necessarily need its own domain, only if you want to create a value help. The first thing that is important here is the data type and the texts to be displayed. You can control a few more things using the properties in the rear area:

• Is Multiple - Multiple values can be entered in this field if different properties are to be displayed.
• Is Secure - The field is stored securely and not displayed in the UI. Information such as access and passwords can be saved here.
• Value Help - The domain's value help is used for display in the app.

 

If you mark a parameter and click on the "Value Help" button, the current values of the search help are displayed. In this example, the domain's fixed values are used.

 

Maintenance

Let's now use the "Communication Arrangements" app to create a new arrangement with our Communication Scenario, we see our three additional properties in a new area.

 

According to the configuration, the value TEST has been pre-assigned for "System". There is a defined search help for "Application Type" so that the value does not have to be entered manually. We can now enter different values in the "Multiple Values" field using free text. When you have finished with the value, you must press ENTER so that it is converted into an element in the list. Here is an example of entering multiple values.

 

Implementation

Now that we have stored the characteristics and implemented three example scenarios, it is now a matter of determining the correct system at runtime. SAP provides a factory for this purpose. In the first step, we define the query for the search query; at least CSCN_ID_RANGE should be filled with our communication scenario, as we are looking for the systems for this. We can use CA_PROPERTY to define further delimitations to further restrict the connection.

DATA(ls_query) = VALUE if_com_arrangement_factory=>ty_query(
    cscn_id_range = VALUE #( ( sign = 'I' option = 'EQ' low = 'ZBS_DEMO_CS_PARAM' ) )
    ca_property   = VALUE #( ( name = 'MULTIPLE' values = VALUE #( ( 'OTHERS' ) ) ) ) ).

 

In the next step, we create the factory to determine the maintained systems. We then pass the query to this and receive a table of systems back. Depending on the restriction, this can be all maintained systems or just one system, as we need.

DATA(lo_factory) = cl_com_arrangement_factory=>create_instance( ).
lo_factory->query_ca( EXPORTING is_query           = ls_query
                      IMPORTING et_com_arrangement = DATA(lt_systems) ).

 

Finally, we use the GET_COMM_SYSTEM_ID method to get the name of the communication system so that we can use it to instantiate the proxy.

lo_system->get_comm_system_id( )

 

Here is a piece of example code showing how we create a destination using the destination provider and derive the communication system using the factory. This means you only have to pass the specific properties of the query and you can control it using the communication arrangement without having to store any further values in the code.

DATA(lo_destination) = cl_http_destination_provider=>create_by_comm_arrangement(
    comm_scenario  = 'ZBS_DEMO_CS_PARAM'
    service_id     = 'ZBS_TEST'
    comm_system_id = lo_system->get_comm_system_id( ) ).

 

Complete example

Here you can find the example code for reading the systems via the factory class and outputting the result to the console.

CLASS zcl_bs_demo_read_systems DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.
ENDCLASS.


CLASS zcl_bs_demo_read_systems IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    DATA(ls_query) = VALUE if_com_arrangement_factory=>ty_query(
        cscn_id_range = VALUE #( ( sign = 'I' option = 'EQ' low = 'ZBS_DEMO_CS_PARAM' ) )
        ca_property   = VALUE #( ( name = 'MULTIPLE' values = VALUE #( ( 'OTHERS' ) ) ) ) ).

    DATA(lo_factory) = cl_com_arrangement_factory=>create_instance( ).
    lo_factory->query_ca( EXPORTING is_query           = ls_query
                          IMPORTING et_com_arrangement = DATA(lt_systems) ).

    LOOP AT lt_systems INTO DATA(lo_system).
      out->write( lo_system->get_comm_system_id( ) ).
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.

 

Conclusion

If you only create one communication arrangement for a communication scenario, you do not need this effort. However, if you have several connections and do not want to store them hard in the code, then the additional parameters are a good option.

 

Source:
SAP Help - Specific Properties