Ich möchte eine Seite für Regierungstermine (ähnlich einer NBI-Terminbuchungsseite) überwachen und möchte nur benachrichtigt werden, wenn sich etwas Wichtiges ändert, wie neue Terminplätze oder ein Statusupdate.
Ich möchte keine aggressive Datenextraktion durchführen oder gegen Website-Regeln verstoßen. Ich muss nur alle paar Minuten prüfen und eine Telegram- oder E-Mail-Benachrichtigung senden, wenn sich wirklich etwas ändert.
Was ist der beste Ansatz in n8n dafür? HTTP Request + HTML Extract + Vergleich mit dem vorherigen Ergebnis? Oder gibt es einen besseren Workflow?
Mich würde interessieren, wie andere diese Art der Überwachung handhaben, ohne Rate-Limiting zu bekommen.
Hallo @jozerizzel Willkommen!
Richte die HTTP-Anfrage auf den JSON-Endpunkt, den der Buchungskalender selbst aufruft, anstatt auf das gerenderte HTML, und speichere dann die Antwort ETag in den statischen Workflowdaten, um sie beim nächsten Abruf als If-None-Match zurückzusenden. Unveränderte Abrufe kommen mit 304 und ohne Body zurück. Aktiviere daher „Include Response Headers and
Danke für die ausführliche Erklärung, ich weiß das wirklich zu schätzen.
Ich hätte nicht gedacht, den JSON-Endpunkt mit ETag und If-None-Match zu verwenden. Das klingt viel besser, als jedes Mal das ganze HTML zu vergleichen.
Danke auch für die Erklärung des Static-Data-Verhaltens. Ich war verwirrt, weil jeder manuelle Test wie ein erster Durchlauf aussah, jetzt weiß ich, warum.
Ich werde meinen Workflow aktualisieren und ihn stattdessen mit einem veröffentlichten Trigger testen. Hoffentlich werden dadurch unnötige Anfragen reduziert und ich werde nicht blockiert.
Danke, dieser Workflow sieht viel verständlicher aus.
Ich probiere das erst mal aus, bevor ich es mit ETags komplexer mache. Mein Hauptziel ist einfach, benachrichtigt zu werden, wenn sich etwas auf der NBI Online Terminseite ändert, damit ich sie nicht den ganzen Tag über manuell überprüfen muss.
Ich baue diesen Flow auf und schaue, wie er sich bewährt. Wenn die Website zu aufwändig zum Abfragen wird, schaue ich mir dann den JSON/ETag-Ansatz an, der vorher erwähnt wurde.
Hi @jozerizzel, hattest du Gelegenheit, diesen Workflow auszuprobieren? Hat er dich über die Terminänderungen benachrichtigt, die du brauchtest, oder bist du auf Schwierigkeiten gestoßen?
Ich baue gerade einen kleinen n8n-Website-Change-Starter und möchte verstehen, wo die bestehenden Ansätze noch zu kurz greifen. Danke!
Ein paar Dinge, die für mich einen Unterschied gemacht haben, wenn ich einen ähnlichen Monitor über mehrere Listing-Seiten laufen ließ:
Die Häufigkeit ist die Hauptvariable, nicht die Technik.
Die meisten Blockierungen, die ich gesehen habe, kamen vom zu häufigen Polling, nicht vom Request selbst. Wenn sich die zugrunde liegenden Daten nur ein paar Mal am Tag ändern, bringt dir das Abfragen alle 5 Minuten nichts und kostet dich nur die Verbindung. Ich bin von häufigem Polling auf einen festen Zeitplan übergegangen und die Blockierungen hörten auf.
Diff auf Feldern, nicht auf der Seite.
Der Vergleich von vollständigem Seiten-HTML gibt dir jedes Mal falsch positive Ergebnisse, wenn sie ein Layout-Update ausrollen. Extrahiere die Handvoll Felder, die dir tatsächlich wichtig sind, hash diese und vergleiche sie mit dem vorherigen Lauf. Weniger Alerts, und die, die du bekommst, sind real.
Führe ein Ledger über das, was du bereits gesehen hast.
Speichere eine ID pro Element und überprüfe neue Läufe dagegen. Das ist das, was „hier ist alles auf der Seite
