生産性は自信を持って近年のトップトレンドに入り、2016年にはさらに需要が高まり、コラボレーションソフトウェア、スマートバーチャルパーソナルアシスタント、ボットなど多くの分野が含まれます...

この記事では、Wrikeがソリューションを拡張し、Office用アドインを実装した方法と、開発経験を共有する方法について説明します。

記事を準備してくれたArkady Rushkevich（リードプロダクトマネージャー）とVladimir Dupelev（ソフトウェア開発グループヘッド）に感謝します。

最近、プロジェクト管理サービスであるWrikeは、Microsoft製品とのいくつかの統合を発表しました。 これで、 Azure Active Directoryコーポレートログインでサービスにログインし、ビジネス用OneDriveからタスクにファイルを追加し、Office 365にWrikeアドオンをインストールできます。



後者は、おそらく職場での生産性の観点から最も重要です。 プロジェクト管理システムがオフィスアプリケーションとの統合を必要とする理由について話し、Officeのアドインの開発における経験を共有することにしました。

生産的な束

非常に競争の激しい市場でWrikeは、PayPalやHTCを含む10,000を超える企業を顧客にすることができました。 サービスは、とりわけチームワークに特に注意を払って際立っています。 プロジェクトマネージャーだけでなく、パフォーマー向けにも設計されています。 ユーザーはタスクのすぐ下でディスカッションを行い、同時にテキストを編集したり、タイプ@ employee_nameに言及して同僚をディスカッションに「呼び出し」たり、部門、プロジェクトなどのニュースフィードを購読したりできます。



別の機能-他の多くのシステムとは異なり、Wrikeは従来の作業ツール（メール、インスタントメッセンジャー、ファイルストレージ、オンラインエディターなど）の完全な拒否を説き、すべての共同作業アクティビティとコンテンツを新しいシステムに転送しません。 可能ですが、必須ではありません。 代わりに、ユーザーはWrikeが提供する多数の統合とアドオンを使用して、使い慣れたアプリケーションを不必要に切り替えることなく快適に作業できます。 この場合、サービス自体がプロジェクトの計画と監視を行う接続ハブとして機能するだけでなく、タスクに関するチーム作業の調整も行います。



Wrikeのこれらの機能を考慮すると、 Office 365などの一般的なソリューションとの統合は自明でした。 主なアイデアは、WordやPowerPointなどの個々のユーザーツールと、作業をスケジュールするためのチームサービスとの間に直接の「通信チャネル」を作成することです。



Office 365のアドオンにより、ユーザーは、ウィンドウ、タブ、ファイル検索を切り替えることなく、オフィスアプリケーションからWrikeにドキュメントやプレゼンテーションを直接ダウンロードできます。 Wrikeでは、作成中のタスクまたは既存のタスクにドキュメントを追加できます。 たとえば、プレスリリースを書くタスクを受け取ったPRマネージャーは、Wordでこれを行い、完成したドキュメントをWrikeのタスクにすぐに添付し、次の幹部をジャーナリストにメールするためのメールマーケティングマネージャーとして任命することができます。



また、Office 365から直接、タスクの説明、ステータス、期限を変更し、コメントを表示してコメントを追加できます。 これにより、ルーチンに費やされる作業時間が節約され、チーム内のコミュニケーションがより透明になります。

技術的な詳細

Office 365のアドインは、Officeアプリケーションのサイドバーで開くWebアプリケーションであり、 Office 365 JS APIを介してドキュメントおよび機能にアクセスできます 。 魅力的で実装しやすいように見えますが、開発者の作業負荷により、非常に厳しい期限がありました-約1か月半すべて。 ただし、予備的な見積もりでは、Office 365インフラストラクチャの機能を考慮して、そのような日にアプリケーションを開発および起動することが現実的であることが示されました。 悪魔は詳細にありましたが、それについては後で詳しく説明します。



アドインはほぼ完全にWeb上にあります。 ローカル（この単語がOffice Onlineに該当する場合）は、マニフェストのみが読み込まれます。マニフェストは、Webアプリケーションのアドレスに関する情報と、互換性のあるOfficeアプリケーションのセット、バージョン、ファビコンへのリンクなどの追加情報を含むXMLファイルです。 アプリケーションは、Office Onlineでiframeとして、 iOSおよびAndroid用のネイティブOfficeアプリケーションとして、Office 2013/2016で独立したブラウザーウィンドウとして開きます。



