How to call a BW ABAP-Backend from SAC Analytic Application

[vitvas_gpg]

Introduction

There are several blogs showing how to organize interaction between SAC and S/4HANA using OData services. However, one cannot ignore the fact that SAC, as an analytical tool, often uses data from SAP BW or BW/4HANA. This blog provides a simple example of how an OData Service can be used to exchange information between a SAC Analytic Application and BW over a live connection. It is important to note, that this exchange is bi-directional.

Our scope does not include a detailed discussion of the rich features of OData, such as the use of complex types in services. Only the necessary setup steps are shown. If necessary, a specialist will be able to use much more complex Services, required in practical tasks, following to the same scheme.

It should also be noted that described solution can be used to transfer data from SAC to BW with subsequent processing in ABAP. This may be required in cases where the SAC scripting language capabilities are insufficient for complex calculations. Also, this solution is useful if the SAC Analytic Application is used as a replacement for the Web Dynpro applications, where it was possible to initiate the execution of any actions at the Application Server using standard ABAP tools.

Prerequisites

CORS Settings

The described scheme only works when using a live connection between SAC and BW. When creating this connection, BASIS Team performs CORS settings on the AS ABAP side. These settings are described in detail in the corresponding section of SAP Help. In our example, SAC Analytic Application will be used. This will require additional CORS settings(service path /sap/opu/odata4/ and allowed header if-match).

Authorizations

It is assumed that the developer of the OData service has the standard set of ABAP development permissions. Including creating and editing ABAP classes and using the debugger. Additionally, following permissions will be required:

- transaction SEGW

