ゆるふわWeb屋の微解決知見簿

仕事メインの技術系ブログです。Web屋の苦悩、葛藤、そして愛（？）

NEW ARTICLE
kintoneのレコード更新情報をLINE WORKSに通知させたい時のメモ
  • kintoneのレコード更新情報をLINE WORKSに通知させたい時のメモ

kintoneのレコード更新情報をLINE WORKSに通知させたい時のメモ

kintoneのレコード更新情報をLINE WORKSに通知させたい時のメモ

生存報告兼「このブログの運営を放棄したわけではないんだよ」の意味を込めて文量軽めの記事を投稿しておきます。二ッチすぎるネタなのでメモ書き程度です。

注意点ですが、これはLINEではなくLINE WORKSと連携する方法ですのでご留意ください。

あと、「kintoneの更新情報をLINE WORKSに送りたい」んじゃなくて「LINE WORKSの投稿をkintoneに登録」したい場合は下記の記事を読むといいでしょう。AWSのアカウントも要るけど。
LINE WORKSのトークをkintoneに保存する方法

目次

事前準備

JS書くよりも設定の方がめんどくさいです。特にLINEWORKS側の作業が初見だと結構キチゲ溜まります。

前提としてkintoneはスタンダードコースで契約してください（API使えないので）。LINE WORKSの方はフリープランでもいいです。

kintone側でやること

アプリを作りましょうとかフィールドを追加しましょうとかそういう当たり前の話は割愛するとして、とりあえずkintone側ではAPIトークンだけ発行しておけばOKです。

アプリの設定画面を開く→「設定」タブを開いて「設定」タブ ＞ 「カスタマイズ／サービス連携」の[APIトークン]を選択するとAPIトークンの設定画面が開きます。

kintoneのAPIトークン

今回はレコードの情報を欲しいだけなので「レコード閲覧」だけチェックして生成するといいと思います。

真面目な解説は公式ヘルプを読んだ方がいいです。

LINE WORKSの設定

まず最初に言っておきたいのですが、LINE WORKSには「Server API」と「Service API」というものがありまして、Service APIの方は今回全く使用しません。なんでそんな紛らわしい名前してんだとツッコミたくなるが、見間違えたり混同したりしないように注意である。

大まかな流れとしては下記のようになる。

  1. API IDを発行する

  2. Server API Consumer Keyを発行する

  3. Server List(ID登録タイプ)を追加する

  4. Server List(ID登録タイプ)にて認証キーを発行する

  5. 認証キーをもとにJWTを生成する

  6. JWTをもとにServer Tokenを生成する

  7. Botを登録する

  8. LINE WORKSの管理者画面で登録したBotを公開設定する

(ﾟДﾟ)ﾊｧ?

まあ順を追ってやっていきましょう。

スタート～認証キー発行まで

まずはLINE WORKS Developersに行ってログインしてください。

※ここで権限がないよって言われた場合は自分の会社の偉い人に相談してなんとかしてもらってください。

API ID

ログインしたら画面の一番上にこういうのがあるんで「発行」ボタンを押して発行してください（上記のスクショは発行後のものです）。これがAPI IDになります。

Server API Consumer Key

次にServer API Consumer Keyのところでも「発行」ボタンを押します（上記のスクショは同じく発行後のもの）。ボタン押した時に色々聞かれるので、下記のようにフィーリングで先に進めてください。

  • API利用範囲：目的に応じて適宜設定。よくわかんなかったら「トークBot すべて」にチェックでよい。
  • Tokenの有効期限：適当でいい。
  • 有効期限の自動延長：「はい」を選択（上記画像では自動延長になってないけど…）。

次はServer Listの追加を行います。Server List(固定IPタイプ)とServer List(ID登録タイプ)があるんですが、今回は後者を使います。

Server List

「追加」ボタンを押すとまたポップアップが出てくるので、「Keyの選択」部分は前の工程で作成したServer API Consumer Keyを選択して進んでください。サーバー名は適当でいいっす。

そしたら上記スクショのように認証キーがダウンロードできるようになるのでこいつを保存しておきましょう。

～JWT生成

JWTってのはJSON Web Tokenの略で、簡単に言うとその名の通りJSONベースでWeb上で認証するためのヤーツです。

このJWTを生成するためにはBASE64であれやこれや変換したりする必要があるのですが、ダルいのでJWT.IOというサイトを使います。

JWT

JWT生成までの大まかな流れ

  1. セレクトボックス部分で「RS256」を選択

  2. （）内を適宜設定。

    {
      "iss": "（「Server List(ID登録タイプ)」内のID）",
      "iat": （JWT生成日時）,
      "exp": （JWT満了日時）
    }

  3. VERIFY SIGNATUREの下のテキストエリアに先ほどの認証キーを貼り付ける
  4. JWTが生成される

「Server List(ID登録タイプ)」内のIDってのは下記画像の赤枠部分です。

Server List ID

で、生成日時や満了日時がどうたらという部分はUNIX時間（コンピューターシステム上での時刻表現）を使用します。…っていうか、この辺の情報は自分もQiitaのLINE WORKS のトークン取得時に必要な JWT をサクっと生成してみたって記事読んでようやく理解できたところなので、もういっそのこと引用するわ。

