Forbedring af GDS-webapplikation: 2 gange højere API-integrationshastighed

Innowise gennemførte en omfattende refaktorering af platformskoden og forenklede processen med at integrere nye API'er betydeligt. 

Kunde

Industri

Region

EU

Kunde siden

2023

Vores kunde, en fremtrædende aktør i rejsebranchen, driver et globalt distributionssystem (GDS) til udstedelse af færgebilletter og andre rejsetjenester. Denne webapplikation er et enkelt kontaktpunkt til håndtering af forskellige færgereservationer, herunder lang- og kortdistancerejser, typer med flere sæder og endda komplekse ruter med flere hop.

Detaljerede oplysninger om kunden kan ikke videregives i henhold til vilkårene i NDA'en.

Udfordring

Navigere i markedsbegrænsninger og dokumentationshuller

Denne kunde følte sig begrænset af sin nuværende markedsstørrelse og ønskede at udvide. For at opnå denne udvidelse ønskede de at oprette API-integrationer med rejsebureauer. 

Derudover var fraværet af en struktureret dokumentation af softwarearkitekturen et stort problem. Dette hul førte til flere udfordringer, som f.eks. at få nyansatte teammedlemmer op i gear, opretholde en fælles forståelse af systemet blandt forskellige interessenter og problemfrit implementere nye produktfunktioner. 

Derfor henvendte kunden sig til os for at få API-integrationer og for at skabe en omfattende arkitektur for softwaredokumentation.

Løsning

Opskalering af webapplikationers effektivitet og finpudsning af API-integrationsteknikker

Innowise leverede modernisering af webapplikationer og optimerede API-integrationer med rejsebureauer for at løfte færgeoplevelsen på tværs af Europa.

Oprettelse af dokumentation for softwarearkitektur

Vi begyndte med at gennemføre omfattende interviews med kundens udviklingsteam og interessenter. Denne tilgang sikrede, at vi fangede essensen af, hvad de havde brug for. 

Med dette væld af oplysninger satte vi os for at designe en intuitiv og forståelig dokumentationsstruktur. Dokumentationen dækkede alt fra systemoversigter på højt niveau til detaljer på kodeniveau. Vi indarbejdede diagrammer, flowcharts og interaktive elementer for at gøre den informativ og engagerende.

Men det handlede ikke kun om at skabe et statisk dokument. Vores erfaring er, at den bedste dokumentation er den, der lever, ånder og udvikler sig sammen med det system, den beskriver. Så vi implementerede en dynamisk dokumentationsproces, der løbende blev opdateret i takt med, at systemet voksede og ændrede sig. Denne tilgang til levende dokumenter sikrede, at dokumentationen altid var opdateret.

Desuden fokuserede vi på at gøre dokumentationen tilgængelig og forståelig for alle involverede parter. Det betød, at vi skulle undgå jargon, bruge et klart og koncist sprog og sikre, at både tekniske og ikke-tekniske interessenter kunne finde værdi i den.

Ved at etablere denne omfattende arkitektur for softwaredokumentation lagde vi ikke bare grunden til det nuværende projekt, vi gav også kunden et værktøj, der ville hjælpe med fremtidig udvikling, onboarding af nye teammedlemmer og fremme klar kommunikation mellem alle involverede parter. Det var den hjørnesten, som al videre udvikling blev bygget på.

Refaktorisering af kode og migration til mikrotjenester

Da vi dykkede ned i kundens eksisterende system, fandt vi en forældet version af Java med kodeduplikationer og forældet praksis. Den oprindelige arkitektur, en monolitisk applikation, havde tjent sit formål i de tidlige faser. Men efterhånden som platformen voksede, viste denne tilgang sine begrænsninger. Skalerbarheden blev vanskelig, og kodebasen blev en forvirrende labyrint, som det blev stadig sværere at navigere i og opdatere uden at introducere nye fejl.

På baggrund af vores analyse besluttede vi, at det var nødvendigt at gå over til en mikrotjenestearkitektur. Microservices tilbød en løsning på det monolitiske systems problemer med skalerbarhed og smidighed. Hver mikrotjeneste i denne arkitektur fungerer uafhængigt, hvilket betyder, at ændringer i én tjeneste ikke har direkte indflydelse på andre. Denne uafhængighed er afgørende for et system som vores kundes, hvor hyppige opdateringer og integrationer er standarden.

Overgangen til en mikrotjenestearkitektur var ikke en proces, der blev gennemført fra den ene dag til den anden. I stedet valgte vi en trinvis tilgang, hvor vi omhyggeligt demonterede den monolitiske struktur og samlede den igen i en mere dynamisk, mikrotjenestebaseret arkitektur. Denne metode gjorde det muligt for os at opretholde systemets funktionalitet under hele overgangen og undgå betydelig nedetid, der kunne påvirke vores kundes drift negativt.

