Productivity surely enters the top trends of recent years and is even more in demand in 2016, and includes such areas as Collaborative Software, Smart Virtual Personal Assistants, Bots and many others ...
In this article, we will talk about how Wrike expanded its solution and implemented the Add-In for Office, as well as share its development experience.
I want to thank for the preparation of the article by Arkady Rushkevich (Lead Product Manager) and Vladimir Dupelev (Head of Software Development Group)

Recently, the project management service Wrike announced several integrations with Microsoft products. Now you can log in to the service with the Azure Active Directory corporate login, add files from OneDrive for Business to tasks and install the Wrike add- on in Office 365.

The latter is perhaps the most important in terms of productivity in the workplace. We decided to talk about why the project management system needed integration with office applications, and to share experience in developing an add-in for Office .

Productive bundle

Wrike was able to make over 10,000 companies, including PayPal and HTC, in its highly competitive market. Service is allocated, above all, a special attention to teamwork. It is designed not only for project managers, but also for performers. Users can conduct discussions right under the tasks, simultaneously edit texts, “call” colleagues into the discussion by mentioning the type @ employee_name, subscribe to the news line of the department, project, etc.
')
Another feature is that, unlike some other systems, Wrike does not preach the complete abandonment of traditional working tools: email, instant messengers, file storages, online editors, etc., and the transfer of all joint work activity and content to a new system. This is possible, but not necessary. Instead, users can use the numerous integrations and add-ons offered by Wrike to work comfortably with familiar applications without switching between them. The service itself in this case acts as a connecting hub where project planning and monitoring is conducted, as well as coordination of team work on tasks.

Given these features of Wrike, integration with such a common solution as Office 365 , suggested itself. The basic idea is to create a direct “communication channel” between individual user tools, such as Word and PowerPoint, and a command service for scheduling work.

The add-on for Office 365 allowed users to download documents and presentations directly from office applications into Wrike, without switching between windows, tabs and file search. There in Wrike you can add a document to a task that is being created or already existing. For example, a PR manager, after receiving the task of writing a press release, can do this in Word, immediately attach the finished document to the task in Wrike and appoint the email marketing manager as the next executive to distribute to the journalists.

Also, right from Office 365, you can change the description, status and deadlines of tasks, view and add comments to them. This allows you to save working time that was spent on the routine, and makes communication within the team more transparent.

Technical details

The add-in for Office 365 is a web application that opens in the sidebar of an office application, with access to the document and functions through the Office 365 JS API . It looks tempting and easy to implement, but we also had very tight deadlines, due to the workload of developers, for everything about a month and a half. However, preliminary estimates have shown that it’s realistic to develop and launch an application at such a time taking into account the capabilities of the Office 365 infrastructure. The devil was in the details, but more on that later.

Superstructure is almost completely located on the Web. Locally (if this word is applicable to Office Online), only the manifest is loaded, which is an XML file with the address information of the web application, as well as additional information, such as a set of compatible Office applications, a version, a link to favicon, etc. The application opens as an iframe in Office Online and native Office applications for iOS and Android , and as an independent embedded browser window in Office 2013/2016.

This “architecture” has defined the development environment. Wrike is written mainly on Dart using Project Polymer . It was also used for our add-in for Office 365. This allowed us to reuse a significant part of the code, and also to write not a standalone application that works with Wrike through the API, but an alternative web representation of the main system. Microsoft Visual Studio was used only for writing and validating the manifest (Community Edition is quite suitable for this purpose). Everything else is traditional in Webstorm.

P3P certification

For successful operation of the application, it was necessary to receive and accept cookies with the secure attribute. Browser internet explorer 10, 11 and Edge still uses special p3p header information that allows saving and sending any cookies, and especially handles the case with a secure cookie ( www.w3.org/Protocols/rfc2109/rfc2109 , the “secure” attribute ).

How to connect a digital version of security policies and data about processed and stored user information (p3p) to a project is described on the W3C website . Without the support of the p3p protocol, the site will run in the sandbox. The restrictions are imposed by the “Dangerous Sites” zone, prohibiting the storage and transmission of cookies.