このような「アーキテクチャ」は、開発環境も定義しました。 Wrikeは、主にProject Polymerを使用してDartで記述されています。 また、Office 365のアドインにも使用されました。これにより、コードの大部分を再利用でき、APIを介してWrikeと連携する自律型アプリケーションではなく、メインシステムの代替Web表現を作成できます。 Microsoft Visual Studioは 、マニフェストの作成と検証にのみ使用されました（この目的にはCommunity Editionが最適です）。 他のすべては伝統的にWebstormにあります。

P3P認証

アプリケーションが正常に機能するためには、安全な属性を持つCookieを受信して​​受け入れる必要がありました。 インターネットエクスプローラー10、11、およびEdgeのブラウザーは、特別なp3pヘッダー情報を使用してCookieの保存と送信を許可し、安全なCookieのケースは特に処理されます（ www.w3.org/Protocols/rfc2109/rfc2109 、属性「secure」 ）



セキュリティポリシーのデジタルバージョンと、処理および保存されたユーザー情報（p3p）のデータをプロジェクトに接続する方法は、W3C Webサイトで説明されています 。 p3pプロトコルがサポートされていない場合、サイトはサンドボックスで実行されます。 対応する制限は、危険なサイトゾーンによって課され、Cookieの保存と送信を禁止します。



p3pプロトコルアーティファクトは、マニフェストファイル（p3p.xml）、 マニフェスト自体です。 マニフェストは、セキュリティポリシーを記述し、機械可読形式（通常はpolicy1.xml）でサイトデータを操作し、記述されたポリシーの短縮バージョンです 。 各リクエストで返されるヘッダーで使用できます（異なるポリシーを記述する3文字の組み合わせ）。



問題は、W3Cドキュメントのパラグラフ3にページが開かなくなったツールがリストされた瞬間から始まり、policy.xmlを作成するための無料のウィザードを見つけることはほとんど不可能です。 マニフェストを手動で入力する場合、サイトにとって重要なセクションと不要なセクションを理解する必要がありますが、法的な観点からは必要です。



オフラインOfficeアプリケーションに組み込まれているInternet Explorerは、デフォルトでマニフェスト（パス/w3c/p3p.xmlに沿っている必要があります）の概念とページ内のタグの内容を無視します。 セキュリティCookieを保存および送信する機能を含む唯一のものは、次の形式のHTTPヘッダーです 。

policyref="/w3c/p3p.xml", CP="CAO DSP COR ...".
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

やはりニュアンスがあります。 サイトに「物理的な連絡先情報」またはCP =「PHY」というルールを入力すると、secure属性を使用したCookieサポートがオフになり、すべてが再び機能しなくなります。



Amazonを使用して確認できますが、サイトにpolicy.htmlがあれば、必要な連絡先をすぐに指定することは難しくありません。

実装の詳細

初期化

1つのHTMLファイルでoffice.jsライブラリのコードを二重接続しないでください-ファイルのコンテンツを受信する段階でエラーが表示されます。 これは、各ページにヘッダーテンプレートがあり、メインページコードでoffice.jsに追加で言及している場合に発生する可能性があります。



初期化は、最も明白な方法では発生しません。 コールバック関数または一般的な将来のパターンを渡してoffice.init（）を呼び出す代わりに、コールバック関数を設定する必要があるinitializeプロパティを見つけました。



