Skip to end of metadata
Go to start of metadata

This article describes step-by-step how you can access your Google Calendar from an ABAP program using the new OAuth 2.0 Client API. The Google Calendar API is used as an example to demonstrate the access using OAuth 2.0, you can also access every other OAuth 2.0 protected Google API very simply.

When accessing the Google Calendar the AS ABAP system should act on behalf of the user currently logged on. Additionally the permissions of the AS ABAP system should be constrained to a subset for security reasons, when it acts on behalf of the Google user. I.e. it should only be able to access certain selected web services not all for which the Google user is authorized.

To demonstrate how to implement this scenario the Google Calendar will be called from the AS ABAP system using the OAuth 2.0 and HTTP Client APIs. As a result the AS ABAP system will display the received Google Calendar information to the end user.

The redirection endpoint of your AS ABAP system which you register at Google must be visible from the internet. Google will check this and if the redirection endpoint cannot be accessed from the internet Google won’t save your OAuth 2.0 Client registration data.

Table of Contents

Register an OAuth 2.0 Client in the Google Cloud Console (The server side)

In this section the server side configurations at Google are described. The following documentations give an overview about how to access Google APIs from a web server as an OAuth 2.0 Client (in this scenario the AS ABAP):

https://developers.google.com/accounts/docs/OAuth2 https://developers.google.com/accounts/docs/OAuth2WebServer

 

The necessary configurations to register an OAuth 2.0 client can be done in the Google Cloud Console which you can access following this link:

https://console.developers.google.com/project

The redirection endpoint of your AS ABAP system which you register at Google must be visible from the internet. Google will check this and if the redirection endpoint cannot be accessed from the internet Google won’t save your OAuth 2.0 Client registration data.

 

Follow the descriptions in the “Google Developers Console Help” to activate the required Google APIs:

https://developers.google.com/console/help/new/#activatingapis

 

Turn on the Calendar API. You can find additional information regarding the Calendar API here:

https://developers.google.com/google-apps/calendar/

 

Follow the descriptions in the “Google Developers Console Help” to create a new OAuth 2.0 Client ID:

https://developers.google.com/console/help/new/#generatingoauth2

 

Choose the application type “Web Application”, remove any “Authorized JavaScript Origins” and insert the redirection URI of your AS ABAP in the field “Authorized Redirect URI”.

 

Use the OAuth 2.0 Client (The client side)

In this chapter the necessary steps are described that need to be done by developers, system administrators and end users to access the Google Calendar using the OAuth 2.0 Client API.

Developer Tasks

Google has defined additional parameters, that are not part of the OAuth 2.0 Standard as described in RFC 6749. These parameters (access_type, approval_prompt and optionally username_hint) must be included in requests with correct values to complete the authorization code flow. Therefore additional development activities are required to adjust the OAuth 2.0 Client API to Google’s OAuth 2.0 Implementation. The following development activities are required:

  • A new Service Provider Type “ZGOOGLE” will be defined.
  • A first BADI implementation will be created to declare endpoint settings, supported grant types and the additional parameters required by Google.
  • A second BADI implementation will be created to define the values of the additional parameters required by Google.
  • An OAuth 2.0 Client Profile will be created to store the scopes required to access the Google Calendar API.
  • Finally a short ABAP program will be written, that demonstrates how to call the Google Calendar API using the OAuth 2.0 and the HTTP Client APIs.

Define a Service Provider Type for Google

TaskDescription
Call transaction OA2C_TYPES

The system will display an overview of the existing OAuth 2.0 Client Service Provider Types.

Create a new entry

Switch to change mode and choose New entries.

Save the new entry ZGOOGLE

Enter a new service provider type ZGOOGLE and save your change.

 

Create a BADI implementation for the new Service Provider Type

To implement the BADI firstly a class needs to be implemented and secondly the actual BADI Implementation object needs to be created.

Implement the Class

TaskDescription
Implement a class for ZGOOGLEFirstly a class needs to be implemented that will be used to adjust the OAuth 2.0 Client to the Google specific OAuth 2.0 implementation.
Create the class in transaction SE24

Use the name “ZCL_OA2C_SPECIFICS_ZGOOGLE” for the new class and press create.

Create settings

Choose the depicted settings for the new class and press Save. Save the new class as a local object first (or save it on a transport request if you would like to transport your scenario).

Set the superclass

