This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Ergänzung Rückkanal (26.7.17)
Da wir keine XSD bekommen aus dem Beispiel-XML per xsd.exe bla.xml -> xsd.exe bla.xsd /classes -> bla.cs generiert.
Ich habe dann die Klassen hinzugefügt und mit dem bsmd.hisnord Namespace dekoriert.
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
