
ThoughtSpot CS Toolsのscriptabilityについてご紹介します
ThoughtSpot CS Toolsの概要のご紹介のページはこちらとなります。
ThoughtSpotのCS Toolsは以下の機能があります。今回はこのうち「scriptability」についてご説明します。
- archiver ・・・ プラットフォーム内の古い回答とライブボードを管理する
- bulk-deleter ・・・ プラットフォームからメタデータオブジェクトを一括削除する
- bulk-sharing ・・・ ブラウザ内でテーブルおよび列レベルのセキュリティをスケーラブルに管理する
- extractor ・・・ ワークシート、ビュー、またはテーブルからデータを抽出する
- git ・・・ 開発者にとって使いやすい方法でvsc/git APIエンドポイントを使用する
- scriptability ・・・ ThoughtSpot環境間でTMLをメンテナンスする
- searchable ・・・ ThoughtSpotでThoughtSpotメタデータを探索する
- usermanagement ・・・ ユーザーを一括管理する(現在ユーザー削除と所有オブジェクトの移転のみが行えます)
CS Tools「scriptability」とは?
CS Toolsのscriptability機能は、日本語だと「スクリプト化可能性」という名の通り、各コンテンツ(ライブボード、検索、接続、などあらゆるThoughtSpotのコンテンツ)をTMLでローカル環境に保存したり、ローカル環境に保存したTMLをThouhtSpot環境に書き戻すことができる機能です。つまり、一気にバックアップしたり、他の環境に移し替えたりといったことがスクリプト(バッチファイル)でできるようにする機能、ということになります。
たとえば、開発環境から本番環境にライブボードを移し替えたり、といったことも可能です(一度ローカル経由にはなりますが)。
全体(機能問わず)で共通のオプション
以下は、各機能共通のオプションになります(すべての機能で有効になるわけではないのでご注意ください)。
--config:コマンドの対象となるThoughtSpotのクラスタの接続先の設定ファイルを指定します。ほぼすべてのコマンドで必須です。
--temp-dir:一時ファイルが作成されるフォルダを指定します
--verbose:「cs_tools logs report」で出力することのできるログファイルについて、このオプションを設定するとより詳しいログを得ることが可能になります。
scriptabilityについて
CS Toolsのscriptability機能は、checkpointオプションとdeployオプションで構成されます。
checkpointオプションは、ThoughtSpotに存在するコンテンツのTMLをローカルに保存する機能で、deployオプションはローカルに保存されているTML(コンテンツ)をThoughtSpot環境に書き戻す機能です。
checkpointオプション
指定のフォルダにTMLを保存する機能です。
--directory:TMLファイルを保存するディレクトリです。指定必須項目です。
--delete-aware:このチェックポイントに存在しない場合、マッピングからTMLを削除します。
--log-errors:オンにすると、コンソールにTMLエラーを表示します。
--org:出力対象Orgです
--environment:TMLファイルを出力する環境名です
--metadata-types:対象となるメタデータを指定します。必須項目です。CONNECTION、TABLE、VIEW、SQL_VIEW、MODEL、LIVEBOARD、ANSWERを指定可能で、複数指定の場合はカンマ区切りで指定します。
--pattern:対象となるオブジェクトの名称を指定しますが、SQLのように%をワイルドカードとして利用可能です。
--authors:対象となるオブジェクトの保持ユーザーを指定します。カンマ区切りで複数指定が可能です。
--tags:対象となるタグを指定します。カンマ区切りで複数指定が可能です。
--include-system:このオプションを指定すると、組み込みの管理者アカウントも対象として含みます。
cs_tools tools scriptability checkpoint --directory "c:\temp" --log-errors --org 1420977858 --metadata-types ANSWER,LIVEBOARD --config mysetting2
上のコマンドを実行すると、以下のようにANSWERとLIVEBOARDのTMLが保存されます。

保存先の「c:\temp」フォルダの中に以下のようにフォルダが作成されます。

