MENU
  1. ホーム
  2. ブログ
  3. Qlikでコピろー！
  4. Qlikのライトテーブル(Write Table)に書き込んでみる 〜その２〜

Qlikのライトテーブル(Write Table)に書き込んでみる 〜その２〜

Qlikでコピろー！

2026年2月、Qlik Cloud上で事件が発生しました。
Qlik Cloud上の利用状況を管理できるアプリ「Entitlement Analyzer」が一斉に止まったのです。
あるお客様から「Entitlemente Analyzerにログが落ちていないようなんです」と連絡があり、他のお客様も確認してみたのですが、すべてのお客様で同じ事象が発生していました。
原因は、QlikのAPI KEYを作成する権限の仕様変更のようです。
API KEYを作成する権限を独立させたようで、デフォルトの設定で作成されたAPI KEYが無効化されたためにAPI接続ができなくなったという経緯みたいです。
何か、事前にアナウンスあったっけ？
多分、僕が知らなかっただけなんでしょうね😂
実は今回のコンテンツにも関係するので、その辺りも触れていきます。

で、なんだっけ?
そうそう、「ライトテーブル（Write Table）の変更ストアのデータを永続的に使えるようにする」という記事を書こうとしていたんだっけ…
ではでは、解説していきます。

目次

ライトテーブルからデータを取得する２つの方法

ライトテーブルのデータはQlikアプリとKEYで関連付けられた「変更ストア」に保存されることは前回お伝えしました。この変更ストアは実際にはQlikアプリ内にはないと思われるので、アプリ内で通常のロードスクリプトで取り扱うことはできません。
では、どうやって、変更ストアのデータを取り出すのか…
方法は以下の２つです。

  1. Qlikアプリから変更ストアにREST APIで接続して、データを取得し、Qlik アプリに渡す
  2. Qlik Automateを使用して、変更ストアからデータをファイルに出力するか、DBに連携させ、Qlikアプリでロードする

いずれにしても、運用を考えると、以前のデータをUPSERT（更新の対象は更新し、以前無かったデータは追加）する必要があるので、ファイルかDBに書き出すことになります。
Qlikのアプリを開発するユーザは必ずしもIT部門の方とは限りません。ライトテーブルのためにDBサーバ立ててもらうというのは大企業になればなるほど面倒ですので、ファイルで管理したほうが手っ取り早いですよね。
ではQlikアプリから扱うか、Qlik Automateで扱うかですが、皆さんはQlikアプリのほうが身近だと思いますので、今回はQlikアプリで変更ストアからデータを取得して管理していく方法を解説していくことにします。

APIキーの作成

今回はREST APIで接続しますので、そのためには事前にAPIキーを作成する必要があります。
で、冒頭ご説明したようにAPIキーを作成する権限は厳格化されていますので、Qlik Cloudの管理コンソールでAPIキーを作成する権限を設定していきます。
まずは、管理 > ユーザーを管理 > 権限タブを開くと右上に[User Default]と[新規作成]というボタンがありますでので、[User Default]をクリックして、デフォルトの状態を確認してみます。

機能とアクション > 開発者 を開くと「APIキーを管理」が「不許可」になっていることがわかります。
誰もがAPIキーを作成できてしまうと、セキュリティ上問題がありますので、ここで「許可」にしてしまうのは問題がありますよね。
ですので、今度は[新規作成]ボタンを押して、新しいロールを作成します。
名前は”API Key Admin”などにして、機能とアクション > 開発者 > APIキーを管理 を「許可」にし、[確認]ボタンを押して登録します。

「API Key Admin」というセキュリティロールができたところで、「API Key Admin」を開いて、[割り当て]ボタンを押して、APIキーを作成するユーザーを追加します。

これでAPIキーを作成する準備ができましたが、ここでAPIキーは作成せず、APIキーの有効期限を決定しておきます。
というのはですね、デフォルトの有効期限が短すぎるからなんです。確か１日だったかな😄
管理 > 設定 でスクロールしていくと、APIキーの設定が出てきますので、「トークンの最大有効期限を変更」で最大日数を設定します。
ここは自己責任にはなってしまいますが、Qlikさんは「セキュリティ上、有効期限は 90 日以下にすることをお勧めします」と書いていますので、90日などで設定しておきましょう。
近年では、API接続が主流になってきましたので、余り長い期間で設定するのは確かにリスクはありますよね。

管理 > APIキー を選択し、[新しく作成]ボタンをクリックすると「新規APIキーの生成」ダイアログが開きます。