The p3p protocol artifacts are a manifest manifest file (p3p.xml), the manifest itself, which describes the security policy of working with your site data in a machine-readable format (usually policy1.xml), as well as a shortened version of the described policy. It can be used in the header returned with each request (three-letter combinations describing different policies).

Difficulties start from the moment that W3C documentation item 3 lists the tools whose pages no longer open, and it’s almost impossible to find a free wizard to create policy.xml. When filling out the manifest manually, it is necessary to understand which sections are important for the operation of the site, and which are not mandatory, but are necessary from a legal point of view.

Internet Explorer, which is built into the offline Office application, by default ignores the notion of a manifest (which should be along the path /w3c/p3p.xml) and the contents of the tags in the pages. The only thing that includes the ability to save and send a security cookie is the HTTP header of the form:

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

Again, there is a nuance. If you fill in the rule that your site has “Physical contact information” or CP = ”PHY”, then support for cookies with the secure attribute will immediately be disabled, and everything will stop working again.

You can go the way of Amazon and do so , but if there is policy.html on the site, it’s not difficult to specify the necessary contact information right there.

Implementation details

Initialization

We realized that you should never connect two times the code of the office.js library in one HTML file - you will get an error at the stage of receiving the content of files and not earlier. This can happen if you have a header template for each page, and you additionally mentioned office.js in the main page code.

Initialization is not the most obvious way. Instead of calling office.init () with passing the callback function or the popular future pattern, we found the initialize property, which needs to set its callback function.

Dart initialization code:

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

Once this is done, the internal office.js timer will catch this event and start initiating the document:

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

That is, the initialization is asynchronous and implemented with an unusual pattern. If for some reason the contents of your anonymous function passed to the initialization is empty, and someone subsequently deletes it, the add-in will stop working. So our advice to developers is to provide sufficient comments for this place.

Data provider

Document data can be obtained using getFileAsync method. Read more about this in the Microsoft documentation. However, the method will not work until it is requested to read the entire document in the manifest.

  <Permissions>ReadAllDocument</Permissions> 

The getFileAsync () method returns a file object in which you can extract pieces of a file and glue them together for transfer to the server, converting them into a Uint8List type. Slices are transmitted in javascript array format. An interesting and not very noticeable feature in the documentation is that you can’t request slices larger than 65536 bytes. Otherwise, this method will not work on all platforms.

Also pay attention to the Remarks section in the getFileAsync method description . The resulting array can be completely sent to the server via the http request POST method.

Difficulties

We encountered the first and main difficulty almost at the beginning of development. The problem appeared in the HTTP header X-Frame-Options. Since by default we work with the value Deny, attempts to log in to the same window were impossible. There was an idea to do everything in popapa. However, we remembered that there is an offline platform. We looked at how our cropped offline browser reacts to such attempts - it blocked everything that pops up. So, our own and Google-authorization could be performed only inside the window. Then we remembered that there is an online mode, and there x-frame-options deny is already on the Google Auth page. Conclusion: you have to do various login methods for online and offline platforms.

Another nontrivial task was debugging the application. According to the requirements of the Office Store, the application should work in IE 11 browsers (you can refuse to support IE 9 and 10 by making a blank page for them), Chrome, Safari and Firefox of the current versions for Office Online and in IE 11 for Office 2013/2016. There were no problems with debugging in browsers, but the built-in browser in the Office desktop does not have a debugging console. since there were errors specific to the offline version, I had to catch them sending fake requests to the server, passing debugging information in the request arguments.

You can view messages by proxy monitor. If your server does not respond, hangs on the output of the add-in page or takes a long time to prepare the data, then most likely the offline Office application will hang. It seems that the loading of the site for the add-in occurs in the main UI stream of the application, which makes it difficult to debug.

Another nasty bug is the pop-up warning “An add-on for this website failed to run. Check the security settings in Internet Options. ”



