make SaaS その他

make 基本操作編機能紹介：DataStores、DataStructures

投稿日 2024.12.09

この記事は「make Advent Calendar 2024」7日目の記事です。

このアドベントカレンダーについて

このアドベントカレンダーは25日間でIPaaS製品の「make」について使い方や、実践を学べる連続ブログ企画です。

「おかしん」「ばるす」「たにあん」の3名がリレー形式でお届けします。

25日間のスケジュールは以下の通りです。

日付	内容	担当
12/1	話題のIPaaS製品「make」とは	おかしん
12/2	makeで作ってみたScenario紹介	ばるす
12/3	make 基本操作編機能紹介：Organization	たにあん
12/4	make 基本操作編機能紹介：Scenario、Template	おかしん
12/5	make 基本操作編機能紹介：Connections	ばるす
12/6	make 基本操作編機能紹介：Webhooks	たにあん
12/7	make 基本操作編機能紹介：DataStores、DataStructures	おかしん
12/8	make 基本操作編機能紹介：Devices	ばるす
12/9	make 基本操作編機能紹介：Functions	たにあん
12/10	make 基本操作編機能紹介：CustomApps	おかしん
12/11	make 基本操作編機能紹介：Flow Control,Tools,Text parser	ばるす
12/12	make ドキュメント動線の話：ResourceHub	たにあん
12/13	make 検証：Make Bridge	おかしん
12/14	make 検証：Make REST API	ばるす
12/15	make 検証：AI Search	たにあん
12/16	make Community Hub：Overview	おかしん
12/17	make Community Hub：Academy Courses,Blog Articles	ばるす
12/18	make Community Hub：Showcase,CustomApps	たにあん
12/19	makeの管理運用の話：Github連携	おかしん
12/20	makeの管理運用の話：実行ログと再実行と停止中リクエスト滞留	ばるす
12/21	makeの管理運用の話：Connection権限管理	たにあん
12/22	makeで作ってみた事例：（未定）	おかしん
12/23	makeで作ってみた事例：（未定）	ばるす
12/24	makeで作ってみた事例：（未定）	たにあん
12/25	makeの総論を語る	ばるす

はじめに

MakeのDataStore機能は、シナリオ間でデータを保存・共有できる、いわばシンプルなデータベースのような機能です。今回は、このDataStore機能の基本から活用方法まで解説していきます。

DataStoreとは？

簡単に言えばデータベースです。機能的に最も近いのはAirTableあたりでしょうか？

DataStoreは以下のような用途で活用できます：

シナリオ実行時のデータ保存
異なるシナリオ間でのデータ共有
実行履歴の保持
一時的なデータの保管
中間テーブル

DataStoreの作成方法

左メニューから「Data stores」を選択
「Add data store」をクリック
以下の設定を行います：
- データストア名の設定
- データ構造の選択または作成
- ストレージサイズの設定（購入したプランの容量内で設定可能）

Data Structureについて

Data Structureは、データストアのテーブル構造を定義するものです。具体的には：

カラム名の定義
データタイプの指定
必須項目の設定

Data Structure作成の2つの方法

手動での作成

Add itemボタンでカラムを1つずつ追加
名前、タイプ、その他のプロパティを設定

設定可能なカラムのタイプには以下があります

Array（配列）
Collection（オブジェクト）
Date（日付）
Text（テキスト）
Number（数値）
Boolean（真偽値）
Binary Data（バイナリ）

なお、ArrayとCollectionはその要素として、上記のタイプ全てを取ることができます。次で説明するとおり、DataStructureはJSONから生成することもできます。つまりDataStructureの構造はJSONそのものです。

ジェネレーター機能の利用

こちらはすでに存在するJSONを読み込ませてDataStructureを生成する機能です

サンプルデータ（JSON等）を入力
自動的にデータ構造を生成
生成後に手動で調整可能

試しにMicrosoft Graphのユーザー情報のJSONを加工したものを読み込ませてみます

