Hur man skickar aviseringar till Teams och Slack från skript med hjälp av säkra webhooks

Om du arbetar med molninfrastruktur, CI/CD, övervakning eller incidenthantering, vill du förmodligen Alla viktiga aviseringar landar direkt i dina kanaler. Microsoft-lag eller SlackDet mest flexibla och enkla sättet att uppnå detta från skript, automatiseringar eller externa tjänster är att använda webhooks ... så länge du skyddar dem väl.

Under senare år har landskapet förändrats: Äldre kopplingar som de från Office 365 i Teams pensioneras.DLP-policyer blir allt striktare, och många tjänster kommunicerar bara med JSON i mycket specifika format (som Amazon SNS, Azure Monitor eller ClickUp). Allt detta innebär att integrationen av aviseringar med Teams och Slack inte bara handlar om att "klistra in en URL" och avsluta; det kräver noggrant övervägande av säkerhet, nyttolastformat och arkitektur.

Vad är egentligen en webhook och varför är den så användbar för aviseringar?

En webhook är inget annat än en HTTP- eller HTTPS-URL som accepterar POST-förfrågningar från ett annat system. Varje gång en händelse utlöses (ett produktionsfel, en misslyckad distribution, en tillståndsändring i en resurs etc.), kommer din skript Tjänsten skickar en JSON till den URL:en och meddelandet visas i den Teams- eller Slack-kanal du har valt.

I detta schema, Teams och Slack agerar som passiva mottagareDe väntar bara på att någon ska skicka dem en förfrågan i rätt format. Fördelen är att du, från din sida, kan använda praktiskt taget vilket språk eller vilken miljö som helst. PowerVåldsamt slag PythonAWS Lambda, Azure Functions, CI-pipelines, lokala applikationer, vad du än vill.

Det är viktigt att vara tydlig Varje plattform förväntar sig en specifik JSON-struktur.Till exempel kräver en Slack- eller Microsoft Teams-webhook vanligtvis minst ett fält med meddelandetexten (normalt "text"), medan andra tjänster som Amazon Chime förväntar sig andra nycklar (till exempel "Innehåll").

En annan viktig punkt är att många molntjänster (Azure, AWS, ClickUp, etc.) De skickar inte exakt det format som Teams eller Slack förväntar sig.utan snarare ett eget nyttolastschema för händelser och varningar. Det är därför man ofta behöver en "mellanhand" för att anpassa informationen till rätt format.

Typer av integrationer: webhooks, connectors, bots och API:er

I Microsoft Teams värld finns det flera sätt att få automatiska aviseringar från skript eller externa tjänsteroch det är viktigt att skilja mellan dem för att välja rätt arkitektur:

På ena sidan finns inkommande webhooksDessa är det mest direkta sättet att skicka meddelanden till en Teams-kanal. Att aktivera den här funktionen i en kanal genererar en HTTPS-URL som accepterar JSON och infogar innehållet i konversationen. De kräver inte att man installerar en komplex app eller ytterligare Azure-resurser; det är en inbyggd kanalfunktion.

I andra änden har du Aviserings-API och aviseringsrobotarDessa är bland de mest avancerade funktionerna i Teams. Vi pratar om fullfjädrade Teams-applikationer som kan skicka avancerade aviseringar till användare, chattar eller kanaler, utnyttja Microsoft Graph, hämta användarkontext, visa innehåll i instrumentpaneler och mer. Det är perfekt om du letar efter personliga upplevelser, dynamiska anpassningsbara kort och sofistikerade affärsregler.

Även inblandade är kontakter för grupper av Microsoft 365Dessa låter dig paketera en webhook med en egen inställningssida som en del av en Teams-app. De använder vanligtvis kopplingskort med en begränsad uppsättning åtgärder, perfekt för "produkt"-integrationer som väder, incident och andra kopplingar.

Slutligen finns det Grafbaserat aviserings-APIDen fungerar som en RESTful-slutpunkt för att utlösa aviseringar i Teams-aktivitetsflödet. Den är mycket kraftfull när du vill att din webbapplikation eller backend ska skicka brådskande aviseringar, med ljud- och operativsystemaviseringar, om kritisk information riktad till specifika användare eller grupper.

Adjö till Office 365-kopplingar: varför det är dags att gå över till Power Automate

Om du har skickat meddelanden till Teams i flera år med hjälp av Webhooks för Office 365-anslutningDu har säkert sett meddelanden om att den här funktionen tas bort. Microsoft anpassar ekosystemet till sin "framtidssäkra" strategi, vilket i praktiken innebär att man strävar mot mer moderna och kontrollerade lösningar, som Power Automate och nuvarande API:er.

