50 lines
3.3 KiB
Plaintext
50 lines
3.3 KiB
Plaintext
- Testing: Ein Service-Endpunkt inkl wsdl wird ab Ende des Monats Feb. zu Verfügung stehen
|
|
- Wir müssen ebenfalls einen Service-Endpunkt implementieren für die "proaktiven" Antwortnachrichten
|
|
-> ein Client Only Ansatz ist das somit nicht und für uns mit zusätzlichem Aufwand verbunden. Ebenfalls unklar die
|
|
von dbh erwartete Funktionssignatur - so müssen sie für alle Schnittstellenpartner eine eigene Antwortschnittstelle implementieren
|
|
dbh implementiert eine Webanwendung, die bis Ende April zu Verfügung steht. Diese Komponente ist der letzte Bestandteil.
|
|
Außerdem soll es eine statistische Auswertung geben (wurde nur in einem Nebensatz erwähnt)
|
|
- doppelte Schiffsanmeldungen werden vom System nicht abgefangen .. dafür ist der Endanwender selbst zuständig.
|
|
- Zeiten sind UTC
|
|
- Zeichensatz, unicode: warten auf Antwort von dbh
|
|
- nach der im NSW erfolgreichen Anmeldung oder generell Meldung zu einem Schiff soll das System ein Protokoll
|
|
erstellen, daß der Kunde als "richtig" gegenzeichnet. Sind Einwände vorhanden kann noch ein Update hinterhergeschickt
|
|
werden.
|
|
- noch offene Fragen: wir wird von dbh ein Meldungs-Reset umgesetzt (muss auch über die Schnittstelle getested werden)?
|
|
- wsdl für response muss eigentlich auch von dbh kommen?
|
|
- Datenbankdesign: Um eine Historie zu erhalten können die Daten nicht nur in einer Maske / einer Tabelle gehalten werden?
|
|
|
|
Zu überlegen:
|
|
- wie "merkt" das Frontend eine Änderung eines Datensatzes im Backend?
|
|
- brauchen wir überhaupt 2 Datenbanken? Würde es nicht ausreichen, ebenfalls auf die Wetris Tabellen zuzugreifen und in
|
|
derselbe DB einfach nur ein paar neue Tabellen anzulegen. Damit könnte man die ggf. komplizierte Replikation sparen.
|
|
|
|
Es muss einen Meldungs / Vorgangskopf und zeitlich sortierte Vorgangspositionen geben, in denen dann die eigentlichen
|
|
Feldwerte enthalten sind, außerdem ein NSW Status (Kommunikationsstatus mit der Schnittstelle) und ein Zeitstempel.
|
|
Damit wird dann auch eine Historie sichtbar. In der Hauptmaske ist der jeweils aktuelle Zustand angezeigt (analog Zollanwendung APD (dbh))
|
|
|
|
Außerdem eine Schiffsanlauf-Kopf Tabelle, in der die IMO, Zeitstempel Hafen und VISIT-ID enthalten sind. Alle Meldungen referenzieren auf
|
|
diese Tabelle. Damit ist ein Schiffsanlauf in einem Vorgang zusammengefasst. Dadurch wird eine Vorbelegung von
|
|
Feldern aus historischen Daten zur leichteren Eingabe möglich.
|
|
|
|
Validierungs-Regeln für die Eingabe von Meldungen sollten direkt in der Maske eingebaut sein, nicht im NSW Service,
|
|
damit hier kein Round-Trip notwendig wird. Diese Regeln müssen leicht änderbar sein.
|
|
|
|
|
|
Zeitplan für die NSW Umsetzung beim BSMD
|
|
|
|
So bald wie möglich:
|
|
- aktuelle Zugangsdaten zu den Testsystemen (Firewall, VPN): Kersten
|
|
- Installation SQL Server auf NSW Rechner (Express Edition, gleiche Version wie Wetris): Kersten
|
|
|
|
Bis Ende des Monats:
|
|
- Anlegen der Datenbankstruktur für die fehlenden Felder über EasyLogic: Kersten, Christin, (Michael), Daniel
|
|
- Anlage der Referenztabelle bzw. Lieferung der Screenshots für die Zuordnung der Felder: Christin
|
|
- Import der aktuellen .xsd Daten und Anlage der Service-Struktur NSW Rechner: Daniel
|
|
|
|
Bis Ende März:
|
|
- Abfrage von VISIT-ID / Einfache Schiffsmeldung inkl Test mit dbh Schnittstelle: Daniel
|
|
|
|
Bis Ende April:
|
|
- Implementierung der restlichen Meldungsklassen (außer Gefahrgut): Daniel
|