{
  "aboutMe": "String",
  "accountEnabled": true,
  "ageGroup": "String",
  "assignedLicenses": [{"@odata.type": "microsoft.graph.assignedLicense"}],
  "assignedPlans": [{"@odata.type": "microsoft.graph.assignedPlan"}],
  "birthday": "String (timestamp)",
  "businessPhones": ["String"],
  "city": "String",
  "companyName": "String",
  "consentProvidedForMinor": "String",
  "country": "String",
  "createdDateTime": "String (timestamp)",
  "creationType": "String",
  "customSecurityAttributes": {
    "@odata.type": "microsoft.graph.customSecurityAttributeValue"
  },
  "department": "String",
  "displayName": "String",
  "employeeHireDate": "2020-01-01T00:00:00Z",
  "employeeId": "String",
  "employeeOrgData": {"@odata.type": "microsoft.graph.employeeOrgData"},
  "employeeType": "String",
  "faxNumber" : "String",
  "givenName": "String",
  "hireDate": "String (timestamp)",
  "id": "String (identifier)",
  "identities": [{"@odata.type": "microsoft.graph.objectIdentity"}],
  "imAddresses": ["String"],
  "interests": ["String"],
  "isResourceAccount": false,
  "jobTitle": "String",
  "legalAgeGroupClassification": "String",
  "licenseAssignmentStates": [{"@odata.type": "microsoft.graph.licenseAssignmentState"}],
  "lastPasswordChangeDateTime": "String (timestamp)",
  "mail": "String",
  "mailboxSettings": {"@odata.type": "microsoft.graph.mailboxSettings"},
  "mailNickname": "String",
  "mobilePhone": "String",
  "mySite": "String",
  "officeLocation": "String",
  "onPremisesDistinguishedName": "String",
  "onPremisesDomainName": "String",
  "onPremisesExtensionAttributes": {"@odata.type": "microsoft.graph.onPremisesExtensionAttributes"},
  "onPremisesImmutableId": "String",
  "onPremisesLastSyncDateTime": "String (timestamp)",
  "onPremisesProvisioningErrors": [{"@odata.type": "microsoft.graph.onPremisesProvisioningError"}],
  "onPremisesSamAccountName": "String",
  "onPremisesSecurityIdentifier": "String",
  "onPremisesSyncEnabled": true,
  "onPremisesUserPrincipalName": "String",
  "otherMails": ["String"],
  "passwordPolicies": "String",
  "passwordProfile": {"@odata.type": "microsoft.graph.passwordProfile"},
  "pastProjects": ["String"],
  "postalCode": "String",
  "preferredDataLocation": "String",
  "preferredLanguage": "String",
  "preferredName": "String",
  "provisionedPlans": [{"@odata.type": "microsoft.graph.provisionedPlan"}],
  "proxyAddresses": ["String"],
  "responsibilities": ["String"],
  "schools": ["String"],
  "securityIdentifier": "String",
  "serviceProvisioningErrors": [
    { "@odata.type": "microsoft.graph.serviceProvisioningXmlError" }
  ],
  "showInAddressList": true
}

このように元のJSONの構造を保ったDataStructureが生成されます

Strictモードについて

Strictモードを有効にすると、定義されていない項目のデータは受け付けなくなります。データの整合性を保つために有用な機能です。

DataStoreの操作方法

主な操作モジュールには以下があります：

Add/Replace a Record：レコードの追加・置換
Update a Record：既存レコードの更新
Get a Record：レコードの取得
Delete a Record：レコードの削除
Search Records：レコードの検索
Count Records：レコード数のカウント

DataStoreの活用例

1. 重複チェックシステム

ユースケース

メールやSlackで受信した情報の重複登録防止
取引先からの注文の二重処理防止
WebフォームからのSubmit重複防止

実装例

1. DataStore構造:
   - Key: 一意の識別子（メールのsubject + 送信日時など）
   - Status: 処理状態
   - ProcessedDate: 処理日時

2. シナリオの流れ:
   a. 新規データ受信
   b. DataStoreで重複チェック
   c. 未処理の場合のみ後続処理実行

2. ステータス管理システム

ユースケース

案件の進捗管理
タスクの状態管理
承認フローの管理

実装例

1. DataStore構造:
   - Key: 案件番号
   - Status: 状態（新規/進行中/完了等）
   - AssignedTo: 担当者
   - LastUpdated: 最終更新日時
   - Notes: 備考

2. シナリオ連携:
   - ステータス更新シナリオ
   - 担当者通知シナリオ
   - レポート作成シナリオ

3. 一時データのキャッシュ

ユースケース

API呼び出し結果の一時保存
バッチ処理の中間データ保存
大量データの分割処理

実装例

1. DataStore構造:
   - Key: 処理ID
   - ChunkNumber: 分割番号
   - Data: 処理データ
   - ExpiryDate: 有効期限

2. 処理フロー:
   a. データの分割保存
   b. 順次処理
   c. 完了後のクリーンアップ

4. マスターデータ管理

ユースケース

商品マスター
取引先マスター
料金テーブル

実装例

1. DataStore構造:
   - Key: 商品コード
   - Name: 商品名
   - Price: 価格
   - Category: カテゴリ
   - LastUpdated: 更新日時

2. 利用シーン:
   - 価格計算シナリオ
   - 在庫確認シナリオ
   - 商品情報更新シナリオ

5. ロギングシステム

ユースケース

エラーログの保存
実行履歴の記録
監査ログの保管

実装例

1. DataStore構造:
   - Key: ログID
   - Timestamp: 発生日時
   - Type: ログタイプ
   - Message: メッセージ
   - Details: 詳細情報

2. 活用方法:
   - エラー分析
   - パフォーマンスモニタリング
   - コンプライアンス報告

より実践的な活用例

他のMake機能との連携

Webhookとの組み合わせ
スケジュール実行との連携
エラーハンドリングとの統合

外部システムとの連携例

