Office Devlopのいろは

Office系の技術を中心に、コアでニッチな話題を繰り広げます。

Sharepoint Frameworkにプロパティ要素を追加し、画面から設定値を変更できるようにする

はじめに

前回の記事では、SharePoint Framework内でWordPress REST API処理を追加し、SharePointページ内でコンテンツを表示する対応を行いました。 SharepointFrameworkを試してみる[WordPressの記事を表示] - Office Devlopのいろは

しかし前回の記事のままだと、取得先のWordPressのURLは、ソースコード内に埋め込まれており、変更できません。
URLを変更するためには、都度ソースコードを変更する必要があり、非常に面倒です。

そのため今回は、SharePoint Frameworkにプロパティ要素を追加し、画面から設定値を変更できるようにする機能を追加します。
今回は、「取得先のWordPressのURLを、画面から変更できるようにする対応」とします。

続きを読む

SharepointFrameworkを試してみる[WordPressの記事を表示]

はじめに

SharepointFrameworkの検証を行います。
この記事では、以下について扱います。

  1. SharePointFrameworkのインストール
  2. とりあえずSharePointFrameworkで実行してみる
  3. jqueryの追加
  4. 独自処理 - WordPress連携部分の追加

※SharepointFrameworkの概念の話はしません。それはまた別の機会に。

実装

今回の参考資料

docs.microsoft.com

続きを読む

【Officeアドイン】OfficeアドインでSSOを有効化 実装編[Laravel]

office.kajitori.co.jp 前回の記事の続きです。今回は、実際に実装して検証しました。

実装方針

MSのサイトに、node.jsASP.NETのサンプルはすでにあるので、今回は別の言語で実装することにします。
今回は最近愛してやまない、PHPLaravelで実装しました。Laravelサイコー。

なお、基本的には以下のドキュメントに記載の内容の後追いになります。こっちと自分の記事を読みながら検証するのがベスト。
docs.microsoft.com

docs.microsoft.com

続きを読む

【Officeアドイン】OfficeアドインでSSOを有効化し、ログインを1回のみにする[Preview版]

はじめに

Officeアドインを開発時に気を付けなければいけない地雷まとめの「Officeのログイン者情報を、Officeアドインで取得することはできない」にも書いたのですが、Officeアドインの安定版では現在、「Officeにログインしているユーザー」を取得することはできません。
画像
どう考えても取れそうな「佐藤 裕」という情報が、残念ながら取得は出来ないのです。安定版では。

そのため、もし「Officeアドインで、Office365のユーザー情報を取得してゴニョゴニョする」というアプリを検討していたとしても、ユーザーに再度ログインを強要する必要があります。
これがクライアント版のOfficeならまだ良いのですが、Online版まで考えると本当に地獄。
アプリがiframeで実装されているがゆえに、認証できず、dialogを表示する必要が出てしまいます。
※これもOfficeアドインを開発時に気を付けなければいけない地雷まとめの「認証が絡む場合、Office Onlineには本当に注意」を参照

しかし、これがPreviewでは、一部できるようになります!
Office系、それもAzure AD v2でのログインに限り、SSOとして、Officeのアプリにログインしている情報(正確にはアクセストークン)を取得できるようになるわけです。
そのため、ユーザーはわざわざ2回目のログインを行う必要がなくなるわけですね。

今回は、この「Office アドインのシングル サインオン」の概要をご紹介します。
検証はまだなので、触りのみとなってしまうことをご了承ください。

続きを読む

Officeアドインを開発時に気を付けなければいけない地雷まとめ

はじめに

「Officeアドイン」は、ざっくり言うとOffice上で動作するWebアプリケーションです。 Office2013から登場し、Office2016、Office365(クライアント版)、Office365(Web版)など、様々なOfficeで動作します。

image.png