APIキーの説明は、ここでは”Write Table”としておきました。有効期限はドロップダウン表示になっていますので、任意に期限を設定しましょう。3ヶ月とかがいいのかな？

上記の画面で[作成]ボタンを押しますと、以下のようにAPIキーが作成されました。
このAPIキーはエディタなどにコピーして、安全な場所に保存するようにします。画面上のアラート表示のように、二度と表示できなくなりますので。

RESTコネクタの設定

RESTコネクタを設定する前に、ストアIDを取得しておきます。
ストアを変更 > ストアIDを変更 のコピーボタンを押して、安全な場所に保管しておきます。

データ接続の作成はデータコネクタから「REST」を探し、クリックして接続の設定画面を表示します。

RESTコネクタの接続を以下のとおり、設定します。
（基本的にはTimeoutやMethodがデフォルト設定で問題ありませんので、設定が必要な箇所のみご説明します）
RequestのURLはテナント名と上で保存した「変更ストアのストアID」を挿入して設定します。
またQuery headersでは、Nameには”Authorization”と入力し、ValueにはBearerと入力し、スペースの後に「APIキーの作成」で保管したAPIキーを貼り付けます。

項目設定
Request > URLhttps://<テナント名>.qlikcloud.com/api/analytics/change-stores/<変更ストアのストアID>/changes/tabular-views
Request > Query headers > NameAuthorization
Request > Query headers > ValueBearer <APIキー>

YouTube動画などでは、Query parametersでName: Limit, Value: 100を入れると解説しているものがありましたが、これを入れると、変更ストアから100行しか取得できなかったので、僕はいらないんじゃないかなあと思っています。
僕の環境ではQuery parametersは入れなくても動作していますが、もしかしたらライトテーブルにはデータの上限があるのかもしれませんね。

設定が終わったら、[接続をテスト]して、成功したら、Nameで接続名を設定して、[追加]ボタンをクリックして登録は完了です。

Qlikのロードスクリプトの生成

データロードエディタで、新しいセクションを追加して、先程作成したRESTコネクタでの接続で「データを選択」アイコンをクリックしてデータ選択画面を開きます。

Tablesのroot/dataのチェックボックスをONにしますと、変更ストアがプレビューされます。
ライトテーブル側で何も登録がないと、rootの下にdataが出てきませんので、注意して下さい。
ダミーでも結構ですので、一旦はライトテーブルの「編集可能な列」に何らかの値が入力されている必要があります。
データのプレビューができて、想定どおりの項目が表示されていたら[スクリプトを挿入]ボタンをクリックします。

以下のように、スクリプトが生成されました。
編集可能な列である[コメント]はコメントのあとに括弧つきでストアIDが付与された形で取得されます。

LIB CONNECT TO 'dev:REST_WT_fdmt';

RestConnectorMasterTable:
SQL SELECT 
	"__KEY_root",
	(SELECT 
		"updatedAt",
		"updatedBy",
		"コメント(<ストアID>)",
		"店舗ID",
		"__FK_data"
	FROM "data" FK "__FK_data")
FROM JSON (wrap on) "root" PK "__KEY_root";

[data]:
LOAD	[updatedAt],
	[updatedBy],
	[コメント(<ストアID>)],
	[店舗ID],
	[__FK_data] AS [__KEY_root]
RESIDENT RestConnectorMasterTable
WHERE NOT IsNull([__FK_data]);


DROP TABLE RestConnectorMasterTable;

このスクリプトは効率がよくないので、プリシーディングロードを使用して、以下のように修正しておきます。
今回は、CommentテーブルにLoadして、初期データとして、Amazon S3にComment.csvとしてStoreするように書き換えておきました。
これをリロードすると、S3の所定のディレクトリに変更ストアの必要な項目が、CSVファイルとして出力されます。
変更ストアからロードされたデータをプレビューするときちんと取り込まれていることがわかります。

LIB CONNECT TO 'dev:REST_WT_fdmt';

Comment:
Load 
    [店舗ID],
	[コメント(<ストアID>)] as コメント,
	Timestamp([updatedAt]) as 更新日時
    WHERE NOT IsNull([__FK_data]);
SQL SELECT 
	"__KEY_root",
	(SELECT 
		"updatedAt",
		"updatedBy",
		"コメント(<ストアID>)",
		"店舗ID",
		"__FK_data"
	FROM "data" FK "__FK_data")
FROM JSON (wrap on) "root" PK "__KEY_root";

