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.
Neue Version (Stand 11.4.2017) mit einzelnen Meldeklassen
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
