Ilmoitusten vastaanottaminen Windowsissa IoT-antureilta Webhookien kautta

Viimeisin päivitys: 23/09/2025
Kirjoittaja: Isaac
  • Validoitu HTTPS-päätepiste, 200/202-vastaukset ja kontrolloidut uudelleenyritykset.
  • Tilaukset, joissa on clientState, tunnukset ja uusiminen ennen vanhenemista.
  • Latenssin rajoittaminen: Vältä hitaita tai katkoksia optimoimalla taustajärjestelmää.

verkkokoukku

Kytke anturit IoT y vastaanottaa ilmoituksia Windowsissa ilman jatkuvaa palvelimen kysymistä tämä on mahdollista webhookien ansiosta. Pohjimmiltaan Webhook on HTTP-takaisinkutsu jota palvelu tekee aloituspisteellesi tapahtuman sattuessa. Jos haluat nopeita ja luotettavia hälytyksiä (esimerkiksi jos lämpötila-anturi laukaisee ilmoituksen tietokoneellasi), tämä malli on juuri sitä, mitä tarvitset.

Jotta se sopisi työpöytäympäristöön, normaalia on avata suojattu päätepiste pilvessä tai verkossa, vastaanottaa ilmoitus ja sieltä eteenpäin levitä sitä Windows järjestelmäilmoituksena tai integroi se sovellukseesi. Tästä eteenpäin näemme vaatimukset, HTTP-vastaukset, uudelleenyritykset, validoinnit, tilausten elinkaaret, käytännön esimerkit (Microsoft Graph, Bot Framework, FME + Survey123, GitHub ja Apps Käsikirjoitus y Google Analytics Cloud Runin avulla) ja miten ne yhdistetään niin, että IoT-anturisi ilmoittavat sinulle työpöydälläsi ilman, että sinun tarvitsee huolehtia siitä.

Mitä webhook ja päätepistevaatimukset ovat?

verkkokoukku

Webhook on HTTP-pohjainen callback-API. Palvelut, kuten Microsoft Graph, käyttävät sitä lähettääkseen sinulle ilmoituksia, kun resurssissa tapahtuu muutoksia. Tee se oikein seuraavasti: Aloituspisteesi on oltava julkinen ja HTTPS-protokollan mukainen., joihin pääsee URL-osoitteen kautta ja jotka pystyvät vastaamaan nopeasti; muuten palveluntarjoajat lopettavat ilmoitusten lähettämisen sinulle.

Päätepisteen on oltava saavutettava, ja sen on palautettava oikeat ja johdonmukaiset HTTP-vastauksetJos palvelimesi ei vastaa ajoissa, palvelu saattaa alkaa pudottaa ilmoituksia. Ole varovainen: tällä tavoin menetettyä ei voida palauttaa, joten on hyvä seurata viivettä ja skaalausta.

Toinen keskeinen näkökohta on valtuutus. Monet palvelut lähettävät tai odottavat käyttöoikeustunnukset, joilla on voimassaoloaika tilausta luotaessa tai ylläpidettäessä. Jos tunnus vanhenee etkä uusi sitä, ilmoituksia ei toimiteta (vaikka niitä voidaan yrittää uudelleen rajoitetun ajan). Säännöllisen uudelleenvaltuutuksen varautuminen on osa suunnittelua.

HTTP-vastaukset ja uudelleenyritykset

Palveluntarjoajat katsovat ilmoituksen toimitetuksi, kun ne vastaanottavat 2xx-koodin. Jos päätepiste palauttaa jonkin muun vastauksen Microsoft Graphissa 10 sekunnin kuluessa, uudelleenyrityksiä aloitetaan enintään 4 tunnin ajan eksponentiaalisella takaiskulla. Tässä on käytännön opas:

  • 200 OK kun voit käsitellä ilmoituksen noin 3 sekunnin ikkunassa.
  • 202 Hyväksytty Jos se kestää kauemmin: aseta ilmoitus sisäisesti jonoon ja vastaa hyväksymällä se.
  • 5xx Jos et pysty käsittelemään sitä tai asettamaan sitä jonoon, palvelu tietää, että sen on yritettävä uudelleen.

