Support
Till senaste kommentaren
Detta inlägg är gammalt och kan innehålla inaktuell information.

Har ni ändrat i Travelplanner 3.1 ?

Hej Support
Sedan drygt en vecka har nedanstående api betett sig stokastiskt!
http://api.sl.se/api2/TravelplannerV3_1/
Ibland levererars bara 2 Leglist när det borde komma 5.
Tror mig hittat workaround men måste undersöka ytterligare.
Undrar när ni ändrade Api't ?
Mvh Peder

Kommentarer

  • Hej Support
    Fixen verkar vara att pausa 30 sekunder mellan varje anrop, nu fungerar det åtminstone i dag, skall kolla resten av veckan. Skulle vilja veta varför det ändrade beteendet  dök upp!
    MVH Peder
  • Hej Peder,

    Det ska inte hända. Jag tilldelar detta ärende till SL.

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Hej Nu har jag loggat anropen till travelplanner och det finns ett antal fel i svaren från apiet. Kan skicka loggfiler från två servrar som hämtar datat, däri står key.  Se nedan på några av felen. Tid och uri och svar jag har maskat ut key
    url:211229041245 http://api.sl.se/api2/TravelplannerV3_1/trip.json?key=**************&originId=4400&destId=125&date=2022-01-07&numF=6&time=04:30&Products=64&passlist=0&destWalk=0&originWalk=0

    Error in GetTimeTableSLMorningboatSync deserialize:{"StatusCode":1002,"Message":"Key is invalid"}


    url:211229051615 http://api.sl.se/api2/TravelplannerV3_1/trip.json?key=*************&originId=125&destId=9192&date=2022-01-04&numF=6&time=14:30&Products=72&passlist=1&destWalk=0&originWalk=0

    Error in GetTimeTableSLMorningboatSync deserialize:{"errorCode":"INT_ERR","errorText":"internal error"}


    Mvh Peder
  • Hej Igen
    Här är är dagens fel (30/12)
    Att observera är att anropet inte ger fel från browsern, ca 10% av anropen ger errorCode i processen som går på natten??
    Behöver ni millisekunder i tidsangivelsen för att hitta i era loggar?

    url:211230041245 http://api.sl.se/api2/TravelplannerV3_1/trip.json?key=&originId=4400&destId=125&date=2022-01-08&numF=6&time=04:30&Products=64&passlist=0&destWalk=0&originWalk=0
    Error in GetTimeTableSLMorningboatSync deserialize:{"errorCode":"INT_ERR","errorText":"internal error"}

    url:211230041747 http://api.sl.se/api2/TravelplannerV3_1/trip.json?key=&originId=9192&destId=125&date=2021-12-31&numF=6&time=04:30&Products=72&passlist=1&destWalk=0&originWalk=0
    Error in GetTimeTableSLMorningboatSync deserialize:{"errorCode":"INT_ERR","errorText":"internal error"}

    url:211230043135 http://api.sl.se/api2/TravelplannerV3_1/trip.json?key=&originId=9192&destId=125&date=2022-01-09&numF=6&time=14:30&Products=72&passlist=1&destWalk=0&originWalk=0
    Error in GetTimeTableSLMorningboatSync deserialize:{"errorCode":"INT_ERR","errorText":"internal error"}


    url:211230043236 http://api.sl.se/api2/TravelplannerV3_1/trip.json?key=&originId=9192&destId=125&date=2022-01-11&numF=6&time=14:30&Products=72&passlist=1&destWalk=0&originWalk=0
    Error in GetTimeTableSLMorningboatSync deserialize:{"errorCode":"INT_ERR","errorText":"internal error"}

    url:211230050837 http://api.sl.se/api2/TravelplannerV3_1/trip.json?key=&originId=125&destId=9192&date=2022-01-08&numF=6&time=04:30&Products=72&passlist=1&destWalk=0&originWalk=0
    Error in GetTimeTableSLMorningboatSync deserialize:{"errorCode":"INT_ERR","errorText":"internal error"}

    Mvh Peder
  • Hej efter att börjat göra ytterligare ett försök vid varje http anrop (om det första misslyckas) får jag det data jag vill ha, men det blir alltså fel {"errorCode":"INT_ERR","errorText":"internal error"} i ca 5-10 % av anropen, och genom att göra samma anrop direkt efter felanropet får jag ett korrekt svar!? Är detta ett känt fel ? Sedan skulle det vara anrops sparande om man kunde få alla triper på ett dygn utan att behöva göra flera anrop med numF=6 för att få allt (Krävs för att generera den tidtabell som jag behöver). Jag har tidigare trott att om man har ett större tidsintervall mellan anrop skulle detta ta bort problemet så verkar inte vara fallet. Ej heller att numF=6 skulle fixa felen.
    Mvh Peder
  • Hej Peder,

    SL's TravelPlanner är ett API som SL tillhandahåller, och där vi tyvärr inte kan se loggarna eller påverka systemet. Jag har taggat SL sen första inlägget så att de får mejl och påminnelser, men av någon anledning har de inte återkommit på ärende. Jag försöker att nå dem på ett annat sätt.

    En förklaring för att det funkar efter ett första anrop som misslyckas skulle vara att ll data om behövs hamnar i någon slags cache.Första anropet tar för mycket tid från servern, men andra frågan går snabbare eftersom att datat är cachad. I så fall kan det kanske hjälpa att ändra NumF till 5 så att frågan blir enklare/snabbare. Detta är dock bara spekulering från min sida, och det skulle vara synligt som en responstid som alltid är lika långt när felet uppstår.

    Sen ser jag att du snackar om att bygga en tidtabell. Det är ett syfte som API:er inte är lämpligt för, eller iaf inte lika lämpligt som våra datasets. Den statiska GTFS Regional data innehåller all information som behövs för en tidtabell, och kombinerad med realtidsdata kan man även se positioner av båtar m.m.

    Hoppas att detta hjälper dig.

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Hej Bert
    Tack för svar.
    Ang cache som möjlig problematik borde ju första anropet av 14 stycken vara problemet men det är alltid efter ett stokastiskt antal anrop felet uppstår.
    Och dessutom är det här ett problem som uppstod efter ca 6 mån klanderfri funktion.
    Gtfs var den ursprungliga lösningen men det var under 2019 problem att få ut mellan vilka datum en tabell gällde ,båtnamn plus diverse annat som saknades i GTFS och om jag minns det rätt så kom vi (Kenneth hos er, som jag har ett antal mail med ang detta) och jag fram till att jag skulle använda sl's api vilket då löste de problem som fanns i gtfs och när det gäller realtid läser vi in AIS data från VHF bandet och får positioner och alla annan båtdata.
    Så jag önskar fortfarande veta om jag kan undvika fel från apiet, eller om jag måste leva med problemet.
    Sen är önskan att få hela dagens turer som svar på en fråga i en "batch".
    MVH Peder
  • Hej Igen Bert.
    Vill bara tillägga att problemet är ju egentligen löst för min del verkar det som, men andra kanske kan vara intresserade av att felet kan uppstå.
    Mvh Peder.
  • Hej Peder,

    Vi har i början av januari fått ett nytt kontakt hos SL för att svara på dessa frågor, men tyvärr har vi inte fått någon respons därifrån.

    Vi på Samtrafiken/Trafiklab kan inte göra mer än göra bra gissningar på hur man kan lösa eller undvika felet med SLs API:er baserad på den dokumentation vi har samt vår kunskap om liknande system. Vi har ingen tillgång till deras system, så vi kan tyvärr inte felsöka, fixa eller uppdatera något. För nutiden måste man alltså leva med problemet.

    När det gäller batches av resesökningar så kan jag säga att även SLs nya API (som vi inte har något estimat på när den skulle släppas) inte heller kommer stödja såna frågor, eftersom att det är en teknisk begränsning av sökmotorn som ligger bakom.

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Hej Bert,

    Det har varit en del med den driftsatta, lastbalanserade, miljön och en nod som inte fungerat tillfredsställande, vilket skulle kunna orsaka den där typen av problem vid upprepade anrop. Det är något vi själva noterat vid konsumtion från användare av webb/app. Förhoppningsvis och så tolkar jag det också hos dig vara löst nu.

    Stöd för att plocka ut alla reseförslag mellan punkt A och B under ett helt dygn är som nämnts inget som stöds av underliggande system, även om just båttrafik är väldigt tidtabellstyrt och med få alternativ så gäller detta inte annan trafik en utsökning av alternativa resor mellan godtyckliga punkter under sådan lång tid kan jag tänka mig är tämligen belastande.

    Mvh,

    /Martin SL
    SL
  • Hej Bert Tack för feedback.
    Tyvärr kvarstår felet se logg från den 22-01-30 har kollat bakåt och felet finns i alla fall kvar från den 220124 samma felprocent som tidigare.
    url:220130053425 http://api.sl.se/api2/TravelplannerV3_1/trip.json?key=377eca5f4092437e93d8c10392681524&originId=125&destId=9192&date=2022-01-30&numF=6&time=14:30&Products=72&passlist=1&destWalk=0&originWalk=0
    Error in GetTimeTableSLMorningboatSync deserialize:{"errorCode":"INT_ERR","errorText":"internal error"}
    Jag hanterar ju felet med ytterligare ett anrop så för min del är det inte något problem.
    Men för andra?!
    Man kan ju också tycka att felkoden är rätt intetsägande.
    Och åter igen hur kommunicerar ni och sl driftproblem i apier till era "förbrukare"?
    Mvh Peder
  • Hej Peder,

    Driftproblem kommuniceras främst genom status.trafiklab.se, där man kan se aktuella statusen på varje API (och även per datakälla när det gäller GTFS Regional). Sen kommuniceras större driftstörningar också ut på Trafiklab själv, fast det är begränsad till bara developer.trafiklab.se just nu. Vi kommer satsa mer på denna typen av kommunikation när nya utvecklareportalen har lanserats, förhoppningsvis blir det en kombination av en ny statussida samt tydliga banners på trafiklabs webbsida och utvecklareportalen. Det arbetet har dock inte påbörjats än, så vi kan inte lova att det kommer bli exakt sådär, och vi kan inte lova någon datum när det kommer bli klart heller.

    Angående felet så får du göra som du gör nu, med en extra anrop, och så får andra användarna också göra om de skulle få samma problem. Sen är det något som man gör hur som helst i de flesta fall, eftersom att mobilapplikationer måste ha någon retry-logik (vid till exempel dåligt nätverk) och de flesta andra applikationer uppdateras ändå varje minut.

    Hälsningar,
    Bert
    Bert på Trafiklab

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.