Interest and thirst for knowledge around Microsoft Teams has been very strong at Microsoft Ignite. There are many ways that developers can deliver even more productivity to users by extending the out-of-the-box Teams experience. Messaging Extensions are one particular type of custom development that can be used to enhance the conversational experience to create a deep integration to line of business applications.
In this theater session Wictor Wilén dived into the technical implementation to show us how to get started developing these Messaging Extensions, some tips and things to watch out for. Wictor has been a driving force in the community in the area of Teams development and is the person behind the popular Yeoman Generator for Teams.
Messaging Extensions covers three different ways that Teams behavior can be enhanced:
Wictor concentrated on Search and Action commands in his demo where he was able to build tighter integration with Planner by developing:
For both Search and Action commands the Bot can request that Teams displays a web page (URL) in a dialog. This provides the extension the ability to take full control of the user experience in the dialog and allows for a very rich custom experience. The Yeoman Generator for Teams is the fastest way to get started and through its interactive questions you can specifically create an app and have it scaffold up the pieces needed for a messaging extension.
An important architectural concept to grasp when getting started with developing messaging extensions is that they require a Bot to respond to the events that are happening in Teams. Both search and action commands result in a series of requests being sent to a Bot (that is registered via a Teams manifest) to handle the extension. The Bot responds to these various commands with an appropriate JSON response. This flow of requests and responses between the Teams client and the backend Bot is not direct, rather it flows through the Microsoft Bot service. This means that during development the Bot needs to be available on a public URL. To fill this requirement Wictor discussed the ngrok utility that can be used on a development machine to expose your localhost on a public URL. Ngrok also provides a great way to inspect the messages being sent between the Bot framework and your Bot while developing. The ngrok inspector is available while ngrok is running on the development machine and by default can be accessed on http://localhost:4040
The source code used for the demo is available on GitHub http://askwictor.com/THR3040-demo and serves as a great reference for how to:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.