Microsoft has been building out its ‘cloud first’ strategy for many years now. As once separate on-premises server products have morphed into online services, we have been reaping the benefit of tighter integration between these services products. We’ve seen this most strongly with the Office 365 services where SharePoint, Office (Word, Excel, PowerPoint, Outlook, OneNote), OneDrive, and Teams have really become tightly integrated. From a development point of view this cloud strategy has provided Microsoft with a way of delivering a single unified API across the entire surface area of Office 365 covering all these product services. This API is called the Microsoft Graph API. Recently Microsoft added a bunch of it’s security services into the Graph API providing a standard interface and uniform schema to integrate security alerts, unlock contextual information, and simplify security automation.
Microsoft is running a developer hackathon (the Microsoft Graph Security Hackathon) which simply involves using the new security APIs to see what good use you can put it too. There’s some awesome prizes on offer
($15,000 worth!). There’s also some great judges that will be looking at the entries which will give your submissions and ideas some great exposure.
Get coding and submit your entry before March 1, 2019.
It’s no secret that I think Microsoft Teams is an awesome product. I’ve written in the past about how I believe Teams is a great enabler for making people more productive and brings the right tools together in a place that makes a lot of sense.
What are messaging extensions?
Message extensions are available when you are creating a chat message (either a new conversation, or when replying to an existing message). Message extensions assist you by inserting content into the chat message you are composing.
Below is the Giphy messaging extension that allows you to search for an animated image and insert it into your message.
Why develop a messaging extension?
One of the resounding benefits of the Microsoft Teams client is being able to extend the out-of-the-box capabilities and integrate with your existing line of business (LOB) applications. Usually the benefit gain in integrating LOB applications into Teams is that it reduces the context switching for users and they spend more time actually getting work done, and less time moving between application, copying/pasting data or links.
Take a CRM application as an example, if you are discussing a customer in a conversation in Teams and needed to explain where that customer was located, or what the contact details were. The steps you would normally go through would be to open your CRM application, search for the customer, find the relevant details, then cut and paste multiple fields of text switching back and forth between the customer details in the CRM app and the conversation in Teams.
By extending Teams with Messaging Extensions, it is possible to provide an integration into your CRM system that would allow a user to search for a customer in Teams while composing a chat message, select the customer and have the details formatted nicely and inserted in the chat message all without having to leave Teams or even open the CRM application.
When you look at the core LOB applications within your organisation there are some key integrations such as this that can bring about real productivity gains.
Where to start with messaging extension development?
I know I should be doing something a little more productive than this, but hey it’s the holiday season and little LEGO MVP me needs to unwind too 🎄
Wishing you all a very happy, healthy and successful 2019.
Pretty sure I’m not the only one who’s gone down this rabbit hole…
Microsoft Teams is the hub for teamwork in Office 365. The vision Microsoft has with Teams, of bringing existing products and services together into a central hub and minimising context switching, is a vision I share in and have been fostering for over a decade. Before Teams came along I’d spent over a decade of my career working primarily within Outlook and integrating/surfacing other applications and services within Outlook to provide that hub. Outlook was (and still is in most organisations) the first application opened in the morning and the last to be closed at the end of the day. To me it has been blindingly obvious that we can help make users more efficient and productive by bringing the data and information they work with into core applications that they live inside of already, and prevent them having a plethora of applications open on the desktop and constantly switching between them. Outlook was that hub application for me.
Enter Microsoft Teams, a client built from the ground up to bring existing services, applications and product features into a central hub in the context of teams of people working together on a common goal or purpose. Finally Microsoft was no longer thinking in individual products isolated from each other and starting to realise the benefit of combining the power of all of those products for a focused purpose. In essence that is what we have all been doing for many many years, we select a mix of products that allow us to get our job done and where possible we try to integrate them because products that are integrated just make our lives easier!
It’s easy to see why Microsoft Teams has been getting some seriously good traction since it’s introduction and is set to overtake Slack.
I’m sure this uptick in usage was also helped by the fact that Microsoft Teams in now a free offering.
As with any product, it won’t magically fix your business problems simply by being installed and present on users machines. To make any product successful you will need a plan and to execute on it. To this end Microsoft has released an excellent resource in the Microsoft Teams Adoption Guide. This flipbook packs a lot of valuable information into a very polished and concise package. I highly recommend it as your starting point to a successful implementation of Microsoft Teams.
What I particularly like about Microsoft Teams is that it already has a rich extensibility story with developers being able to bring existing line of business application into the Teams client and allowing Teams to be the hub not only of Microsoft products and services but also non-Microsoft products and your own custom applications.
I attended my first Office Developer Bootcamp on Friday last week. I wasn’t 100% sure of what to expect and had a little extra pressure as I was also presenting on Office Add-in development and assisting with the labs.
I ended up having a really fun day. Lots of great conversations had during the bootcamp at Microsoft office at North Ryde. I was a little surprised that the questions weren’t all technical and I fielded a few questions more related to the business side of commercialising add-ins. Thanks to all those that attended and to the great people behind organising the day (Ashish, Amr, John)
Here’s my slide deck from the ‘Developing Office Add-ins‘ talk.
Thanks for everyone that came along to the Sydney SharePoint User Group this month. It was great to be able to deliver so much exciting SharePoint news following all the announcement made at Microsoft Ignite. Given Microsoft Ignite now covers far more than just SharePoint it takes a while to distil the SharePoint specific announcements from over 700 sessions that were presented over 5 days at Microsoft’s biggest conference of the year.
I’ve kept the presentation to just the User/IT Pro announcements (sorry developers I couldn’t fit all the news into a 1 hr presentation!)
Feel free to take this presentation and use it for your own user groups or internal within organisations.
As the dust settles on Microsoft Ignite for another year I’m left going back over my notes and recalling discussions I had for all those key announcements, advice and snippets of gold that will have a real impact for Office developers.
If you are looking for a high level list of announcements made at the conference, the Ignite Book of News is a good place to start although it doesn’t cover many of the announcements that were made in the Office Developer area – this book covers a lot of the Azure announcements, which most Office developers will have a mild interest in (we have to host our code somewhere!)
Here’s some of my favourite announcements:
- Call Microsoft Graph and Web APIs and deploy Extensions across your SharePoint sites
- Deploy your web parts and application pages to Microsoft Teams
- Connect across components with dynamic data capabilities
- Deliver complete applications with application pages
- Harness more of SharePoint with new Microsoft Graph APIs
- Managed access to Microsoft Graph (data connect to bulk export to Azure subscription)
- Notifications API
- Dynamics is now in Microsoft Graph
- New PowerApps templates
- Security API
- Microsoft Teams, Messages, Calendars, Files, and Folders
- In preview but suitable for production use
- Capable of reaching both v1 and v2 services
I thought this years conference was very well run and the volume of people moving about the conference centre wasn’t overwhelming. I had a lot of fun meeting new people and reconnecting with old friends. It’s great to have such knowledgeable Microsoft staff accessible on the expo hall floor (both from a Marketing and Engineering side) to discuss particular scenarios, technologies, ad bounce ideas off.
One of the critical components of an Office Add-in is the add-in manifest. This is the xml file that describes how your add-in should be activated when an end user installs and uses it with Office documents and applications. This manifest contains references to URLs where your web application resides and also to other resources for your add-in such as images to show on ribbon buttons and task panes.
Your manifest.xml file is uploaded to a central location where it is made available to users of your add-in (this may be a public location such as AppSource or the Office Store).
When users acquire your add-in a copy of the manifest.xml file is cached onto the host device and is only periodically resynced if the manifest.xml file is subsequently updated in AppSource/Office Store. I have seen this take weeks on some combinations of host products/devices.
You need to be careful if you are modifying your application and the changes involve modifications to the URLs in the manfiest.xml file. Imagine your add-in has been deployed and is in use by many users. The manifest.xml file might look similar to the fragment below (notice the SourceLocation URL on line 13).
That SourceLocation URL (line 13) is the main page of the add-in that gets loaded into the Task Pane when the add-in is launched. Lets imagine you change the structure of this add-in so that the starting page of the app is now https://www.contoso.com/apps/search/index.html
How do you go about deploying the updated manifest file that points to this new URL?
If you update the manifest.xml file with the new URL you then have to go through the AppSource/Office Store submission process to get the new manifest approved. You are far from 100% in control of the approval process so you don’t know when the new manifest will get approved and thus when the new URL will come into effect. So do you need to keep your application running at both the old and the new URL at least until the new manifest is approved? It gets a little worse than that though, it seems the deployment of a manifest change can take weeks to reach “saturation” whereby it had propagated down to all client host product caches and the old manifest is no longer being used. I can’t exactly tell you how long this process takes and if it ever fully reaches “saturation” as I’m still seeing some users hitting my service on a URL in a manifest that was superseded almost 3 months ago!
Rather than keeping your old and new application running side by side, the approach I have taken that works quite nicely is to put in place temporary redirects from any URLs that were present in the old manifest and have changed in the new manifest. I suggest creating these as temporary redirects as you will be able to monitor your traffic over time and know when you have reached saturation and you stop getting users coming in on URLs from old manifests. If you use permanent redirects, this may get cached by the client and next time the client will have done the redirect itself and you will no longer be able to track if the new manifest has been deployed or it’s an old manifest being redirected via a client side cached redirect.
How do you go about implementing temporary redirects? Well this depends on what you’ve developed your website using and how you are hosting it. In my case I am hosting the app as a Web App in Azure, redirects can be configured in the web.config file that is located in the root folder of the Web App.
Below is an example web.config file that would achieve that temporary redirection.