CRMシステムとの同期
基幹システムとのデータ連携
分析ツールへのデータ提供

その他

私が真っ先に考えついたのは、SmartHRやEntraIDの中間テーブルとして機能する人事マスタのようなData Storeです。
Okta（Universal Directory）やSmartHRが雇用形態問わず全ての従業員に付与されていれば、それらをマスタとすれば良いですが、そうでない場合にSmartHRやEntraIDに存在していない従業員の氏名等をストアしておくことで、様々な自動化の際に利用することができます。

実装時のTipsと注意点

makeにおける注意点というよりは、一般的なデータベース設計についての注意点になる為、いくつかの例を羅列するにとどめます。

効率的なキー設計

検索性を考慮したキー設計
複合キーの活用
プレフィックスの活用による分類

パフォーマンス最適化

インデックスの活用
不要データの定期的なクリーンアップ
大量データの分割処理

セキュリティ考慮事項

センシティブデータの暗号化
- 暗号化および複合化を行うEncryptorというモジュールが存在します
アクセス権限の適切な設定
定期的なバックアップ

残念な部分

調査した限りでは、Data StructureやData Storeごとの権限設定、Data Storeのカラムごとの権限設定はできません。makeには後日解説予定ですが「Team」という概念が存在し、Data StructureやData Storeそのものや、中のデータを操作する権限は全てこの「Team」の権限に依存します。

また、その「Team」の権限も残念ながらそこまで細かく設定できません。詳しくはこちらに記載がありますが、以下の権限設定しかできません。

Team Admin: チーム内のすべてのデータに完全なアクセス権を持っています。カスタム関数を作成できるのはチーム管理者のみです。
Team Member: チーム内のすべてのデータに完全なアクセス権を持っていますが、チームメンバーの管理やチームの削除はできません。
Team Monitoring: チーム、シナリオ、およびテンプレートに対して閲覧専用のアクセス権を持っています。
Team Operator: チーム内のすべてのデータに閲覧専用のアクセス権を持っています。それに加えて、シナリオの有効化や停止、シナリオスケジュールの設定を行うことができます。
Team Restricted Member: チーム内のすべてのデータに完全なアクセス権を持っていますが、チームの変更はできません。

これをData StructureやData Storeの観点で分類すると以下のようになります

フルアクセス
- Team Admin: チーム内のすべてのデータに完全なアクセス権を持っています。カスタム関数を作成できるのはチーム管理者のみです。
- Team Member: チーム内のすべてのデータに完全なアクセス権を持っていますが、チームメンバーの管理やチームの削除はできません。
- Team Restricted Member: チーム内のすべてのデータに完全なアクセス権を持っていますが、チームの変更はできません。
閲覧権限
- Team Monitoring: チーム、シナリオ、およびテンプレートに対して閲覧専用のアクセス権を持っています。
- Team Operator: チーム内のすべてのデータに閲覧専用のアクセス権を持っています。それに加えて、シナリオの有効化や停止、シナリオスケジュールの設定を行うことができます。

また、別のTeamのData StructureおよびData Storeはシナリオ上で利用できない為、「シナリオは作ったり編集したりしたいが、Data StructureやData Storeは直接操作できない」といった権限管理はできません。

要するにシナリオを編集できるユーザーはData Store上のデータを直接操作できてしまうという欠陥があります。

せっかくポテンシャルの高い機能にも関わらず、権限管理ができないのであれば、高度な利用に耐えられない為、これに関しては弊社としてもmake社にフィードバックを行っていきたいと思います。

まとめ

DataStoreは、Makeのシナリオ間でデータを永続化・共有するための強力な機能です。適切なデータ構造の設計と、定期的なバックアップを行うことで、より安全で効率的なワークフローを構築することができます。

しかし、権限管理面で制限があり、センシティブなデータを扱うには不向き。

okash1n

香川大学医学部医学科中退→SES・情シス・SREを経てクラウドネイティブ入社。趣味はIT。

・有限会社脇屋代表取締役
・一般社団法人日本ビジネステクノロジー協会代表理事
・一般社団法人 SRE NEXT 理事
・情シスSlack、BTCONJP、SRENEXT運営

記事一覧

このアドベントカレンダーについて

はじめに

DataStoreとは？

DataStoreの作成方法

Data Structureについて

Data Structure作成の2つの方法

手動での作成

ジェネレーター機能の利用

Strictモードについて

DataStoreの操作方法

DataStoreの活用例

1. 重複チェックシステム

ユースケース

実装例

2. ステータス管理システム

ユースケース

実装例

3. 一時データのキャッシュ

ユースケース

実装例

4. マスターデータ管理

ユースケース

実装例

5. ロギングシステム

ユースケース

実装例

より実践的な活用例

他のMake機能との連携

外部システムとの連携例

その他

実装時のTipsと注意点

効率的なキー設計

パフォーマンス最適化

セキュリティ考慮事項

残念な部分

まとめ

okash1n

この記事をシェア