Microsoft Teams erweitern – Überblick für Architekten und Entwickler

Mit der Einführung von Microsoft Teams hat die Produktgruppe schon sehr früh Konzepte und Methoden für Entwickler herausgegeben, wie der Client mit eigenen Versatzstücken erweitert werden kann. Dieser Artikel fasst die derzeitigen Möglichkeiten zusammen und versucht, die Optionen in verschiedene Anwendungsfallklassen in einem Development Poster zu clustern.

Microsoft folgt dabei recht gewissenhaft der eigenen Maxime und benutzt Standards, die bereits an anderer Stelle im Rahmen von Office 365 und Azure zum Einsatz kommen. Für alles weitere werden offene Webstandards und die prinzipiell freie Auswahl von Tools, Hosting und Techniken mittlerweile gerne gesehen.

Das Development Poster für Microsoft Teams

Das Poster gibt die derzeitige Situation zum Stand November 2017 wieder. Da sich das immer noch sehr junge Produkt stetig im Wandel und in Entwicklung befindet, kann es sein, dass die Informationen hier schnell veraltet sind. Ich werde versuchen, das Development Poster möglichst aktuell zu halten und bin für Hinweise und Feedback immer dankbar.

Addendum: Da ich explizit gefragt worden bin, ob dieses Schaubild weiterverwendet werden darf: Natürlich! Meine einzige Bitte ist, dass es als Ganzes erhalten und die Quelle sichtbar bleibt. Ich denke aber, dass das nur fair ist. Die Zeiten, in denen man so etwas nicht macht, sollten mittlerweile vorbei sein . 🙂

Update 04. November 2017: Einen Tag nach Erstellung der orginalen Grafik kam das PowerShell Modul offiziell heraus. Dementsprechend wurde der Bereich „Automatisieren“ angepasst.

Die Anwendungsfälle

Bei der Arbeit mit Teams und insbesondere bei der Auseinandersetzung mit den Optionen für Entwickler fällt es manchmal schwer, die vorhandenen Anknüpfungspunkte in den rechten Kontext zu setzen. Es gibt zwar die heilige Dreifaltigkeit von Tabs (Registerkarten), Bots und Konnektoren. Aber erst, wenn man etwas in dieses Schnittstellengeflecht hineinschaut und sich konkrete Anwendungsfälle überlegt, lichtet sich der Nebel, was den Einsatz angeht.

Die erste Gliederungsebene stellt dabei die grundsätzliche Ausrichtung einer Entwicklung dar:

• Administrieren von Teams – Hier geht es um Automatisierung von oft genutzten Prozessschritten wie beispielsweise die Provisionierung von neuen Teams. Ein Blick auf die Zusammenstellung zeigt, dass dieser Bereich immer noch nicht allzu breit besetzt ist. Dieses soll sich allerdings in sehr absehbarer Zeit ändern. Gerade, wenn man die Worte von der Ignite bezüglich der Governance noch im Ohr hat, sollte sich an dieser Front auch bald etwas regen.
• Funktionen erweitern/Systeme integrieren – In diesem Teil der Anwendungsfälle soll dargestellt werden, welche Möglichkeiten sich ergeben, wenn der Client entweder um komplett neue Anwendungsfälle ergänzt werden soll oder aber wenn es darum geht, bereits bestehende Anwendungen und Plattformen in den Dienst zu integrieren. In den meisten Fällen ist hiermit angedacht, dem Benutzer die Wege so einfach wie möglich zu machen. Dazu wird die kollaborative Arbeitsumgebung um Funktionen erweitert, die es ermöglichen, Informationen zu aggregieren oder Aktionen in den angeschlossenen Systemen auszulösen.

Während die erste Klasse von Anwendungsfällen recht stringent und selbsterklärend ist, clustert die zweite den übergreifenden Anwendungsfall in drei verschiedene Unteraspekte, welche versuchen, das Spektrum der Ansatzpunkte in Teams zusammenzufassen.

