とっても簡単!Microsoft Flowを使ってハンバーガー関連のツイートをTeamsに投稿する
こんにちは。
唐突ですが、好きな食べ物を食べる瞬間って幸せですよね。私はハンバーガーが大好きなのですが、特に最初の一口目を頬張る瞬間はなんとも素晴らしいものです。
そんなわけで、タイトル通りハンバーガーとTeamsを絡めたことを書こうと思います。
Microsoft Flowを利用し、Twitterのハッシュタグに特定のもの(今回は#ハンバーガー)があった場合、Teamsの特定チャネルに投稿する、というものになります。
Microsoft Flowも非常に便利なツールなので、ぜひ活用してみてください。
事前準備
まずはMicrosoft Flowが利用できる環境を準備しましょう。Microsoft FLowは様々なサービスを組み合わせ、自動化ができるサービスで、基本的なOffice 365プランでは利用可能です。(詳細なプランの情報についてはこちらを参照)
似ているサービスとしてはIFTTTやZapierが挙げられますね。
次にTwitterを利用するのでTwitterのアカウントを用意しましょう。
また、Flow経由で投稿するTeamsのチャネルも用意しましょう。今回は以前の投稿作成した「Hamburger」チームの「Cheese Burger」チャネルを利用します。
なお、Microsoft Flowはプランによって実行できる回数が異なるので、多数の実行が予想される場合は注意してください。特に今回のようにTwitterなど、SNSと連携する場合は、ほうっておくとあっという間に上限に達する場合がありますので注意が必要です。
フローを作ってみる。
それではMicrosoft Flowでフローを作ってみましょう。Office 365ポータル等かMicrosoft Flowを開きます。
フローはテンプレートから作ることも可能ですし、一から作成することも可能です。
今回はテンプレートから作ってみます。「新しいツイートがハッシュタグと一致したときにMicrosoft Teamsに投稿する」を利用します。
連携するサービスのアカウント情報が必要になるので、今回はTwitterのアカウントでサインインします。
サインインしたら「続行」をクリックします。
以下のように検索テキストに任意のテキスト、Team IdとChannel Idにもそれぞれ任意のチーム名、チャネル名を設定し、「フローの作成」-「完了」でフローを保存してください。
ここまででフローの作成が完了しました。
Teamsに投稿されるのを待つ
それでは設定したハッシュタグでTwitterに投稿されるのを待ちましょう。
以下のようにちゃんと投稿されてますね。(すごい勢いで投稿されておりました。。)
有効にしている時間は10分くらいだったのですが、思った以上に実行数が多かったです。(「#ハンバーガー」の実力を少し甘く見てたようですね。。)
先ほども書いたように実行回数には制限があるので、キーワードのチョイスには気をつけましょう。
また、今回のテンプレートの場合、リツイートも投稿されてしまいますので、除外したい場合は条件を書いたり別途考える必要があります。
ちなみにFlow側でも実行履歴を確認できます。
とっても簡単ですね。
今回はTwitterを利用しましたが、もちろんほかのサービスとも連携できます。例えばExchange Onlineで特定の送信者からのメールをTeamsに投稿するといったことも簡単に実装できます。また、テンプレートも充実しているので、活用すると非常に便利なサービスです。
TeamsというよりもFlowよりの話になりましたが、今回は以上になります。
今後Teamsと他サービスの連携やチーム作成での運用いったあたりを少し検証しようと思いますので、そのあたりについて投稿しようと思います。
ではまた次回。
とっても簡単!Advanced REST clientを使ってIncoming Webhook経由でTeamsに投稿する
本格的に寒くなりましたね〜〜。(毎度天気の話ですいません。。)
私は雪国出身(今は関東在住)なのですが、それでも東京寒いな〜と感じます。周りのマスクの着用率も日に日に増えてきている気がてますので、手洗いうがいを心がけましょう。
さて、前回の投稿でIncoming Webhookのことを書く、と書いたので、Advanced REST clientというGoogle Chromeのアドオンを使ってTeamsのIncoming Webhook経由で投稿するというないようについて備忘録として書こうと思います。
昨今様々なクラウドサービスある中でAPI経由で何かする、と言ったことは非常に良くありまが、その際に、Advanced REST clientのようなツールを使えると、curlなどコマンドを叩かなくてもAPIを実行できるというのは非常に便利です。知らない方は参考にしていただければ幸いです。
事前準備
まず前提のTeamsのお話。Teamsの構造ですが、Slackとは違い「チーム」-「チャネル」の二階層があります。(Slackは一階層)
チームは各部署、チャネルは部署のチームごとや部署内での情報共有の目的別に作るといった使い方が良さそうですね。
それでは、本題に入りましょう。今回利用するIncoming Webhookですが、チーム単位ではなく、チャネルごとに設定する必要があります。
今回は以下のように「Hamburger」チームに「Cheese Burger」チャネルを作っておりますので、このチャネルにIncoming Webhookを追加してHTTP経由で投稿できるように設定しましょう。
まず、チャネル名の右の「・・・」をクリックし、コネクタをクリックします。
コネクタを選択できますので、「Incoming Webhook」を構成します。※前回の投稿で触れたように、テナント全体の設定でIncoming Webhookが許可されていないとここで出てこないため、ご注意ください。
任意の名前や画像を選択し、作成をクリックします。
作成をクリックすると、URLが表示されるので、コピーボタンでコピーし、控えておいてください。※このURLを知っているとこのチャネルに投稿できてしまいますので、大切に保管しましょう
最後に完了をクリックします。
※すぐSlackと比べるのは良くないのですが、そういえばOutgoing Webhooksはないんですね。
そして今回の主役のもう一つ。Advanced REST clientをインストールしてみましょう。
Google Chromeのアドオンとして「Advanced REST client」を追加します。
ここまでで準備が整いました。
HTTP経由で投稿してみる
それでは早速投稿してみましょう。Advanced REST clientを立ち上げ、以下のように設定します。
- Method: POST
- Request URL:Incoming Webhookを追加した時に発行されたURL
また、Bodyタブをクリックし、以下のように設定します。
- Body content type:application/json
- Property name:text
- Editor view:任意ですが、JSON editorがわかりやすいと思います
- Property value:投稿したい任意のテキスト※今回は「Cheeseburgers are so delicious!!」
「SEND」ボタンをクリックし、200が返って来ればOKです。
Teams側にもちゃんとCheeseburgers are so delicious!!が投稿されてますね。
非常に簡単ですよね。Incoming Webhookを利用することで、システムで異常を検知したらTeamsに投げると言ったことも比較的容易に実現することができます。
また、Advanced REST clientを使うことで、非常に簡単にAPIを叩けるので、私は良くAzure FunctionsやAzure Automationのテストをするのに利用していたりするので、重宝しております。
本日はここまでとなります。
次回は別の方法でTeamsに投稿するやり方として、これまたOffice 365のサービスとして提供されているMicorosoft Flowを利用した投稿について書ければと思います。
(飽きっぽいと良く言われるB型なので、続けられるように頑張ります。)
ではまた次回。
Teams初心者がTeamsを使ってみた。[使い始める編]
最近夜は大分寒くなりましたね~~。昼と夜とで気温差が高いので着るものに少し困ってしまいますね。(普段は私服なので)
電車でもゴホゴホしている人が多いので、風邪ひかないように気を付けなければですね。
さて、前回の投稿でTeamsをちゃんと使おうかなと書きましたので、備忘録として使ってみた感想等々を書きます。
ちなみに私はSlackユーザーなので、Microsoft版Slackと言われている?Teamsのことはざっくりとは理解しているつもりでしたが、触ってみると細かい違いがいくつかありました。この辺の違いについても今度記載したいと思います。
まずそもそもTeamsってなんじゃい!という話ですが、一言で言うとチャットツールです。
チャットツールなので、リアルタイムなコミュニケーションが非常に円滑にできるというメリットがあります。
実際私の所属している会社ではコミュニケーションツールとしてSlackを使っておりますが、社内間のコミュニケーションはほぼSlackで完結します。
社内でメールをするなんてことは非常に稀です。そのくらいチャットツールは非常に強力なコミュニケーションツールです。
また、この手のサービスのメリットとしては、他のサービスとのインテグレーションも挙げられます。例えば、サーバーの死活監視をしておき異常を検知したら通知を行う、といったこともよくある使い方かと思います。
(ここまではTeamsに限らずSlackやその他サービスの一般的なメリットでありますが。)
Teamsのメリットとしては、やはりOffice 365をお使いの会社は利用可能だということではないでしょうか。(もちろんプランにもよります。詳細はこちら)
ただし、Office 365の1サービスゆえに他のサービスとの使い分けが難しかったりもするので、このあたりに悩まれている会社さんは多いのではないでしょうか。
Yammerとの違い
特に分かりづらいのはYammerとの違いですね。この辺りはMSさんが記事を公開してくれてますね。
【2017年版】Skype, Skype for Business, Teams, Yammer の違いは?【10/30 更新】 – Microsoft Partner Network ブログ
実際にコミュニケーションの特性的に以下のような感じでしょうか。
Teams:
緊急性(リアルタイム性)のある情報
(例)今打ち合わせ中なんだけど、至急これ教えて~!電車遅れてるから打ち合わせ遅れる><
Yammer:
緊急性(リアルタイム性)の低い比較的ゆるい情報
(例)渋谷界隈の美味しいお店、イベントの告知
ん~~、、特性が違うのはなんとなくは分かる、ただ使い分けは難しいですよね。
渋谷界隈の美味しいお店もイベントの告知もTeamsに投稿しても十分な情報だと思いますし、イベント告知もチャット特有の流れてしまうことを避けたいのであれば、SharePointにリストを作ってそこに投稿しても良いと思います。
となると、流れて欲しくない情報で、かつSharePointにも乗せれないゆるい情報はYammerという感じでしょうか。使い分けが少し難しいですね。
完全に個人的な意見ですが、まずはTeamsを使い、運用がしっかりと定着してから、どうしてもそこに乗らない「ゆるい」情報があればYammerの利用を検討する、といった形が良いのではと考えております。
下手に色々手を出しすぎるとどちらも使われないもの、になってしまうでしょうし。
ちなみに私が所属している会社では以前YammerとSlackと併用しておりました。しかし、今はSlackを社内間のメインのコミュニケーションツールとして使うようにしましたが、全く不便を感じてません。
ただし、大企業やグループ会社で一つのOffice 365を利用している、といった場合はYammerのメリットも出てくるかと思います。TeamsはOffice 365グループの機能であるため、1つのグループが2500人までという制限がありますし、同じ会社で接点が無い場合が多いといった大きな企業においては、YammerのようなSNSツールは有用であると考えております。このあたりは企業によって千差万別なのかなと。
使ってみた
ではそんなTeamsを使い始めてみました。まずはライセンスですね。
基本的にはこれで使えます。管理者側でもう少し細かな設定をしたい場合は次の設定ですね。「設定」の「サービスとアドイン」からMicrosoft Teamsを選択。
そうすると管理者の細かな設定が行うことができます。
ここでどのアプリを許可するか設定できますが、少なくとも「Incoming Webhook」の利用を許可しておいた方が良いと思います。http経由で投稿ができたりするので、死活監視をしておいて、異常を検知したら、http経由でTeamsに投稿する、といったことが可能になります。
あとはワッフルマークからTeamsをクリックすることで使うことができます。
※ブラウザで開いた画面です。
使い始めるのも簡単ですね。
今度はWebhookを追加して他のサービスと連携のお話でも書いてみようかと思います。
ではまた次回。
第20回 Office 365勉強会まとめと所感
前回から大分空いてしまいました。。。さぼり癖ですね、良くない良くない。
先日2017/11/4(土)に開催された第20回 Office 365 勉強会に参加してきましたので、後から振り返られるようにまとめておきます。
ちなみに私もお菓子タイムにLTさせていただきました。
各セッションの簡単なまとめと所感について記載しております。
Office 365 を NPO に導入してみました(仮)
タイトル通りNPOにOffice 365を導入したお話です。
通常のOffice 365の苦労に比べてNPO団体特有の審査等で時間がかかったお話など普段聞けないお話もありました。
また、非常に共感した話として、これはOffice 365の導入について言える話ですが、なんでもできる魔法の箱!というイメージが強いので、そうではないということを最初から伝えることが非常に大事だというお話もありました。本当にその通りだと思います。
他にもSharePointの権限のお話など多くの人が躓きがちな部分の話もありました。
Exchange エンジニアが語る、Exchange Online の設計要素
こちらはExchange Onlineを導入する上で必要な設計要素が簡潔にかつ的確に網羅されておりました。
Office 365をご利用のお客様や導入ベンダーが増えていて、携わる方の母数は確実に増えている中で、こういった話は非常に貴重だなと感じました。
休憩&お菓子タイム&ライトニングトーク
私もこの時間にOffice 365×ハンバーガーというゆるいテーマでLTさせていただきました。
資料は以下にアップしております。※ちなみにスライドは自作しました
他にもPowerQueryのお話やFormsのお話、Flow便利だよ!というお話など短い時間で非常に興味深いお話が多かったように思えます。
また、いつも思いますが、お菓子選びのセンスが抜群です。
MFCMAPI を用いた Office 365 トラブルシューティング
非常にディープな内容でした。MFCMAPIというツールを用いて様々なトラブルシューティングを実施するというお話でしたが、MAPIのプロパティを丸裸にするツールで「やり方によっては簡単に壊れるから注意してね♬」というものでした。私も試すときはテスト環境で実施しようと思います。
本ツールでのトラブルシューティングは通常プレミアサポートにて実施される内容らしく、普段のサービスリクエストでは聞けない情報のため非常に貴重でした。
Microsoft 365 で両立するセキュリティと働き方改革
何かと話題のMicrosoft 365。その中でもセキュリティについてのお話。
DefenderATPというクライアント側でのふるまい検地を行うサービスについての説明もありました。全体的にセキュリティに対するコンセプトが一貫していて、また、高機能で製品としても素晴らしいと思います。ただ高機能な分、高額でもあるので、どの程度の需要が今後出てくるものかはある種楽しみなところでございます。
上記がセッションの内容でした。また、各セッションにおいて、質問のコーナーがございまして、その中でTeamsとYammerの使い分けの話が出ておりました。
Yammer=リアルタイム性の低いSNSツール、Teams=リアルタイムのコミュニケーションツールのようにコミュニケーションの性質ごとにツールを使い分けるというケースが多いと思うのですが、この使い分けは正直私の中で少し腹落ちしていない部分があるので、今後しっかり触ってみようと思います。
ではまた次回。
【SharePoint Online】IPアドレスでのアクセス制御
東日本大震災から今日で6年ですね。Yahooで3.11と検索すると10円寄付されるようですので、後1時間程度しかありませんが是非。
さて、今日はOffice 365勉強会でした。100名ほどの方が土曜日なのにも関わらず集まるという素敵なコミュニティですね。スピーカーや主催の方、場所提供の会社さんありがとうございます。ブログを書くところまでが勉強会とのことでしたので、約3ヶ月ぶりに投稿いたします。笑
私もSharePonint Onlineの新機能であるIPアドレス制御についてLTさせていただきましたので、今日はその内容を書きたいと思います。
まだ先行リリースの機能ですので、今後変更される可能性は大いにあり得ます。その点ご注意ください。
設定方法
正式リリース前の機能のため、先行リリースを有効化する必要があります。
※本番環境に先行リリースを有効化することは気を付けましょう。私はテスト環境で実施しています。
しばらくすると「デバイスアクセス」というメニューが出てきます。許可するIPアドレスを入力する箇所があるので、ここにアクセスを許可するIPアドレスを入力してください。
(注)必ずアクセス可能なIPアドレスを入れてください。以下のように、場合によってはアクセスができなくなる可能性があります。
管理エクスペリエンス管理者は、ネットワーク範囲に現在のマシンの IP アドレスを含める必要があります。IP アドレス範囲は厳格に遵守されるため、管理者のマシンの IP が含まれていないと管理セッションがロックアウトされます。管理セッションがロックアウトされた場合は、サポート担当に接続の再確立を依頼してください。
許可IP以外からのアクセス
それでは、登録されていないIPアドレスからアクセスしてみましょう。以下のようにアクセスが拒否されます。
設定としては、非常に簡単にIPアドレス制御を実装することができました。現時点では例外の設定ができないため、全ユーザーにIP制御が適用されます。そのため、特定の管理者だけはアクセス制御をかけないといったことはできません。
非常に素直なIP制御
さて、このIPアドレス制御は非常に素直に適用されます。ユーザーにも管理者もどちらにもIP制御がかかりますし、すべてのサイトコレクションに適用されます。また、まさかのSharePoint管理センターにも適用されます。そのため、災害時などにIP制御を無効化したいという要望を現時点では満たすことができません。(せっかくのクラウドのメリットをあまり享受できていないような。。)
そのため、現時点で実運用を想定するのであればAzure AD Premiumの条件付きアクセスかサードパーティー製のソリューションを組み合わせるのが良いかと思います。
とはいえ、手軽に実現出来るに越したことはないので、これからに期待の機能ですね。
それではまた次回に。(いろいろ書きたいことはあるので頻度を上げたいですね笑)
トランスポートルールで実現する企業ブランディング
みなさんどうも初めまして!
これからOffice 365とMicorosoft Azureに関する情報とかとか自分の備忘録も兼ねて書いていきます。(タイトルは実は韻踏んでみてます)
技術的なところから小ネタ的なところまで書いていけたらと思ってます。
皆様のお役に少しでも立てればと思いますので、どうかよろしくお願い致します。
現在Office 365 Advent Calenderに参加中で、MVPの方々が多数参加されている中参加でき、大変恐縮でございます。
(ぼーっとしてたらブログの一発目の投稿がAdvent Calendarでの投稿になってしまいました。。)
さてさてそんな初投稿の私ですが、メールの署名での企業ブランディングについて書こうかと思ってます
ここで二つ質問です!
みなさんメールに署名はつけてますか??
多くのビジネスマンの方はビジネスマナーとして会社に入社した時に教えられることかと思いますので、 意図的に署名を付けない方を除き、多くの方は「はい」と答えるかと思います。
それではみなさんの会社では署名が統一されていますか??
ここでは多くの方が「いいえ」と答えるかと思います。
とある調査では70パーセント以上の企業でメールの署名は統一されていないそうです。
(実は私が所属する会社も全員統一はできてなかったりします)
もちろん署名に電話番号やメールアドレスなど必要な情報が網羅されていれば署名の機能としては問題ないですが、 メールを受け取る側に気を配るのであれば、署名が統一されていた方が与える印象は良いですよね。
多くの企業では個人でビジネスをしているわけではないので、例えば営業がいて購買がいて技術者がいてカスタマーサポートがいてとかの会社だとそれぞれバラバラの署名が付いているのと、企業のロゴなんかが入った署名がビシッとあるのでは、 与える印象は後者の方が良いのではないでしょうか。
前置きが長くなりましたが、そんなわけで企業内での署名の統一を実現しちゃおう!というのが今日の内容です。
もちろん会社全員が使う署名テンプレートを作っておき、その署名を各人が使うというのもできるのですが、 部署移動や部署名変更のたびに実施が必要であったり、OotWとOutlookでは署名を同期してくれないのでそれぞれで署名を登録する必要があったりとエンドユーザーの負荷が少し高いと思います。
そこで今回はタイトル通りExchange Onlineのトランスポートルールで実現する方法を紹介します。
トランスポートルールには「免責事項の追加」という処理があります。
これを使うことで本文に任意の文字列やHTMLタグを差し込むことができます。
免責事項に会社全体で使う署名を作成せしておき、ユーザーがメールを署名を付けずに送ると トランスポートルールで自動的に署名を付けてくれると言った仕組みです。
また、免責事項では変数も用意されており、主に以下のようなものを使うことができます。
%%displayname%%(表示名)
%%company%%(会社名)
%%department%%(部署)
%%Email%%(メールアドレス)
%%title%%(役職)
%%Phone%%(電話番号)
%%zipcode%%(郵便番号)
%%state%%(都道府県)
%%city%%(市区町村)
%%street%%(番地)
これらを組み合わせることで部署移動があってもOffice 365をメンテナンス(ADと連携している場合はADをメンテナンス)すれば対応できますし、 エンドユーザーが署名を登録したり明示的に付けたりと言ったことをする必要もなくなります。
実際に以下のようなトランスポートルールを作成してみました。
今回はSignature Makerで署名のサンプルを作成しました。
これらのルールを適用し、実際にメールを送ると受信者は以下のような署名がついたメールを受け取ります。 これだとパッと見てどこの会社からのメールかわかりますねー!
また、トランスポートルールですので、様々な条件を組み合わせることで、 対顧客向けの署名を作ったり、添付ファイルがあった場合特定の文言を差し込んだりといったことも可能です。
以下は添付ファイルがあった際にちょっとした文言を追加する例です。 (前回Office 365勉強会で同様の内容をLTさせてもらいました)
実装方法はとてもシンプルですが、中々便利な機能なのではないでしょうか。
是非皆様の企業でも企業のブランディングの一つとしてはこういった機能を使ってみてはいかがでしょうか。
今日はこの辺で。明日もAdvent Calendarは続きますので、そちらも是非チェックしてください。
ではでは、また次回。
当ブログの閲覧に際して必ずお読みください
免責事項
このサイトならびにコミュニティ等における発言は個人としての意見/見解であり、所属する会社・団体の正式な見解・コメントではございません。
また、掲載されている情報は掲載時で確認した内容であり、仕様変更等の理由により利用できなくなっている可能性もございます。
当ブログの内容を元にした行動によりおきた損害・損失について、管理人は一切の責任を負いかねますので、自己責任のもとで行ってください。予めご了承下さい。
記事内容の変更・修正について
記事の内容は予告なく、変更・修正されます。
予めご了承ください。
外部リンクについて
当ブログには外部サイトへのリンクが含まれています。意図して危険なサイト等へのリンクを載せる事はありませんが、リンク先の安全性や信頼性を保証するものではありません。
リンク先のサイトでおきた問題について、管理人は一切の責任を負いかねます。自己責任の元でご使用ください。