Dart初期化コード：

 void initOfficeDocument() { var office = context['Office']; office['initialize'] = (_) { … }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これが完了するとすぐに、内部office.jsタイマーがこのイベントをキャッチし、ドキュメントの開始を開始します。

 g.waitForFunction(function(){return Microsoft.Office.WebExtension.initialize!=undefined},...  window.Office=Microsoft.Office.WebExtension
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、初期化は非同期であり、異常なパターンによって実装されます。 何らかの理由で初期化に渡された匿名関数の内容が空で、その後誰かが削除した場合、アドインは機能しなくなります。 したがって、開発者への私たちのアドバイスは、この場所について十分な解説を提供することです。

データプロバイダー

ドキュメントデータは、 getFileAsyncメソッドを使用して取得できます。 詳細については、Microsoftのドキュメントをご覧ください。 ただし、ドキュメント全体を読み取るためにマニフェストが必要でない限り、メソッドは機能しません。

  <Permissions>ReadAllDocument</Permissions>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

getFileAsync（）メソッドは、ファイルの一部を抽出し、Uint8List型に変換してサーバーに転送するためにそれらを接着できるファイルオブジェクトを返します。 スライスはjavascript配列形式で送信されます。 このドキュメントの興味深い、あまり目立たない機能は、サイズが65536バイトを超えるスライスを要求できないことです。 そうしないと、このメソッドはすべてのプラットフォームで機能しません。



getFileAsyncメソッドの説明の「備考」セクションにも注意を払う価値があります。 結果の配列は、httpリクエストのPOSTメソッドを介してサーバーに完全に送信できます。

難しさ

開発のほぼ最初に直面した最初の主要な困難。 この問題は、X-Frame-Options HTTPヘッダーに現れました。 デフォルトでは拒否値を使用しているため、同じウィンドウにログインすることはできませんでした。 ポップアップですべてを実行するというアイデアがありました。 ただし、オフラインプラットフォームがあることを思い出しました。 トリミングされたオフラインブラウザがこのような試みにどのように応答するかを確認しました。ポップアップするものすべてをブロックしました。 これは、私たち自身とGoogleの承認がウィンドウ内でのみ実行できることを意味します。 それから、オンラインモードがあり、x-frame-options denyが既にGoogle認証ページにあることを思い出しました。 結論：オンラインプラットフォームとオフラインプラットフォームのさまざまなログイン方法を作成する必要があります。



別の重要なタスクは、アプリケーションをデバッグすることでした。 Officeストアの要件に従って、アプリケーションはIE 11ブラウザー（IE 9および10のダミーページを作成することでサポートを拒否できます）、Office Onlineの現在のバージョンのChrome、Safari、Firefox、およびOffice 2013/2016のIE 11で動作するはずです。 ブラウザーでのデバッグに問題はありませんでしたが、デスクトップOfficeの組み込みブラウザーにはデバッグコンソールがありません。 オフラインバージョンに固有のエラーがあったため、ダミーのリクエストをサーバーに送信し、リクエスト引数にデバッグ情報を渡してエラーをキャッチする必要がありました。



プロキシモニターでメッセージを表示できます。 サーバーが応答しない場合、アドインページの出力でハングする場合、またはデータの準備に時間がかかる場合は、オフラインのOfficeアプリケーションがフリーズする可能性があります。 アドオン用のサイトの読み込みは、アプリケーションのメインUIスレッドで行われ、デバッグが非常に複雑になるようです。



もう1つの厄介な間違いは、ポップアップ警告「このWebサイトのアドオンを実行できませんでした。 インターネットオプションのセキュリティ設定を確認してください。











Microsoftチームによってテストされた場合、これはアドインサイト全体がHTTPSプロトコルで実行される必要があるという要件に違反していると解釈されます。 HTTPSのサイトに関する情報は、サイドメニューの[セキュリティ情報]、[SSL：オン]にあります。

ActiveXオブジェクトがDOMに表示されるか、JavaScriptコードがそれを生成すると、セキュリティエラーがポップアップすることが判明しました。 ActiveXコンポーネントを特別に作成した人はいませんでしたが、本当にしたかったのです。 デフォルトのブラウザでリンクを開くには、新しいActiveXObjectオブジェクト（「wscript.shell」）を作成し、そのオブジェクトでRunメソッド（「link」）を呼び出して、Internet Explorerでのみリンクを開くことでユーザーを驚かせないようにします。



このエラーは、Dart Polymer（0.5）およびjqueryマイナーバージョン（1.3）で使用されているwebComponentsライブラリが原因です。 初期化段階の両方のライブラリは、ドキュメント「」に添付して、ブラウザの機能とバージョンをテストしようとしています。 Internet Explorerでは、HTMLObjectElementはActiveXオブジェクトであり、説明できない文書化されていないエラーにつながります。 jqueryの場合、アップグレードする必要があり、バージョン1.9では接続時にオブジェクトが作成されなくなりました。 webComponentsの場合、独自の「改善された」バージョンを作成する必要がありました。



不注意のために神経と時間を浪費する些細なことは、Office 365 APIの制限であり、ファイルへのアクセスを提供する主な方法はgetFileAsync（）です。 現在、この方法はWordデスクトップおよびオンラインバージョン、Excel OnlineおよびPowerPointデスクトップでサポートされています（PP Onlineまで、アドインは最近まで起動できませんでした）。 Excel Desktopでメソッドがサポートされていない理由は不明です。 ドキュメントを注意深く読む必要があり、ジョークのようにライターである可能性が高いため、Excelに1週間以上ファイルがロードされなかったためにバグを検索しました。 マニフェストで任意のアプリケーションマトリックスを指定することはできず、Word / Excel / PPとOnline / Desktopを別々にしか指定できないため、Excel Onlineサポートを削除する必要がありました。



ベータテストへの参加に同意したWrikeの顧客によると、このようなアプリケーションはExcelで非常に役立つため、MicrosoftがExcelでgetFileAsync（）をサポートすることを本当に期待しています。



一般に、生態系の完全性の問題がまだいくつか残っています。 そのため、ある時点で、テストがすでに本格的に行われていたとき、SafariでOffice Onlineを起動するためのアドオンサポートは、警告なしに数週間消えました。 幸いなことに、作業の復元後、何も修正する必要はありませんでした。何も壊れませんでした。



別のポイント-上記のように、公開時まで、アドオンはPowerpoint Onlineでサポートされておらず、テストのためにアプリケーションを送信した後、警告なしで再び表示されました。 エコシステムが若くて活発に開発されていることは明らかであり、将来、技術的な変更のより明確な報告があることを願っています。



実際、これはすべて、開発自体（約3週間）よりもデバッグと公開（約1か月）に時間がかかったという事実につながりました。

転記

公開プロセスは非常にシンプルで、他のアプリストアの同様のプロセスに似ていました。 セラーダッシュボードを介して、アプリケーションが作成され、ストアに表示するための情報が表示され、マニフェストがロードされ、これらすべてが公開のために送信されます。 アプリケーションは手動テストを受け、その後、すべてが正常である場合、送信時に指定された日以内に自動的にストアにアップロードされます。



マイクロソフトのテストチームに敬意を表する必要があります。通常、検証のための送信からレポートの受信までに1営業日しかかかりません。 また、アプリケーションは十分に詳細にテストされています。特に、ブラウザーとOfficeアプリケーションの特定の組み合わせでしか見られなかった、キャッチしにくいバグに関連する最初の障害が発生しました。



2回目のディスパッチでは、技術コンポーネントを修正しました...アプリケーションの機能のストアでの簡単な説明の不一致や、最初のページの外観によるアプリケーションのタスクの理解不足など、失敗の理由を含むレポートを見て驚いた。 サテライトアプリケーション（Office用Wrikeアドイン）の場合、この自明性は基本的に不要です。対象読者は、Office用アドインが必要な理由を想像する既存のWrikeユーザーです。 ただし、ガイドラインについて議論することはできません。そのため、ログインページに主要な機能に関する数行を追加する必要がありました。



ところで、興味深いことに、公開が成功した後、マニフェストの変更を必要としないアプリケーションの更新は、原則として、ストアで検証せずに実行できます。



レポート形式自体には小さな問題がありました。 彼のレポートはPDFでのみ利用できますが、スクリーンショットは、たとえばエラーテキストが表示されないような解像度で提供されます。

まとめ

3回目の検証が完了し、アプリケーションがストアに表示されました。 ユーザーからのフィードバックの収集はまだ始まったばかりで、実際の効果について言うのは難しいですが、ダウンロード数の最初の数字は勇気づけられます。



私たちは、そのタスクに対処するかなり人気のある興味深いアプリケーションを作成することができました。 コピーライター、テクニカルライター、マーケティングライターなど、さまざまな種類のドキュメントで多くの作業を行っているユーザーからはすでに肯定的なフィードバックを受け取っているため、作業は無駄ではなかったと感じています。 この経験が、Office 365用のアドインの作成を検討している他の開発者に役立つことを願っています。