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: · phone: · fax: · email: · 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