Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Authorizing SAP Build Process Automation to automate Google Applications

former_member43401
Employee
Employee
‎11-14-2022 1:25 PM

Introduction


In this blog post, I am going to take you through the Google Authorization SDK and will be covering,

  •  Authorization mechanisms supported by the SDK.

  •  When to use which mechanism ?

  •  How to use the activities ?


SAP Build Process Automation enables users to automate Google Workspace Products such as Gmail, Google Drive, Google Sheets, Google Docs, Google Calendar and other services such as Google Cloud Storage, Document AI and Vision AI.

The below mentioned SDKs must be added to the project to automate the respective Google Applications.

  • Google Authorization SDK

  • Google Workspace SDK

  • Google Cloud Storage SDK

  • Google Document AI

  • Google Vision AI SDK


The Google Authorization SDK is mandatory for authorizing SAP Build Process Automation to Google Applications. It contains activities to support authorization mechanisms such as Service Account and OAuth. The Authorize activity must be used before any Google SDK Activity and the Disconnect activity must be used at the end of the automation.


Fig 1 : Google Authorization Activities


 

Authorization using Service Account


Service account differs from user accounts and it will be used by a software application to make authorized API calls. The service account can also be authorized to access data on behalf of users in a domain without their consent by enabling Domain-wide delegation.

The service accounts should be created and configured through Google Cloud Console before using the activity. Here are the steps to Setup Service Account.

Note: Download the Service Account Key in JSON format and save it safely on your local machine to avoid credential leakage, which is a major risk when using the service account approach.

When and How to use the service account activity?


The Authorize Google (Service Account) activity is used to authorize using service account and the same activity is supported on Desktop Agent 2.0 and Desktop Agent 3.0. Once the activity executes successfully, the bot is authorized to execute any subsequent google activities.

The Bot using Service Account Authorization doesn’t require any human intervention such as providing the user consent or credentials. Hence this will be a suitable choice for unattended scenarios.

To perform actions on behalf of the user, Domain Wide Delegation must be enabled for the service account, and the user's email address is mandatory. For instance, the user's email is required in order to send emails or schedule events on the Google calendar. However, neither the user's email address nor Domain Wide Delegation are required for services like Google Document AI and Vision AI.


Fig 2 : Activity to Authorize using Service account



Input Parameters:



  • serviceAccountKeyPath: The fully-qualified path of the downloaded JSON file.


                     Example : C:\temp\client_secret.json

  • scopes: Scopes provide a way to limit the amount of access that is granted while authorizing, the corresponding scopes required for the subsequent activities should be selected. The subsequent google activities will fail, if the scopes were not appropriate.


                     Example : GmailScope and GoogleDriveScope must be selected, if the automation                                               contains Gmail and Drive Activities.

  • userEmail : The user's email address to perform actions on behalf of them. Domain-wide delegation is mandatory if user's email is provided


                     Example: user@domain.com

Note : The value for the parameters like serviceAccountKeyPath and userEmail can be directly provided as strings, but it is advisable to use environment variables which can be shared across automations in the given environment.

Authorization using OAuth 2.0 Client ID


OAuth 2.0 is an industry standard, token-based user authorization mechanism. The client must be registered through Google cloud console and the JSON credential file which contains Client ID and Client secret should be downloaded to a safe location. Here are the steps to Setup OAuth Client.

When an user runs the bot for the first time, The user consent screen with the scopes will be launched on the browser window. Once the user consent is given, the access token and refresh token will be generated. The user can configure the activity to store these tokens and use it for subsequent bot runs without user intervention. When the refresh token expires or the scopes change, re-authentication and re-authorization are necessary. Every unique combination of client Id, email ID and scopes requires the user's consent on each system running the bot for the first time.

When and How to use OAuth activity?


OAuth approach is preferred over service account, when accessing user resources and retrieving user data is the use case.

Example: Accessing the Drive files of the user, Scheduling a Calendar Event, Replying to an Email etc.

The Authorize Google (OAuth Client ID) activity is used to authorize using OAuth Client and the same activity can be used for both Desktop Agent 2.0 and Desktop Agent 3.0. Once the activity executes successfully, the bot is authorized to execute any subsequent google activities.

 


Fig 3 : Activity to Authorize using OAuth Client ID


While running the bot, the browser will be launched for user Authentication. After successful authentication, the consent screen will be prompted with the selected scopes, where the user has to verify the scopes and provide their consent.


Fig 4 : OAuth Consent Flow



Input Parameters:



  • clientCredentialFilePath: The fully-qualified path of the OAuth Credential File.


                    Example : C:\temp\client_secret.json

  • scopes : Scopes provide a way to limit the amount of access that is granted while authorizing, the corresponding scopes required for the subsequent activities should be selected. The subsequent google activities will fail, if the scopes were not appropriate.


                    Example : GmailScope and GoogleDriveScope must be selected, if the automation                                               contains Gmail and Drive Activities.

  • userEmail : The user's email address is mandatory. Because, the OAuth Approach is used to perform actions on their resources.


                    Example: user@domain.com

  • storeRefreshToken:  The refresh tokens can be configured to be stored, in order to build unattended bots. However, the first bot run will be attended, since the user consent screen will be launched and user has to provide their consent.

  • webBrowser : Select the web browser to be launched for completing Google Authorization.


Note : The value for the parameters like clientCredentialFilePath and userEmail can be directly provided as strings, but it is advisable to use environment variables which can be shared across automations in the given environment.

How to use OAuth Client ID Authorization Mechanism on Desktop Agent 3.0?


Desktop Agent 3.0 has an optimized way to use the OAuth mechanism as summarized.

  • The Authentication details can be configured and operated centrally on SAP Build Process Automation Tenants. Hence the bot developer is less concerned about configuration.

  • The Authorization can be done directly through the agent. So that the tokens can be fetched before running the bot, which makes the bot unattended right from the first run.


SAP Build Process Automation External Authentication Configuration


The Tenant-Specific Configuration can be done on External Authentication Section of SAP Proces Automation Settings. Here the client id, secret and scope should be provided. The Scope selection is based on the type of google application being automated. This configuration can be identified using the name. As shown in the below diagram, The configuration is stored on the cloud and identified as Google Workspace Authentication.


Fig 5 : SAP Build Process Automation External Authentication Configuration


Once the configuration is done, this configuration will be shared to all the connected agent machines. These details will be available on External Authentication section of Agent 3.0 Settings. Here the user has to register by providing the email id and can mark it as default Authentication. The user can also unregister the registered authentication.


Fig 6 : Desktop Agent 3.0 External Authentication Settings


While registering, the consent screen will be launched on the browser window automatically, where the user will be prompted to enter their password and provide consent for the scopes configured on the SAP Build Process Automation Tenant.

After successful registration, the user can use Select Google Authentication activity for Authorization.


Fig 7 : Activity to Authorize using OAuth Client ID - Desktop agent 3.0


Here the only parameter required is name, In our case it is Google Workspace Authentication as configured on the SAP Build Process Automation Tenant.

If the parameter is not provided, the default authentication will be used. Once the execution of the activity is successful, the bot is authorized to execute any subsequent google activities.

Useful Resources:



 

Find more information on SAP Intelligent RPA:
1 Comment
Labels in this area
Popular Blog Posts