Press the button „Superclass“ on the properties tab in transaction SE24 and enter the class “CL_OA2C_SPECIFICS_ABSTRACT“. This class contains the standard settings for the OAuth 2.0 protocol implementation.

Redefine the endpoint settings

Switch to the methods tab, mark the method „IF_OA2C_SPECIFICS~GET_ENDPOINT_SETTINGS“ and press the button “Redefine”.

Insert method code

Replace the method implementation with the following code:

************************************************************************************************************************

e_changeable                  = abap_false.

e_authorization_endpoint_path = `accounts.google.com/o/oauth2/auth`.
e_token_endpoint_path         = `accounts.google.com/o/oauth2/token`.
e_revocation_endpoint_path    = `accounts.google.com/o/oauth2/revoke`.

************************************************************************************************************************

Redefine the supported grant types

In the next step mark the method “IF_OA2C_SPECIFICS~GET_SUPPORTED_GRANT_TYPES” and press the button “Redefine”.

Insert method code

Replace the method implementation with the following code:

**********************************************
e_authorization_code = abap_true.
e_saml20_assertion   = abap_false.
e_refresh            = abap_true.
e_revocation         = abap_true.
**********************************************
Redefine the configuration extension

Then mark the method “IF_OA2C_SPECIFICS~GET_CONFIG_EXTENSION” and press the button “Redefine”.

Insert method code

Replace the method implementation with the following code:

*********************************
r_config_extension = `ZGOOGLE`.
*********************************
Redefine authorization request parameter names

Then mark the method “IF_OA2C_SPECIFICS~GET_AC_AUTH_REQU_PARAM_NAMES” and press the button “Redefine”.

Insert method code

Replace the method implementation with the following code:
*************************************************************************
DATA: ls_add_param TYPE if_oa2c_specifics~ty_s_add_param.
CALL METHOD super->if_oa2c_specifics~get_ac_auth_requ_param_names
  IMPORTING
    e_client_id           = e_client_id
    e_redirect_uri        = e_redirect_uri
    e_response_type       = e_response_type
    e_response_type_value = e_response_type_value
    e_scope               = e_scope.
ls_add_param-name = `access_type`.
INSERT ls_add_param INTO TABLE et_add_param_names.
ls_add_param-name = `approval_prompt`.
INSERT ls_add_param INTO TABLE et_add_param_names.
ls_add_param-name = `login_hint`.
INSERT ls_add_param INTO TABLE et_add_param_names.
*************************************************************************
Activate the classActivate the class ZCL_OA2C_SPECIFICS_ZGOOGLE.

 

Implement the Enhancement Spot

TaskDescription
Implement the Enhancement SpotThis section contains a description how to implement the Enhancement Spot for the new Service Provider Type “ZGOOGLE” and the class “ZCL_OA2C_SPECIFICS_ZGOOGLE”.
Create the Enhancement Spot Implementation

Start transaction SE80 and choose the package “SOAUTH2_CLIENT_EXTENSIONS”. Next choose the Enhancement Spot “OA2C_SPECIFICS” and in the context menu choose “Implement”.

Set name and description

Enter the name “Z_OA2C_SPECIFICS” and the description “OAuth 2.0 Client Specifics Implementation” for the new enhancement spot implementation.

Define the BADI settings

Confirm the following popups. On the popup „Create BADI Implementation“ choose the BADI Definition „OA2C_SPECIFICS_BADI_DEF“, enter the implementation class „ZCL_OA2C_SPECIFICS_ZGOOGLE“ (that was created in the last section) and define the BADI Implementation „Z_OA2C_SPECIFICS_ZGOOGLE“. Then press “Continue”.

Create a Filter

On the following screen expand the BADI Implementation “Z_OA2C_SPECIFICS_ZGOOGLE” and doubleclick the node “Filter Val.” Then press “Create Filter Combination”.

Change the Filter

Then mark the new filter combination and press „Change Filter Value“ and enter “ZGOOGLE” in the field Value 1 on the following popup. Press Continue and then activate the Enhancement Implementation.

 

Create a BADI implementation for the Configuration Extension

To implement the BADI firstly a class needs to be implemented and secondly the actual BADI Implementation object needs to be created.

Implement the Class

TaskDescription
Implement a class for the ZGOOGLE configuration extensionSecondly a class needs to be implemented that will be used to fill the Google specific additional OAuth 2.0 parameters correctly.
Create the class in SE24

