Importserver: Unterschied zwischen den Versionen
Alice (Diskussion | Beiträge) (→Galileo) |
(→Datenübernahme) |
||
Zeile 284: | Zeile 284: | ||
|- | |- | ||
| RM*UMB-SC/nnnn || RM*UMB-SC/OFF || Der durch 'nnnn' gekennzeichnete SalesChannel (externer Code) wird auf dem Dossier gesetzt | | RM*UMB-SC/nnnn || RM*UMB-SC/OFF || Der durch 'nnnn' gekennzeichnete SalesChannel (externer Code) wird auf dem Dossier gesetzt | ||
+ | |- | ||
+ | | RM*UMB-SV/NFdd.dd FOdd.dd RCaa FTaa || RM*UMB-SV/NF3000.00 FO2000.00 RC10 FT50 || Savings-Daten. Die RM können Pax und/oder Segmenten zugeordnet werden, um Savings für spezifische Tickets auszuweisen. | ||
+ | |||
+ | * NF - Benchmark fare | ||
+ | * FO - Offered fare | ||
+ | * RC - Reason code | ||
+ | * FT - Fare type | ||
|} | |} | ||
Version vom 23. Oktober 2015, 07:08 Uhr
Inhaltsverzeichnis
Übersicht
Der Importserver dient als Schnittstelle zwischen diversen Reservationssystemen und Umbrella.net. Buchungsrecords werden in ein Standardformat (Umbrella B2B) konvertiert und an Umbrella.net geschickt.
Grundsätzlicher Ablauf
- Daten via FTP, E-Mail, SOAP
- Konvertierung
- B2B in MSMQ
- Retry bis zu 10x, dann "unsent"
Entgegennahme von Daten
FTP / Files
Dateien können via FTP (oder Fileshare) dem Importserver bereitgestellt werden.
E-Mails
E-Docs werden von vordefinierten E-Mail Adressen abgeholt und verarbeitet. Dabei muss der Attachment-Name und der Mail-Betreff ggf. bestimmte Bedingungen erfüllen damit die Dokumente dem richtigen Dossier zugeordnet werden können.
Pricecoach / SOAP
Eine SOAP-Schnittstelle erlaubt die Entgegennahme von Pricecoach-Daten (im Moment inaktiv)
Konvertierung
Galileo
Amadeus
CETS
XHT / Direct Sales
Delivery
Die (konvertierten) Daten werden in einer Queue auf dem Importserver gehalten, und - sofern Umbrella.net verfügbar ist - via SOAP an Umbrella.net geschickt.
- Falls entsprechend konfiguriert kann der Importserver mehrere Umbrella.net Instanzen "abfragen", um eine Agency ID korrekt zuzuordnen
- Falls Umbrella.net nicht verfügbar ist (dh Unavailable, oder im Single-User Mode), so wird die Delivery alle 5min erneut versucht (unbegrenzte Retries)
- Ist Umbrella.net verfügbar, aber die Agency ID ist nicht bekannt, wird der Datenrecord verworfen.
Technische/Funktionale Details
Datenübernahme
Der ImportServer ist fähig DBI-Daten aus dem PNR zu lesen, sofern der Mandant [Tenzing Faces] verwendet. Dort kann der Setup definiert werden, so dass zB ein "RM*KS1:/" auf die Kostenstelle 1 abgebildet wird. Ohne Tenzing Faces ist eine Übernahme der DBI-Daten nicht möglich.
Ein PNR mit mehr als einem Reisenden muss für die korrekte Funktion gesplittet werden. Im Anschluss sind zwei MIR's oder AIR's zu generieren.
Amadeus
Neben dem generischen Setup für die DBI-Daten gelten folgende Konventionen:
Eingabe | Beispiel | Verwendung in Umbrella.net |
---|---|---|
AIAN | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird beim OrderGen als Default gesetzt | |
RM*UMB-TRAV/nnnn | RM*UMB-TRAV/744 | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird auf dem Dossier als Reisender gesetzt. Die DBI-Daten des Reisenden werden zudem als Defaults auf dem Dossier gesetzt. (Es ist zu beachten dass explizite DBI-Daten aus dem PNR diese Defaults übersteuern) |
RM*UMB-ARR/aaaa | RM*UMB-ARR/FR HUBER | Die Angaben in 'aaaa' werden auf dem Dossier als "Besteller" gesetzt. Dieser wird dann auf die Rechnung übernommen |
RM*UMB-SC/nnnn | RM*UMB-SC/OFF | Der durch 'nnnn' gekennzeichnete SalesChannel (externer Code) wird auf dem Dossier gesetzt |
RM*UMB-SV/NFdd.dd FOdd.dd RCaa FTaa | RM*UMB-SV/NF3000.00 FO2000.00 RC10 FT50 | Savings-Daten. Die RM können Pax und/oder Segmenten zugeordnet werden, um Savings für spezifische Tickets auszuweisen.
|
Galileo
Neben dem generischen Setup für die DBI-Daten gelten folgende Konventionen:
Eingabe | Beispiel | Verwendung in Umbrella.net |
---|---|---|
DI.FT-SAnnnnnn | DI.FT-SA891244 | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird beim OrderGen als Default gesetzt |
DI.FT-TRAVnnnnnn | DI.FT-TRAV891244 | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird auf dem Dossier als Reisender gesetzt. Die DBI-Daten des Reisenden werden zudem als Defaults auf dem Dossier gesetzt. (Es ist zu beachten dass explizite DBI-Daten aus dem PNR diese Defaults übersteuern) |
DI.FT-ARRaaaa | DI.FT-ARRFR HUBER | Die Angaben in 'aaaa' werden auf dem Dossier als "Besteller" gesetzt. Dieser wird dann auf die Rechnung übernommen |
DI.FT-SLCHnnnn | DI.FT-SLCHOFF | Der durch 'nnnn' gekennzeichnete SalesChannel (externer Code) wird auf dem Dossier gesetzt |
DI.FT-SV NFdd.dd FOdd.dd RCaa FTaa | DI.FT-SV NF3000.00 FO2000.00 RC10 FT50 | Savings-Daten welche global für alle Flugtickets gelten
|
DI.FT-SV/T2 NFdd.dd FOdd.dd RCaa FTaa | DI.FT-SV/T2 NF3000.00 FO2000.00 RC10 FT50 | Wie oben, aber die Daten gelten nur für das Ticket für Tnr '2' |
RI.S3*SV NFdd.dd FOdd.dd RCaa FTaa | RI.S3*SV NF3000.00 FO2000.00 RC10 FT50 | Wie oben, aber für PNRs mit mehreren Tickets und unterschiedlichen Savings-Daten sowie für Hotel- und Mietwagen-Segments. Der RI-Eintrag muss das entsprechende Segment referenzieren. |
DBI-Felder können in einem beliebigen DI.FT-Format abgebildet werden.