Det rekommenderade sättet att fortsätta skicka aviseringar från skript är orkestrera leveransen till Teams med hjälp av ett Power Automate-flödeIstället för att direkt anropa en Office 365-webhook utlöser dina skript en Power Automate HTTP-utlösare, och det här flödet hanterar att skapa och skicka meddelandet till Teams-kanalen med hjälp av stödda kopplingar.

I ett typiskt scenario skapar du en molnflöde med en utlösare som "När en HTTP-begäran tas emot"Från ditt PowerShell-, Bash- eller Python-skript gör du en POST-begäran till den slutpunkten och skickar relevanta data (allvarlighetsgrad, källa, incidentbeskrivning etc.). Arbetsflödet bearbetar JSON-filen, omvandlar den till ett kort eller meddelande anpassat för Teams och publicerar den till den kanal du väljer.

Denna metod har flera fördelar: Det abstraherar dig från framtida ändringar i kopplingar.Det låter dig centralisera logiken för formatering och dirigering av aviseringar, och gör det enklare att uppfylla säkerhets- och efterlevnadskrav, eftersom Power Automate kan integreras med Microsoft 365 DLP och styrning.

Skydda dina webhooks: tokens, hyresgäster och DLP

En av de stora frågorna när man exponerar en webhook-URL är hur Förhindra att någon skickar meddelanden till din kanal Om du upptäcker den adressen. Även om webhooks är mycket praktiska måste de behandlas som känsliga inloggningsuppgifter.

Ett vanligt förekommande mönster består av lägg till en auktoriseringstoken som en parameter i URL:enTill exempel kan en slutpunkt se ut så här: https://miservicio/webcallback?tokenid=sometokenid&someparameter=somevalueTjänsten som tar emot anropet verifierar att token är giltig innan begäran behandlas. På så sätt kan någon inte använda URL:en utan rätt token, även om de ser den.

I Azure- och Microsoft 365-miljöer är det vanligt att gå ett steg längre och Registrera ett program på Microsoft Enter ID (tidigare Azure AD) för att skydda HTTP-slutpunkten. Power Automate-flödet kan publiceras bakom en API Management- eller Entra-skyddad funktion, så endast autentiserade skript som tillhör din klientorganisation kan utlösa webhooken.

Dessutom ansöker många organisationer policyer för förebyggande av dataförlust (DLP) i miljöer som Power Automate eller Power apparDessa policyer kan blockera eller begränsa användningen av vissa kopplingar (till exempel att skicka data från en "konfidentiell" miljö till kopplingar som anses vara "otillförlitliga", till exempel en Teams-webhook). Om du stöter på fel när du sparar eller kör ett flöde kan grundorsaken ligga i DLP.

I så fall är det nödvändigt att granska det tillsammans med IT- eller styrningsteamet. Hur är segmenteringen av kontaktdonet konfigurerad? och gör justeringar för att tillåta att din Teams- eller Slack-webhook är en del av de tillåtna kopplingarna i miljön där ditt flöde eller din applikation körs.

JSON-uppladdningsformat: från Azure Monitor till Teams och Slack

Tjänster som Azure Monitor, Azure-aktivitetslogg eller säkerhetssystem genererar varningshändelser med mycket omfattande och detaljerade JSON-schemanNär dessa händelser skickas till en webhook som en del av en grupp åtgärder, innehåller nyttolasten som din slutpunkt tar emot mycket information, inte bara meddelandetexten.

Den typiska layouten för en varningsmeddelande Azure-aktivitetslogg inkluderar ett fält schemaId och ett objekt data som innehåller varningsstatus, kontext och egenskaper. Inom data.context.activityLog Data såsom kanaltyp, correlationId, händelsens tidsstämpel, nivån (Kritisk, Fel, Varning, Informationsmässig), den operationName, den berörda resursidentifieraren och mer.

Beroende på värdet av eventSource I den lasten varierar den specifika strukturen: det finns händelser av typen Administrativ, Säkerhet, Rekommendation, ServiceHälsa o Resurshälsavar och en med sina egna specifika egenskaper. Till exempel kan en säkerhetshändelse specificera brutala våldsförsök SSH, angriparnas IP-adress, använda användare, antal misslyckade försök och föreslagna åtgärdssteg.

Andra element i lasten inkluderar fält som tillstånd (åtgärd och omfattning av rollbaserad åtkomstkontroll), uppringare (e-postadress eller UPN för användaren som utförde operationen), händelseDataId (unik identifierare), understatus (ofta med HTTP-koder som 200, 400, 404, 500, etc.), och en ordbok med properties med nyckel-värde-par som ger mer kontext till händelsen.