Mappingファイルは以下のようなJSONの形式で出力されます。
{
"metadata": {
"cs_tools": {
"extract_environment": "ts-cloud_**********"
}
},
"mapping": {
"d5402979-c850-4e2b-87b9-9f2287ada799": null,
"6a27dbfe-c6ce-43a2-913d-96cdd978b742": null,
"375db379-b7de-4abb-8996-ec7f64b06172": null,
"5e487903-4597-43cd-98c1-d609aa967513": null,
"ae08b624-a01b-4b57-9f83-e60cc2b0e083": null
},
"additional_mapping": {},
"history": [
{
"by": "cs_tools/1.6.4/scriptability/checkpoint",
"at": "2025-10-19T03:16:45.596667+00:00",
"mode": "EXPORT",
"status": "OK",
"info": {
"files_expected": 7,
"files_exported": 7
}
}
]
}
このマッピングファイルの内容は以下のとおりです。
- metadata:ドキュメントではDeploy環境に移す様々な情報を記載できるとあります。
- mapping:もともとの環境のguidをDeploy先のどのguidに対応させるか、を記載します。Exportしたときにnullと記載されているところにDeploy先のオブジェクトのguidを記載します
- additional_mapping:TML内の文字列で移行先に対して置き換える必要がある場合に使う項目です。
- history:CS Toolsで自動的に作成されたログで、マージとDeployに使われます。
deployオプション
指定のフォルダにあるTMLをThoughtSpotにインポートする機能です。この機能を使うためには、クラスタ管理者の権限が必要になります(クラスタ管理者の権限がない場合は、コマンド開始後に「Switching Org context to ***」のメッセージのあと止まります)。
--directory:ここで指定したディレクトリにあるTMLファイルをThoughtSpotの方にDeployします。指定必須項目です。インポートに不要なファイルがあるとエラーになるので「deploy-policy」オプションとうまく組み合わせてください。
--tags:Deploy先の環境で、インポートされたオブジェクトにつけるタグを指定します。指定しなくても良いですが、確認のためにはつけておいたほうがわかりやすいのではないかと思います。カンマ区切りで複数指定が可能です。
--org:Deploy先の対象Orgです
--log-errors:オンにすると、コンソールにTMLエラーを表示します。
--source-environment:TMLファイルを出力した環境名です。指定必須項目です。
--target-environment:TMLファイルをDeployする環境名です。指定必須項目です。
--metadata-types:対象となるメタデータを指定します。必須項目です。CONNECTION、TABLE、VIEW、SQL_VIEW、MODEL、LIVEBOARD、ANSWER、ALLを指定可能で、複数指定の場合はカンマ区切りで指定します。デフォルトはALLです。
--deploy-type:DELTA(変更点のみ)かFULL(すべて)を選択可能です。
--deploy-policy:IMPORT時にエラーがあった場合どうするかを指定します。PARTIAL(取り込めるところだけ取り込む)、ALL_OR_NONE(エラーがあったら中止)、VALIDATE_ONLY(検査のみ)から選択します。デフォルトはALL_OR_NONEです。
以下コマンドは、「Kaji1」というOrgにあったTMLを「Kaji2」というOrgに書き込むようなコマンドです。
cs_tools tools scriptability deploy --directory "c:\temp" --tags DEPLOYED,IMPORTED --org 2078203495 --log-errors --source-environment Kaji1 --target-environment Kaji2 --deploy-type FULL --deploy-policy PARTIAL --config mysettingp
もし以下のように「Switching」のところで止まってしまった場合、クラスタの管理者権限を持っていないユーザーで行おうとしていると思われるため、configurationを見直してください。

また、以下のようにマッピングファイルはcheckpointオプションで実行した時そのままのファイル名だと使えません。「移行元クラスタ名+-guid-mappings.json」という名称に変更してください。

うまく進めば、エラーの状況などが出力されます。

今回は、ALL_OR_NONEで行ったので、エラーがあった以上何も変更は行われませんでした。
エラーなく成功した場合は、以下のようになります。

指定したタグ(DEPLOYED、IMPORTED)も以下のようにつきました。

また、mappingフォルダには、新環境でどうなったかというマッピングファイル(およびログ)が作成されます。
※2025/12/05時点の情報です
運営会社