When testing by the Microsoft team, this is interpreted as a violation of the requirement that the entire add-in site should work on the HTTPS protocol. Information that the HTTPS site can be found in the Security Info sidebar, SSL: On.
It turned out that the security error pops up at the moment when the ActiveX object appears in the DOM or the Javascript code generates it. Nobody specifically created the ActiveX component, although I really wanted to. To open links in the default browser, you could create a new ActiveXObject object (“wscript.shell”) and call the Run method (“link”) on it, so as not to surprise the user by opening links only in Internet Explorer.

The error is caused by the webComponents library used in Dart Polymer (0.5), and jquery lower versions (1.3). Both libraries at the initialization stage try to attach to the document “” to check the capabilities and version of the browser. In Internet Explorer, HTMLObjectElement is an ActiveX object, which results in an undocumented and undocumented error. For jquery, you need to upgrade, and version 1.9 no longer creates an object on connection. For webComponents, I had to create my own “improved” version.

The little thing that cost us time and nerves because of inattention is the restriction of the Office 365 API. The main method that provides access to the file is getFileAsync () . Currently, the method is supported in Word desktop and online versions, in Excel Online and PowerPoint Desktop (in PP Online, add-ins could not be run until recently). What is the reason for the lack of support for the method in Excel Desktop is unknown. We were looking for a bug that prevented files from loading into Excel for more than a week, because it was necessary to read the documentation more carefully, and we, as a joke, are more like writers. After we figured out, we had to remove Excel Online support, because you cannot specify an arbitrary matrix of applications in the manifest, only Word / Excel / PP and Online / Desktop alone.

According to Wrike customers who agreed to participate in beta testing, such an application would be very useful in Excel, so we are really looking forward to Microsoft's support for getFileAsync () in Excel.

In general, some problems of ecosystem integrity are still present. So, at some point, when testing was already underway, add-on support for Office Online in Safari disappeared for several weeks without warning. Fortunately, after the restoration of work, I didn’t have to correct anything - nothing broke.

One more thing - as mentioned above, until the publication of the add-in was not supported in Powerpoint Online, and appeared, again without warning, after sending the application for testing. It is clear that the ecosystem is young and is actively developing, and we hope that in the future there will be more clear information about technical changes.

Actually, all this led to the fact that it took us longer to debug and publish (about a month) than to develop it (about three weeks).

Publication

The publishing process was quite simple, and is similar to similar processes in other app stores. An application is created through Seller Dashboard , information is displayed for display in the store, a manifest is loaded, and all of this is sent for publication. The application passes a manual test, after which, if everything is in order, it is automatically laid out in the store during the day specified when sending.

We must pay tribute to the Microsoft testing team - usually no more than a working day passed from sending to validation until the report was received. And the application is being tested in sufficient detail - in particular, we received the first refusal in connection with a pair of hard-to-catch bugs, which manifested themselves only in a specific combination of the browser and the Office application.

For the second dispatch, we corrected the technical component and ... were surprised to see a report with such reasons for refusal as a mismatch of the brief description of the application’s functionality in the store and the lack of understanding of the application’s tasks in terms of its first page. For a satellite application, such as Wrike Add-in for Office, this obviousness is not necessary in principle - the target audience is already existing users of Wrike, who understand why we need our add-in for Office. But you can't argue with the guidelines, so I had to add a few lines about key functions to the login page.

It is interesting, by the way, that after a successful publication, any application update that does not require modification of the manifest, in principle, can take place without validation in the store.

There were also minor difficulties with the report format itself. He report is available only in PDF, while the screenshots in it are given in such a resolution that, for example, the text of the error is not visible.

Results

From the third time, the validation was completed, and the application appeared in the store. The collection of feedback from users has just begun, and it is difficult to say something about real efficiency, but the first numbers in the number of downloads are encouraging.

We managed to create a rather popular and interesting application that copes with its tasks. We have already received positive feedback from users who work a lot with different types of documents - copywriters, technical and marketing writers, etc., so there is a feeling that the work has not been done in vain. We hope that our experience will be useful to other developers who are thinking about creating an add-in for Office 365.