Overview

This module helps in accessing the files in Google Drive using Google Drive API.

The below mentioned APIs are available in the module,

• COPY File
• CREATE File
• DELETE File
• GET File
• LIST File
• UPDATE File

Documentation

Typical usage scenario

Google Drive Connector wraps the Google Drive API v3 file endpoints in seven Mendix microflows. Each one takes an OAuth access token as a String parameter and performs one REST call — create, update, copy, delete, get metadata, download content, list — using nothing but standard Call REST service activities and JSON import mappings. The Drive file resource is modelled as a set of non-persistable entities, so a listing or a metadata read comes back as objects you can put straight into a data grid. A set of test pages exercises every call so you can confirm your credentials before writing any logic of your own.

Use it wherever files should live in Drive rather than in your Mendix database:

• Archive completed documents out of the app. When a case closes, call SUB_Drive_File_Create with the System.FileDocument and a small metadata JSON, store the returned Drive file id on your record, and delete the local file.

• Offload file storage from the Mendix database. Uploads that would otherwise sit in FileDocument rows go to Drive instead, and SUB_Drive_File_GetAsDocument streams them back on demand with Delete after download set, so nothing accumulates server-side.

• Share a generated report with people outside the app. Upload the PDF or spreadsheet, then read WebViewLink and WebContentLink from the response and mail those to the recipient. No Mendix user account and no anonymous page needed.

• Back up exports on a schedule. A scheduled event that pushes a nightly CSV or Excel export to Drive gives you off-platform copies with Drive's own version history, without any file share, SFTP endpoint or cloud SDK.

• Show a Drive folder inside your app. SUB_Drive_File_List with a q= query returns the file list mapped into GoogleDriveFile objects — name, size, MIME type, owner, thumbnail link, modified date.

• Replace an existing document in place. SUB_Drive_File_Update patches both content and metadata for a known file id, so a revised contract keeps its Drive id, its link and its sharing settings.

The problem it solves is the one every Mendix app with attachments eventually hits: file documents grow the database, complicate backups, and are only reachable through the app itself. Talking to Drive directly means a REST client, multipart uploads, a token that expires every hour and a domain model for the Drive file resource — a few days of work before the first file moves. This module is that work already done, in a form you can read.

Features and limitations

• The JSON responses are already mapped. Three import mappings and three JSON structures are included, so you can extend them with fields you need.

• Search and field selection are open-ended. Params is appended to the URL as-is, so any documented Drive query parameter works — q=, fields=, pageSize=, pageToken=, orderBy=, spaces=.

• Downloads arrive as a normal Mendix file document, with Delete after download set in the example flow.

• Failures do not throw. Every REST activity has a custom error handler that logs and returns empty, so a Drive outage does not roll back your microflow.

• A working test app is included — eleven pages, seven ACT_ example microflows and a ReadMe snippet.

• Model-only implementation. No Java actions, no JavaScript actions, no JARs, no widgets, no npm packages.

Entities. GoogleDriveFile mirrors the Drive files resource across 38 attributes; GoogleDriveListRoot + FilesList carry the list response; Capabilities holds the 28 can… flags; plus owners, permissions, parents, spaces and link-share metadata. All response entities are non-persistable — nothing is written to your database except the Doc and TestGoogleDrive file documents.

Dependencies

All three of the following must be in place. Importing this module into an app that lacks them produces 21 consistency errors — 7 microflows × (one GoogleOAuthSettings retrieve + one Encryption.Decrypt call), plus the pages built on them. These are documented prerequisites, not defects; the errors disappear as soon as the two modules are present.

Installation

Order matters. Import the two prerequisite modules first, then this one.

1. Google Cloud console. Create or open a project. Under APIs & Services > Library, enable the Google Drive API.

2. Under OAuth consent screen, choose the user type, fill in the app details, and add the Drive scope you need. While the consent screen is in testing, add every Google account that will authorise the app as a test user.

3. Under Credentials, create an OAuth client ID of type Web application. Add your app's callback as an authorised redirect URI — with the Google OAuth 2.0 module this is <your app URL>/rest/oauth/v2/callback (locally, http://localhost:8080/rest/oauth/v2/callback). Copy the client id and secret.

4. Import the Encryption module and set its EncryptionKey constant. The same key must be in place when tokens are stored and when the Drive flows decrypt them.

