Transferproblem

Hi!

Ich bin mir nicht sicher, ob's hier reingehört oder vielleicht doch besser in "Brainstorming"!? Also bitte verschieben, falls notwendig. DANKE.

- - - - - - - - - - - - - - -

Auf Web-Server 1 (Intranet) befindet sich ein System, mit dem Daten verwaltet werden. (Berechnungen etc.)

Diese Daten sollen nun an Interessenten verkauft werden.

Ein Interessent bekommt eine Mail und muss einen Vertrag unterschreiben.

Danach erhält er einen Login für Web-Server 2 (Internet), auf dem die Daten für ihn zur Ansicht bereitliegen.

Soweit zum geplanten Vorhaben.

Die Frage ist nun: Wie bekomme ich die Daten von Web-Server 1 (Intranet) sauber und ausfallsicher zu Web-Server 2 (Internet) transferiert?

Der Login für den Kunden wird manuell erstellt. Das ist nicht das Problem.

Und dass der Daten-Anbieter nach Vertragsabschluss den Transfer der Daten auf Web-Server 2 durch eine Aktion (Button-Klick) "anstossen" muss, ist auch okay.

Doch was passiert nach dem Button-Klick?

Ich habe mir zuerst überlegt, ein verstecktes/gesichertes Formular auf Web-Server 2 zu installieren, das ich vom Web-Server 1 aus automatisiert befülle (Stichwort cURL) und das die Daten in die DB schreibt.

Aber sowas ist doch irgendwie recht unsicher, oder? Dabei kann immer mal irgendwas mit dem Connect nicht stimmen und dann ist's Essig mit den Daten. (Klar gibt's Errorcodes und ich könnte mir eine Mail zuschicken lassen, doch möchte ich ja so wenig Arbeit wie möglich mit diesem Transfer haben.)

Bei einem automatierten Upload einer Datei (bspw. XML), die dann per Cronjob von Web-Server 2 eingelesen wird, ist eine Fehlerquelle ebenfalls gegeben.

Hat jemand eine Idee?

Ach ja:
Die Daten per Mail an den Kunden zu schicken ist nicht so gut, da diese recht sensibel sind und nicht in ungeschützten Mails durch die Gegend geschickt werden sollen.

Die Verschlüsselung der Mails (PGP etc.) fällt wegen Unkenntnis der Kunden weg.

cya

Warum machst Du das nicht per REST? Eigentlich kannst Du Dir dann hier eine entsprechende Kontrollstruktur (UserID oder irgend eine andere Auth Instanz) einrichten und die Daten in einem von Dir festgelegten Format (JSON oder XML) ausliefern.

Eine andere Möglichkeit wäre ein CronJob der die Daten zwischen den beiden Servern in einem von Dir festgelegten Zeitpunkt abgleicht, so dass auf Server 2 immer ein Backup der Daten von Server 1 liegt.Vorzugsweise in einem Ordner, der nicht von außen zugänglich ist. Sollte keine Verbindung zum Intranet möglich sein, könntest Du zunächst die Daten aus dem Backup ermitteln. Du sagst kein Wort darüber, wie oft sich die auszuliefernden Daten ändern. Von daher müsstest Du selbst festlegen, wie oft der CronJob ausgeführt wird, und ob es überhaupt Sinn macht, dieses System zu verfolgen.

Den Ausfall der Verbindung oder andere Fehlerquellen musst Du eben bedenken und dem User entsprechende Lösungen anbieten. Wenn kein Status 200 geliefert wird, besteht ein Problem. Anhand des zurückgelieferten Status könnte man dem Kunden ja anzeigen, dass momentan ein Problem besteht und er doch bitte später wiederkommen soll.

Komplett ausfallsicher wirst Du einen solchen Datentransfer niemals realisieren können.Es könnte immer irgend etwas sein. Du als Programmierer bist dafür zuständig die meisten dieser Fälle zu bedenken und entsprechende Lösungen anzubieten.

Du willst also verhindern, dass die Verbindung zwischen zwei Servern niemals ausfällt?

Von Server1 direkt in die DB auf Server2 schreiben wäre für dich nicht denkbar?

Solange nicht von dritten und/oder unterschiedlichen Systemen aus Daten auf Server2 änderbar sein müssen, sehe ich die Notwendigkeit nicht, eine spezielle Schnittstelle dafür zu schaffen.

Ich möchte vor allem einen zuverlässigen Transfer. Eine "Man-in-the-middle"-Gefahr sehe ich nicht und wenn jemand die Daten abfangen ("mithören") kann, wäre das auch nicht so problematisch. (Aber unschön. )

Direkt in die DB zu schreiben fällt aus Sicherheitsgründen aus. Ich hätte ungern einen Server im Internet, der nicht ausschließlich durch localhost angesprochen werden kann.

Ein Datenabgleich ist nur bedingt möglich, da die Datenbankstrukturen sehr unterschiedlich sind und das "Gefummel" ziemlich zeitintensiv wäre. Da ist es besser, die Daten in einem sauberen Format zu exportieren und auf dem Zielrechner einzulesen.
Ausserdem würde ein Datenabgleich ja nicht das eigentliche Problem lösen, sondern "nur" für eine frühzeitige Fehlermeldung sorgen, auf die man reagieren kann.

Dass man eine Verbindung niemals zu 100% garantieren kann, ist mir klar. Aber es wäre schon mal ein wichtiger Schritt, eine der besten Lösungen zu wählen und nicht gerade die, die besonders fehleranfällig ist.
Deshalb wollte ich ja Meinungen einholen, ob jemand noch eine gute Idee hat.

Übrigens: Der Kunde bekommt keine Fehlermeldung, wenn der Transfer nicht funktioniert hat. Er bekommt halt nur keine Daten. Das wäre aber schon peinlich genug.
Eine Fehlermeldung bekommt derjenige, der den Transfer gestartet hat, also ein Mitarbeiter des Anbieters.

Was "REST" ist, muss ich erstmal googeln, da mir das überhaupt nichts sagt.

Zitat von sallow2001

Direkt in die DB zu schreiben fällt aus Sicherheitsgründen aus. Ich hätte ungern einen Server im Internet, der nicht ausschließlich durch localhost angesprochen werden kann.

Na ja, ob nun eine REST-Schnittstelle in irgendeiner Form „sicherer“ ist, als einfache MySQL-Replikation, wage ich praktisch zu bezweifeln.
Wenn man da wirklich Angst hat, kann man ja einen DB-Server nur dafür einrichten, der auf einem nicht-standard-port lauscht und nicht viel mehr macht als die Daten annehmen.

Die Replikation hat den Vorteil, dass man sich um nix kümmern muss. MySQL macht alles automatisch und man muss auch nichts dafür programmieren.

Es lässt sich ja ein Benutzer nur für einen bestimmten Host/IP einrichten, dazu dann noch SSL-only und fertig.