Frage

Ich arbeite derzeit an einem Projekt mit spezifischen Anforderungen.Hier ein kurzer Überblick:

  • Die Daten werden von externen Webservices abgerufen
  • Die Daten werden in SQL 2005 gespeichert
  • Die Datenbearbeitung erfolgt über eine Web-GUI
  • Der Windows-Dienst, der mit den Webdiensten kommuniziert, ist außer über die Datenbank nicht mit unserer internen Web-Benutzeroberfläche gekoppelt.
  • Die Kommunikation mit den Webdiensten muss sowohl zeitbasiert erfolgen als auch durch Benutzereingriffe auf der Web-Benutzeroberfläche ausgelöst werden.

Das aktuelle (Vor-Vor-Produktions-)Modell für die Auslösung der Webdienstkommunikation erfolgt über eine Datenbanktabelle, in der Auslöseanforderungen gespeichert werden, die durch den manuellen Eingriff generiert werden.Ich möchte nicht wirklich mehrere Triggermechanismen haben, möchte aber die Datenbanktabelle basierend auf dem Zeitpunkt des Aufrufs mit Triggern füllen können.Aus meiner Sicht gibt es zwei Möglichkeiten, dies zu erreichen.

1) Passen Sie die Triggertabelle an, um zwei zusätzliche Parameter zu speichern.Einer ist "Wird dieses zeitbasierte oder manuelle hinzugefügt?" und ein nullierbares Feld, um die Zeitdetails zu speichern (genaues Format zu ermitteln).Wenn es sich um einen manuell erstellten Trigger handelt, markieren Sie ihn als verarbeitet, wenn der Trigger ausgelöst wurde, nicht jedoch, wenn es sich um einen zeitgesteuerten Trigger handelt.
oder
2) Erstellen Sie einen zweiten Windows-Dienst, der die Trigger in festgelegten Zeitabständen spontan erstellt.

Die zweite Option kommt mir wie ein Trick vor, aber die Verwaltung von Option 1 könnte sich leicht in einen Programmier-Albtraum verwandeln (woher wissen Sie, ob die letzte Abfrage der Tabelle das Ereignis zurückgegeben hat, das ausgelöst werden muss, und wie können Sie es dann stoppen?). erneutes Auslösen bei der nächsten Umfrage)

Ich würde mich freuen, wenn jemand ein paar Minuten Zeit hätte, um mir bei der Entscheidung zu helfen, welche Route (eine dieser beiden oder möglicherweise eine dritte, nicht aufgeführte) ich nehmen soll.

War es hilfreich?

Lösung

Warum nicht einen SQL-Job anstelle des Windows-Dienstes verwenden?Sie können Ihren gesamten Datenbank-Triggercode in gespeicherten Prozeduren kapseln.Dann können Ihre Benutzeroberfläche und Ihr SQL-Job dieselben gespeicherten Prozeduren aufrufen und die Trigger auf die gleiche Weise erstellen, sei es manuell oder in einem Zeitintervall.

Andere Tipps

Ich sehe es so.

Sie haben einen Windows-Dienst, der die Rolle eines Planers übernimmt, und darin gibt es einige Klassen, die einfach die Webservices aufrufen und die Daten in Ihre Datenbanken einfügen.

Sie können diese Klassen also auch direkt über die WebUI verwenden und die Daten basierend auf dem WebUI-Trigger importieren.

Mir gefällt die Idee nicht, eine vom Benutzer generierte Aktion als Flag (Trigger) in der Datenbank zu speichern, wo ein Dienst sie abfragt (in einem Intervall, das nicht unter der Kontrolle des Benutzers liegt), um diese Aktion auszuführen.

Sie könnten sogar den gesamten Code in eine Exe-Datei umwandeln, die Sie dann mit dem Windows-Scheduler planen können.Und rufen Sie dieselbe Exe auf, wenn der Benutzer die Aktion über die Web-Benutzeroberfläche auslöst.

@Vaibhav

Leider lässt die physische Architektur der Lösung keine direkte Kommunikation zwischen den Komponenten zu, mit Ausnahme der Web-Benutzeroberfläche zur Datenbank und der Datenbank zum Dienst (der dann die Webdienste aufrufen kann).Ich stimme jedoch zu, dass die Wiederverwendung der Kommunikationsklassen hier ideal wäre – ich kann das einfach nicht innerhalb der Grenzen unseres Geschäfts tun*

*Ist es nicht immer so, dass eine technisch „bessere“ Lösung durch äußere Faktoren behindert wird?

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top