Toimittamattomat ilmoitukset lähetetään uudelleen peruutusmallin mukaisesti. Tämä tarkoittaa, että Niiden täydentäminen voi kestää jopa 4 tuntia. Kun päätepisteesi on taas toiminnassa, varaa aikaa jonoille ja jatkuvuudelle siltä varalta, että sovelluksesi tarvitsee tapahtumien järjestämistä.

Rajoitus: Hitaat tai reagoimattomat päätepisteet

Suorituskyvyn ja tietoturvan suojaamiseksi jotkin palvelut merkitsevät huonosti toimivat päätepisteet. Esimerkiksi Microsoft Graphissa piste merkitään hitaaksi, jos Yli 10 % vastauksista kestää yli 10 sekuntia 10 minuutin sisällä; tässä tilassa uudet ilmoitukset lähetetään sinulle lisäviiveellä.

  1. Hidas tila: Jos vasteaika >10 s ylittää 10 % 10 minuutissa, 10 sekunnin viive kun uusia ilmoituksia lähetetään. Poistut tästä tilasta, kun arvo palaa alle 10 %:n.
  2. Pudotustila: jos kyseinen prosenttiosuus ylittää 15% 10 minuutissaUudet ilmoitukset voidaan poistaa enintään 10 minuutiksi. Ne poistetaan, kun niiden määrä laskee alle 15 %:n.
  RAW-osio kiintolevyllä: mikä se on, syyt, oireet ja kuinka korjata se

Jos päätepisteesi ei täytä näitä suorituskykyominaisuuksia, harkitse käyttöä Tapahtumakeskukset tai tapahtumaruudukko välivaiheena piikkien absorboimiseksi ja prosessoinnin irrottamiseksi.

Tietoturva: todennus, vanheneminen ja palomuuri

Kun luot tilauksen, palvelu lähettää usein käyttöoikeustunnuksen päätepisteeseen. Tätä tunnusta käytetään voimassaolon tarkistamiseen ja sillä on muu elinkaari kuin tilausJos se vanhenee, ilmoituksia ei enää toimiteta, mutta tämä ei rajoita päätepistettäsi. Palvelu kuitenkin yrittää yleensä uudelleen tietyn ajan (esimerkiksi jopa neljä tuntia) vanhenemisen jälkeen, jos uudelleenvahvistat sen ajoissa.

Voit ennakoida vanhenemispäiviä lisäämällä elinkaari-ilmoitukset tilaukseen, jos ne ovat saatavilla. Tällä tavoin saat ilmoituksia, kun token tai tilaus on vanhenemassa, ja voit uusia ne keskeytyksettä. Tilauksen uusiminen päivittää yleensä myös tokenisi.

Verkkoyhteyksien osalta voit määrittää palomuurin sallimaan saapuvat yhteydet vain palveluntarjoajan luotettavista IP-osoitteista (esimerkiksi Microsoft Graphin käyttämät osoitteet). Tämä pienentää hyökkäyspinta-alaa ja estää vääriä ilmoituksia.

Tilausten luominen ja päätepisteen validointi

Tilausmalli on samanlainen eri alustoilla. Microsoft Graphissa asiakassovellus suorittaa POST-komennon /subscriptions-valikolle, joka ilmaisee seurattavan resurssin ja ilmoitusosoite johon ilmoitukset tulisi lähettää. Jos pyyntö on kelvollinen, palvelu lähettää vahvistuksen kyseiseen URL-osoitteeseen ja odottaa vastaustasi ajallaan.

Vahvistuksen aikana pyynnössä lähetetään läpinäkymätön tunniste. Päätepisteesi on vastaa alle 10 sekunnissa jossa on 200 OK, Content-Type text/plain ja vahvistustunnus rungossa (dekoodattu tekstiksi). Jos et noudata näitä ohjeita, tilausta ei luoda. On hyvä käytäntö käyttää koodinvaihtoa (escape) kaikille näytetyille syötteille injektioiden estämiseksi: vaikka palveluntarjoaja ei lähetä HTML- tai JavaScript-koodia, käsittelee tokenia läpinäkymättömänä.

