Travel Web API inkl. Geschäftslogik
Intelligente Middleware, die Reiseangebote nach individuellen Kriterien filtert, zusammenführt, mit Regeln versieht und über eine Web-Schnittstelle bereitstellt
Unsere Travel Web API iXX1 stellt die geeignete, flexible Geschäftslogik für Ihre Benutzeroberfläche und stellt mittels integrierter Rules Engine die Reiseangebote nach unternehmenseigenen Kriterien zur Verfügung. Danach werden relevante Angebote zusammengeführt und erneut mit Regeln versehen, wie z.B. Reiserichtlinien, Präferenzen des Reisenden, Vorgaben des Unternehmens, bevorzugte Anbieter etc. Die Reiseangebote werden anschließend über eine Web-Schnittstelle (Web API) einer Benutzeranwendung, wie z.B. einer Grafischen Benutzeroberfläche (GUI) bereitgestellt. Unsere intelligente Travel Web API stellt somit bereits einen ersten Microservice-Ansatz zur Aggregation von Multi-Source-Reiseangeboten dar, der sich zukünftig zu einem Representational State Transfer (REST) Interface (z.B. JavaScript Object Notation – JSON) entwickeln soll.
Nachdem unsere Travel XML API XX1 seit dem Jahr 2000 eine einheitliche, stabile und performante XML-Schnittstelle für alle Global Distribution Systeme (GDS) und andere Multi-Source-Anbieter darstellt, geht der intelligente XX1 (iXX1) somit noch einen Schritt weiter.
Warum unsere Travel Web API iXX1 einsetzen?
Der Prozess des Shoppings wird vereinfacht und Reiseangebote werden von vornherein mit Reiserichtlinien und persönlichen Präferenzen versehen und auf das Wesentliche reduziert. Die Reisebuchung (auch: Passenger Name Record, PNR) erfolgt über das Warenkorb-Management. All dies, inkl. nachgelagerter Prozesse wie File-Finishing und Reporting, wird zentral definiert und verwaltet. Alle Buchungstools, die Messages des PASS Travel Web APIs nutzen, erhalten einheitliche Richtlinien und Datenauszeichnungen – sprich, der Content ist für alle identisch. Die Reisebuchung wird, nach den Vorgaben einer für das Unternehmen typischen Buchungsreferenz, innerhalb der Freitextfelder (Remarks) ergänzt. Auf diese Weise können Folgeprozesse wie Midoffice, Backoffice, Travel Risk Management oder Abrechnung ohne Probleme durchlaufen werden (File-Finishing). Dies erleichtert und vereinfacht u.a. die Entwicklung eines eigenen Buchungstools oder Genehmigungsverfahrens enorm.
Weiterhin bietet iXX1, neben Such-, Buch-, Umtausch- und Rückerstattungsvorgängen über alle Content-Anbieter, die Möglichkeit der intelligenten Datenbeschaffung aus dem GDS und anderer Inhaltsquellen wie Low Cost Carrier. Diese berücksichtigt nicht mehr alle, sondern nur noch relevante PNR-Änderungen. Für ein Travel Risk Management Unternehmen ist es im Zusammenhang mit Duty of Care (Sorgfaltspflicht) wichtig zu wissen, welche Reisenden sich wo und wann aufhalten sollten. Eine Sitzplatzänderung beispielsweise ist dabei weniger von Bedeutung als die Umbuchung auf einen anderen Flug oder die Änderung des Zielortes, da diese neue Risiken in sich bergen. Auch der von der Fluglinie hervorgerufene Schedule Change kann – gewissen Regeln folgend – eine Verbesserung darstellen, aber ebenso eine Verschlechterung hervorrufen, wenn z.B. ein Passagier sein Schiff nicht mehr erreichen kann oder ein Reisender seinen Anschlussflug verpassen wird.
Zielgruppen
Die Travel Web API ist für alle Benutzergruppen interessant, die selbst User Interfaces für sich oder ihre Kunden kreieren möchten, jedoch auf eine einfache Microservice-Schnittstelle für die komplexe Reisebuchungswelt zugreifen wollen.
- Agentur / Geschäftsreisemanagement: Vereinheitlichte Bereitstellung von komprimierten Daten bzw. Reiserichtlinien / File-Finishing / Reporting über alle UI-Anwendungen hinweg.
- Technologieanbieter / Client-Anwendungen: Reduzierung der Komplexität, da eine Implementierung von Reiserichtlinien / File-Finshing / Tariferkennung / Marketing-Nachrichten / Reporting-Felder im Client nicht erforderlich ist. Die reine Darstellung der von iXX1 komprimierten Daten aus den Messages ist für den Entwickler von Client-Anwendungen ausreichend, um ein ansprechendes User Interface zu kreieren.
- Unternehmen: Alle Client-Anwendungen (Desktop, Mobile, Chat Bots etc.) müssen lediglich die iXX1-Messages implementieren und erhalten sofort (zentral gesteuert) identische Inhalte mit den notwendigen Auszeichnungen, wie z.B. bevorzugte Tarife oder bevorzugte Leistungsträger. Damit wird die Steuerung der Buchung zentralisiert, vereinheitlicht und vereinfacht.
Vereinfachung der Komplexität der Reisebuchungssysteme in der Praxis
Durch die stringente Trennung von User Interface (UI) und Geschäftslogik entsteht der Vorteil, dass einerseits die Businesslogik nicht immer wieder neu entwickelt werden muss und andererseits die UI-Schicht im Laufe der Zeit flexibel angepasst werden kann. Dank einer über Jahre hinweg stabilen Travel-Schnittstelle ist es für unsere Kunden nicht mehr erforderlich, ständig Anpassungen zu den Anbietersystemen zu überarbeiten, zu ersetzen bzw. anzupassen.
Die integrierte State-of-the-Art Open Source Rules Engine (Drools) ermöglicht es unseren Kunden, selbst in jegliche Prozesse einzugreifen, unabhängig vom Hersteller (uns). Der Kunde konzentriert sich somit auf seine attraktive Kommunikationsschnittstelle mit dem Reisenden, während PASS für die moderne und reibungslos laufende Travel-Technologie einsteht.
Wir stellen sicher, dass die Geschäftslogik der komplexen Reiseindustrie problemlos funktioniert und die Anbindung an die Reisebuchungssysteme für Hotel, Mietwagen, Flug und Bahn konstant gewährleistet ist. Darüber hinaus bieten wir die Anbindung an folgende Backendsysteme an:
- Multi-GDS: Amadeus, Sabre, Travelport’s Systeme Worldspan, Galileo/Apollo, uAPI
- IATA‘s New Distribution Capability (NDC), z.B. über Farelogix aber auch eigene Entwicklungen von Airlines oder Travelfusion
- Billigflieger – auch Low-Cost-Carrier (LCC) genannt, z.B. über Newskies direkt oder Aggregatoren wie Travelfusion, Amadeus’s Extended Air Choice (EAC) sowie Pyton direkt oder Travelport‘s Airline Content Hub (ACH)
Unsere Reisecontent-Anbieter in XX1:
Unsere Travel-APIs und -Schemas weisen in der Regel eine Stabilität von fünf Jahren und mehr auf, bevor ein Update notwendig ist. Drittsysteme verlangen z.T. Updates mehrmals im Jahr.
Kommunikation zwischen Buchungsapplikation und Reservierungssystem
Komplexität und Datenmengen können von der Standard-API über die XX1-API hin zur iXX1-API deutlich vereinfacht werden
Zur Kommunikation zwischen UI-Applikation (darunter fallen alle möglichen Kommunikationsformen mit dem Endanwender) und den Standard Webservice APIs der GDS und sonstigen Reiseservice-Anbietern sind heute bei einer typischen Buchung mit einem Such-/Buchverhältnis von 5:1 mindestens 23 Messages (Request-/Response-Messages) notwendig, die zum Teil eine signifikante Anzahl an Attributen aufweisen. Bei mehreren Anbietern vervielfacht sich die Anzahl entsprechend.
Mit unserer SOAP-Schnittstelle (XML) XX1 wird die Anzahl der Messages bereits auf 18 reduziert: Je eine Nachricht um das Profil des Reisenden zu erhalten – sowohl das persönliche Profil als auch das der Abteilung. Je fünf Flugabfragen inkl. Bepreisung. Danach wird die Buchung sowie ca. fünf weitere File-Finishing Messages erzeugt, um midoffice-, backoffice- und unternehmensrelevante Informationen einzustellen. Die Messages selbst weisen jedoch nach wie vor eine signifikante Anzahl an Attributen und Kombinationen auf. Das Ergebnis ist daher immer noch sehr umfangreich.
Bei unserer Web-Schnittstelle iXX1 werden Services bereit gestellt, die nur noch 7 bis 11 Messages benötigen, die teilweise keinerlei Attribute mehr aufweisen, da die Kommunikation zwischen UI-Applikation und der iXX1-API lediglich über Identifikationskennzahlen erfolgt und dadurch die Messages deutlich schlanker werden. Natürlich wird weiterhin das umfassende Angebot der Shopping-Engine benötigt (der Sabre Bargain Finder Max gibt z.B. bis zu 200 Flugkombinationen zurück), die jedoch mit Regeln vorsondiert werden können. Sobald die Client-Applikation einmal ein Angebot erhalten hat, für das sich der Reisende entscheidet, wird nur noch über UUID (universally unique identifier), ähnliche, eindeutige Identfikationen, mit der Web-Schnittstelle von PASS kommuniziert. Zum Beispiel wird dieser lediglich mitgeteilt: „Buche Flug Nummer 3“ anstelle von „Buche Flug Nummer LH 462 von Frankfurt nach Miami am TT.MM.JJJJ usw. “. Dies stellt ein Beispiel für Microservices dar. Die komplexen Services, wie Such-, Buch-, Warenkorb-, Umtausch- und Rückerstattungsvorgänge etc., bestehen aus einer unterschiedlichen Anzahl an Microservices. Jeder Microservice gruppiert für sich einen bestimmten Anteil an Komplexität und vereinfacht damit die Programmierung einer UI enorm.
Praxisbeispiel
Beispiel einer einfachen Reisebuchung
Der User nutzt ein Online-Buchungstool, um Flüge von A nach B zu finden. Durch die integrierte Rules Engine von iXX1 erkennt das Travel API Tool, welche Person reist und kann die Profildaten, Richtlinien und Präferenzen des Unternehmens aufrufen. Anhand dieser Informationen werden bereits die Abfragen an jede Quelle so optimiert, dass die besten Ergebnisse für Firmen und Reisenden zurückgegeben werden. Anschliessend werden die passenden Reiseergebnisse gefiltert. Die Rules Engine arbeitet dabei alle spezifischen Wenn-Dann-Beziehungen ab. Das vereinfachte Ergebnis wird anschließend der Shopping-Engine bereitstgestellt und dem Nutzer angezeigt. Sobald der Benutzer einen Flug in den Warenkorb legt, muss die Shopping-Engine nur noch die spezifische, eindeutige ID zur Verfügung stellen. Die Übertragung von großen Datenmengen entfällt somit. Das Travel API Tool führt abschließend das gesamte File-Finishing nach den zuvor festgelegten Regeln durch.
Leistungsangebot von iXX1
Zusätzlich zu den XX1-Serviceleistungen, wie
- Such-, Buch-, Umtausch- und Rückerstattungsvorgänge,
- Profil-Management,
- Fluggesellschaften-, Hotel-, Mietwagen-Management sowie
- Reisedatenkonsolidierung bzw. Angebots- und Auftragsmanagement
bietet iXX1 folgende Leistungen:
- Integriertes PASS-Profilmodul oder
- Integration kundeneigener Profildatenbanken
Fehlerbezogene Services1:
- Fehlernormalisierung und Übersetzung
- Automatischer “No Empty Result Service”
- Offer-Service: ermöglicht dem Anwender verschiedene Angebote aus den Ergebnissen zusammenzustellen und zu vergleichen (Mix & Match)
- Anreicherung von Daten über zusätzliche Content-Anbieter
- Dynamische Auswahl von Reiseanbietern und -angeboten basierend auf den speziellen Bedürfnissen des Kunden (Unternehmen und Reisende)
- Nachschlagesystem für Flughäfen einschließlich Geodaten, Flughafengröße, Weltregion via Cirium (ehemals Flightstats) und Bahnhöfe (inkl. EuroStar)
- Überblick über das In-flight-Angebot mit Daten von Routehappy
- Zusätzliche Dienstleistungen für Low Cost Carrier, NDC Direktanbindungen, Newsky (z.B. Eurowings etc.), optionale Zahlungsgebühr (OPC), Wechselkurse
- Multi-Source-Shopping- und Buchungsservice inkl. Super-PNR-Management
- Kombinierte Einzelflüge2
- Integrierte Geschäftslogik für komplexe Drittanbietersysteme3
- Zielgebietsmanagement4
- Vereinfachte und zwischengespeicherte Kommunikation zwischen Reiseanbieter und Anwendung
- ID-Management: vereinfachtes Datenhandling mit UUIDs
- Hintergrunddienste: Reiseverlauf, Buchungsbestätigung, Termindaten
- Class Mapper: Zuordnung von Class of Service (CoS) zur Kabine auf Basis von Fluggesellschaft und Routenplanung
- Fertig nutzbares Warenkorb-Management: Angebote anfordern, ein Angebot in den Warenkorb legen, Warenkorb bestellen
- Profilregeln (Agentur, Unternehmen, Reisende)
- Allgemeine Vertriebs- und Marketingregeln
- In/Out Policy Flags: Hinweis an den Vorgesetzten, wenn außerhalb der Reiserichtlinie gebucht wird
- Automatisierte PNR-Qualitätsprüfung/File-Finishing (PNR-konform)
- Auto-Ticketing einschließlich Qualitätskontrolle über die Rules Engine
- Datenklassifizierung: Sortierung und Filterung der Ergebnisse
- Dynamisches Hinzufügen von vertraglich vereinbarten Tarifen und anderen Daten der Anfrage basierend auf der Quelle
Besondere iXX1-Services:
1Fehlerbezogene Services
Fehlernormalisierung und Übersetzung:
Die teils nicht transparenten Fehlermeldungen der Drittsysteme werden normalisiert und auf klare Fehlercodes in iXX1 abgebildet. Die zusätzlichen Fehlertexte können auf Wunsch in klare und/oder kundenindividuelle Handlungsempfehlungen für den Endanwender "übersetzt" werden.
No Empty Result Service:
Dieser Service verhindert leere Ergebnismengen. Fehler werden nicht nur bereinigt, es wird auch automatisch auf bestimmte Fehler reagiert. So kann beispielsweise eine Funktion konfiguriert werden, die eine zu restriktive Abfrage abschwächt und automatisch erneut sendet, wenn das erste Ergebnis leer wäre. Beispiel: Flugabfrage München - Los Angeles morgens 9.00 Uhr +/- 2 Stunden mit Lufthansa. Das Ergebnis wäre in diesem Fall leer, da die LH-Flüge erst um 12.00 Uhr Mittag starten. Wenn iXX1 das leere Ergebnis empfängt wird sofort eine weitere Abfrage gesendet und z.B. die Zeiteinschränkung herausgenommen. Dann gibt das System das geänderte Ergebnis mit einem Hinweis aus, dass das Zeitfenster entfernt wurde, da sonst keine Ergebnisse gefunden worden wären.
2Kombinierte Einzelflüge
Neben definierten Hin- und Rückflügen (Round Trips), welche von GDS angeboten und bepreist werden, bezieht unser intelligenter XX1 auch relevante Einzelflüge (One-way) von allen angebundenen Systemen mit ein, kombiniert diese und vergleicht, ob es günstiger geht. Dabei werden für jeden Hinflug die möglichen Rückflugkombinationen aus unterschiedlichen Systemen (z.B. Hinflug über Amadeus und Rückflug direkt über Eurowings, Hinflug direkt über Lufthansa und Rückflug über Low Cost Carrier oder sämtliche Kreuzprodukte aller Anbieter) sowie die durchschnittliche Preisspanne aus der günstigsten und teuersten Flugkombination ermittelt, um die beste Kombination zu erhalten. Die Reiserichtlinie wird entsprechend auf diese möglichen Flugkombinationen angewandt (Hinweis: Von einer Bepreisung kombinierter One-way GDS-Flüge sehen wir aufgrund der Point of Commencement Problematik ab).
3Integrierte Geschäftslogik für komplexe Drittanbietersysteme
Neben Nachrichteninhalten wird auch das Verhalten von Drittsystemen für die Client-Anwendung normalisiert und dadurch ihre Komplexität weiter reduziert, ohne dabei den Leistungsumfang zu verringern. Ein Beispiel hierfür ist das 4Zielgebietsmanagement: Manche Content-Anbieter erwarten, dass vor Abfrage einer Verbindung geprüft wird, ob die jeweilige Fluggesellschaft diese Destination überhaupt anfliegt. Nur wenn dies der Fall ist, darf die Quelle abgefragt werden. Diese Vorabprüfung übernimmt iXX1 automatisch im Hintergrund. Die Client-Anwendung benötigt kein Wissen über Flugrouten oder das Streckennetz der jeweiligen Fluggesellschaft. Ein weiteres Beispiel stellt die Branded-Fares-Prüfung dar: Ähnliche Logiken sorgen dafür, dass unnötige Abfragen und Wartezeiten für den Kunden vermieden werden. So werden bestimmte Tarife (z.B. Markentarife bzw. Branded Fares) bereits im Hintergrund bei gewissen Workflows geprüft und der Client-Anwendung signalisiert, ob es sinnvoll ist, diese abzufragen. Auf die Markentarife und die Upsell-Abfrage kann verzichtet werden, wenn iXX1 bereits im Hintergrund festgestellt hat, dass es für diese Verbindung keine gibt.
Highlights der Travel Web API
Schnelle Integration
Vereinfachte Kommunikation und Workflows (Result-ID), Super PNR-Management, Service für Multi-Source (inkl. Distributionskontrolldienst), Warenkorb-Management, Angebotsmanagement, Mehrsprachigkeit
Weitere zusätzliche Daten
Integrierte PASS- oder externe Daten-Plattform, Profil-Datenbank, Rules Engine (z.B. Richtlinien, konforme PNR etc.)
Schnelle Transaktionszeit
Ausgewähltes Daten-Caching, ID-Management, Performance
Weltweiter Zugriff
Reiseservice-Anbieter: Global Distribution Systems, Low Cost Carrier, Direct-Connect (z.B. NDC, Mietwagen, Hotel)
Benefits
Anwender
- Laden und Speichern von Profilen (Reisender und Unternehmen)
- Anwenden von Geschäftsregeln- und Firmenrichtlinien
- Marketing, wie z.B. eine Erinnerungsfunktion („Hotelbuchung fehlt“) oder ein Hinweis auf Sonderkonditionen bei bestimmten Verträgen („eine Flasche Wasser pro Tag inbegriffen“)
- Beschleunigung der Anwendung durch Caching, mit Möglichkeit der Sofortreaktion auf Events bzw. Darstellung der Historie
- Laden, Sortieren und Filtern von Shopping-Ergebnissen
- Anzeigen aller verfügbaren Ergebnisse (z.B. „Zeige mir spätere Flüge an“)
Fachseite
- Separate Anzeigen- und Businesslogik
- Intelligente Middleware für alle Benutzeroberflächen (auch Robotik)
- Anwenden von File-Finishing
- Vereinfachung und hohe Leistungsfähigkeit: Die Benutzeroberfläche muss sich nicht um komplexe Geschäftslogik sorgen und kommuniziert nur über UUID-ähnliche IDs mit iXX1
IT-Verantwortliche
- Erfordert deutlich weniger reisespezifisches Spezialwissen
- Wartung und Instandhaltung von Travel-Schnittstellen entfällt
- Ressourceneinsparung durch ID-Management und Microservice-Architektur
- Keine Schnittstellen-Barrieren: iXX1 kann optional mit einem einfach zu bedienenden Client geliefert werden, welcher in Ihre App integriert wird
Entscheider / Management
- Konzentration auf die Benutzeroberfläche anstatt Beschaffung und Aggregation von Content
- Schnelle Markteinführung
- Kostenreduzierung
- Unabhängigkeit von Lieferanten
- Erzeugung eigener Emotional User Interface Experience (eUIx)
Nutzungsmodelle der Travel Web API
Geeignet für
TMCs/ Unternehmen/ Technologieanbieter
TMCs/ Unternehmen/ Technologieanbieter
Art der Nutzung
gebuchter PNR
Transaktionspaar: request/ response
Lizenzen
SaaS
SaaS
Ist eine Wartung notwendig?
Ja, nur um Service Level Agreement (SLA) zu haben
Ja, nur um Service Level Agreement (SLA) zu haben
Ist eine Installation notwendig?
Ja
Ja
Vorteile
bewährtes Preismodell, direkte Verrechnung auf den PNR
kein Look-to-Book notwendig
Lizenzpreise (excl. Hosting)
0,15€ - 0,50€ pro PNR**
0,00€ - 0,03€ pro iXX1-Transaktion
*Beide Nutzungsmodelle setzen eine monatliche Grundgebühr von 15.000€ voraus.
**Durchschnittliches Look-to-Book-Verhältnis von nicht mehr als 100:1 pro Kalendermonat.
Häufige Fragen zum iXX1
In der Reiseindustrie gibt es drei große globale Reservierungssysteme (GDS): Amadeus, Sabre und Travelport. Ursprünglich arbeiteten diese Reservierungssysteme über den Datenstandard EDIFACT mit den Reservierungssystemen der Airlines zusammen. NDC (New Distribution Capability) könnte diese EDIFACT Pipeline ersetzen bzw. komplettieren. Seit dem Jahr 2000 bieten wir ein einheitliches Interface auf Basis von XML zu allen großen globalen Reservierungssystemen an. Heute sind jedoch handhabbare, komfortable Services, die einfach und schnell zu integrieren sind, für Oberflächenentwickler die bevorzugte Alternative zu den XML-Datenstandards. Auch im Hinblick auf zukunftsweisende Travel-Technologie ist es uns wichtig, mit der Zeit zu gehen. Während sich also die Technologie in Richtung Microservice-Architektur entwickelt, arbeitet die Reiseindustrie gegensätzlich mit großen unhandlichen XML-Nachrichten. Mit der NDC, deren erste Version sogar auf unser XML-Schema aufsetzte, wird dies noch komplexer. Ein Beispiel hierfür ist der Umfang der Air Shopping Message, welche das Kreuzprodukt mit allen möglichen Kombinationen anzeigen kann. Mit unserem Ansatz möchten wir die technologische Verbindung zwischen der komplexen Welt der Reiseindustrie und der schnelllebigen Welt der User Interfaces herstellen. Somit erleichtert iXX1 die Frontendentwicklung und bietet die Chance, auch in der Reiseindustrie innovative Oberflächen auf flexible und komfortable Weise erstellen zu können.
Die intelligente Travel Web API eignet sich für alle Unternehmen, Agenturen oder Geschäftsreiseagenturen (TMCs) mit mindestens 20.000 Reisebuchungen im Monat.
Im Vergleich zu den Round-Trip-Zeiten der GDS, ist der Zeitverlust, der bei unserem iXX1 einige 100 Millisekunden beträgt, nicht spürbar. Allerdings hängt dies von den zugrundeliegenden Regeln ab: Wie sind sie definiert, um wie viele handelt es sich (Grundregelsatz und Regeln liegen in Ihrer Verantwortung) und wie schnell wird ein Ergebnis ausgespielt. Die sinnvolle Anwendung von Regeln zur Auswahl des individuellen Reiseangebots im Multi-Source-Betrieb kann erst nach Erhalt der Optionen aller Anbieter erfolgen. D.h., das System muss auf das langsamste Drittsystem warten und kann erst dann seine Regeln anwenden. Es kann allerdings eine zügige Vorsondierung stattfinden, die der Benutzeroberfläche zur Verfügung gestellt wird und danach eine Feinsortierung im Hintergrund vollzogen werden.
Derzeit bieten wir eine SOAP-Schnittstelle ohne Geschäftslogik mit XML (XX1) und eine Web-Schnittstelle inklusive Businesslogik mit XML (iXX1) zu allen Reiseanbietern an. Es ist geplant, die Travel Web API iXX1 künftig auf eine REST-basierte API (JSON, etc.) auszuweiten. Derzeit basiert iXX1 auf unserem XX1-Schema, um rückwärtskompatibel zu unseren aktuellen XX1-Kunden zu bleiben. Sie werden das gleiche Vorgehen bei allen anderen Reiseservice-Anbietern vorfinden. Für eine intelligente Geschäftsanwendung ist es wichtig, dass man nahezu 100% der Funktionalitäten in eine Travel-Schnittstelle integriert. Im Backend verwenden wir häufig sogar kryptische Nachrichten von GDS, um Funktionen bereitzustellen, die nur im kryptischen Format bei den Drittsystemen (GDS) verfügbar sind. Somit können unsere Kunden diese Funktionalität wie gewohnt strukturiert nutzen.
Die Schema Definition unserer Travel Web API (iXX1) ist aktuell die gleiche wie bei unserer Travel XML API (XX1).
Ja, sie sollen sogar selbst erstellt werden. Abgesehen von Standards, sollten die Regeln sowohl in Ihrem Eigentum, als auch in Ihrem Verantwortungsbereich sein. Sie kreieren Ihre Regeln so, dass das System zu Ihnen passt.
Nein, die Drools Rules Engine ist eng mit jedem Business-Objekt von iXX1 verknüpft. Jede Regel sollte eine Beziehung zu einem der iXX1-Business-Objekte haben.
Ja, iXX1 wird u. a. von der weltweit zweitgrößten TMC (lt. „The Beat“) eingesetzt. Zuvor hatte dieser Kunde nur XX1 genutzt. Des Weiteren basieren alle unsere eigenen GUI-Anwendungen auf iXX1 und damit auf der intelligenten Trennung von GUI und Geschäftslogik. Alle unsere eigenen GUI-Anwendungen basieren auf iXX1 und demnach der intelligenten Trennung von GUI und Geschäftslogik. Das weltgrößte, unabhängige Agentur Franchiseunternehmen setzt ebenfalls mit seiner Agentenlösung auf eine flexible GUI von PASS und demnach iXX1. Wir haben unsere bestehenden Installationen Schritt für Schritt auf diese Microservice-Architektur umgestellt. Wir sind jedoch kein auf Massenproduktion ausgerichtete Firma, sondern bieten Ihnen individuelle Produkte auf Basis von wiederverwendbaren Komponenten.
Die Travel Web API eignet sich für alle, die eben keine sublizenzierte „Off-the-Shelf-White-Label-Komplettlösung“ einsetzen wollen, bei der nur das Design verändert wird und die Lösung von Kunde A genauso wie die Lösung von Kunde B funktioniert. Mit iXX1 kann man entweder komplett seine eigene Lösung designen und erstellen (ohne spezielles Travel Know-how zu haben bzw. unzählige Businesslogiken programmieren zu müssen) oder sich von PASS eine Oberfläche bereitstellen zu lassen.