Edited at
kintoneDay 8

kintone×Microsoft Flow連携のトラブルシューティングの基本

More than 1 year has passed since last update.


はじめに

サービス間連携を簡単に実現できるサービス、Microsoft Flowの(以下MS Flow)kintoneコネクタの公開が来月1月に迫りました。

パワフルさとちょっと癖のある操作性が魅力(?)のMS Flow。

今年何度かハンズオン勉強会をした中での数々の失敗を元に、基本的なトラブルシューティングの情報をまとめました。

※ MS Flowとkintoneコネクタの基本的な使い方は割愛します。詳しくはcybozu developer networkの記事をご参照ください。

※ 先行環境でkintoneコネクタの試用をしています。


フローがうまくいかないときに確認するところ

フローがうまくいかないときは以下の順番で見ていきましょう。


  1. フローの実行履歴(一覧)

  2. フローの実行履歴(詳細)

  3. サービス側のログ(あれば)

  4. Microsoft サポートページ


フローの実行履歴(一覧)

「マイフロー」からフロー名をクリックして、実行履歴のステータスを確認します。

ステータスには次の種類があります。


  • Succeeded : 成功

  • Failed : 失敗

  • Running : 再試行中

kintoneコネクタがトリガーになっている場合は、即時でフローが実行されます(おそらく、実質kintone Webhookだからかと)。そのため、トリガー実行後すぐにステータスを確認できます。次のフローの実行履歴(詳細)へ進んでください。

一方、トリガーがkintoneではないサービス、かつMS Flowがチェックしに行くタイプのフローの場合は、ちょっと注意が必要です。

(例)トリガーがGmailのメール新規受信、アクションがkintoneのレコード登録のフローの場合

以下にその際の判断方法を記載します。


Failedが出ていない場合

MS Flowのプランにより、トリガーのチェック間隔が何分かあります。

トリガー実行からこの分数が経過していない場合は、未チェックのためにフローが実行されていない可能性があるため、とりあえず待ちましょう。

MS Flowのプラン毎のチェック間隔は次のとおりです。

プラン
Flow Free
For Office 365
Flow プラン1(USD5$/月)

チェック間隔
15分
5分
3分

詳細プラン


Failedが出ている場合

フローの実行ステータスは当日の場合、○分前 という形式がつきます。

トリガーの想定時刻から上記のフローのチェック間隔の分数以上過ぎてFailedが出ている場合は、フローの失敗です。フローの実行履歴(詳細)に進みましょう。

(例)フローのチェック間隔 5分で、トリガーの想定時刻 11:55の場合、12:02の段階で2分前のFailedが出ていれば、最新のフローの実行が失敗したことがわかります。


フローの実行履歴(詳細)

一覧のFailedをクリックして以下のような詳細画面を表示します。エラーの概要の中の、

エラーメッセージの内容を確認します。

さらに右上の「×」をクリックすると、右上の緑または赤のアイコンで、どの部分で失敗したのか切り分けに役立ちます。

さらに赤いアイコンの付近をクリックすると、HTTPヘッダーやボディの実際に送られたデータが確認できます。





エラーの原因を直したら、フローを編集し、再送信してテストすることができます。

この場合の再送信は、トリガーまでやったことにしておいた想定でアクションを再送信するということのようです。(ヘルプに記載がなかったので、推測です)


サービス側のログ

MS Flow側のエラー確認だけで解決できなかった場合は、サービス側のログも確認します。以下は、kintoneに関しての情報です。


kintoneがトリガーの場合

kintoneコネクタ/kintone Webhook どちらを使用した場合も、kintone Webhookのログとして確認できます。

また、監査ログでも確認できます。


kintoneがアクションの場合

監査ログで以下のようなレコード操作のログが確認できます。


Microsoft サポートページ

まったく問題なかったフローが、ある日突然動かなくなったことがあり、調べたところ、MS側の問題でした。

そのような場合、サポートページでサービス状況の確認ができます。

参考までに、以下はその時のエラー内容です。


「BadRequest. HTTP 要求に失敗しました。状態コードは 'NameResolutionFailure'、状態メッセージは 'The remote name could not be resolved: 'japan.azure-apim.net'' です。」


こういったエラーの場合は、末尾の「azure」の記載からMS側ではないかと推測できます。


おまけ

参考情報です。


モバイルアプリを活用

MS FlowはZapierやIFTTTと異なりモバイルアプリの提供があることも特徴です。トラブルシューティングのツールとしては、こんなことに使うと便利かと思い、挙げてみました。


  • アクションを何回も試したい場合、トリガーを一時的にモバイルのボタンに置き換える。

  • アクションの条件分岐で、任意のケースをモバイルの通知にする。


コミュニティを活用

どうしてもうまくいかなかったときの最終手段? として、コミュニティで質問するのも手です。

バグ報告や要望もこちらへ。

日本語が気になるところがあるのでフィードバックしようと考えています。


おわりに

この記事でkintone × MS Flowの敷居が低くなれば幸いです。

kintoneコネクタは最初は有償のPremiumコネクタとしてリリースされます。(12月5日の投稿でも触れられていますね)

Premiumコネクタは試用プランや開発者向けプランで利用が可能ですが、その利用される状況次第では、Freeコネクタになって広く一般に公開になる可能性があります。

というわけで皆さん、kintoneコネクタ公開の折にはぜひお試しのほど、よろしくお願いします!


関連リンク

Microsoft Flowのkintoneコネクタで特定のツイートをkintoneに登録する

フローのトラブルシューティング