REST action – adding files to Google Drive

Applies to version 2019.1; author: Tomasz Pytlak

 

Introduction

Working with attachments is one of the basic functionalities in WEBCON BPS. Some processes, such as document repository, are only used to catalog and make files available to selected users. In others, the attachments may be of secondary importance.

For example, when you want to work on a file together with your client, a good solution may be the integration of WEBCON BPS with file storage such as One Drive or Google Drive. It allows you to avoid situations where you have several different versions of the same document because the changes made by you and by the client are not merged.

 

Google API preparation

The process preparation should start with the Google API configuration – see https://developers.google.com/drive/api/v3/about-sdk.

First, go to https://console.developers.google.com/, log in with your Google account and select a project from the list or create a new one.

 

Fig. 1. Google projects

 

In the "Library" tab search and activate "Google Drive API" - this is the extension allows the client to communicate with Google Drive resources. 

 

 

Fig. 2. API selection

 

Next, in the “OAuth consent screen” tab, select which type of users (internal or external) will have access to API.

 

Fig. 3. User type selection

 

Click the “Create” button and name the application. You can also add a logo, indicate domains, and set contact e-mail for users.

 

Fig. 4. Configuration of the application

 

Go to the “Credentials” tab and create a new OAuth client using the “Create credentials” button.

 

Fig. 5. Adding the OAuth client

 

In the configuration specify the name and type of the application.

 

 

FIg. 6. The OAuth client configuration

 

After creating the client, go to their configuration and remember the Client ID and Client secret parameters – they will be needed to obtain a token.

 

Fig. 7. The OAuth client configuration

 

Creating tokens

To create a refresh token, make two invokes – see here: https://developers.google.com/identity/protocols/oauth2/native-app#loopback-ip-address.

The first invoke is used to obtain the authorization code. In the following call you must replace {ClientID} with the correct Client ID described in the previous chapter.

https://accounts.google.com/o/oauth2/v2/auth?scope=https://www.googleapis.com/auth/drive&response_type=code&state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&redirect_uri=http://127.0.0.1:80&client_id={ClientID}   

Due to security policy, a warning about the unverified application will be displayed on the screen. This verification is possible but requires contact with Google and it is not required at this moment. Just expand the “Advanced” tab, accept the risk, and confirm the access.

 

Fig. 8. The confirmation window

 

In response, the code parameter will be displayed in the URL address – save them and paste into the next invoke (it has a specific validity). A possible appearance of the 404 error is related to the lack of the application hosted at the address indicated as redirect_url. The parameters in the URL should be available even in this case.

The second invoke is used to convert the obtained code to the token. This is a POST type invoke – use dedicated software e.g. Postman.

Select POST, indicate endpoint https://oauth2.googleapis.com/token and in the “Body” tab fill in 5 parameters:

• Code –  value obtained from the previous invoke
• Client_id  - client ID in the same way as in the previous invoke
• Client_secrets – value available in client parameters under Client ID
• Redirect_url – server that receives the response (local server)
• Grant-type – “authorization_code” value

 

Fig. 9.Invoke in Postman

 

When copying the value, it is worth paying attention to whether white space I pasted at the end of the parameter.  

In response, the Google Drive API sends 5 values, the most important of which for the workflow described below is refresh token. It allows you to periodically refresh the access token.

 

Fig. 10. Response in Postman

 

Maintaining the API token

Since the access token is only valid for an hour, and additionally it needs to be made available for the system, it is best to create a technical workflow. It will be to store this token and periodically renew it using the “Invoke REST Web service” action.

The example workflow: 

 

Fig. 11. The workflow

 

When registering an instance, fill in the call parameters in the form. Two first parameters can be found in the client configuration, the third is set to the constant “grant_type” value and the fourth – is a refresh token obtained in the previous invoke

 

Fig. 12. The technical workflow during registration

 

On entry to the “Active” step, the “Refresh Token” (Invoke REST Web Service) action has been added – set the Authentication type as a custom and indicate the request endpoint.

 

Fig. 13. Refresh token - Authentication tab

 

In the “Request data” change the HTTP method to POST.

 

Fig. 14. Refresh token - Request data tab

 

In the “Request body” invoke parameters have been entered.

 

Fig. 15. Refresh token - Request body tab 

 

In the “Response” tab define mapping of the obtained access token on the form.

 

Fig. 16. Refresh token - Response tab

 

Additionally, a Timeout has been added to the step that will perform an automatic call to renew the token every 50 minutes.  

 

FIg. 17. The technical workflow after obtaining the access token

 

After going through the registration path, the first access token is downloaded and the system will automatically renew them in at a given time interval.  

 

FIg. 18. Technical workflow after obtaining the access token

 

File publication - example

We want to send to Google Drive the last attachment added to the form. On the “Register” transition path add the “Invoke REST Web Service” action called “Send file”. In the “Authentication” tab use the anonymous authentication and indicate the appropriate endpoint - https://www.googleapis.com/upload/drive/v3/files.

 

Fig. 19. Send file – Authentication tab

 

In the “Request data” tab change the method type to POST and add two parameters:

• Authorization – access token is downloaded using the business rule from the technical workflow
• uploadType – multipart which is one of the three available transfer types next to “media” and “resumable”. This method is recommended for files up to 5MB. For more information see - https://developers.google.com/drive/api/v3/manage-uploads.

 

Fig. 20. The “Att: Authorization” tab

 

The “Request body” tab contains data about the file:

• Body type – multipart allows you to send both metadata and binary data within one request
• JSON part headers – “Content-Type:application/json” header
• JSON part value – metadata that contains the file name in the “name” parameter
• Binary part header – contains “Content-Type” parameter with information about the file type
• Binary part value –  contains binary data to be sent. There are three available modes:
  • Providing the attachment ID in WEBCON BPS database
  • Providing data in the Data URL format which allows you to send e.g. picture form field content
  • Any text content other than in the above sections

 

Fig. 21. Send file - Request body tab

 

There are three business rules that can be seen in the screenshot above. The “Att: ID” rule is the basis for the others. It contains a SQL query that returns the ID of the last added attachment added to the current instance.

 

Fig. 22. The “Att: ID” rule

 

The “Att: Name” and “Att: Content type” rules are based on the “Att: ID” and new, predefined functions and return the attachment name and their type.

 

Fig. 23. The “Att: Name” rule

 

Fig. 24. The “Att: Content type” rule

 

To test the workflow, add an attachment and go through the registration path.

 

Fig. 25. Attachment on the form

 

The file will be added to Google Drive.

 

Fig. 26. Attachment added to Google Drive

 

Summary

The standard action available in WEBCON BPS allows integrating with many external software providers such as Google Drive. You can use it to transfer files or maintain an active access token.