HULFTの集配信定義の管理。誰がする問題？
HULFTの集配信定義の管理。皆さんどうされていますか？
「うちはエクセルで管理しているよ」とか「うちはHULFT-HUBで統合管理している」とかとか
そして、この話を更に進めていくと、HULFTってアプリが管理するんだっけ？インフラだっけ？と、役割の話に発展していきます。
この役割をつなげていくのがワークフローと呼ばれもので、「申請→確認→承認」と実はワークフローとHULFTの連携って密接に絡んできます。
冒頭の誰が管理する問題？の答えは、誰か特定の人が管理するというよりも、役割に応じて横断的に管理するのがわかりやすい。という解決策に落ち着くのかなと個人的に思います。
ワークフローで集配信定義を作ってHULFTへ反映させたい
やりたいことは、アプリの人が起票して、インフラの人が承認、設定反映、集配信定義のマスタ管理を業務フローとしてコントロールしたいです。
絵にするとシンプルなんですが、ワークフローも今どきはSaaSの世界。(インターネット側にある)
できれば、承認したあとの作業も自動化したい。が、常に求められますよね。
実はそれを解決するソリューションが出来たのです！
HULFT10 API Gateway
その名の通り、APIのGatewayとなって、HULFTをRESTで操作管理出来ます。
以下に歩き方がまとまっています。
つまり、以下のようなことがスルスルっと。出来るのかなと、妄想が掻き立てられます。
早速実験してみた！
結論からいうと、作れました！
ちなみに、あくまでも実験なので、HULFT10 API Gateway部分のセキュリティはkintoneからのリクエストを受け付けるIPフィルタを入れています。
1.kintoneでHULFT管理情報の申請アプリを作る
kintoneはホントに直感的に操作でき、30分ぐらいで以下のような、Windows版HULFTを想定した配信管理情報の申請画面が出来ました。
2.kintoneでワークフロー設定をする
kintoneでワークフロー設定するには「アプリの設定」-「設定」-「一般設定」-「プロセス管理」から設定を行います。
以下のようなプロセスを設定してみました。
ほぼデフォルトです。ただ、プロセス最後のステータス名は「承認済み」と変更しました。
後ほど、プロセスが「承認済み」となったら、APIを呼び出す。というJavaScriptを書いていきます。
3.HULFT10 API GatewayのWebAPIリファレンスを確認する
ざっくりHULFT10 API GatewayのWebAPI仕様を解説すると
- HULFT10 API Gatewayの管理画面からアクセストークンを取得する
- 取得したアクセストークンをリクエスト時のBearerトークンにセットする
- 利用するAPIに応じて、[POST]や[GET]する
上記な感じです。一般的なRESTの操作感覚で利用出来ます。
今回は配信管理情報をkintoneアプリで作って、Windows版HULFTに設定反映させたいので、以下のリファレンスを参照します。
上記のリファレンスページにはリクエスト時のヘッダー仕様が記載されていなかったので、以下補足しておきます。
'Content-Type': 'application/json',
'Authorization': 'Bearer {AccessToken}'
4.kintoneアプリにJavaScriptをセットする
kintoneではユーザがJavaScriptを任意にセットすることが出来ます。
今回はインフラの人が承認をすると先ほどのAPIリクエストするJavaScriptを書きました。
(function() {
'use strict';
// レコード詳細画面と一覧画面でステータスチェックを実施
kintone.events.on(['app.record.detail.show', 'app.record.index.show'], function(event) {
const record = event.record;
const status = record['ステータス'].value; // ステータスフィールド名を入力
if (status === '承認済み') {
executeHttpRequest(record);
}
return event;
});
// リクエスト送信先のURL
function executeHttpRequest(record) {
const url = 'http://{ControlURL}/api/v1/hulft/{hulft-host-id}/managements/sendings/detail'; // {ControlURL}と{hulft-host-id}は環境を応じて書き換える
const method = 'POST';
const headers = {
'Content-Type': 'application/json',
'Authorization': 'Bearer {AccessToken}', // {AccessToken}は環境を応じて書き換える
};
// 使用するレコードのデータを準備
const data = {
"id": record['id'].value, // kintone側のフィールドコードに合わせる
"file": {
"name": record['file'].value,
"type": record['type'].value
},
"communication": {
"transfer_group": record['group'].value
},
"code_conversion": {
"side": record['side'].value
},
"compression": {
"type": record['compression'].value
}
};
// HTTPリクエストをkintone.proxyで送信
kintone.proxy(
url,
method,
headers,
JSON.stringify(data),
function(response) {
console.log('Success:', response);
},
function(error) {
console.error('Error:', error);
}
);
}
})();
作成したコードをkintone側にセットします。
「アプリの設定」-「設定」-「カスタマイズ／サービス連携」-「JavaScript / CSSでカスタマイズ」から設定を行います。
コードをアップロードしていきます。
最後にアプリに対して設定変更を実施します。
5.kintoneからAPI経由でHULFT配信定義作成をテスト！
いよいよテストです。
まずはアプリの人の気持ちになって、配信定義を記入していきます！
記入が完了したら、インフラの人へ承認依頼を出します。
続いて、インフラの人の気持ちになります。アプリ側が出してきたファイルID申請を確認して、よしOKの承認を実行します。
実行後の様子です。特に画面出力はしていないので、あっさりと事実だけが記録されています。
Chromeのコンソールを見ると、HULFT10 API Gatewayからのレスポンスが返ってきている様子です。
本当にHULFTに配信定義が出来ているのか確認
API経由で作成した配信定義がHULFT10 API Gatewayから確認できました。
ちなみにkintone上はどうなっているか？
上記のように配信管理情報がレコードに記録されています。
そうです。これがまさしく、ファイルI/Fのマスタになっていきます。
アプリの人が申請して、インフラの人が承認して、HULFTへの設定反映が自動で行われて、最後に記録として証跡が残る。手間なくHULFT運用が出来そうですね。
まとめ
今回はkintoneからHULFT10 API Gatewayを経由して、HULFTへ配信定義を作って、その過程のワークフローも考えてみました。
HULFT10 API Gateway自体はREST APIで操作できるので、いろいろなサービスと汎用的に組み合わせることができます。例えばオーケストレーションツールと組み合わせて、インストールから日々の運用まで全部自動化させるなど、夢が広がります！