Service Request should be written in JSON

※ カスタマーからリクエストを受ける仕組みを、改善する画面を書いたので、一筆

状況

エンドユーザーからServiceRequest(以下、SR) を受け取る場合、可能であれば、Webから受け取って、受け取った値をそのままDBに反映したり、fabricコマンドを発行したりしたいのだが、SRの受け取り方によって、そう出来ないケースがある。
ひっかかっているのは、"SR の受け取り方が承認フローとして固定されており、かつ、承認に使用している画面が変更できない場合" となる。
※ 承認された際に担当者にメールが飛んで担当者がコマンドを発行する。ツールから直接fabricコマンドを発行して欲しいのだが、、

現状、SR の本体(このSQLを発行して欲しい、ここにファイルを置いてほしい、など) は、エクセルに記述しており、条件付き書式等を使って入力をチェックしたりしているのだが、エクセル(Windows)からfabric(RHEL)を呼び出すところの書き方が微妙だったり、JavaScriptほどチェックが書きやすくなかったりで、今後のことを考えると、どこかでこの仕組みをWeb化しておきたいところだった。

対応

対応として、入力したフォームをJSONとしてエクスポートするための、新規のWeb画面を作ってみた。
新規フローは以下となる。

  1. 画面から作業内容を記述 -> JSONとしてエクスポート。
  2. エクセルの代わりにJSONを添付。承認フローを通す。
  3. オペレーターが、JSONRHELの某ディレクトリに配置。常駐ジョブが、JSONを解釈してfabricを呼び出す(ジョブが多数定義されている場合も、そのまま続けて呼び出す)

※ 作業用のweb画面

※ 上記画面に対応するJSON

効果

今までエクセルの内容をコピペしてfabricコマンドを作ったりしていたので、オペレーターの作業が非常に大変だったのだが、今後は、そのまま流せるのでだいぶ作業が楽になりそうだ、、
※ 当初 rundeckやjenkinsを使って上記を実現しようとしていたのだが、どちらもコマンドを自由に書けてしまうため、採用出来なかった、、(各種事前チェックの実装がDev任せになってしまう、リリースロジックの出来にムラあり)

(参考)作り

画面本体はDjangoJQueryを組み合わせて書いている。(fabfileを除くと600行くらい)
githubに上げてみようとしたのだが、コード内に固有名詞がありすぎて難しかった、、 orz



2016/2/28追記
-> githubにアップしました
https://github.com/aaabbb200909/execjson