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
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
Följ inlägget
0
följare
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
Det ska inte hända. Jag tilldelar detta ärende till SL.
Hälsningar,
Bert
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
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
Mvh 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
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
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.
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
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
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
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