JWT の生成日時と満了日時の間にトークンのリクエストを行う必要があります。UNIX 時間で記述します。最長 60 分有効となるよう指定できます。

UNIX 時間の変換はこのあたりの Web サイトを使いましょう。

https://keisan.casio.jp/exec/system/1526003938

～Server Token生成

Postmanを使います。2つのAPIをガッチャンコして何かしてやろうとか思いつく時点でPostmanを知らないことはないとは思うのですが、知らなかったらインストールしてきてください。

Server Token

えと、流石にPostmanの使い方はめんどいので省くとして（「Postman 使い方」とかでググれば無限にヒットするはず）、Token生成までの手順を説明します。

LINE WORKS認証サーバーへのTokenリクエスト手順

  1. 「POST」メソッドを選択し、URL欄に下記を入力。API IDは最初の方に取得したやつです。

    https://auth.worksmobile.com/b/(API ID)/server/token

  2. 「Body」タブ内「form-data」を選択

  3. 項目に「grant_type」「assertion」を追加。

    urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer

    grant_typeには上記を、assertionには先ほど生成したJWTを貼り付け

  4. 「Send」ボタンを押下
  5. 問題なければ画面下部の「access_token」箇所にServer Tokenが出力される

Sendボタンを押してもなんかダメだぜって言われたら「Headers」タブに切り替えて項目に「Content-Type」を追加して

application/x-www-form-urlencoded; charset=UTF-8

って記述も追加してみてください。

それでもダメならパラメータか何かが間違ってたりJWTが失効してたりする可能性があるので、エラーメッセージを解読してなんとかしましょう。

～Botの登録と設定

Botの作成

LINE WORKS Developersの画面に戻りまして、画面左の「Bot」を押下します。で、「登録」ボタンを押せばBotを追加できます。

Bot

追加時の設定については最低限「メンバーが送信可能なメッセージタイプ」の「テキスト」にチェックしておいてください。また、グループトークで使う場合は「複数人のトークルームに招待可」にチェックを入れてください。

それ以外は適当でいいです（上の画像ではCallback URLを設定してますが、別に要りません）。

Botの設定

Bot作成後、LINE WORKSサイトのフッター部分に「管理者画面」ページへのリンクがあるので、押下してログインします。

Botの公開

次に、メニューから「サービス」→「Bot」画面を開き、画面右上「Bot追加」ボタンを押します。すると先ほど作成したBotが表示されるので、選択して追加します。

対象のBot名を選択すると詳細画面が表示されるので、「修正」ボタンを押してモーダル内下部の「公開設定」トグルをオンにします。

これでようやく下準備が終わりです（長ぇ…）。

JSを書く

事前準備で用意した「API ID」、作成したBotの「Bot No.」、「Server API Consumer Key」、「Server Token」、「kintoneアプリのAPIトークン」を使用することになります。

実物はこんな感じです。

kintone APIの書き方についてとか説明するのはダルすぎるというか仕様読んでくださいで終わる話なので割愛しますが、「kintone.events.on」部分でレコード追加・更新完了時に発火→レコードのフィールド情報を取得→「kintone.proxy」で外部API実行→問題なければLINE WORKS側に投稿されるという流れになってます。

なお、自分で書いてみたりコピペしたりしても上手く動かなかったら「事前準備の段階で得た情報が間違ってないか」「kintone APIの発火やフィールド取得で動いてない箇所がないか」「kintone.proxyで正しく通信できているか」の3要素に切り分けて調べてみるといいかもです。

補足

LINE WORKSアカウントで設定されているメールアドレス＝kintoneアカウントのメールアドレス想定でのソースになってますが、そうでない場合は、たとえば「通知先LINE WORKSアカウント」みたいなフィールドを作って

creatorEmail = record[‘通知先LINE WORKSアカウント’].value.code;

とか書き換えたらいいと思います。通知先が自分一人でOKとかだったら直書きしちゃうのもいいでしょう。

補足2

まさか一日に20,000件も手作業でレコードが更新されることはないと思いますが、一応LINE WORKSのトークBot APIには使用制限があるので注意。詳しくはドキュメント参照。

JSをアップロード

kintone上の対象アプリに上記のJSをアップロードして、レコード更新後に正しく動いたら成功です。

ここでいう「正しく動く」とはレコード作成者以外の者がレコードを更新した際に、レコード作成者のLINE WORKSアカウント宛てに通知が届くということです。

なお「設定」→「JavaScript / CSSでカスタマイズ」からJSをそのままアップロードしてもいいんですが、都度アップしてはアプリ更新するという工程がダルいので、JSEdit for kintoneというプラグインを入れておいて、プラグイン画面からJSを書くのがオススメです。

じゃあ本日はこの辺で。ちなみに、この件に関しては質問されてもまともな回答できるかは怪しいです。なぜなら～…今後しばらくkintoneやLINE WORKSを触るような環境ではなくなるからです。

まあ、ぶっちゃけ仕事以外では触りたいと思わないしなあ…。