Tilaus vaaditaan yleensä asiakkaan tila (sovelluksesi ja palvelusi välillä sovittu salainen arvo), jonka avulla voit varmistaa, että vastaanottamasi ilmoitukset tulevat palveluntarjoajalta eivätkä kolmannelta osapuolelta. Jokaisella tilauksella on oma tunnisteensa, vaikka valvoisit samaa resurssia samalla ilmoitus-URL-osoitteella.

Ilmoitusten vastaanottaminen ja käsittely

Niin kauan kuin tilaus on voimassa ja muutoksia tapahtuu, palveluntarjoaja lähettää POST-viestin tapahtuman tiedoilla notificationUrl-osoitteeseesi. Joskus he lähettävät sinulle useita ilmoituksia yhdessä erässä. optimoida toimituksetMicrosoft Graphin ilmoituksiin sisältyvät muun muassa ilmoitustunnus, tilaustunnus, tilauksen päättymispäivämäärä, asiakkaan tila (clientState), muutostyyppi (luotu, päivitetty jne.), muutoksen kohteena oleva resurssi ja resurssitiedot.

Kun saat ilmoituksen, vahvista ensin asiakkaan tilaJos se ei vastaa tilausta luodessasi lähettämääsi viestiä, älä pidä sitä voimassa: se on saattanut olla peräisin palveluntarjoajan ulkopuolelta. Vahvistamisen jälkeen käytä liiketoimintalogiikkasi (käyttöliittymän päivittäminen, prosessien jonottaminen, Windows-ilmoitusten käynnistäminen jne.).

Elinkaari: uusimista, hävittämistä ja elinkaari-ilmoituksia

Kaikki tilaukset vanhenevat tai poistetaan. Kun luot tilauksen, määrität vanhenemispäivämääräaikaTuolloin palvelu poistaa tilauksen ja lopettaa ilmoitusten lähettämisen. Sillä välin jokainen vastaanottamasi ilmoitus sisältää yleensä seuraavan päättymispäivämäärän, joten voit ajoittaa uusimisen etukäteen.

  Käyttäjien hallinta PowerShellistä: Täydellinen vaiheittainen opas

Jos et enää tarvitse ilmoituksia, voit Lopeta tilaus tunnuksellaan; jos kaikki menee hyvin, palvelu palauttaa 204-koodin ilman sisältöä. Vielä mielenkiintoisempia ovat elinkaari-ilmoitukset (jos saatavilla): ne tarjoavat elinkaaren ilmoitusURL Saat ilmoituksia, kun käyttöoikeustunnuksesi on vanhenemassa, kun tilauksesi on päättymässä tai jos järjestelmänvalvoja peruuttaa sovelluksesi käyttöoikeudet.

Webhookit viestikanavissa: Bot Frameworkin pääpiirteet

Mukautetuissa viestintäkanavissa, jotka integroivat agentteja tai edustajia, tapahtumat ja viestit lähetetään määritettyyn webhook-päätepisteeseen. Tyypillinen malli käyttää POST-lähetystä keskustelun loppupiste tyyli: {webhook_url}/v3/conversations/{conversationId}/activities.

Puhelu tehdään otsikolla Lupa (operaattori saatu rekisteröidystä sovelluksesta) ja uudelleenyrityskäytäntö on yksinkertainen: jopa kolme yritystä, 10 sekunnin odotusajalla yritystä kohden. Kolmen epäonnistumisen jälkeen ei enää yritetäJos kaikki on kunnossa, päätepisteesi vastaa 200-koodilla ja lähetettyä tekstiä ei oteta huomioon vastauksessa.

Hyötykuormat noudattavat Bot Framework -kaavaa: kenttiä, kuten tyyppi (viesti, tapahtuma tai kirjoitus), kanavan tunnus, lähettäjä (tunnus ja nimi), keskustelun tunnus, tekstimuoto (esim. markdown) ja liitteet (contentType ja contentUrl mukaan lukien) soveltuvin osin. Tämä malli sallii viestit, kirjoitusindikaattorit ja tapahtumat järjestelmän liittymis-/sulkemisvaiheena.