Use the name “ZCL_OA2C_CE_ZGOOGLE” for the new class and press create.

Enter the settings

Choose the depicted settings for the new class and press Save. Save the new class as a local object first (or save it on a transport request if you would like to transport your scenario).

Add interfaceOn the tab interfaces add the interface „IF_OA2C_CONFIG_EXTENSION” and press “Save”.
Implement interface method

Implement the method “IF_OA2C_CONFIG_EXTENSION~GET_AC_AUTH_REQU_PARAMS” and add the following code:

**************************************************
DATA: ls_nvp LIKE LINE OF et_additional_params.

*   parameter: access_type
ls_nvp-name  = `access_type`.
ls_nvp-value = `offline`. "online|offline
APPEND ls_nvp TO et_additional_params.
*   parameter: approval_prompt
ls_nvp-name  = `approval_prompt`.
ls_nvp-value = `force`. "auto|force
APPEND ls_nvp TO et_additional_params.
**************************************************
Activate the classActivate the new class “ZCL_OA2C_CE_ZGOOGLE”.


Implement the Enhancement Spot

TaskDescription
Implement the Enhancement SpotIn this section is described how an Enhancement Spot Implementation for the Google specific configuration extension is created. (This is analog to the Enhancememt Spot for the Service Provider Type.)
Create the Enhancement Spot Implementation

Start transaction SE80 and choose the package “SOAUTH2_CLIENT_EXTENSIONS”. Next choose the Enhancement Spot “OA2C_CONFIG_EXTENSION” and in the context menu choose “Implement”.

Enter a name and description

Enter the name “Z_OA2C_CONFIG_EXTENSION” and the description “OAuth 2.0 Client Configuration Extension Implementation” for the new enhancement spot implementation. Press “Creation of Enhancement”.

Define the BADI settings

Confirm the following popups. On the popup „Create BADI Implementation“ choose the BADI Definition „OA2C_CONFIG_EXTENSION_BADI_DEF“, enter the implementation class „ZCL_OA2C_CE_ZGOOGLE“ (that was created in the last section) and define the BADI Implementation „Z_OA2C_CE_ZGOOGLE“. Then press “Continue”.

Create Filter

On the following screen expand the BADI Implementation “Z_OA2C_CE_ZGOOGLE” and doubleclick the node “Filter Val.” Then press “Create Filter Combination”.

Change Filter

Then mark the new filter combination and press „Change Filter Value“ and enter “ZGOOGLE” in the field Value 1 on the following popup. Press Continue and then activate the Enhancement Implementation.


Create an OAuth 2.0 Client Profile

TaskDescription
Create an OAuth 2.0 Client Profile

Create a new OAuth 2.0 Client Profile to connect your ABAP program with a certain OAuth 2.0 Client. An OAuth 2.0 Client Profile contains all Scopes that are required on the server side (i.e. in this example Google Calendar). In this example the client needs one OAuth 2.0 Scope:

https://www.googleapis.com/auth/calendar.readonly
Create a new OAuth 2.0 Client Profile

In SAP Gui start the Repository Browser with transaction SE80. Switch to your local objects and in the context menu of the root node “$TMP …” choose Create => More… => OAuth 2.0 Client Profile.

Set Profile type and name

On the following popup choose the OAuth 2.0 client profile type “ZGOOGLE” and enter the name “Z_GOOGLE_CALENDAR”.

Namespace and Transport settings

On the next popups confirm that the OAuth 2.0 Client Profile should be created in customer namespace and as local object (package assignment “$TMP”).
Assign OAuth 2.0 Scopes

Then assign the OAuth 2.0 Scopes to the OAuth 2.0 Client Profile, which are required on the server side (Google) to access the web service protected with OAuth 2.0. In this example only one scope “https://www.googleapis.com/auth/calendar.readonly” is required. Save the OAuth 2.0 Client Profile.

OAuth 2.0 Client Profile completed

As a result you can use this OAuth 2.0 Client Profile “Z_GOOGLE_CALENDAR” to link programs in the AS ABAP with your Google OAuth 2.0 Client.

 

Call the OAuth 2.0 Client API in your ABAP program

In a second step start transaction SE38 from SAP GUI and create a small demo ABAP program “ZGOOGLECALENDAR” that calls the Google Calendar and displays an overview about the authenticated user’s appointments to the end user. The following listing shows this program.