Vi udtog omhyggeligt hver tjeneste, forfinede den og implementerede den uafhængigt. Vores udviklere adskilte tjenester som f.eks. billetbestilling og rejseplanlægning i forskellige enheder. Denne adskillelse betød, at opdateringer til f.eks. rejseplanlægningssystemet kunne foretages uden at risikere utilsigtede konsekvenser i bookingsystemet.

Til denne transformation brugte vi Spring Boot og Spring Cloud. Spring Boot gjorde det nemmere at opsætte og konfigurere mikrotjenester, hvilket fremskyndede udviklingen. Spring Cloud tilbød værdifulde værktøjer til distribuerede systemer, f.eks. konfigurationsstyring og service discovery.

Vi integrerede også Kafka som vores message broker. Dens evne til at håndtere store datamængder og sikre pålidelig kommunikation mellem tjenester var afgørende, især i betragtning af det store dataflow i den nye arkitektur.

Endelig implementerede vi nye mikrotjenester på den nyeste version af Java. Denne opgradering bidrog til bedre ydeevne og øget sikkerhed og dannede et stærkt og moderne fundament for hele arkitekturen.

Uddybning af udviklingen af et nyt behandlingsmodul

Da vi forfinede og forbedrede vores kundes system, identificerede vi behovet for en mere effektiv måde at håndtere nye integrationer på. Det førte til udviklingen af et specialiseret behandlingsmodul, en afgørende tilføjelse til systemet, som medførte betydelige forbedringer i integrationsprocessen.

Håndtering af redundansudfordringer

En af de primære udfordringer, vi stod over for, var den gentagne karakter af kodeskrivningsprocessen for hver ny integration. Før udviklingen af dette behandlingsmodul blev hver ny integration med en anden rejsebureau eller -tjeneste krævede en betydelig mængde kode skrevet fra bunden.

Design af behandlingsmodulet

Det behandlingsmodul, vi udviklede, blev designet til at fungere som en alsidig grænseflade mellem vores kundes system og eksterne API'er. Modulet består af forudbyggede, tilpassede skabeloner og værktøjer, som reducerer behovet for at skrive ny kode til hver integration. Det fungerer ved at abstrahere standardfunktionaliteter og -processer, der typisk er involveret i integration med forskellige rejsetjenester, såsom billetbestillingssystemer eller kundedatabaser.

Modulet indeholder flere vigtige funktioner:

  • API-kommunikationshåndteringer: Disse er designet til at håndtere rejsebureauers indgående og udgående API-anmodninger. De håndterer kompleksiteten i forskellige API-protokoller og dataformater, hvilket gør det nemmere at oprette forbindelse til eksterne systemer.
  • Værktøjer til kortlægning og transformation af data: Ofte varierer datastrukturer mellem forskellige systemer. Vores modul indeholder værktøjer, der automatisk mapper og transformerer data til og fra det format, der kræves af vores kundes system og eksterne tjenesteudbydere. Det gør det lettere at udveksle og integrere data.
  • Grænseflade til konfiguration og tilpasning: I erkendelse af behovet for fleksibilitet er modulet udstyret med en grænseflade, der giver udviklere mulighed for nemt at konfigurere og tilpasse integrationer uden at dykke dybt ned i kernekoden. Det giver mulighed for hurtig tilpasning til de specifikke krav fra hvert nyt rejsebureau eller hver ny tjeneste.

API-integrationer med rejsebureauer

Derefter integrerede vi vores kundes GDS med 4 rejsebureauer, der brugte REST- og SOAP-udvekslingsmekanismer. Disse integrationer var afgørende for at forbedre billetbestillings-, ændrings- og afbestillingsprocesserne for færgetjenester. Vores udfordring var at skabe en integrationsramme, der kunne håndtere en bred vifte af færgebookinger, herunder forskellige ruter, sædekonfigurationer og supplerende tjenester.

Implementeringen af disse integrationer involverede flere kritiske trin. I første omgang gennemgik vi agenturernes API'er for at forstå deres datastrukturer og funktionelle krav. Ved at udnytte vores nyudviklede behandlingsmodul skabte vi tilpassede forbindelser til hvert bureau. Disse konnektorer blev skræddersyet til at håndtere hvert bureaus specifikke dataformater og operationelle arbejdsgange, hvilket sikrede en flydende dataintegration med vores kundes GDS.