För att göra allt detta användbart i Teams eller Slack är det inte meningsfullt att kopiera hela JSON-filen som den är. Det praktiska tillvägagångssättet är att använda ditt skript eller din funktion. extrahera de relevanta fälten (berörd resurs, allvarlighetsgrad, beskrivning, kritiska tidsstämplar, korrelation) och skapa ett mer läsbart meddelande som tydligt anger vad som hände, var och vad som ska göras härnäst.

Från Amazon SNS till Slack, Teams och Chime med Lambda

Amazon Simple Notification Service (SNS) är en annan viktig del när du vill reagera på AWS-händelser och skicka dem till chattkanalerSNS kan publicera meddelanden till HTTP/HTTPS-slutpunkter, men inte alltid i det format som Slack-, Microsoft Teams- eller Amazon Chime-webhooks förväntar sig.

När du till exempel konfigurerar ett SNS-ämne att publiceras på en webhook, har meddelandets JSON-nyttolast sina egna nycklar (meddelande, ämne, tidsstämpel osv.). Men, Slack och Teams förväntar sig att förfrågningstexten innehåller en "text"-nyckel. med meddelandet som kommer att visas på kanalen, medan Amazon Chime söker efter en nyckel "Innehåll"SNS har inte direkt stöd för omvandling av det formatet vid publiceringstillfället.

Den rekommenderade lösningen i AWS är att använda en Lambdafunktion som ett mellanlagerIstället för att prenumerera på webhooken direkt på SNS-ämnet skapar du ett SNS-ämne, konfigurerar en Lambda-funktion som prenumererar på det ämnet, och från Lambda skickar du POST till webhooken med JSON-filen transformerad till rätt struktur.