REPORT ZGOOGLECALENDAR LINE-SIZE 1023.


DATA: profile    TYPE oa2c_profile,
      target     TYPE string,
      method     TYPE string,
      param_kind TYPE string,
      lt_param   TYPE tihttpnvp,
      ls_param   TYPE ihttpnvp.


AT SELECTION-SCREEN.


START-OF-SELECTION.

  profile = 'Z_GOOGLE_CALENDAR'.
  target  = `https://www.googleapis.com/calendar/v3/calendars/primary/events`.
  method  = `GET`.
  param_kind = 'F'.




  DATA: lo_http_client  TYPE REF TO if_http_client,
        lo_oa2c_client  TYPE REF TO if_oauth2_client,
        l_status_code   TYPE i,
        l_response_data TYPE string,
        lt_fields       TYPE tihttpnvp,
        lx_oa2c         TYPE REF TO cx_oa2c.

  FIELD-SYMBOLS: <ls_field> LIKE LINE OF lt_fields.


**********************************************************************
* Create HTTP client
**********************************************************************
  CALL METHOD cl_http_client=>create_by_url
    EXPORTING
      url                = target
      ssl_id             = 'ANONYM'
    IMPORTING
      client             = lo_http_client
    EXCEPTIONS
      argument_not_found = 1
      plugin_not_active  = 2
      internal_error     = 3
      OTHERS             = 4.
  IF sy-subrc <> 0.
    MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
               WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
  ENDIF.

* Turn off logon popup. Detect authentication errors.
  lo_http_client->propertytype_logon_popup = 0.

  CALL METHOD lo_http_client->request->set_method
    EXPORTING
      method = method.

  LOOP AT lt_param INTO ls_param.
    CALL METHOD lo_http_client->request->set_form_field
      EXPORTING
        name  = ls_param-name
        value = ls_param-value.
  ENDLOOP.



**********************************************************************
* Set OAuth 2.0 Token
**********************************************************************
  TRY.

      CALL METHOD cl_oauth2_client=>create
        EXPORTING
          i_profile        = profile
        RECEIVING
          ro_oauth2_client = lo_oa2c_client.

    CATCH cx_oa2c INTO lx_oa2c.
      WRITE: `Error calling CREATE.`.
      WRITE: / lx_oa2c->get_text( ).
      RETURN.
  ENDTRY.

  TRY.

      CALL METHOD lo_oa2c_client->set_token
        EXPORTING
          io_http_client = lo_http_client
          i_param_kind   = param_kind.

    CATCH cx_oa2c INTO lx_oa2c.
      TRY.
          CALL METHOD lo_oa2c_client->execute_refresh_flow.
        CATCH cx_oa2c INTO lx_oa2c.
          WRITE: `Error calling EXECUTE_REFRESH_FLOW.`.
          WRITE: / lx_oa2c->get_text( ).
          RETURN.
      ENDTRY.
      TRY.
          CALL METHOD lo_oa2c_client->set_token
            EXPORTING
              io_http_client = lo_http_client
              i_param_kind   = param_kind.
        CATCH cx_oa2c INTO lx_oa2c.
          WRITE: `Error calling SET_TOKEN.`.
          WRITE: / lx_oa2c->get_text( ).
          RETURN.
      ENDTRY.
  ENDTRY.



**********************************************************************
* Send / Receive Request
**********************************************************************
    CALL METHOD lo_http_client->send
      EXCEPTIONS
        http_communication_failure = 1
        http_invalid_state         = 2
        http_processing_failed     = 3
        http_invalid_timeout       = 4
        OTHERS                     = 5.
    IF sy-subrc <> 0.
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
                 WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    ENDIF.

    CALL METHOD lo_http_client->receive
      EXCEPTIONS
        http_communication_failure = 1
        http_invalid_state         = 2
        http_processing_failed     = 3
        OTHERS                     = 4.
    IF sy-subrc <> 0.
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
                 WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    ENDIF.



