Microsoft Teams Bot

Die Microsoft-Teams-Bot-Integration ermöglicht es Benutzern, eine bidirektionale Unterhaltung mit OctoMesh direkt aus einem Microsoft-Teams-Chat zu führen: Sie können Nachrichten (Fragen) senden und Dateien (zum Beispiel Rechnungen) hochladen und erhalten Antworten in derselben Unterhaltung zurück.

Sie basiert auf dem Azure Bot Service und zwei Pipeline-Nodes des Mesh Adapters:

Node	Art	Zweck
FromTeamsBot@1	Trigger	Hostet den Messaging-Endpunkt des Bot Framework (POST /{tenant}/teamsBot), authentifiziert die Anfrage, lädt etwaige Dateianhänge herunter und startet die Pipeline für die eingehende Nachricht.
TeamsBotReply@1	Load	Sendet über die REST-API des Bot Framework eine Antwort zurück in die ursprüngliche Unterhaltung.

Anders als der abfragebasierte FromMicrosoftGraph@1-Trigger (der einen Teams-Kanal nur liest), ist der Bot echtzeitfähig und bidirektional: Er unterstützt 1:1-Chats, Datei-Uploads und Antworten in Threads.

Architektur

1. Der Benutzer schreibt dem Bot in Teams.
2. Der Azure Bot Service leitet die Activity an den Messaging-Endpunkt des Mesh Adapters weiter. Für die lokale Entwicklung wird der Endpunkt über einen Dev Tunnel bereitgestellt (siehe Setup); in der Produktion ist es eine öffentliche HTTPS-URL des Adapters.
3. FromTeamsBot@1 normalisiert die Activity — einschließlich heruntergeladener Dateianhänge — in die gleiche $.Emails[] / AttachmentData-Struktur, die von den E-Mail- und Graph-Triggern erzeugt wird, sodass die nachgelagerte Pipeline kanalunabhängig ist. Metadaten zum Routing der Unterhaltung (serviceUrl, conversationId, Absender) werden unter $.Conversation abgelegt.
4. Ihre Pipeline tut, was auch immer sie tun muss (Daten abfragen, einen KI-Prompt ausführen, eine hochgeladene Datei speichern …).
5. TeamsBotReply@1 postet die Antwort zurück in die Unterhaltung.

Vereinheitlichte Nachrichtenstruktur

FromTeamsBot@1 gibt die gleiche Struktur aus wie FromEmail@1 / FromMicrosoftGraph@1:

$.Emails[0].Body                     — the message text
$.Emails[0].From                     — sender display name
$.Emails[0].Attachments[0].Data      — base64 file content (PDF, image, …)
$.Emails[0].Attachments[0].ContentType
$.Conversation.ServiceUrl            — where TeamsBotReply@1 sends the answer
$.Conversation.ConversationId
$.Conversation.ActivityId            — for threaded replies

Das bedeutet, dass eine einzige Pipeline sowohl E-Mail als auch Teams bedienen kann, wobei sich nur der Trigger und der Reply-Node je Kanal unterscheiden.

Anmeldedaten

Beide Nodes lesen ihre Anmeldedaten aus einer MicrosoftGraphConfiguration-Entität, die über eine Uses-Assoziation an der Pipeline per Name aufgelöst wird. Die ClientId / ClientSecret der Azure-AD-App Registration dienen zugleich als App-ID / Secret des Bots, und AzureTenantId wählt die Token-Authority (erforderlich für einen Single-Tenant-Bot — siehe unten) und wird außerdem zum Herunterladen von Datei-Anhängen aus Kanälen (SharePoint) über Microsoft Graph verwendet.

Single-Tenant- vs. Multi-Tenant-Bot

Viele Azure-AD-Tenants blockieren mittlerweile die Erstellung von Multi-Tenant-App-Registrierungen, sodass die Azure-Bot-Ressource nur Single Tenant anbietet (oder Managed Identity, das kein Client-Secret besitzt und hier nicht verwendet werden kann). Ein Single-Tenant-Bot wird vollständig unterstützt:

• TeamsBotReply@1 fordert sein Bot-Framework-Token von der Tenant-Authority https://login.microsoftonline.com/{AzureTenantId}/oauth2/v2.0/token an, wenn AzureTenantId gesetzt ist, und von der botframework.com-Authority (Multi-Tenant), wenn es leer ist.
• Daher ist AzureTenantId für einen Single-Tenant-Bot verpflichtend.

Fahren Sie mit dem schrittweisen Setup fort.