254 lines
10 KiB
Plaintext
254 lines
10 KiB
Plaintext
Neue Version (Stand 11.4.2017) mit einzelnen Meldeklassen
|
||
Alle Informationen aus den E-Mails hier zusammengetragen:
|
||
|
||
|
||
1.) Welche Informationen werden erwartet unter conveyance->visit-> name/code?
|
||
|
||
Im Bereich der choice mit id=“visit“ kann entweder eine bekannte VisitId bzw. TransitId oder ein eindeutiger Code (zusätzlich optional ein Name),
|
||
den Sie selber für sich festlegen können, angegeben werden
|
||
a. Im letzten Fall wird zusätzlich die Angabe der IMO- oder ENI-Nummer erwartet, sowie der PortOfCall und ETAPortOfCall um eine entsprechende VisitId
|
||
bzw. TransitId zu beantragen
|
||
|
||
2.) HAZA, DPGOnArrival: hier kann es auch passieren dass Position unterschiedlichen Typs zusammen in der Liste landen, z.B. IMDGPosition, IBCPosition?
|
||
Soweit ich weiß gibt das NSW das nicht vor
|
||
|
||
Ich kann Sie beruhigen, dass NSW verträgt mehrere Positionen unterschiedlicher Typen
|
||
|
||
3.) Identifier: wie werden die Identifier von z.B. IMDG Position übertragen. Ist das implizit durch die Reihenfolge?
|
||
|
||
Hier wird zurzeit von uns aus automatisch ein Identifier beim Erzeugen der NSW-Meldung generiert.
|
||
a. Beim Rückkanal würden Sie die erfolgte Meldung an das NSW mit den erweiterten Identifier bekommen, sowie den Status, d.h. ob akzeptiert oder Violation/Error
|
||
|
||
4.) noanod: ETAToKielCanal gibt es nicht separat, ist das bei Transitmeldungen ETAtoPortOfCall? dito ETD?
|
||
|
||
Exakt
|
||
|
||
|
||
Eine andere Frage zum Testbetrieb:
|
||
Wie können gesendete Testdaten eingesehen werden? Steht dazu noch die Webanwendung mit den alten Verbindungsdaten zu Verfügung?
|
||
|
||
Die Testdaten bekommen Sie als erstes über den Rückkanal (wie in 3.a beschrieben)
|
||
a.Zusätzlich werden die Daten im Referenzsystem dargestellt, sofern wir die Berechtigung zum Abholen der Daten vom NSW-Nachrichtenkorb besitzen,
|
||
d.h. wenn wir dort keine Berechtigung haben, ist Ihre einzige Kontrollmöglichkeit der Rückkanal
|
||
|
||
- Die Verbindungsdaten für den Transmitter sind dieselben geblieben?
|
||
Ja
|
||
|
||
- Ich kann nach wie vor dieselbe Version des Transmitter verwenden?
|
||
Ja, lediglich den Parameter Version in der Konfiguration anpassen auf BSMD
|
||
|
||
- Wir haben ein xsd für das Datenformat der Meldeklassen erhalten, allerdings noch nicht für die zusätzl. Funktionen:
|
||
o Anforderung einer Visit-Id
|
||
die Anforderung einer Visit-id erfolgt mit dem gleichen Schema unter Angabe von:
|
||
der IMO- oder ENI-Nummer, sowie der PortOfCall und ETAPortOfCall um eine entsprechende VisitId bzw. TransitId zu beantragen
|
||
|
||
o Abfrage des "Belegt"-Status einer Meldeklasse ....
|
||
|
||
Bitte benutzen Sie für die Abfrage folgende Seite:
|
||
Page: https://ref-app.his-nord.de/HIS-Service/StatusInfoNSW.jsp
|
||
Login: BSMD-REF
|
||
Password: Hd47#fz9Bl48sxU#2
|
||
|
||
Was wir noch benötigen für ein erfolgreiches Login, ist die IP-Adresse/n über welche die Abfrage/n ausgeführt werden
|
||
|
||
im Rückkanal des Transmitter erhalten Sie wie abgesprochen die Antworten (XML-Response) vom NSW Kernsystem.
|
||
Bei Systemfehlern, die ein Senden an das NSW Kernsystem verhindern, erhalten Sie ein Fehler XML.
|
||
Beschreibung und Beispiel finden Sie im Anhang (SystemError-ProcessStatus.7z).
|
||
|
||
noch ein Hinweis für das Login "Live Abfrage - NSW-Kernsystem".
|
||
Wenn der Zugriff verweigert wird, dann bekommen Sie vom Server eine Fehlermeldung.
|
||
- Enthält die Fehlermeldung keinen Code, dann ist die JavaScript Validierung auf der Page fehlgeschlagen.
|
||
- Enthält die Fehlermeldung einen Code, dann können Sie diesen wie folgt interpretieren.
|
||
|
||
---
|
||
URL-REF: https://ref-app.his-nord.de/HIS-Service/StatusInfoNSW.jsp
|
||
|
||
Fehler-Code:
|
||
- Fehler-Code = -10 -> Login und/oder Password falsch
|
||
- Fehler-Code = -11 -> IP-Adresse ohne Berechtigung
|
||
- Fehler-Code = -12 -> Mehr als 3 fehlerhafte Login Versuche
|
||
- Beispiel:
|
||
Zugriff verweigert, keine Berechtigung für diesen Service. [Code: Fehler-Code ]
|
||
---
|
||
|
||
Nach mehr als 3 fehlerhafte Login Versuche, erhalten Sie den Code:-12.
|
||
In diesem Fall erfolgt keine Prüfung des Logins mehr.
|
||
Es gibt dann drei Möglichkeiten um die Login Prüfung auf dem Server wieder anzustoßen:
|
||
- warten bis die Session abgelaufen ist (z.Z. 8 Stunden)
|
||
- einen anderen Browser nehmen
|
||
- den aktuellen Cookie im Browser löschen
|
||
|
||
Beispiel (Anhang: Login-Fehler-Code-10.jpg):
|
||
Zugriff verweigert, keine Berechtigung für diesen Service. [Code: -10]
|
||
|
||
Info:
|
||
Beim NSW-Kernsystem ist es nicht möglich einen einzelnen Meldetypen abzufragen.
|
||
Es werden immer alle Informationen zu einer VisitID bzw. TransitID zurückgegeben.
|
||
|
||
-----------------------------------------------------------------------------------------
|
||
Spezialitäten bei HIS Nord (Stand 17.4.16)
|
||
|
||
Generell: Die Datenvorlage (XSD) wird per xsd.exe /classes aus den einzelnen Quelldateien generiert. Wir bekommen XSD 1.1 geliefert
|
||
(Java-Implementierung auf der Gegenseite), wofür es unter .NET keine Unterstützung gibt. Ich habe mich so beholfen, alle "ASSERT"s aus
|
||
dem XSD einfach zu löschen, damit funktioniert dann die Konvertierung. Allerdings verlieren wir dann die Validierung bei der Erzeugung.
|
||
-> Assert Prüfungen müssen in der zukünftigen Benutzerschnittstelle implementiert werden
|
||
|
||
- "transmitter" wird verwendet um die erzeugten Daten an D&D zu schicken
|
||
- eine Rückmeldung erfolgt direkt über das Transmitter-Tool (Verstoß gegen XSD) oder über Email an den Meldenden, das passiert
|
||
bei "Highlevel" Fehlern aus dem NSW (Error/Violation).
|
||
|
||
- Da ein Haufen Pflichtangaben notwendig sind habe ich mich entschlossen, bei D&D den Message-Core immer komplett zu schicken
|
||
Sollen die doch das ganze auseinanderflöhen.
|
||
|
||
Ursprüngliche Mail von Deffke:
|
||
- Generell: Ist es möglich nur Teilnachrichten zu verschicken oder erwartet die Schnittstelle eine komplette Anmeldung?
|
||
|
||
à Die Schnittstelle erwartet bisher folgende Pflichtangaben, damit ein reibungsloser Ablauf funktioniert:
|
||
|
||
· Angabe der VISITID, TRANSITID oder ein eindeutiger CODE (können Sie selbst festlegen), zu dem alle Nachrichten gesandt bzw. zusammengefasst werden können
|
||
|
||
· Angabe der Melderdaten (OWNER_SENDER)
|
||
|
||
o Hier schlagen wir Ihnen folgende Handhabung vor:
|
||
|
||
§ In „name_short“ und „name_long“ werden die Firmenkurz- und –langnamen eingetragen von dem jeweiligen Makler, Reederei etc.
|
||
|
||
· Auf dieser Basis können wir in unserem System eine eindeutige Zuordnung erreichen
|
||
|
||
· Deshalb besteht hier Abstimmungsbedarf hinsichtlich der Firmen für die Sie melden möchten.
|
||
|
||
o Zum Beispiel in unserem System ist Baltimar wie folgt gespeichert:
|
||
|
||
§ name_short: Baltimar
|
||
|
||
§ name_long: Baltimar Schiffahrt u. Transport GmbH
|
||
|
||
§ In der „address“ die Firmenadresse, z.B. von Baltimar
|
||
|
||
§ Im „contact“ bitte folgende Vorgaben berücksichtigen
|
||
|
||
· name: BSMD
|
||
|
||
· firstname: <Name eines zentral Verantwortlichen>
|
||
|
||
· phone: <Nummer unter der zentral jemand für Rückfragen erreichbar ist>
|
||
|
||
· fax:<Nummer, die zentral erreichbar ist>
|
||
|
||
· email: <Mail-Adresse, die zentral erreichbar ist>
|
||
|
||
· Angabe der notwendigen Schiffsstammdaten
|
||
|
||
· Angabe IMPORT, EXPORT, TRANSIT
|
||
|
||
o Sind Pflicht, da somit ermittelt werden kann, ob es sich um einen Eingang bzw. Ausgang für den Hafen bedeutet
|
||
|
||
o Transit ist für den Nord-Ostsee-Kanal (NOK) vorgesehen
|
||
|
||
· Angabe PERSONSONBOARD
|
||
|
||
o Zur Zeit noch Pflicht (historisch bedingt), könnten wir auf Wunsch auch optional machen
|
||
|
||
· Alle anderen Meldetypen und Angaben, die weiter oben nicht aufgezählt wurden, sind optional, d.h. können als Teilnachrichten gesandt werden
|
||
|
||
- Mit welchen Werten werden folgende Felder in nsw belegt:
|
||
|
||
- date_registration (aktuelle Zeit?)
|
||
|
||
· Dieser Wert wird bisher nicht für das Senden ans NSW benötigt
|
||
|
||
· Es dient lediglich der Auswertung, in welcher Reihenfolge die Meldung bzw. XML-Files erzeugt und abgearbeitet wurden
|
||
|
||
- message_sender
|
||
|
||
· Hier bitte BSMD eintragen
|
||
|
||
· Ans NSW werden aber die Werte aus dem OWNER_SENDER verwendet, speziell aus CONTACT
|
||
|
||
- message_recipient
|
||
|
||
· Hier bitte HIS-NORD eintragen
|
||
|
||
- document_reference (kann das verwendet werden um bei einer Antwort eine Rückwärts-Referenz auszuwerten?)
|
||
|
||
· Auf welcher Ebene erwarten Sie eine Rückwärts-Referenz?
|
||
|
||
o Beim Transmitter erhalten Sie die Fehlerausgabe der Schemavalidierung und dort wird der Dateiname als Referenz verwendet
|
||
|
||
o Falls was beim Import in unsere Datenbank bzw. beim Senden an das NSW schief geht und es an den gesandten XML-Files liegt, dann werden Mails an die Mail-Adresse aus CONTACT (OWNER_SENDER) gesendet
|
||
|
||
§ Über diesen Weg könnten auch angeforderte VISITIDs etc. gesendet werden, falls erwünscht
|
||
|
||
|
||
|
||
- Gibt es vom NSW Standard abweichende / ergänzende Felder und sind diese dokumentiert?
|
||
|
||
· Ich habe Ihnen hierzu die NSW-Spezifikation im Anhang zur Verfügung gestellt
|
||
|
||
· Grundsätzlich orientiert sich das an Ihnen überreichte XML-Schema an diesen Vorgaben mit folgenden Abweichungen
|
||
|
||
Meldetypen
|
||
|
||
|
||
Abweichungen
|
||
|
||
NOA_NOD
|
||
In IMPORT, EXPORT, TRANSIT vorkommend,
|
||
wobei zusätzlich Hafengebiet oder GISIS-Code gemeldet werden kann, ansonsten wird das Standard-Hafengebiet genommen, z.B. ÜSH für Überseehafen Rostock
|
||
|
||
ATA/ATD
|
||
In IMPORT, EXPORT
|
||
|
||
POBA/POBD
|
||
In PersonsOnBoard, je nach IMPORT, EXPORT wird entsprechender Ein-/Ausgang gemeldet
|
||
|
||
Name
|
||
In NameOfMaster
|
||
|
||
TIEFA/TIEFD
|
||
In Draught_DMT, je nach IMPORT, EXPORT wird entsprechender Ein-/Ausgang gemeldet
|
||
|
||
BKRA/BKRD
|
||
In BunkerFuelList, je nach IMPORT, EXPORT wird entsprechender Ein-/Ausgang gemeldet
|
||
|
||
STAT
|
||
In vessel
|
||
|
||
LADG
|
||
In GeneralCargo->LoadUnit
|
||
|
||
HAZA/HAZD
|
||
In GeneralCargo->LoadUnit, je nach IMPORT, EXPORT wird entsprechender Ein-/Ausgang gemeldet
|
||
|
||
SEC
|
||
In SEC
|
||
|
||
INFO
|
||
In Info
|
||
|
||
SERV
|
||
In SERV
|
||
|
||
PRE72H
|
||
In Pre72H
|
||
|
||
MDH
|
||
In MDH
|
||
|
||
WAS
|
||
In Waste
|
||
|
||
CREW/PAS/BPOL
|
||
In CREW/PAS/BPOL
|
||
|
||
TOWA/TOWD
|
||
In TOWS, je nach IMPORT, EXPORT wird entsprechender Ein-/Ausgang gemeldet
|
||
|
||
|
||
|
||
|
||
|
||
Für die Schemaänderung mit dem Hafengebiet erhalten Sie ein erneute Version des XML-Schemas.
|
||
· Unter PortOfCall (ComplexType: portofcallhazmat) kann zusätzlich das Hafengebiet/GISISCode zugeordnet werden, damit eine saubere Zuordnung im System erfolgen kann, ansonsten werden Standard-Hafengebiete verwendet
|
||
|
||
|