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

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

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

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

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

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

目次

はじめに

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

DataStoreとは？

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

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

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

DataStoreの作成方法

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

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を加工したものを読み込ませてみます

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

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