Pages Menu
TwitterRssFacebook

Posted by on Jan 31, 2019 in Development, Microsoft Teams | 0 comments

Teams Dev Project: Expose existing LOB apps in Teams for users to share easily with Compose Extensions

Teams Dev Project: Expose existing LOB apps in Teams for users to share easily with Compose Extensions

Every organisation has data locked up in silos. The orders database. The products database. The accounts database.

Solving anything but the simplest problem involves visiting each of these stores of knowledge and pulling out relevant information, then tying it together. This tends to involve application switching, sometimes even system switching. If you’re trying to do all this whilst also collaborating on a project, it’s really painful and it harms creativity and productivity.

Microsoft Teams is the app for modern working, with its chat-based workspace. But it’s also extensible. What does this mean? It means that you can enhance what Teams means to users in your organisation, by giving them access to data from disparate systems across your estate, right within Teams.  There are a number of different ways to do this, but one which I think is under-represented, are Compose Extensions.

Show me

The easiest way to explain how useful Compose Extensions are is to show you an example. Let’s say you have an products database, with a description of items and their stock level. This information is critical to making decisions in your organisation every day, and many conversations each day centre around specific products.

Rather than a conversation including stock codes which forces readers to go and look up exactly what the poster meant (“we’re seeing great sales of 335.335 today, anyone know why?”), wouldn’t it be better if that information could be surfaced right within the conversation. Like this:

 

 

This is a Compose Extension. Once installed, they live just under the compose window (alongside the emoji and gifs!). They are a really easy and intuitive way for users to include additional content in their messages. Users are already used to going there to add files, images and smiley faces, so they will quickly learn that this is also an easy way to add product information, or contacts, or whatever organisation-specific information you want to include.

Here’s the code

The code for the sample you saw in the video is on GitHub. Here are some things to note about it:

  • The code is based on the excellent sample code provided by Microsoft on GitHub at https://github.com/OfficeDev/BotBuilder-MicrosoftTeams. That sample gives a very complete example of all the things you can do – I have taken away everything not needed for a simple Compose Extension, hoping that in making it simpler it’s easier to see how it works.
  • If you’ve previously written any Bot Framework code, then you’ll find this very familiar. The way to think about the code is that every search that the compose extension makes is sent to your code, via the same Post method that a bot update would be (MessagesController.Post). There’s a special type of activity to denote a compose extension action (ActivityTypes.Invoke) which is of a special activity type (activity.IsComposeExtensionQuery()). This means you could actually include compose extension functionality in a bot project rather than having a separate Web App just for compose extensions.
  • In the sample code I’m creating a dummy product catalog in the Products class, generating the names, codes and stock item automatically. (hint: this is where you replace my code with an API call to your own product catalog 🙂 )
  • If you look around line 95 in the MessagesController.cs file, you can see that I’m searching my product catalog for matching product codes (Teams calls multiple times as the user types, giving me that nice, responsive Intelli-Sense type search), and then iterating through each result, building a Hero Card for each one. This lets me show a image (auto-generated but would typically come from a real product catalog) and a button to link to more information.
  • None of this code is complicated, it’s all under 150 lines of code, and the productivity effect on users is huge!
  • It’s also sample code, missing exception handling, unit tests, and other niceties. You don’t have to comment on that, I’m aware, thanks. 🙂
  • This post just has the sample code. If you need to know how to turn this into an application you can consume in Teams, look out for a series of blog posts I’m doing soon on the new Calls & Meeting API; the registration process is exactly the same.

Making the Teams App

Once you’ve written the code, in order to get it into Teams for your users, you need to create a Teams App. I’ve done posts about this before, but here are the bits specific to Compose Extensions.

When using the App Studio Manifest Editor (the only civilised way to build apps), there’s a special section for compose extensions, also called messaging extensions:

You first add your extension and specify the App ID that links to your code (just like writing a bot). Then you specify one or more Commands. These are actions that the user will take, and each one can result in your code taking different actions. For each command you specify, you provice three values: the Name, the Title and the Description. The title and description is shown to the user, the name is used in your code:

When a user searches and your code is invoked, you can look up the value of the parameter, done in line 90 of the MessagesController:

var searchTerm = composeExtensionQuery.Parameters.Single(p => p.Name == "Location").Value.ToString();

(my parameter for the stock code is called ‘Location’ because I was originally writing a weather app, before I changed my mind. Sue me.)

Of course, you don’t have to perform a lookup every time the user enters text like I am – if you know all your stock codes are 6 characters long then you can choose to only make an expensive API call once the parameter value is 6 characters long.

LOB Company App? Publish in the Company Store!

It’s likely that if this has been a useful post then you’re about to go and create an application that’s very useful for your organisation, but also very specific to your organisation, and it doesn’t make sense for external users to have your app and your compose extension. If that’s the case then you should definately publish to your organisation’s Company Store and not attempt to side-load your application onto every user’s client in an attempt to avoid publishing. I have a blog post on publishing your apps to the Comapany Store which you may find useful.

 

Post a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This site uses cookies to help make this website better. By continuing to use this site we’ll assume you’re OK with that (implied consent).