• Benutzer benachrichtigen stellt somit dar, wie man in Teams und den dort zur Verfügung stehenden Strukturebenen (Teams, Kanäle, Registerkarten) Informationen von draußen hineinbekommt. Ein ausführliches Beispiel hat es in diesem Blog dazu bereits einmal gegeben, als es um die Nutzung von Flow zusammen mit Teams ging. Im Kern steht dabei der Gedanke, dass die Nutzer sämtliche wichtigen Informationen in ihren Kanälen aggregiert bekommen. Wenn es z.B. wichtig ist, dass zu einem Projekt Daten aus einem anderen LOB System wie einem CRM kommen, sollen diese Informationen sich nicht nur dort wiederspiegeln, sondern auch dort, wo die dazugehörige Arbeit verrichtet wird. Ein Klassiker ist hier nach wie vor das Posten von Vertriebsaktivitäten zu einem Kunden (Dynamics CRM -> Vertriebsteam), aktuelle Zahlen aus Reportingquellen (beispielsweise Google Analytics für Webseitenzugriffe). Wenn hier allerdings die Konnektoren im Standard nicht mehr ausreichen, hat man mit den vorgestellten Optionen einen Ansatzpunkt, wie man das Bestehende um das Gewünschte ergänzen kann.
• Aktionen auslösen – Der erste betrachtete Punkt ist ein rein passiver Akt. Das bedeutet, dass der Benutzer neben dem Lesen der Nachrichten keinerlei Möglichkeit hat, hier zu reagieren. Mit den im Development Poster vorgestellten Optionen bringt man dem Client bei, wie man eigene Schnittstellen oder gar ganz eigene, extra für Teams geschriebene funktionale Erweiterungen bedienen kann. Bei der Integration anderer Systeme ist auch hier wieder der Fokus, die Fäden im Teams Client zusammenlaufen zu lassen und damit Möglichkeiten zu schaffen, den Flow der Arbeit nicht zu unterbrechen. Hat man im Unternehmen beispielsweise zentrale Dienste etabliert, die von allen möglichen Stellen über passende Webschnittstellen angesprochen werden können, kann sich auch Teams hier direkt andocken und Befehle abgeben. Etwas weniger bekannt ist dabei, dass auch die Messages in Office 365 dazu eignen, einen Rückkanal zu integrieren. Dieses scheint durchaus interessant zu sein, auch wenn die Abgrenzung zwischen einem Bot und den Actionable Messages zunehmend verwischt. Aber dazu in einem späteren Blogartikel mehr.
• Oberflächen bereitstellen ist auf der einen Seite der wohl umfassendste Punkt, auf der anderen ist er aber am wenigsten Teams-spezifisch. Was man wissen muss ist, dass man mit den Registerkarten, die Teams bereitstellt, bereits viel anstellen kann, insbesondere, wenn man bereits einen SharePoint zur Verfügung hat oder man auf anderen Webseiten die gewünschten Informationen bereitstehen hat. Auch die anderen Services bringen bereits eine fertige Registerkarte mit. Das hindert einen dennoch nicht, Teams unter Umständen auch so zu erweitern, dass mit einem Hosting in Azure komplette Anwendungen geschrieben und integriert werden können. Man muss sich eine solche Erweiterung wie eine klassische Webanwendung mit eigener Datenbank und Konfiguration vorstellen, die allerdings dann direkt in Teams instantiiert und inline verwendet werden kann. Durch die Übergabe Team-spezifischer Parameter ist dabei sichergestellt, dass der Entwickler eine entsprechend notwendige Instanzfähigkeit implementieren kann.

Das Toolset im Development Poster

Die Übersicht enthält einige Hinweise, welche Tools und Technologien jeweils zum Einsatz kommen. Neben den obligatorischen Ressourcen möchte ich aber explizit noch einmal auf den Yeoman Generator von Wictor Wilen hinweisen. Dieser bietet mittlerweile für jede der Entwicklungsarten ein hervorragendes Grundgerüst. Wer schon einmal mit yo teams sein Projekt gestartet hat, kann das sicher bestätigen.

Updates

Sobald die nächsten großen Änderungen bezüglich der Entwicklungsschnittstellen ins Haus stehen, werde ich die Grafik anpassen. Insbesondere die Möglichkeiten mit der API (die noch immer gut versteckt in der Graph API ihr Beta-Dasein fristet) werden hier einige interessante neue Optionen aufdecken und ein aktuell recht deutlich klaffendes Loch im Service selbst stopfen.