Tweet
Strategische Planung für Mobility-Support
Hallo Experten
Ich bin gerade mit der Architekturplanung eines grösseres Systems beschäftigt, auf Basis C# & SQL-Server.
Die Hauptfunktionalität (bzw. alles) soll in einem modularen Fat-Client implementiert werden, während einige Funktionen für einen grösseren Anwenderkreis zusätzlich in ASP.NET für das Web zur Verfügung gestellt werden.
Nebst Anderen, wird es auch Assemblies geben, welche Business-Klassen und Persistenz-Layer enthalten.
Diese Assemblies sollen die gemeinsame Basis für die beiden Teilsysteme bilden.
Soweit so gut ;-)
Der nächste, zukünftige Schritt wäre, die Tür offen zuhalten, so dass evtl. auch mal mobile Offline-Geräte an das System angeschlossen werden könnTen…
(vielleicht wird UMTS ja auch zwischen zeitlich zahlbar, dann wird das hinfällig)
Da mich mit Palms, Handhelds etc. nicht so speziell auskenne, möchte ich mal wissen, was es denn da zu berücksichtigten gibt.
Vorgestellt habe ich mir mal folgendes:
- Die o.g. Assemblies mit der Business-Logik könnten/sollten (nach Möglichkeit) ebenfalls die Basis für die mobile Offline-Version des Systems darstellen. Da drin ist eigentlich nur „Standard-Code“ enthalten; DB-Zugriff über System.Data.sqlClient; unter der Annahme, dass ein SQL-Server Mobile Edition auf diesen Geräten installiert ist, sollte das vermutlich relativ einfach möglich sein, denn die Konfig-Daten für die DB habe ich in einem XML ausgelagert.
- In der Hauptanwendung (dem Fat-Client) würde ich eine Art „Check-Out“-Funktion vorsehen. Das wäre nichts anderes, als ein Flag, das ein Partner (Kunde, Mitglied, sonstiger Kontakt) für online-Berarbeitungen sperren würde
- Im Datenbankschema wäre dieses Flag vom Typ DateTime, damit nach ca. 10 Tagen eine Warnung realisiert werden könnte, oder die Sperrung rückgängig gemacht werden könnte. Diese Flag sehe ich nur für die Kunden (Partner) Tabelle vor.
- Im Hauptprogramm (Fat-Client) würde der check out-Vorgang in etwa so aussehen:
1. Der Sachbearbeiter schliesst sein Gerät am PC des Fat-Clients an
2. Der Sachbearbeiter ‚reserviert’ den gewünschten Kunden, in dem er ihn in den offline-Modus setzt; a) sämtliche Daten, oder mindestens alle Daten dieses Kunden (aller Tabellen) auf den mobilen SQL-Server überträgt b) Den Kunden im Haupt-System für online-Bearbeitungen sperrt c) Den gewünschten Kunden im mobilen System für die Bearbeitung freigibt (alle anderen, nicht im offline-Modus befindlichen sind im mobilen System nur read-only“
- Der Check-in wäre genau das gleiche:
1. Der Sachbearbeiter schliesst sein Gerät am PC des Fat-Clients an
2. Der Sachbearbeiter setzt den/die Kunden wieder in den online-Modus, das System wird a) Alle Daten des betroffenen Kunden vom mobilen SQL-Server in den Haupt-Server übertragen b) den offline-Modus im Mobilen Gerät aufheben c) Den Kunden im mobilen System wieder read-only setzen
oder halt alternativ nur den offline-Modus des betroffenen Kunden wieder löscht ohne Datenangleich; dann ist wieder das Haupt-System Master der Daten.
Irgendwie müsste man natürlich noch die Kommunikation der Systeme regeln, dass das offline Gerät den Kunden korrekt writable/read-only setzt nach erfolgreichem Umschalten des Modus.
Könnte das so etwa hinhauen oder ist das dämlich und ginge viel einfacher ? ;-)
Es stellt sich natürlich die Frage, ob gleich ein so rigoroses Sperren des Kunden für Änderungen am (stationären) Haupt-System nicht ein bisschen extrem ist, oder ob mit vertretbarem Aufwand die Daten abgeglichen werden könnten/sollten. Aber wenn ich von „sämtlichen“ Daten eines Kunden spreche, so betrifft das halt einige Child-Tabellen.
Auch wenn die Daten eines Kunden über einen längeren Zeitraum im offline-Modus bleiben und in diesem mehrmals (z. B. an verschiedenen Tagen mutiert werden) so werden die Daten im Haupt-System nur einmal historisiert und zwar beim import, also dem „definitiven Speichern“ der Daten. Obwohl die Business-Klassen der (gemeinsamen) Assemblies die Historisierung (ihrerseits via Stored-Procedures) direkt vornehmen; es wird nur der gültige Datensatz züruck an das Haupt-System geliefert; die historisierten Sätze auf dem mobilen SQL-Server würden dann gelöscht.
Die offline-Bearbeitung von Stammdaten habe ich mal bewusst weggelassen, so was soll gefälligst am Haupt-System (Fat-Client) erfolgen…. ;-)
Im Fat-Client selbst wird für „interne“ Transaktionen nichts gesperrt, es wird optimistisches Locking/Multi-User-Handling implementiert, das ein nicht explizit verlangtes Überschreiben neuerer Daten verhindert.
Bin gespannt auf Eure Meinungen ;-)
Roger
Hallo Experten
Ich bin gerade mit der Architekturplanung eines grösseres Systems beschäftigt, auf Basis C# & SQL-Server.
Die Hauptfunktionalität (bzw. alles) soll in einem modularen Fat-Client implementiert werden, während einige Funktionen für einen grösseren Anwenderkreis zusätzlich in ASP.NET für das Web zur Verfügung gestellt werden.
Nebst Anderen, wird es auch Assemblies geben, welche Business-Klassen und Persistenz-Layer enthalten.
Diese Assemblies sollen die gemeinsame Basis für die beiden Teilsysteme bilden.
Soweit so gut ;-)
Der nächste, zukünftige Schritt wäre, die Tür offen zuhalten, so dass evtl. auch mal mobile Offline-Geräte an das System angeschlossen werden könnTen…
(vielleicht wird UMTS ja auch zwischen zeitlich zahlbar, dann wird das hinfällig)
Da mich mit Palms, Handhelds etc. nicht so speziell auskenne, möchte ich mal wissen, was es denn da zu berücksichtigten gibt.
Vorgestellt habe ich mir mal folgendes:
- Die o.g. Assemblies mit der Business-Logik könnten/sollten (nach Möglichkeit) ebenfalls die Basis für die mobile Offline-Version des Systems darstellen. Da drin ist eigentlich nur „Standard-Code“ enthalten; DB-Zugriff über System.Data.sqlClient; unter der Annahme, dass ein SQL-Server Mobile Edition auf diesen Geräten installiert ist, sollte das vermutlich relativ einfach möglich sein, denn die Konfig-Daten für die DB habe ich in einem XML ausgelagert.
- In der Hauptanwendung (dem Fat-Client) würde ich eine Art „Check-Out“-Funktion vorsehen. Das wäre nichts anderes, als ein Flag, das ein Partner (Kunde, Mitglied, sonstiger Kontakt) für online-Berarbeitungen sperren würde
- Im Datenbankschema wäre dieses Flag vom Typ DateTime, damit nach ca. 10 Tagen eine Warnung realisiert werden könnte, oder die Sperrung rückgängig gemacht werden könnte. Diese Flag sehe ich nur für die Kunden (Partner) Tabelle vor.
- Im Hauptprogramm (Fat-Client) würde der check out-Vorgang in etwa so aussehen:
1. Der Sachbearbeiter schliesst sein Gerät am PC des Fat-Clients an
2. Der Sachbearbeiter ‚reserviert’ den gewünschten Kunden, in dem er ihn in den offline-Modus setzt; a) sämtliche Daten, oder mindestens alle Daten dieses Kunden (aller Tabellen) auf den mobilen SQL-Server überträgt b) Den Kunden im Haupt-System für online-Bearbeitungen sperrt c) Den gewünschten Kunden im mobilen System für die Bearbeitung freigibt (alle anderen, nicht im offline-Modus befindlichen sind im mobilen System nur read-only“
- Der Check-in wäre genau das gleiche:
1. Der Sachbearbeiter schliesst sein Gerät am PC des Fat-Clients an
2. Der Sachbearbeiter setzt den/die Kunden wieder in den online-Modus, das System wird a) Alle Daten des betroffenen Kunden vom mobilen SQL-Server in den Haupt-Server übertragen b) den offline-Modus im Mobilen Gerät aufheben c) Den Kunden im mobilen System wieder read-only setzen
oder halt alternativ nur den offline-Modus des betroffenen Kunden wieder löscht ohne Datenangleich; dann ist wieder das Haupt-System Master der Daten.
Irgendwie müsste man natürlich noch die Kommunikation der Systeme regeln, dass das offline Gerät den Kunden korrekt writable/read-only setzt nach erfolgreichem Umschalten des Modus.
Könnte das so etwa hinhauen oder ist das dämlich und ginge viel einfacher ? ;-)
Es stellt sich natürlich die Frage, ob gleich ein so rigoroses Sperren des Kunden für Änderungen am (stationären) Haupt-System nicht ein bisschen extrem ist, oder ob mit vertretbarem Aufwand die Daten abgeglichen werden könnten/sollten. Aber wenn ich von „sämtlichen“ Daten eines Kunden spreche, so betrifft das halt einige Child-Tabellen.
Auch wenn die Daten eines Kunden über einen längeren Zeitraum im offline-Modus bleiben und in diesem mehrmals (z. B. an verschiedenen Tagen mutiert werden) so werden die Daten im Haupt-System nur einmal historisiert und zwar beim import, also dem „definitiven Speichern“ der Daten. Obwohl die Business-Klassen der (gemeinsamen) Assemblies die Historisierung (ihrerseits via Stored-Procedures) direkt vornehmen; es wird nur der gültige Datensatz züruck an das Haupt-System geliefert; die historisierten Sätze auf dem mobilen SQL-Server würden dann gelöscht.
Die offline-Bearbeitung von Stammdaten habe ich mal bewusst weggelassen, so was soll gefälligst am Haupt-System (Fat-Client) erfolgen…. ;-)
Im Fat-Client selbst wird für „interne“ Transaktionen nichts gesperrt, es wird optimistisches Locking/Multi-User-Handling implementiert, das ein nicht explizit verlangtes Überschreiben neuerer Daten verhindert.
Bin gespannt auf Eure Meinungen ;-)
Roger