5. Import the Google OAuth 2.0 module. Add its settings page to your navigation, grant its module role, and check that its published REST service (rest/oauth/v2) and SCE_RefreshToken scheduled event are enabled.

6. Now import this module — App Explorer > Import module package, select GoogleDriveConnector.mpk.

7. Check the error list. It should be empty. If you see errors on Encryption.Decrypt or GoogleConnectorOAuth2.GoogleOAuthSettings, step 4 or 5 was skipped, or the module was imported under a different name — references are by qualified name, so the modules must be called exactly Encryption and GoogleConnectorOAuth2.

8. Add Test_GoogleDrivePage_Overview to your navigation and grant the GoogleDriveConnector.Administrator module role. Every test page and ACT_ microflow is restricted to that role.

9. Run the app, open the Google OAuth 2.0 settings page, create a configuration and complete the consent flow so an access token is stored.

10. There is nothing to place in userlib and no npm install step.

Configuration

Constant — CONST_GoogleDriveURL, default https://www.googleapis.com, used by all seven calls. Leave it unless you route Google traffic through a proxy. Not exposed to the client. That is the module's only constant; everything else lives in the Google OAuth 2.0 module's GoogleOAuthSettings record, and the encryption key lives in the Encryption module.

Credentials record. Create one GoogleOAuthSettings record with ClientID, ClientSecret, RedirectURI (identical to the value registered in Google Cloud), and Scope. Authorise it, confirm an access and refresh token are stored, and set it Active. Keep a single record — the example flows retrieve the first one without any constraint.

Recommended first-run test

1. Open Test_GoogleDrivePage_Overview as a user with the Administrator module role.

2. Start with List — Include trashed off, Show metadata on, which builds ?fields=*&q=trashed=false. A populated grid confirms host, token, scope and mapping in one step.

3. Copy a file id into the Get page and run it.

4. Use the download button to confirm alt=media content downloads.

5. Only then try Create with a small file.

6. If a step fails, read the application log — each failure is logged under its own node name with the HTTP status and Google's error body. Note these are written at Info level, so set that log node to Info or lower.

Known bugs

None

Frequently Asked Questions

Why do I see 21 errors right after importing the module?

Because the two prerequisites are missing. Import the Encryption module and the Google OAuth 2.0 module and the errors clear — the module names must be exactly Encryption and GoogleConnectorOAuth2.

Which OAuth scope should I request?

…/auth/drive.file if the app only manages files it creates, …/auth/drive if it must see and change everything. Read-only and metadata-only scopes work for Get, List and download but make Create, Update, Copy and Delete fail with 403.

Can I use my own token instead of the Google OAuth 2.0 module?

Yes. Every SUB_ microflow takes AccessToken as a plain String, so any valid bearer token works. The dependency comes only from the ACT_ example flows, which you can exclude once you call the SUB_ flows from your own logic.

Does the module refresh the access token when it expires?

No. Refreshing is handled by the Google OAuth 2.0 module's SCE_RefreshToken scheduled event.

Can I upload into a specific Drive folder?

Yes, but not from the test pages. Add a parents array with the folder id to the metadata JSON you pass to Create.

Can I create a folder?

There is no dedicated microflow. In Drive a folder is a file with Google's folder MIME type and no content, so it is a matter of the metadata JSON you supply.

Can I share a file or set permissions?

No. The module reads the permission entries Drive returns with a file's metadata, but makes no call to the permissions endpoint. Share the file in Drive, then use WebViewLink or WebContentLink.

How large a file can I upload?

Create and Update use a single multipart request, recommended for roughly 5 MB or less; resumable upload is not implemented. 300 seconds per call, and all content passes through the Mendix runtime.

Does Delete move the file to the bin?

No — it removes the file permanently. For a recoverable delete, patch trashed to true with Update instead.

How do I get more than the first page of results?

Append pageSize and pageToken to the Params string and loop while NextPageToken is not empty. The token is mapped for you; the loop is yours to write.

Can I call this from a nanoflow, a native app or offline?

No. All seven operations are microflows and run server-side.

Why does Studio Pro show module version 1.0.0?

The module-level version metadata was not bumped when the package was rebuilt. The release is 3.0.0, published as tag V3.0.0; cosmetic only.

Issues, suggestions and feature requests:

https://github.com/bharathidas/Google-Drive-Connector/issues