Tapahtumien nimien osalta nimikentässä lähetetyt arvot kattavat tilanteita, kuten Agentti Hyväksytty, Agentti Suljettu, Keskustelu Suljettu, Agentin AloitusToissijainen Kanava ja muita vuorovaikutussyklin vaiheita. Luetteloon kuuluvat mm. PrimaryAgentEndConversation, AgentDisconnected, AgentRaiseSecondaryChannel, AgentEndSecondaryChannel, CloseConversation, SupervisorForceClosedConversation, ConsultAgentInitiated, ConsultAgentFailed, ConsultAgentAcceptSession, ConsultAgentEndSession, ConsultAgentRejectSession, ConsultAgentSessionTimedOut, ConsultAgentRemoved, TransferToAgentInitiated, TransferToAgentFailed, TransferAgentAcceptSession, TransferAgentRejectSession, TransferAgentTimedOutSession, AgentEndedConsult, AgentJoinedCustomerConversation, ConsultantAgentLeftPublicConversation, TransferToQueueInitiated, TransferToQueueFailed, CustomerDisconnected, CustomerDisconnectedWaitingForAgent, AgentAssigned, OutOfOperationHoursDueToNonWorkingHours ja Poissaoloajat lomapäivien vuoksi.

Esimerkki toteutuksesta: Webhook-sovellus Cloud Runissa

Google Cloud Runin avulla voit ottaa käyttöön HTTP-palvelun, joka kuuntelee POST-kutsuja ja käsittelee webhook-ilmoituksia. Yksinkertainen esimerkki Expressin käytöstä jäsentää JSON-tiedoston, lukee otsikon ja X-Goog-kanavatunnus ja kirjaa rungon, palauttaen arvon 200, jos kaikki menee hyvin. gcloudilla käyttöönoton jälkeen suorita deploy, saat julkisen URL-osoitteen palvelun; tämä on URI, johon palveluntarjoaja lähettää sinulle ilmoituksia.

Google Analytics Data API (v1alpha) -työnkulussa voit lisätä yleisöluettelon luodessasi webhook-ilmoitus URI:n ja valinnaisen channelTokenin avulla väärentämisen estämiseksi. Palveluntarjoaja odottaa päätepisteeltäsi arvoa 200; jos se vastaanottaa jotain muuta, se palauttaa virheen (se voi esimerkiksi ilmoittaa odottaneensa arvoa 200, mutta vastaanottaneensa virheen 404). Tällä tavoin tiedät, mitä tehdä. URL-osoite tai vastauslogiikka.

Ilmoitusten tila ja sisältö Analyticsissa