Processen omfattede implementering af sofistikerede værktøjer til kortlægning og transformation af data i vores behandlingsmodul. Denne teknologi spillede en afgørende rolle for at sikre dataintegritet og -konsistens. Vores team foretog omfattende test for at validere effektiviteten og pålideligheden af disse integrationer. Vi simulerede forskellige bookingscenarier for at teste integrationerne under forskellige forhold. Efter vellykket testning implementerede vi integrationerne i live-miljøet og oprettede løbende overvågningsmekanismer for at overvåge deres ydeevne og hurtigt løse eventuelle problemer.

Teknologier

Java 17, Spring, Spring støvle, Spring Cloud, dvale

API

REST, SOAP

Opbevaring af data

PostgreSQL, Memcached

Budskabsmæglere

Kafka

GitLab CI/CD-pipelines

Serviceydelser

Gitlab, Jira, Confluence

Proces

Opdagelse og analyse

Vi oprettede et Vision & Scope-dokument for at afstemme projektets mål med kundens forventninger i den indledende fase. Dette dokument lagde fundamentet for projektet ved at forstå kundens mål og systemudfordringer.

Udvikling af dokumentation for softwarearkitektur

Derefter udviklede vi dynamisk, letforståelig dokumentation, der var designet til at udvikle sig i takt med projektet og dermed optimere teamkommunikationen og gøre onboarding-processen mere effektiv.

Design og udvikling

Her fokuserede vi på at implementere mikrotjenestearkitekturen og skabe behandlingsmodulet. Denne fase viste vores tekniske ekspertise, hvilket resulterede i en raffineret systemarkitektur og et fuldt funktionsdygtigt behandlingsmodul.

Integration og afprøvning

Ved at udnytte behandlingsmodulet integrerede vi problemfrit rejsebureauernes API'er. Grundige tests sikrede systemets pålidelighed og forbedrede funktionalitet.

Kommunikation og sporing af opgaver

Microsoft Teams var vores primære kommunikationsværktøj, der strømlinede diskussioner, opdaterede delinger og opretholdt et centralt informationslager. Vi brugte Jira til at holde orden og effektiv workflow-styring til opgavesporing.

Hold

4

Back-End Engineers

1

QA Engineer

1

Teamleder

1

Projektleder

1

Softwarearkitekt

1

Forretningsanalytiker

1

Leder af levering

Resultater

Opnåelse af transformative resultater med stigende salg og udvidet markedstilstedeværelse

Efter den vellykkede implementering udviste kundens webapplikation bemærkelsesværdige forbedringer af ydeevnen. Kombinationen af refaktorisering af koden og migrering til en mikrotjenestearkitektur resulterede i en betydeligt mere smidig drift. Dette tekniske eftersyn kombineret med den problemfri integration af nye tjenester katalyserede en betydelig stigning i kundens salg.

Virkningen af denne transformation strakte sig ud over det finansielle område. Den førte til en betydelig ekspansion, ikke kun i omsætning, men også i geografisk tilstedeværelse. Dette markerede et stort spring i virksomhedens markedsdækning og styrkede dens position som en fremtrædende aktør i branchen. Vores partnerskab med kunden fortsætter med flere integrationer i horisonten.

Projektets varighed
  • Marts 2023 - Løbende

30%

Øget salg

2x

Forøgelse af API-integrationshastigheden

    Kontakt os

    Book et opkald eller udfyld formularen nedenfor, så vender vi tilbage til dig, når vi har behandlet din anmodning.

    Send os en talebesked
    Vedhæft dokumenter
    Upload fil

    Du kan vedhæfte 1 fil på op til 2 MB. Gyldige filformater: pdf, jpg, jpeg, png.

    Ved at klikke på Send accepterer du, at Innowise behandler dine personlige data i henhold til vores Politik for beskyttelse af personlige oplysninger for at give dig relevante oplysninger. Ved at indsende dit telefonnummer accepterer du, at vi kan kontakte dig via taleopkald, sms og beskedapps. Opkalds-, besked- og datatakster kan være gældende.

    Du kan også sende os din anmodning
    til contact@innowise.com

    Hvad sker der nu?

    1

    Når vi har modtaget og behandlet din anmodning, vender vi tilbage til dig for at beskrive dine projektbehov og underskriver en NDA for at sikre fortrolighed.

    2

    Når vi har undersøgt dine ønsker, behov og forventninger, udarbejder vores team et projektforslag med forslag med arbejdets omfang, teamstørrelse, tids- og omkostningsoverslag.

    3

    Vi arrangerer et møde med dig for at diskutere tilbuddet og få detaljerne på plads.

    4

    Til sidst underskriver vi en kontrakt og begynder at arbejde på dit projekt med det samme.

    pil