Flödet skulle se ut ungefär så här: SNS publicerar händelsen till Lambda-funktionen; funktionen läser händelse[«Poster»][0][«Sns»][«Meddelande»]Skapa en ordbok med lämplig nyckel ("Content" för Chime, "text" för Slack eller Teams, valfritt tillägg kanalisera, Användarnamn o icon_emoji (i fallet med Slack), serialiserar till JSON och gör POST-förfrågan med hjälp av ett HTTP-bibliotek som t.ex. urllib3.

I Python-kod är det grundläggande skelettet mycket enkelt: du skapar en PoolchefDu definierar webhook-URL:en, konstruerar meddelandet med de förväntade fälten, konverterar det till UTF-8-kodad JSON och skickar begäran. Sedan kan du logga statuskod och svarstexten för felsökning, kontroll av att webhooken korrekt accepterar meddelandet (kod 200) eller identifiering av 4xx-fel om det finns ogiltiga parametrar eller om URL:en är felaktig.

När Lambda-beteendet har validerats med en testhändelse i konsolen (med hjälp av mallen "SNS Topic Notification") är nästa steg lägg till SNS-temat som en trigger av funktionen. Således, varje gång en tjänst publicerar till ämnet (till exempel CloudWatch-larm, instansstatushändelser etc.) kommer aviseringen att hamna i Slack, Teams eller Chime i det ideala formatet.

Webhooks i Microsoft Teams: inkommande, utgående och kopplingar

Inom Teams finns det olika typer av anslutningar som går utöver den typiska inkommande webhooken och det är värt att känna till dem för att bättre utforma din aviseringslösning.

mycket utgående webhooks De låter dig "anropa" en extern tjänst från en kanal med hjälp av ett @-symbol. Du konfigurerar den utgående webhooken med din tjänsts URL, och när en användare anropar den med ett meddelande skickar Teams texten till din slutpunkt och förväntar sig ett snabbt svar (vanligtvis inom 10 sekunder) med innehåll som kan vara vanlig text eller ett kort. Detta är användbart för kommandon eller frågor på begäran, inte så mycket för automatiska aviseringar.

mycket inkommande webhooksSom vi nämnde tidigare är de perfekta för få regelbundna varningar och meddelanden Från externa applikationer. Du skapar en webhook i en kanal (till exempel en DevOps-kanal) och konfigurerar dina pipelines, distributionsskript, övervakningsverktyg eller säkerhetssystem för att skicka sina händelser till den URL:en med HTTP POST.

Sedan finns det Kopplingar för Microsoft 365-grupperDessa fungerar som ett sätt att paketera en inkommande webhook med ett konfigurationsgränssnitt i Teams. De skickar vanligtvis meddelanden i form av kopplingskort och möjliggör en mer "produktliknande" upplevelse, till exempel att välja en plats i en väderkoppling, schemalägga aviseringstider och så vidare.

Ur ett arkitektoniskt perspektiv, om ditt huvudsakliga behov är att Dina skript och verktyg skickar meddelanden till en kanal Utan för många visuella finesser räcker det oftast med en enkel inkommande webhook. Om du letar efter komplex logik, avancerad anpassning och interaktiva åtgärder är en aviseringsbot eller en Teams-app med ett aviserings-API mer lämplig.

Hur man skapar en inkommande webhook i Teams och använder den från en extern tjänst

Processen för att aktivera en inkommande webhook i en Teams-kanal är ganska mekanisk, men det är värt besväret. förstå varje steg fullt ut för att sedan integrera det med dina skript eller applikationer.

Först väljer du teamet och standardkanal var du vill att varningarna ska visas. Detta kan vara en befintlig kanal (till exempel "Incidenter") eller en ny som skapats enbart för integrationer.

Sedan klickar du på de tre punkterna bredvid kanalnamnet och väljer alternativet att AnslutningarI listan över tillgängliga kopplingar letar du upp "Inkommande webhook" och klickar på "Konfigurera". Tilldela sedan ett namn som identifierar dess syfte (till exempel "CertSecure-aviseringar", "CI/CD-aviseringar" eller "Azure-övervakning") och laddar eventuellt upp en ikon för att göra det lättare att känna igen meddelandekällan.

När du bekräftar skapandet genererar Teams en Unik webhook-URLDet är adressen du kopierar och klistrar in i inställningarna för ditt externa verktyg eller din externa tjänst. Det är viktigt att hålla den säker, eftersom alla som får tillgång till den kan skicka meddelanden till kanalen för din räkning.

Vissa produkter, såsom certifikathanteringslösningar (till exempel CertSecure), har ett specifikt avsnitt i sin egen administrationsportal för integrera TeamsDär ber de dig vanligtvis att klistra in webhook-URL:en; efter att den har sparats skickar systemet ett testmeddelande till teamkanalen som indikerar att integrationen har slutförts.

Därifrån kan du aktivera eller inaktivera olika aviseringshändelser (utfärdande av nya certifikat, återkallelser, förnyelser, utgångsdatum eller aviseringar före utgångsdatum) så att varje relevant ändring genererar ett automatiskt meddelande i kanalen, vilket håller teamet uppdaterat utan att behöva ständigt komma åt verktygets panel.

Vanliga problem med ClickUp, Slack och andra tjänster

Inte alla plattformar är kompatibla med Slack- eller Teams-webhooks direkt, även om det verkar som att allt du behöver göra är att klistra in en URL. Ett typiskt exempel är... ClickUp och Slack när du vill meddela kanalen varje gång statusen för en mapp eller lista ändras.

Med ClickUp kan du konfigurera automatiseringar där en åtgärd utlöses vid en tillståndsändring som skickar en begäran till en webhook-URL (till exempel Slack-URL:en som genererar en inkommande webhook). Problemet är att ClickUp skickar sin egen JSON-nyttolast med ett schema som inte matchar vad Slack förväntar sig, så aviseringen kanske inte visas i kanalen.

I Slack förväntar sig den inkommande webhooken vanligtvis något så enkelt som { "text": "Mensaje a mostrar" }med några valfria fält som kanal, användarnamn eller ikon. Om du istället får en kapslad JSON med ClickUp-specifika fält, du kan ignorera begäran eller misstolka den, vilket resulterar i en varning som aldrig faktiskt syns.

Det bästa sättet att lösa den här typen av inkompatibiliteter är att införa en mellanlager som fungerar som översättarePrecis som med SNS och Lambda, istället för att peka ClickUp-webhooken direkt till Slack, dirigerar du den till din egen slutpunkt (en molnfunktion, ett litet API i din backend). Den slutpunkten tar emot ClickUp JSON, väljer relevant information (till exempel uppgiftsnamn, tidigare och ny status, tilldelad) och konstruerar den lägsta JSON som Slack behöver, och vidarebefordrar sedan begäran till Slacks inkommande webhook.

Detta mönster kan generaliseras till många andra verktyg som "skickar JSON" men inte i det format som krävs av Slack eller Teams. Genom att ha ett eget integrationslager har du fullständig kontroll över meddelandeformatering, filtrering, säkerhet och berikandeOch du kan hantera API-ändringar utan att behöva röra konfigurationen av alla dina skript.

Att utnyttja säkra webhooks för att skicka aviseringar från skript till Teams och Slack innebär mer än att bara kopiera och klistra in URL:er: det kräver förståelse för de olika typerna av Teams-integrationer, JSON-scheman för tjänster som Azure Monitor och Amazon SNS, rollen för mellanprogramvarulager som Power Automate eller AWS Lambda, och säkerhets- och DLP-åtgärderna kring allt detta. Om du utformar den här arkitekturen väl kommer dina team att få tillgång till omfattande, tillförlitliga och realtidsaviseringar, utan chocken av föråldrade anslutningsändringar eller inkompatibla format som tyst sväljer dina aviseringar.