Front-end bouwen voor een Global Distribution System

[Verwijderd]

Hallo iedereen :-)

Omdat ik sinds kort voor een luchtvaartmaatschappij werk op de dienst financiën maak ik dagelijks gebruik van de beschikbare GDS systemen om reservaties te checken, irregulariteiten op te sporen, tickets te annuleren wegens fraude, chargeback,terugbetalingen of eender wat. Dit gebeurt via een text based terminal session waar je effectief een hele reeks commando's moet intypen om de nodige informatie te krijgen. Op zich vind ik zo'n GDS een vrij fascinerend iets als je ziet wat er allemaal mee gedaan kan worden.

Eigenlijk ben ik IT-er van opleiding en het leek me leuk om te zoeken naar informatie over hoe je een front-end kunt bouwen om bepaalde operaties uit te voeren. Bij mijn zoektocht naar documentatie over de API van zulke systemen ben ik op weinig tot niks bruikbaars uitgekomen, behalve contactgegevens van de grote spelers om een wel erg dure license te nemen... Omdat het niet kan via mijn werkgever's systemen, niet over de nodige financiële middelen beschik om een licentie te nemen en ik dit eigenlijk meer als een soort self-study project zie is dat niet echt haalbaar...

Is er iemand die enig idee heeft waar ik informatie kan vinden over het programmatorisch benaderen van systemen zoals Worldspan, Galileo, Amadeus, Axres/PARS, Sabre etc?

Alle tips zijn welkom ^^

Alvast bedank

[diabolofan]

Is het niet gewoon mogelijk om met C++ (met bijv programma QtSDK) of een Windows Forms Application (met bijv. Visual Studio) de commando's vanuit de GUI door middel van buttons naar de terminal session te schieten?

[Gomez12]

Grotere vraag is over het algemeen : Wat denk je op te schieten met een GUI?

Mijn ervaring met character based systemen is dat ze heden ten dage heel erg moeilijk zijn te vervangen door een GUI omdat er simpelweg typmiepen achter zitten die met 1.000 aanslagen per seconde alle informatie verwerken. Moeten die alleen al een beweging maken richting de muis dan gaat de productiviteit al door de helft, moeten ze ook nog ergens op klikken dan heb je nog maar een kwart productiviteit en haal je de hele command line weg dan heb je nog maar 1% productiviteit.

Is het enkel voor jezelf / management die er niet dagelijks in hoeft in te voeren dan kan je de weg van diabolofan overwegen zodat je best of both worlds hebt. Maar wil je het grootschaliger inzetten dan is het opeens niet meer even een GUI bouwen, dat moet dan een echt 100% uitgewerkte GUI zijn voor de mensen die er daadwerkelijk mee werken. Elk nieuwigheidje introduceert namelijk simpelweg productiviteitsverlies...

[Brainstorm]

Een simpele start zou bijvoorbeeld zijn om het Selling Platform van Amadeus aan te spreken via COM. Je hoeft dan niet de terminal te scrapen, maar kunt via gestructureerde objecten (zoals PNR) data ophalen. Uit mijn hoofd: je start handmatig het selling platform op, vervolgens kun je met een extern programma de sessie "uitlezen" en er commando's naar toe sturen.

Overigens denk ik wel dat je snel tegen het probleem van licenties gaat aanlopen, op zich vrij logisch omdat je toch toegang tot de betreffende GDS moet krijgen.

[Verwijderd]

Bedankt voor reacties \(^_^)/

De front-end zou vooral dienen als een soort feedback en reporttool/archief voor operaties die in PARS en Amadeus.

Bij customer relations en revenue accounting komen vaak aanvragen van passagier binnen voor claims en terugbetaling van ongebruikte tickets, downgrades, etc. Ook agenschappen kennen er wat van, want zodra het verdwijnt uit de IATA Billing & Settlement Plan website is het paniek en mogen wij het opzoeken in het GDS en of accounting systemen. Gewoonlijk zijn ze er snel bij, maar vaak is de PNR niet meer actief of is het etkt allang gepurged omdat het bijvoorbeeld een final status heeft gekregen, soms onterecht bij irregularities.
Hierdoor gebruikt men 3rd party database webapp uit de jaren stilletjes waar een copy/paste van zo'n etkt of pnr in gezet wordt, vaak met emails, nota's, berekening en andere dingetjes die van belang zijn als feedback naar de passagiers of agencies toe.

Omdat iedereen maar wat doet en zo zijn eigen manier van werken heeft, leek het me interessant op een oplossing te zoeken waarbij zodra een aanvraag binnenkomt, de nodige gegevens uit het GDS gehaald worden en 'gearchiveerd' in een externe DB om te voorkomen dat bepaalde gegevens na verloop van tijd verdwijnen en a.d.v. die gegevens netjes een status report, een brief of statistieken e.d. kan genereren.

Als je dan bijvoorbeeld iets moet terugbetalen, kan de applicatie voor de gebruiker al een berekening maken, rekening houdend met de fare rules en huisregels of tickets een final status geven als fraude ontdenkt wordt etc. en die eenmaal goedgekeurd de nodige commands doorstuurt naar het GDS en de final output. Bijgevolg zijn voor alle gebruikers de spelregels hetzelfde. Zo durft de ene wel eens een penalty niet aan te rekenen of vergeet men rekening te houden met een bepaalde bulletin of annulaties van vluchten. Als de klant er dan achter komt dat het fout is, moeten ze momenteel alle werk quasi opnieuw doen, want niet echt efficient is.

Dus het zijn niet de checkin agents of de salesforce dat erop zitten. Er zijn er maar 2 waarvan ik weet dat het echte typmiepen zijn die dat al quasi 30 jaar doen :3

Als terminal wordt gebruik gemaakt van HP's OPAT/WinDSM client... Er zal wel wat hooking bij te pas komen om toegang te krijgen tot de terminal I/O voor zover het mogelijk is?