Store Comment into [lib://<Path>/Comment.csv](txt);

変更ストアのデータを管理するためのスクリプト

以上で、変更ストアのデータがS3に格納されました。
しかし、変更ストアは前回の記事でお伝えしたように、90日でデータは消えてしまいますので、その対策を施す必要があります。
今回は、ライトテーブルに書き込んだ後で、登録を確認できるように「パーシャルリロード(Partial Reload)」できるようにしておきますね。
ご存知ない方のために補足しますと、このパーシャルリロードは全体をリロードしなくても、一部のみデータを追加したり更新するリロードの方法です。
Load…　の前にReplace（テーブルを置き換える）またはAdd（テーブルに追加する）を追加すれば、Qlik側がパーシャルリロードと判断して、この部分だけリロードしてくれます。
ロードスクリプトを以下のように変更しておきます。

LIB CONNECT TO 'dev:REST_WT_fdmt';

//Commentテーブルの置き換え
Comment:
Replace Load 
    [店舗ID],
	[コメント(<ストアID>)] as コメント,
	Timestamp([updatedAt]) as 更新日時
    WHERE NOT IsNull([__FK_data]);
SQL SELECT 
	"__KEY_root",
	(SELECT 
		"updatedAt",
		"updatedBy",
		"コメント(<ストアID>)",
		"店舗ID",
		"__FK_data"
	FROM "data" FK "__FK_data")
FROM JSON (wrap on) "root" PK "__KEY_root";

//Commentテーブルに対して店舗IDがない既存のデータから追加
Add Load 
	店舗ID,
    コメント,
    更新日時
From [lib://<Path>/Comment.csv]
(txt, utf8, embedded labels, delimiter is ',', msq)
Where Not Exists(店舗ID);

Store Comment into [lib://<Path>/Comment.csv](txt);

上記のスクリプトでは、以下のように動作するように作成しました。
変更ストアのデータをCommentテーブルにロードします。ここでは、Replace Load…していますので、既存のCommentテーブルがあれば、置き換えられます。
ここで、Commentテーブルは、パーシャルリロードの場合は置き換えですが、フルリロードの場合は、通常のリロードが行われます。
Add Reload…では、直前に作成したれCommentテーブルにS3からデータを追加しますが、Where Not Exists(店舗ID)として、Commentテーブルの店舗IDに存在しない店舗IDのデータをComment.csvから追加します。
動作的にはConcatenateしていると考えて下さい。
また、今回は、店舗IDだけをキーにして更新していますが、年度毎にコメントを残したい場合などは、スクリプトを工夫する必要があります。
複数の項目でExistsで処理する場合については、また別の機会にご説明したいと思います。

更新ボタンでパーシャルリロードしてみる

シート上に[更新]ボタンを配置し、ライトテーブルで書き込んだデータを即時にアプリに反映させるようにパーシャルリロードを実行するように設定していきます。

ボタンアクションで、「データのリロード」を選択し、部分的なリロードにチェックを入れます。
この状態で、2行目のコメントを追加し、[更新]ボタンを押してみます。

パーシャルリロードが実行されたら、ライトテーブルに「コメント」（これはライトテーブルの「コメント」ではなく、アプリ内のCommentテーブルにある「コメント」という項目です）を追加し、ラベルを「登録済みコメント」と設定します。

Commentテーブルの「コメント」に2行目の項目が追加されているのがわかると思います。
ライトテーブルですが、このようにアプリ内に取り込まれた値と「編集可能な列」は別物ですので、並べておくような構造しておくと良いと思います。

まとめ

以上、長くなりましたが、ライトテーブルのデータをCSVデータとしてStoreして、データを保全する方法をご紹介しました。
設定のために、APIキーとストアIDを使いましたよね。
APIキーは、RESTコネクタで変更ストアに接続するためのキーなので、変更ストアがいくつになっても共通です。もちろん、セキュリティのために複数持っても構わないのですが、キーの期限が来ると接続できなくなることを考えると増やしすぎると管理できなくなるかもしれません。
一方、ストアIDは変更ストアの数だけできます。変更ストアの数だけできるということは、ライトテーブルの数だけできるということになります。
RESTコネクタでの接続では、URLでストアIDを指定する必要がありますので、ライトテーブルの数だけ接続を作成する必要があります。

どうでしたか？
記事は長いですが、設定自体は難しくはありません。
変更ストアのデータ保全のスクリプトは簡素な方法で作成してみましたが、皆さんの環境に合わせて組んでみて下さいね。

新機能のライトテーブルは、アイディアしだいで、色々応用できそうですよね。
ではまた！

関連記事はこちら
Qlikのライトテーブル(Write Table)に書き込んでみる 〜その1〜

Qlikでコピろー！
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

Yokoのアバター Yoko

関連記事

目次