Webhookille lähetetty POST-pyyntö sisältää JSON-esityksen kohteesta pitkäaikainen toiminta ja lähetetty Aikaleima (aikakausi unix (mikrosekunteina). Voit käyttää tätä lippua toistuvien ilmoitusten havaitsemiseen. Kun luot yleisöluetteloa, saat yleensä kaksi POST-ilmoitusta: ensimmäisen välittömästi, jonka tila on LUONNOSSA; toisen valmistuttua, jonka tila on AKTIIVINEN tai EPÄONNISTUNUT.

Näihin lähetyksiin kuuluvat kentät, kuten nimi (resurssipolku), kohdeyleisö, kohdeyleisön näyttönimi (audienceDisplayName), ulottuvuudet, tila, beginCreatingTime, käytetyt kiintiötunnukset, rivien lukumäärä, valmistumisaste ja itse webhookNotification-lohko (URI:n ja channelTokenin kanssa). Tämän rakenteen avulla voit reagoi palvelimellasi, tallentaa edistymisen ja käynnistää toimintoja Windowsissa jokaisen näppäinmuutoksen yhteydessä.

  Ohjelmien yhteensopivuusongelmien vianmääritys Windowsissa

Automaatio GitHubin ja Apps Scriptin avulla

Toinen hyödyllinen tapaus on vastaanottaa GitHub-tapahtumia webhookin kautta ja muuntaa ne esimerkiksi sähköpostiksi jakelulistalle. Voit julkaista verkkosovellus Google Apps Scriptin avulla (suorita omalla tililläsi ja kuka tahansa voi käyttää sitä), kopioi sen julkinen URL-osoite ja määritä se GitHubissa kohdassa Asetukset > Webhookit hyötykuorman URL-osoitteeksi sisältötyypillä application/json.

GitHubin asennuksen aikana saatat nähdä vaihtoehtoja, kuten SSL-vahvistusJoissakin testitilanteissa se on poistettu käytöstä, vaikka tuotannossa on suositeltavaa pitää se käytössä. Kun aktivointi on valmis, GitHub lähettää tapahtumia URL-osoitteeseesi; skriptisi voi muotoilla ne ja välittää ne kohteeseen (esim. sähköpostipalveluun). syklin sulkeminen ilmoitus hyvin pienellä koodilla.

Paikkatietovirrat Survey123:n ja FME Serverin avulla

GIS-ympäristöissä Survey123:sta käynnistetty webhook voi syöttää tietoa työtila FME-palvelimella joka käsittelee JSON-tiedoston ja luo tulosteen (esim. Excel, jossa on useita taulukoita). Tätä varten FME Workbench käyttää tekstitiedostonlukijaa, jossa on Lue koko tiedosto kerralla -vaihtoehto, ja JSONFlattener-ominaisuutta JSON-kenttien kääntämiseen FME-attribuuteiksi.

Kun julkaiset työtilan FME-palvelimella, rekisteröi se vähintään nimellä Työn lähettäjäOta sen ominaisuuksista käyttöön Lähetä HTTP-viestin runko Readerille -vaihtoehto, jotta webhook-runko lähetetään suoraan Readerin tekstitiedostoon prosessin suorituksen aikana. Tämä varmistaa, että sisältö siirtyy ehjänä putkeesi.

Webhookin URL-osoite luodaan FME-palvelimen web-käyttöliittymässä (Suorita työtila > Lisäasetukset). Ensin symbolinen Tämä määrittää webhookin voimassaolon. Viimeisessä valintaikkunassa näet URL-osoitteen. Voit integroida sen Survey123:n kanssa valitsemalla Valtuutus kyselymerkkijonolla ja liittämällä sen kyselyparametreihin.

Kun kaikki on valmista, sisältö siirretään FME-palvelimelle aina, kun käyttäjä lähettää kyselyn. Työt > Valmistuneet Voit seurata tuloksia. Tämä arkkitehtuuri sopii hyvin lomakkeita tai tapahtumia julkaisevien antureiden kanssa ja mahdollistaa niiden muuntamisen raporteiksi tai hälytyksiksi.

Webhookista Windows-ilmoituksiin: käytännöllinen silta

Kun palvelinpuolen ongelmat on ratkaistu (vahvistus, suojaus, uudelleenyritykset), on aika lähettää ilmoitus Windowsille. Idea on yksinkertainen: julkinen päätepisteesi vastaanottaa anturitapahtuman ja lähetä viesti tiimillesiVoit tehdä tämän välittäjäpalvelulla, joka julkaisee väylään, ja kevyellä Windows-agentilla, joka tilaa ja näyttää ilmoituksen.

Jos käsittelet piikkejä, on hyvä idea sisällyttää jonot taustajärjestelmään (esimerkiksi kun ilmoituserät saapuvat) ja soveltaa idempotenssia seuraavasti: tapahtumatunnisteet ja sentTimestampTällä tavoin vältät kaksoiskappaleet työpöydälläsi, jos palvelu yrittää uudelleen tai jos agenttisi muodostaa yhteyden uudelleen.

Synkronoi mobiililaitteet Windowsin kanssa ilmoitusten vastaanottamiseksi
Aiheeseen liittyvä artikkeli:
Matkapuhelimien synkronointi Windowsin kanssa ilmoitusten vastaanottamiseksi