**********************************************************************
* Display result
**********************************************************************
    CALL METHOD lo_http_client->response->get_status
      IMPORTING
        code = l_status_code.
    WRITE / |{ l_status_code }|.

    WRITE /.

    IF l_status_code = 200.
      CALL METHOD lo_http_client->response->get_cdata
        RECEIVING
          data = l_response_data.

      DATA(l_content_type) = lo_http_client->response->get_content_type( ).
      IF l_content_type CP `text/html*`.
        cl_demo_output=>display_html( html = l_response_data ).
      ELSEIF l_content_type CP `text/xml*`.
        cl_demo_output=>display_xml( xml = l_response_data ).
      ELSEIF l_content_type CP `application/json*`.
        cl_demo_output=>display_json( json = l_response_data ).
      ENDIF.
    ELSE.
      CALL METHOD lo_http_client->response->get_header_fields
        CHANGING
          fields = lt_fields.

      LOOP AT lt_fields ASSIGNING <ls_field>.
        WRITE: / <ls_field>-name, 25 <ls_field>-value.
      ENDLOOP.

    ENDIF.



**********************************************************************
* Close
**********************************************************************
  CALL METHOD lo_http_client->close
    EXCEPTIONS
      http_invalid_state = 1
      OTHERS             = 2.
  IF sy-subrc <> 0.
    MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
               WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
  ENDIF.

System Administrator Tasks

This chapter contains a description of the system administrator tasks that are required to access Google APIs from an AS ABAP. This tasks include:

  • Create an OAuth 2.0 Client Configuration
  • Assign end user authorizations
  • Configure proxy settings (if required)
  • Configure SSL settings

As a prerequisite the system administrator needs authorizations to create OAuth 2.0 Client Configurations. Make sure that the system administrator has the authorization S_OA2C_ADM with at least the activities 01, 02 and 03 in the AS ABAP system.

Create an OAuth 2.0 Client Configuration

TaskDescription
Start OAuth 2.0 Client Configuration

From the SAP GUI start the transaction OA2C_CONFIG. This will open the OAuth 2.0 Client Configuration in a web browser. Alternatively you can call the URL

https://<yourhost>:<yourhttpsport>/sap/bc/webdynpro/sap/oa2c_cconfig?sap-language=EN&sap-client=<yourclient>

in a browser.

Create a new OAuth 2.0 Client

In the OAuth 2.0 Client Configuration Application choose Create new OAuth 2.0 Client.

Choose an OAuth 2.0 Client Profile and a Client ID

On the following popup choose the newly created OAuth 2.0 Client Profile “Z_GOOGLE_CALENDAR” and enter the ID of your OAuth 2.0 Client received during registration at Google. The OAuth 2.0 Client ID ends with “.apps.googleusercontent.com”.

Configure the Redirection URI at server side (Google) and configure the Target Endpoint

On the following screen copy the redirection URI and paste it in the field Redirect URI of the server side configuration of your OAuth 2.0 Client. (This makes your OAuth 2.0 Client known to Google’s OAuth 2.0 Authorization Server.) See section "Register an OAuth 2.0 Client in the Google Cloud Console (The server side)" for details.

In the field “Target Endpoint” you need to enter an endpoint on your AS ABAP to which the end user’s browser should be redirected after completing the authorization code flow. In this scenario the default target endpoint is used, i.e. the grant application / transaction OA2C_GRANT (see section "Request OAuth 2.0 Tokens" for details).
Configure OAuth 2.0 Client Secret

Next enter the client secret that you received during registration of the client at the Google authorization server and press Enter to confirm your input.

Verify the OAuth 2.0 Client Scope assignment

Then finally verify that on the scopes tab of your OAuth 2.0 Client Configuration the profile “Z_GOOGLE_CALENDAR” is displayed in the Profile table. In the Scope table there should be only one Scope displayed:

https://www.googleapis.com/auth/calendar.readonly
Save the new OAuth 2.0 Client ConfigurationFinally save the new OAuth 2.0 Client configuration.

 

Assign end user authorizations

Make sure that the end users who should be allowed to use the new OAuth 2.0 Client have the required authorizations assigned. During execution of OAuth 2.0 flows there is a check of the authorization object “S_OA2C_USE”. This authorization object has two fields “PROFILE” and “ACTVT”. Set the authorization field values as follows:

  • S_OA2C_USE
    • PROFILE       = Z_GOOGLE_CALENDAR
    • ACTVT           = 16

 

"Z_GOOGLE_CALENDAR" is the name of the OAuth 2.0 Client Profile created in section "Create an OAuth 2.0 Client Profile".