Officeアドインは2013年頃に登場し、細々と機能追加を繰り返してきました。 しかし、いかんせんノウハウと情報が少ないです。 そしてこの技術を使えるエンジニアの方も非常に少ないので、なかなか広まらないのも事実です。 「Officeアドイン」と日本語で検索すると、MS公式か、ほとんどが自分の発信な気がしてます・・・笑 (先日、「officeアドイン」で検索したら、MS公式ページより先に、自分の過去の発信が上位に出てきました笑

そしてもう一つ。 このOfficeアドインは、いかんせん情報が少ないこともあり、いざやってみると、意外なところで詰まってしまう「地雷」が多いです。 そこで今回は、幾多の案件を行ってきて、この地雷に立ち向かってきた自分が、「Officeアドインで気を付けなければいけないところ」についてまとめます。 今後、もしOfficeアドインを案件や自社開発などで使用することを検討している方は、まずこの記事を読んでいただいて、事前に検証いただけることをオススメします。

地雷まとめ

Officeの種類によって、出来ることがぜんぜん違う

OfficeアドインはOffice2013から登場した、ということは上記で説明しました。 そこからOffice2016、Office365(クライアント版)、Office365(Web版)と増えてくるにつれて、出来る機能も増えてきました。 ですが、その出来る機能が、すべてのOfficeで使えるものではありません。

例えば「アドインコマンド」。これはOfficeのメニューにコマンドを追加するという機能です。 あらかじめアドインを設定しておけば、以降わざわざOfficeアドインを選択しなくても、メニューボタンをクリックするだけでアドインを実行できます。 image.png

※引用:(https://docs.microsoft.com/ja-jp/office/dev/add-ins/design/add-in-commands)

しかし、この機能はOffice2013とOffice2016では動作しません(ただしOutlook2016のみOK)。 こちらにアドイン コマンドの要件セットというページがあるのですが、ここでアドインコマンドは、Office2013と2016は「N/A」や「16.0.4678.1000 Supported in Outlook only」となっています。 つまり非対応ですね。 最新のOfficeだけで合わせると、「これ出来なかったのか」という事故につながるので、気をつける必要があります。

なお、各Officeで出来ること、出来ないことは、以下のページをご参照ください。 Office Common API requirement sets

Officeのログイン者情報を、Officeアドインで取得することはできない

Office2013から、Officeにログインを行うことができます。 image.png

なのでOfficeアドインを始める際、「このログイン情報を取得しよう」と誰もが思うでしょう。このログイン情報からアクセストークンを取得し、ゴニョゴニョしよう、ということです。 ですが、このOfficeの情報を、Officeアドインでは取得することが、現在は出来ません。 なので、ユーザーのOffice365の情報を絡めたアプリを作成する場合、ユーザーは再度、サインインページを表示する必要があります。

なお正確に言うと、2019/04/13現在、上記機能はプレビュー版です。Identity APIという名前で、現在プレビュー版ということで実装しているようです。 ただし、それでもやはり「Office 2013 or later for Windows」では「N/A」になっているので、いずれにせよOffice2013と2016は切り捨てて実装しなければなりません。

認証が絡む場合、Office Onlineには本当に注意

クライアント版のOfficeアドインが、Office Onlineでも動作すると思っていると、確実に失敗します。 なぜなら、クライアント版のOfficeアドインと、Office OnlineのOfficeアドインは、作られ方がぜんぜん違うからです。

クライアント版のOfficeアドインは、ざっくり言うとアプリ内で、ブラウザ(IE)を立ち上げるような形式に対し、 Office OnlineのOfficeアドインは、iframeで起動します。

もし、サードパーティ(GoogleやOffice365やGitHubなど)のアクセストークンを使用して、サードパーティの情報を使用したアプリを開発しようと考えた場合。 iframeなので、つまりサードパーティ(GoogleやOffice365やGitHubなど)のログイン画面などは、パネル内で表示されないことになります。

一方で、クライアント版では普通に表示されます。 なので、最初にクライアント版でログイン画面が表示され、よしこのままOnline版もやっちゃおう!となった場合、 このことを知らないと、Office Onlineでは確実にエラーになってしまいます。

回避方法もあるが、IEで以上に面倒なことになる

これを回避するために、office-js-helpersという仕組みも用意されています。 これは、ログイン画面をOfficeアドイン内ではなく、ダイアログを起動してログイン画面を表示する仕組みです。 image.png 上記のように、アドインとは別のダイアログを起動します。 未ログインの状況であれば、そのままログイン画面が表示され、IDパスワードを入力し、ログイン完了したら、ダイアログを自動で閉じて、アドイン側にトークンを受け渡す、という仕組みです。 ダイアログ内で表示するので、iframeの制約にも引っかかることなく、ログインを行うことができます。

これを使えばいいじゃないか、と思うかもしれませんが、今度はIEの場合で、「信頼済みサイト」の問題が出てきます。 「信頼済みサイト」の問題とは、簡単にいうと「ブラウザ内のすべてのサイトを、同一のセキュリティゾーンに入れなければいけない」、という制約です。

例えば、Office365にログインを行ってアクセストークンを取得し、Office365の情報を取得するようなアプリを考える場合。 この場合、以下のページの信頼済みサイトを揃える必要があります。 「Office OnlineのSharePointサイト」(https://foobar.sharepoint.com) 「アドインの本体のサイト」(https://foobar1234567.azurewebsites.net) 「Office365ログインページ」(https://login.microsoftonline.com) image.png

「揃える」とはすなわち、 「すべて信頼済みサイトに入れる」か、「すべて信頼済みサイトに入れない」の、どちらかです。 これが揃っていないと、エラーが発生します。

そしてこれが厄介なのが、『いつの間にか、Office OnlineのSharePointサイトが追加されていることがある』ということです。 Office365をいじっているときなのか、クライアント版のOfficeにアプリのURLを追加した場合なのかは分かりませんが、気付いたらこのSharePointサイトが信頼済みサイトに追加されているときがあります。 そうなると、アプリが起動できなくなります。その場合には、残りのサイトを追加する必要があります。

そして、この一連の流れを、アプリを利用する利用者にやってもらわなければなりません。 会社でポリシー配布などを行っていればいいですが、そうでない場合でIEで実行を行う場合に、すべての利用者に、この信頼済みサイトの追加をやってもらわなければなりません。・・・まあ、超面倒ですね。 対策としては、「IEをサポートから切り捨てる」というのも有りかもしれないですね笑

Windows10のIE11で、データのやり取りが正常に動作しない場合がある

上記のダイアログ形式で、アクセストークンのやり取りをするわけですが、ここまでやっても、正常に動作しないことがあります。 それはどうも、Windows10の、一定時期より古いIE11だと、正常に動作しないようです。 かんたんに調査してみたでのすが、

  • ダイアログ同士のデータのやり取りは、標準ではjavascriptのpostMessageで行う
  • だが、IEではpostMessageに対応していないので、localStorageの監視によりデータをやり取りしている
  • だがだが、Windows10のIE11だと、上記の「IEかどうか」という条件が正常にしておらず、うまく動かない(Office.jsのバグ?)
  • そのため結果的に、一部のWindows10のIE11だと動作しない

ということで、Windows10のIE11だと、うまく動かないことがあるようです。 なので、最終的な結論としては、Online版はIE非推奨にしてしまうのが一番ですね。(切実)

まとめ

Officeアドインはどうにも伸び悩んでいます。 その背景は多々ありますが、一つはこの地雷の多さにあると、私は思っています。 それでも、Officeアドインで開発する!という事になった場合、まずはこの記事を読んでいただき、どんな地雷があるかどうか、知ってもらえると嬉しいです。

【Officeアドイン】設定値を保存する2つの方法

■はじめに

Officeアドインで、設定値を保存したい場合。 例えば、アプリの表示言語を変更・設定できるようにしたい場合、 設定値を保持することが出来れば、アプリを再起動した場合でもわざわざ再設定する必要が無くなって便利ですね。 1

このような機能を実装したい場合、果たしてどのように開発すればいいでしょうか? その方法について、実は2つの方法があります。 その2つの方法はどのようなものか? その使い分けも含め、今回はその開発方法について解説します。

■解説

上記でも記載した通り、Officeアドインで設定値を保存する方法は主に2つあります。 それぞれメリット・デメリットあるので、それぞれ見てみましょう。  

①Officeアドインの関数"Settings.set"を使用する

"Office.context.document.settings.set"というメソッドを使用することで、 Officeのドキュメントに名前/値のペアとして設定値を格納します。 参考:https://msdn.microsoft.com/ja-jp/library/office/fp161063.aspx

イメージとしては、Officeファイルに名前/値のペアとして設定値を格納することになります。 2

Officeファイルに格納するので、保存時とは別のOfficeファイルを開いた場合は、その設定値を読み込むことは出来ません。別の値として扱われます。 3

一方で、別ユーザーが同じファイルを読み込んだ場合は、すでに保存済みの設定値を読み込むことができます。 これはファイルそのものに設定値を書き込みしているので、どのユーザーが開いても同じ設定値を利用することが出来るのです。 4

HTML5の機能"LocalStorage"を使用する

LocalStorageは、HTML5で新たに追加された機能です。 ブラウザ側に名前/値のペアとして設定値を格納する事ができます。 http://wp.tech-style.info/archives/742 5

「OfficeなのにHTML5の機能を利用できるの?」と思う方もいるかもしれませんが、 OfficeアドインはれっきとしたWebアプリケーションなので、問題なくLocalStorageを使用できます。 OfficeアドインでLocalStorageを使用した場合、そのアプリ内では共通して同じ値として管理されます。 つまり、別のOfficeドキュメントでアプリを起動した場合でも、同じ設定値を保存・読込することが出来ます。わざわざ保存し直す必要がなくて便利ですね。 6

しかし、別ユーザーが同じファイルを開いたとしても、同じ設定値を使用することは出来ません。 そこはご注意下さい。 7

③結局どっちがいいの?

ぶっちゃけ用途によります。 以下、簡単にまとめてみました。

※Settings.set関数 ・ドキュメントに設定値を格納する ・同じファイルを開いた場合、どのユーザーであっても同じ設定値を保存・読み込むことができる ・別のファイルを使用した場合、設定値は共有されない ・Excelセルに記載された金額・人物名など、各Officeファイルに紐付いた値を保持しておきたい場合におすすめ

※LocalStorage ・ブラウザに設定値を格納する ・保存時とは別のファイルを開いた場合でも、設定値を共有することができる ・別のユーザーが保存時のファイルを開いた場合、設定値は共有されない ・アプリの表示言語など、実行したユーザーごとに異なる設定を保持しておきたい場合におすすめ

開発したいアプリの用途によって使い分けることをおすすめします。 もちろん両方使用することもアリでしょう! あなたの開発にお役立て下さい。

■おわりに(自己紹介)

まだまだマイナーながら、無限の可能性を秘めた「Officeアドイン」の解説記事を少しずつ執筆しています。 もっと詳しく知りたい!といったことや、この内容を解説して欲しい!ということがありましたら、 コメントなどにてお気軽にご連絡ください。

連載[3/3] いちから学ぶOfficeアドイン – Officeアドインの生きる道とは(考察)

はじめに

その1 その2 前々回でOfficeアドインの紹介、およびメリット。 前回は、Officeアドインの現状抱える課題、デメリット。 これらについてまとめてきました。 特に前回は、ある意味致命的ともいえる「Officeでやる必要ない」という欠点についても紹介しました。 ……こんな事言ってしまって、今回ひっくり返せるのかすごく心配ですが(゚o゚;笑

さて!連載最終回となる今回は、「Officeアドインの生きる道とは」をテーマにまとめていきたいと思います! VBAほどの柔軟さは無く、Webアプリであればブラウザで十分。 そんな中で、Officeアドインが今後広まっていくにはどうすればいいか? 一筋の光となるかもしれない、そんな提起をしようと思います。

※今回は今までより更に、私見が大量にあります。 その点ご理解いただける方のみ続きをお読みください。

これがOfficeアドインの生きる道

結論から言いましょう。それはズバリ、 「そのアプリでしか出来ない価値を提供する」 「Officeの機能を拡張する事を徹底追及する」** という事です!

………?(´・ω・`) なに当たり前の事を言ってるんだ……?と思う方もいるでしょう、多分笑 どういう事か?今からこれを説明していきますが、その前に。 前回の課題で挙げた、「Officeでやる必要ない」。 これがどうして発生するのか、もう少し深堀りして考えてみます。

失敗パターン

前回の記事の例ですと、「家計簿サイトをアプリで実行し、内容をExcelに出力できるアプリ」。これを作ることを想定します。 1468355556_calc ①すでに完成されている家計簿サイトをアプリで呼び出して、 ②1ヶ月に1回ぐらいの頻度で内容を出力する。こんなフローになります。

……もうお分かりだと思いますが、Officeアドインである必要がまったくありません。 ①は通常のWebブラウザ、またはスマホあたりで登録すればいいし、 ②もやっぱり、WebアプリケーションでExcelファイルを作成する仕組みの方が、よっぽど柔軟性があるはず。 改めてこういう風にまとめると、Officeアドインの必要が無いことが良く分かると思います。

ただ現実の話、今完成されているサービス・アプリを見て、 「家計簿→Excel→Officeアドイン…… あっ!これOfficeアドインに向いてそう!!」と思い、開発に飛び付いてしまうと、きっと失敗します。 何故ならば、そのサービスは大抵がすでに完成されていて、Officeアドインである必要がないから。 開発をする前に、本当にOfficeアドインでやる必要あるか?という点を、改めて改めて改めて考慮してみてください。

改めて、Officeアドインの生きる道

以上のように、失敗パターンをまとめてみました。 それを踏まえた上で、もう一度Officeアドインの生きる道である 「そのアプリでしか出来ない価値を提供する」「Officeの機能を拡張する事を徹底追及する」 を見てみましょう。

普段のOffice業務を中心軸に

失敗パターンが「普段のWeb業務をOfficeでやろう」だとするならば、その逆です。 「普段のOffice業務をアプリで補助する」 これが唯一の、当たり前とも思える、Officeアドインを開発する上で唯一の最大の鍵だと思います。**

皆さんの普段のOffice業務は何でしょうか? プレゼン資料作成?設計書作成?勤怠管理?経費精算? 色んな業務があるはずですが、その普段やっている業務を補助するためのアプリを作ることが超大切。

×Officeアドインの為にOfficeを開かせよう(絶対めんどくなる) ○OfficeをサポートするOfficeアドインを使わせよう この考え方を持ち続けて設計・開発すること。 そして、開発者がこれを常に意識して、開発したアプリがOfficeストアに公開され続ければ、皆さんの普段の業務を網羅する、「なんか便利なものがあるらしいぞ」と広がっていくことになるでしょう。 Microsoftもきっと、キラーアプリを待ち望んでいるんじゃないかと思います。 どんな人、どんな業務でも使える、Microsoftきってのオススメアプリを! そんなアプリを、あなたの手で開発してみましょう。  

まとめ

あくまでもOfficeアドインは、Officeのアプリなんです。Webアプリケーションとは基本はOffice。 Officeを使った業務を活かすアプリ、これを作れば、きっとOfficeアドインも、作ったあなたも、知名度が変わってくるでしょう。 貴重なビジネスチャンスを作っていけるはずです!