- transactions /IWFND/***

- transactions /IWBEP/***

These authorizations can be described as follows:

- SEGW development authorization: authorization object /IWBEP/SB. In our example, a project (i.e. OData service) with the technical name ZODATAV4 will be created, it will be placed in the local ABAP package $TMP. Corresponding authorization should look as follows:

- authorizations to start the OData service. In our example, ZODATAV4_GROUP service group will be created. To do this, you will first need to have the following authorizations on the S_USER_STA object:

Here the choice is made from the list in the AUTHOBJNAM field. Please, note that you must first select the type of object in the “Type” drop-down list

Then the required values can be selected from the list or the “Full Authorization” button is pressed. After confirming the selection, AUTHOBJTYP and AUTHPGMID fields will be filled in automatically according to the value selected in the “Type” drop-down list.

After that you should restart transaction PFCG and add the following S_START authorization with the same way as previous:

S_USER_STA authorisations are required only while editing the S_START object. When it is done, S_USER_STA can be deactivated or removed from the role profile.

Demo Scenario

1. OData Service creation and configuration in BW. For the service, an action will be defined that “is able to” launch a BW process chain.


2. Creation of SAC Analytic Application.


3. An OData connection will be placed in Application to communicate with our Service.


4. A button will be placed in Application. An onClick-script for this button will call the action in OData Service.

OData Service creation

Press the “Create Project” button in SEGW transaction, enter project technical name and description. Make sure that “OData 4.0 Service” is selected as project type. Also, select a development package if necessary. Here and below, in all examples, objects are created locally in the $TMP package:

You can ignore following pop-up message:

Select newly created Project and press the “Generate Runtime Objects” button:

All fields in this window will be filled in automatically, you don't have to change them.

The ZCL_ZODATAV4_MPC and ZCL_ZODATAV4_DPC classes contain standard code that is automatically copied by the system. This code should not be changed. All custom logic need to be implemented by descendant classes whose names end in _EXT.

The Model Provider Class will declare the actions available in OData Service. It also should describe the returns produced by actions. If necessary, you can declare input parameters for these actions. For our example, we will create a StartProcessChain action with a ChainTechName input parameter. The SAP BW process chain technical name will be passed to input parameter when the action is called. The action will have a string type return, which will show the ID of the chain run that was started during the action execution. This is an artificial example, only to demonstrate that input parameter and return of action are provide a bi-directional data exchange between SAC and BW.

To implement the logic described, we’ll create the new method START_CHAIN in Model Provider Class. Also, standard method /IWBEP/IF_V4_MP_BASIC~DEFINE should be redefined. Our action will be called directly from the SAC Analytic Application without instantiating any helper types. Therefore, it must be unbound, that is, described as an Action Import. For explanations of this OData terminology see, for example, in corresponding sections of SAP Help.

Let’s create the START_CHAIN method as follows:

I added a code comments to clarify the logic:

  METHOD start_chain.

    DATA:

      lo_action        TYPE REF TO /iwbep/if_v4_med_action,

      lo_action_import TYPE REF TO /iwbep/if_v4_med_action_imp,

      lo_parameter     TYPE REF TO /iwbep/if_v4_med_act_param,

      lo_return        TYPE REF TO /iwbep/if_v4_med_act_return.



    "Declare an Action Import to be implemented in this OData Service

    lo_action = io_model->create_action( 'STARTCHAIN' ).

    lo_action->set_edm_name( 'StartProcessChain' ).

    lo_action_import = lo_action->create_action_import( iv_action_import_name = 'STARTCHAIN' ).

    lo_action_import->set_edm_name( 'StartProcessChain' ).



    "Declare a local parameter type from standard OData types

    io_model->create_primitive_type( iv_primitive_type_name = 'STRING' )->set_edm_type( /iwbep/if_v4_med_element=>gcs_edm_data_types-string ).

    "Define an import parameter of this type for action described above

    lo_parameter = lo_action->create_parameter( 'CHAIN' ).

    lo_parameter->set_edm_name( 'ChainTechName' ).

    lo_parameter->set_primitive_type( 'STRING' ).



    "Declare that action should have a return and of which type it will be

    lo_return = lo_action->create_return( ).

    lo_return->set_primitive_type( 'STRING' ).

  ENDMETHOD.

The redefined DEFINE method first calls the ancestor class method with the same input parameters. And then transfers control to the START_CHAIN method, specific to our task:

  METHOD /iwbep/if_v4_mp_basic~define.

    TRY.

        CALL METHOD super->/iwbep/if_v4_mp_basic~define

          EXPORTING

            io_model      = io_model

            io_model_info = io_model_info.

      CATCH /iwbep/cx_gateway .

    ENDTRY.



    start_chain( io_model ).



  ENDMETHOD.

Data Provider Class implements the action return calculation logic. It will be enough to redefine the method /IWBEP/IF_V4_DP_ADVANCED~EXECUTE_ACTION for ZCL_ZODATAV4_DPC_EXT class. In our example, a standard function module will be used to start the chain in BW:

  METHOD /iwbep/if_v4_dp_advanced~execute_action.

    TYPES: BEGIN OF s_chain_action,

             chain TYPE string,

           END OF s_chain_action.



    DATA: ls_chain_params TYPE s_chain_action,

          l_chain         TYPE rspc_chain,

          l_logid         TYPE rspc_logid,

          l_response      TYPE string.



    DATA:

      lv_action_name        TYPE /iwbep/if_v4_med_element=>ty_e_med_internal_name,

      ls_done               TYPE /iwbep/if_v4_requ_adv_action=>ty_s_todo_process_list,

      ls_todo               TYPE /iwbep/if_v4_requ_adv_action=>ty_s_todo_list.





    "Read todo list of requested operations

    io_request->get_todos( IMPORTING es_todo_list = ls_todo ).



    "Check that action import 'STARTCHAIN' was requested

    IF ls_todo-process-action_import = abap_true.



      io_request->get_action_import( IMPORTING ev_action_import_name =   lv_action_name  ). 



      IF lv_action_name = 'STARTCHAIN'.



        io_request->get_parameter_data(

          IMPORTING

            es_parameter_data =  ls_chain_params "Structure with the action parameters

        ).



        ls_done-parameter_data = abap_true. "Parameters reading was executed



        l_chain = ls_chain_params-chain. "This is necessary for data types compatibility

        CALL FUNCTION 'RSPC_API_CHAIN_START'

          EXPORTING

            i_chain     = l_chain

            i_dont_wait = 'X'

            i_gui       = 'N'

          IMPORTING

            e_logid     = l_logid.



        l_response = l_logid.

        io_response->set_busi_data( ia_busi_data = l_response ). "logid transferred as response of the action

        ls_done-action_import = abap_true. "Action import was executed

        io_response->set_is_done( ls_done ). "We return a list of executed operations



      ENDIF.

    ENDIF.

  ENDMETHOD.

OData Service publishing

Service ZODATAV4 must be published in the system. Following steps are necessary for this:

1. Create Service Group in transaction /IWBEP/V4_ADMIN, if there is no previously created group relevant for our purposes.


2. Assign OData Service to Service Group.


3. Publish Service Group, that is to make the services assigned to Group available for use by other users with the necessary authorizations (authorization object S_START). For that, the /IWFND/V4_ADMIN transaction is used.

Start transaction /IWBEP/V4_ADMIN and press the “Register Group” button. Enter Service Group technical name and description:

After creating a Group, the system will prompt you to immediately assign some Service to this Group:

You can choose “Assign”. If the relevant Group has already been created earlier, or if you want to assign a Service to a Group later, you can do so using the “Assign Service” button. Here you can simply select a Service and a Group from the list:

Service Group with the services assigned to it will be listed in the transaction:

If the Service Group has been newly created, then it must be published. To do this, go to transaction /IWFND/V4_ADMIN and click the “Publish Service Groups” button:

Since we are talking about objects in the current system, select LOCAL in the System Alias field, and then click “Get Service Groups”. A list of all unpublished groups will appear:

Highlight the desired group and click “Publish Service Groups”. Then return to the previous window. Now it shows the published group and the services assigned to it:

OData Service testing

The published service can be tested. This testing, if necessary, will allow you to fix the issues in the classes and methods described above by break-points enabling and switching to ABAP debugger. Testing can be started by highlighting our service as shown in the previous screenshot and selecting "Service Test -> Gateway Client":

First of all, please, note the path displayed in the Request URI field:

The starting part of this path upto the $ sign is the End-Point URL, which will be required later in the SAC settings. In our example, the End-Point URL turns out to be as follows: /sap/opu/odata4/sap/zodatav4_group/default/sap/zodatav4/0001/

To start testing, you must first switch the HTTP Method to POST. Secondly, in the Request URI, after the End-Point URL, you need to specify the name of the action that will be called. Thirdly, you need to pass the value of the input parameter to the action using JSON-Syntax. To test the service, a dummy chain ZPC_ODATA4_TEST was prepared. It simply calls a program that contains no code. Therefore, the launch of testing in the end looks like this:

Now testing can be started by pressing the “Execute” button. The successful result looks like this:

In the RSPC transaction we can verify that the service actually started the execution of the chain and returned the run ID:

OData Service utilization in SAC Analytic Application

Now we can use our OData Service in the SAC Analytic Application. For the demonstration, the simplest application was prepared. It contains three components: OData Service named ZODATAV4, button PC_START_BUTTON (labeled "Start Process Chain"), text field CHAIN_RUN_ID, designed to display the value of action return:

In the ZODATAV4 component settings you must specify the name of the Live Connection to that BW system where the service was created. See above for the required CORS settings for this system. You also need to specify the End-Point URL. The value of this parameter, corresponding to our example, was also indicated earlier:

To check the connection to the Service, you need to click the “Refresh” button to the right of the Metadata section. If SSO between SAC and BW is not configured, then an additional window will appear at this moment asking for your BW credentials. If the connection to the Service is successful, then the Metadata section will display OData version used and a list of actions provided by this Service:

Now the action can be called with the onClick script for the PC_START_BUTTON button:

First line of the script shows how to call an action from the ZODATAV4 service connected to the SAC, how to specify the name of this action, how to pass the technical name of the chain to the input parameter of this action. Then, if there were no errors while calling the action, return value from the action is stored in the logid local variable. It, in turn, is displayed in the CHAIN_RUN_ID text field.

So, before the button is clicked, application window looks like this:

After clicking the button, chain run ID appears:

As before, we can check correctness of this number in the RSPC transaction.

[Siva_Raju]

Very good explanation vitvas_gpg

[Raksha_SAP]

Very Well explained

[Henry_Banks]

Thanks for this vitvas_gpg very nicely worked out, i will recommend to my customers

[hemanth89k]

Hi Vitaly Vasilyev,

Thank you so much for the detailed blog, its very helpful. I was able to configure steps till generating the URL.

I am stuck in adding the button in Application Designer layout. I have tested and added the Odata service ZODATAV4 in the layout, but script functions like executeAction are not showing(CTRL+Space) in the button, getting error message: 

executeAction is not a function 

executeAction is an unused property.

I am trying this by selecting Application Designer -> New -> Classic Design Experience.

Please let me know how to resolve.

[vitvas_gpg]

Hi Hemanth,

Thank you for your feedback.

I tried to reproduce the issue you described. It is of critical importance that OData Action name should be listed in 'Metadata' section of ZODATAV4 settings:

If Action name is not visible here, than indeed error messages listed by you will arise. So, my advice is to go through the following implementation sequence:

1. Add OData Service to SAC Application
2. Rename this Service as ZODATAV4, for example
3. Select a corresponding BW Live Connection from the list
4. Enter the End-Point URL
5. Press the 'Refresh' button to the right of 'Metadata' section. Probably (if SSO between SAC and BW has not been configured) your BW credentials will be requested at this moment
6. After a few seconds, OData Version and Action name should be displayed under 'Metadata' section, as it shown on my screenshot. If it is not the case, then there could be two reasons for this. First reason is that your login has not necessary authorizations on BW side to work with OData Service. Second possible reason is that CORS settings are not configured properly. In that case SAC can not view any OData services. My recommendations for setting of authorizations and CORS are listed in 'Prerequisites' section of my blog. Probably, you will need help of your SAP BASIS Team to check and configure these prerequisites.
7. If OData Version and Action name are not displayed in 'Metadata' section, then indeed you will see error messages 'executeAction is not a function' and 'executeAction is an unused property'.
8. If you see the Action name in 'Metadata' section, then SAC also know that this Action exists. Only then you can start to implement the onClick script for Button. In this case you will see the executeAction function when pressing CTRL+Space. Moreover, Action name and Parameter name also will be suggested with CTRL+Space:

[former_member466150]

Thank you vitvas_gpg, that is very helpful, after fixing the BW Live Connection issue I was able to get the metadata and set up the button to run the PC.

Can you please share how to setup the CSRF token validation issue in POST method.

Getting this below error while debugging the application.

[Rasmus]

Hi Vitaly,

Thank you for a great blog - very useful functionality!

Unfortunately I'm struggling to fetch the metadata for the OData Service:

Access to fetch at 'https://<BW>/sap/opu/odata4/sap/zlm_gw_sacodatav4/default/sap/zlm_gw_sacodatav4/0001/StartProcessChain/$metadata' from origin 'https://<company>.eu10.sapanalytics.cloud' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Do you have any good guide for how to setup the additional configuration for CORS and the allow if-match allow header? It looks very like adjustments are needed for the CORS on BW, like https://userapps.support.sap.com/sap/support/knowledge/en/2748971 and thereby https://help.sap.com/docs/SAP_ANALYTICS_CLOUD/00f68c2e08b941f081002fd3691d86a7/39d0e79aa6a0480a90417... so step 7 and onwards?

Screenshot from F12

[vitvas_gpg]

Hi Rasmus,

Thank you for your interest in my blog.

CORS settings, from my point of view, is more subject of BASIS Team, then for BI specialist. Unfortunately, I don't have enough BASIS knowledge to install Cloud Connectors, configure SSO, SSL, etc. While preparing this blog, I used a Live connection from SAC to BW, that was already created in advance by my BASIS colleagues. As I see, there are two methods of establishing of Direct CORS Connection. Method mentioned by you uses an ICM script. In my case method with Unified Connectivity was used. I can't say why BASIS team considered it preferable than ICM Script. But all I had to do was edit existing CORS settings. Initially, CORS settings were configured for usual SAC reporting based on Live BW Models. I only added more settings that necessary to use OData Services. For example, I added a configuration for path /sap/opu/odata4/ via transaction UCONCOCKPIT as described for Unified Connectivity.