Having this authorization assigned is a prerequisite that an end user can initiate an OAuth 2.0 Token Request and access his Google Calendar from a program in the AS ABAP system.

Configure proxy settings

If required, a description can be found in the article " Configure proxy settings ".

Configure SSL settings

TaskDescription
Export SSL certificate of GoogleTo export Google’s SSL certificate navigate to the Google Calendar URL in a browser window, display the website identification, show the certificate and export it to a file.
Navigate to the web service URL in a browser window

When you navigate to the web service URL in a browser window there should be an error because of missing authentication.
 

Display the website identification

Next click on the SSL symbol in your browser and display the website identification data. Choose button “Further information…”.

Show the certificate information (Description for Firefox.)

On the following screen choose tab “Security” and then choose button “Show certificate”. Switch to tab “Details” and choose the signing certificate (“Google Internet Authority G2”). Then choose button “Export”. Save the certificate to a file using the suggested name.

Import the SSL certificate in the AS ABAP

Start transaction STRUST in SAP GUI and switch to change mode. Choose PSE “SSL Client Anonymous”. In the frame “Certificate” choose button “Import certificate” and import the saved certificate file. Then choose button “Add to Certificate List” and save the PSE.

After that the AS ABAP will trust SSL servers whose identity is confirmed by this certificate.

 

End User Tasks

After the development and system administration tasks described in sections "Developer Tasks" and "System Administrator Tasks" were executed end users can start using the OAuth 2.0 Client. They first need to request OAuth 2.0 Tokens which is described in detail in section "Request OAuth 2.0 Tokens". Then they can execute the program “ZGOOGLECALENDAR” as described in section "Use OAuth 2.0 Tokens".

Request OAuth 2.0 Tokens

An end user first needs to execute an initial OAuth 2.0 Token Request. The server will then issue an Access Token and a Refresh Token. After this initial OAuth 2.0 Token Request the end user doesn’t need to interactively request OAuth 2.0 Tokens again. Instead the AS ABAP can use the refresh token to get a new set of tokens when the access token has expired.

There are two possibilities to initiate the authorization code flow as described step-by-step in section "Use transaction OA2C_GRANT" and "Call the grant endpoint".

Use transaction OA2C_GRANT

TaskDescription

Start transaction OA2C_GRANT

In the SAP GUI start transaction OA2C_GRANT. This will start a web browser application, which allows triggering the initial access token request.

Mark your Google OAuth 2.0 Client

Mark your Google OAuth 2.0 Client, which was configured in the previous chapters. (If you cannot see a client with your registered Google Client ID, there is an authorization error. See section "Assign end user authorizations" then.) As there is no token yet, the status “Access not allowed” is displayed.

Request OAuth 2.0 Tokens

Next press the button “Request OAuth 2.0 Tokens”. This will start the OAuth 2.0 Authorization Code flow.

Redirection to the Google authorization endpoint

The AS ABAP will then redirect the end user’s browser to Google’s authorization endpoint. The end user has to authenticate with his Google Account and will then see the consent screen to grant the requested scope to the AS ABAP.

Redirection back to the grant application

After the enduser gave their consent and authorized the clients request for the scope , their browser is redirected back to the AS ABAP and the OAuth 2.0 Authorization Code flow is completed. After that the AS ABAP has an Access Token and a Refresh Token for the end user currently logged in. In the grant application the status “Access possible” with infinite expiry time is displayed.

 

Call the grant endpoint

TaskDescription
Call the grant endpoint from your web application.

In the picture the call of the grant endpoint is shown in the web browser, that is used to initiate the authorization code flow.

The path is /sap/bc/sec/oauth2/client/grant/authorization. The only required parameter is profile, that is set to the value Z_GOOGLE_CALENDAR.

The AS ABAP system will first authenticate the user and then derive the OAuth 2.0 client from the given profile. It will then construct the authorization request URL and redirect the user’s browser to the authorization server’s authorization endpoint.

Redirection to Google’s authorization endpoint

The AS ABAP will then redirect the end user’s browser to Google’s authorization endpoint. The end user has to authenticate with his Google Account and will then see the consent screen to grant the requested scope to the AS ABAP.

Redirection back to the grant application

After the end user gave their consent and authorized the clients request for the scope

https://www.googleapis.com/auth/calendar.readonly,

their browser is redirected back to the AS ABAP and the OAuth 2.0 Authorization Code flow is completed.

After that the AS ABAP has an Access Token and a Refresh Token for the end user that authenticated at Google’s authorization server.

After completing the authorization code flow the AS ABAP system will redirect the end user’s browser to the grant application because that was configured as target application in the field “Target Endpoint “ of the Oauth 2.0 Client configuration. (See also section "Create an OAuth 2.0 Client Configuration" step "Configure the Redirection URI ...")

In the grant application the status “Access possible” with infinite expiry time is displayed.

 

Use OAuth 2.0 Tokens

TaskDescription
Test the scenarioUse the test report ZGOOGLECALENDAR described in section "" to test the OAuth 2.0 protected access of the AS ABAP to the Google Calendar API.
Start transaction SE38

Start transaction SE38 to execute the test report ZGOOGLECALENDAR. This report will use the OAuth 2.0 Client API to set the access token in the HTTP client. If the access token has expired, the report will execute the refresh flow using the OAuth client API and request a new access token using the available refresh token.

Execute the report ZGOOGLECALENDAR

When an access token is available, the report will read and display the calendar data of the user who authenticated at Google’s authorization server.

 

Troubleshooting

If required, a description can be found in the article " Troubleshooting ".

 

  • No labels

5 Comments

  1.  

    Dear Joachim,

    We are replacing MS outlook gy google mail. I need to implement a functionality in SAP R/3 (NW7.40) that shows the user the gmail userinterface in chrome , and opens a new mail with a attchement. The functionality should be triggered by the user from R/3 then pushing a button. I think using the Google mail APIs is the right way to implement the functionality and I like to follow your guide. However the  transaction OA2C_TYPES does not exist in our system. Is there any other way to define a service provider type for Google in SAP?

    Best regards,

    Peter

    1. Former Member

      Dear Peter,

      transaction OA2C_TYPES is available from 7.40 SP08 onwards (it is delivered together with the OAuth 2.0 Client functionality).

      Please see also the section Prerequisites on the introduction page: http://wiki.scn.sap.com/wiki/display/Security/OAuth+2.0+-+Integrating+access+protected+web+services+using+the+OAuth+2.0+Client

      Best regards,

      Joachim

  2. Former Member

    Hi Joachim,

    I'm facing the problem when I try to test the Oauth Token request using t-code OA2C_GRANT (excatly followed your blog post Access Google APIs using the OAuth 2.0 Client API)

     

    but i get the following error   "missing grant_type" parameter when requesting for token froom google.

    Please suggest..

     

    H HTTP> ab_HttpCleanupHandler (plugin handle: 2, role: 1, protocol: 2)
    H HTTP> ab_HttpSearch (plugin handle 2 not found)
    N OA2C: error=invalid_request
    N OA2C: error_description=Required parameter is missing: grant_type
    N OA2C: >>> CL_OA2C_CLIENT_PROTOCOL_UTILS=>HANDLE_ERROR_RESPONSE
    N OA2C: HTTP-Errorcode: 400
    N OA2C: Error: invalid_request Required parameter is missing: grant_type
    N OA2C: Error-URI:
    N OA2C: Protocol Error sending access token request.
    N OA2C: Source position:
    N Mon Jan 19 15:39:57 2015
    N OA2C: Program: CL_OA2C_CLIENT_PROTOCOL_UTILS=CP
    N OA2C: Include: CL_OA2C_CLIENT_PROTOCOL_UTILS=CM002
    N OA2C: Source: 18
    N OA2C: SENDING REDIRECT:

     

     

    Regards

    Karthik

  3. Depending on the configuration of gateway , we need to choose which  PSE to import the Google certificate into.  First execution of the service via gateway client should provide a trace in SMICM which identifies the SSL PSE being used. The certificate needs to be imported into the same.

  4. Hello,

    Great blog! Thank you so much for sharing your knowledge!

    I was able to access Gmail thru API with OAuth 2.0 authentication. I'm wondering if I want to access multiple e-mail accounts if I have to create as many client configurations and grant each one or if I can grant once one by one in the same client profile... Since the API has the option to implicitly indicate the e-mail address we want to reach, I have some hope that if I want to access to 1000 different inbox, I don't have to perform the whole backend configuration and client id configuration for each.

    Sorry if I don't explain my goal very clearly. Any idea if it's possible?

    Thank you.

    Best regards,
    Marco Silva