Internal error SL
Jag får detta felmeddelande vid användning av denna adress https://journeyplanner.integration.sl.se/v1/TravelplannerV3_1/trip.xml?originId=0277&destId=4400&date=2024-02-15&time=00:00&key=xxxxxxxxxxxxxxxxx
<Error xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="hafas_rest" serverVersion="1.4" errorCode="INT_ERR" errorText="internal error"/>
<Error xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="hafas_rest" serverVersion="1.4" errorCode="INT_ERR" errorText="internal error"/>
Följ inlägget
4
följare
Hälsningar,
Bert
SL har hittat buggen och kommer lösa detta.
Hälsningar,
Bert
Jag får samma felmeddelande för liknande url fast med trip.json.
Finns det något tidsestimat när detta kommer att fixas? Med tanke på att det sägs att gamla url:en kommer sluta fungera om ca 5 veckor (den 15e Mars) behöver vi som publicerar appar och tjänster vara ute med en uppdatering i god tid för säkerställa att våra användare har tillgång till vår senaste uppdatering med nya url:en.
Jag har stöter på samma fel och undrar också när detta kommer vara löst.
Vänligen,
Jesper
Vi har bett SL om en prognos för när felet kommer vara löst och återkommer så fort att vi har ett svar.
Hälsningar,
Bert
Nu ska det vara löst. Det behövdes en prefix "30010" till varje id, och nu har platsuppslag-api:et rättats för att returnera rätt hållplats id. Från närliggande hållplatser är det mainMastExtId som ska användas.
Hälsningar,
Bert
Är det alltid prefix "30010"? Har testat lite och ser att vissa stationer returnerar prefix "30110" ibland. Vad är skillnaden på dessa två? Tänker då min app har sparat ner stationer från platsuppslag där siteId är 4 siffror, och ska jag prefixa detta själv behöver jag veta att det alltid funkar.
Att byta värden på aktiva API:er är dock helt galet, nu funkar ju inte Departures på nya stationer? Departures vill ju ha föregående siteId som är 4 siffror.
https://www.trafiklab.se/api/trafiklab-apis/sl/departures-4/
Varför justeras inte reseplaneraren till att ta gamla siteId utan prefix istället som det är specifierat i dokumentationen, eller att båda funkar om det är så viktigt att lägga till detta nu. Vi som använder dessa API:er har ju byggt en infrastruktur kring dokumentationen, och plötsliga oplanerade ändringar breakar ju detta.
Praxis är väl ändå att göra sånna här ändringar i nya API versioner, så att vi har tid att migrera nuvarande struktur?
- Mikael
Tyvärr vet vi inte vad som avgör detta skillnad, prefixen 30010 var den informationen vi fick från SL, samt att det löstes genom att returnera dessa nya ID:er från platsuppslag-API:et. Jag kan inte heller hitta någon överblickslista över alla hållplatser med dessa nya id:er. Vi tar kontakt med dem för att se om de har en komplett lista.
> nu funkar ju inte Departures på nya stationer
Det stämmer, departures kommer utgå snart när SL är färdigt med ersättaren. Tyvärr vet vi inte än när detta kommer ske.
> Praxis är väl ändå att göra sånna här ändringar i nya API versioner, så att vi har tid att migrera nuvarande struktur?
Dessa ändringar påverkar bara de nya, uppdaterade API:er. Tyvärr stämmer det att man, genom att flytta över användarna till det nya platsuppslag-API:et (med nya URL:en men samma fråga/responsstruktur) har förstörd den här kompatibiliteten med de gamla API:er. När det gäller dessa API:er kommer det nog vara rörigt en månad till med något som verkar kommer bli en väldigt kort övergångstid mellan Departures 4 och API:et som kommer ersätta den. Vi kollar med SL om det finns någon prognos om när detta nya API:et kommer vara färdigt.
Hälsningar,
Bert
Tack så mycket för snabbt svar!
Då förstår jag lite bättre, det var min förståelse att dessa ändringar endast innebar nya URL:er och inget annat, vilket även står i dokumentationen: "Query parameters, response bodies and API keys remain unchanged.".
Skulle det vara möjligt att kolla med SL om de kan förlänga de gamla URL:erna (Stop lookup, Journey Planner, Nearby Stops) tills de blivit färdiga med nya Departures? Dessa hänger ihop när det kommer till id:n, och det blir väldigt rörigt att använda API:er där vissa använder nya id:n, och vissa gamla.
Även om det går att lösa genom att lägga till eller ta bort siffror beroende på API, känns det som en väldigt osäker lösning att vi på klient-sidan ska göra dessa antaganden. Speciellt då detta med "30010" prefixen inte verkar vara dokumenterat någonstans?
- Mikael
Tyvärr är det inte möjligt att förlänga de gamla URL:erna, det datumet är fast vilket gör att det blir så kort övergångstid på all dessa API:er. Tanken var att de skulle släppas kort efter varandra, men sen blev sista API:et med ersättaren till Departures v4 försenad. Sen verkade den här id-förändringen ha ramlat mellan stolarna hos SL.
Angående 30010 prefixen så har vi inte hunnit dokumentera detta än, samtidigt som att allt rör sig och vi behöver ha en överblicksbild för att kunna skriva tydlig dokumentation som knyter ihop API:er och id:er. Jag har dock fått lite mer information som borde hjälpa dig:
Ta site number, och padda det med nollor tills du har 7 digits. Nya id:et blir 3BA1CDEFG där ABCDEFG är de 7 digits av site number.
OBS: De första två digits, mellan 3 och 1, byter plats!
1234 blir alltså 300101234
123456 blir alltså 310123456
Hoppas att detta hjälper.
Hälsningar,
Bert
Känner att jag redan uttryckt min besvikelse i hur SL hanterat detta, så jag avstår från att upprepa mig. 😅
Med det sagt uppskattar jag verkligen den hjälp jag fått av dig, för med id informationen kan jag åtminstone få in en temporär lösning tills saker är mer stabila. Informationen om 3xx1 prefixen var precis vad jag behövde!
Innan dess satt jag och experimenterade med 30010 och 30110 som prefix, vilket gav spännande resultat ibland med 30110. Antar att det makes sense nu, men blev ändå lite förvånad att jag fick två ids som var till samma station.
Tex dessa två ids blev båda till Sollentuna Sim- och Sporthall i reseplaneraren:
30110 + Stockholms Central (9000) 301109000
Sollentuna Sim- och Sporthall 300105061
Mer en intressant observation än fråga. I det här fallet funkar det som det ska med 30010 prefix:en, så 3xx1 logiken verkar vara en hållbar lösning.
- Mikael
SiteId: 3xx1xxxxx where xx and xxxxx are the 7 last digits of site.number padded with zeroes.
StopId: 4xx1xxxxx where xx and xxxxx is JourneyPatternPoint.number padded with zeroes.
StopAreaId: 2xx1xxxxx where xx and xxxxx is StopArea.number padded with zeroes.
För info så har SL nu släppt ett nytt API som ersätter SL departures v4. Mer information följer i ett mejl imorgon men går redan att läsa om nya API:et här: https://www.trafiklab.se/api/trafiklab-apis/sl/transport/.
Hälsningar,
Bert
3xx1xxxxx formatet funkar inte för tillfället. Tex funkar det med 9000 men inte 30010900.
https://transport.integration.sl.se/v1/sites/9000/departures
https://transport.integration.sl.se/v1/sites/300109000/departures
Sen känns det lite märkligt att alltid få 200 respons med tomma arrays oavsett vad siffror man lägger in som id.
I korthet så är det för närvarande helt omöjligt att veta 1) vilka ID SL levererar till dig imorgon via Platsuppslag, och 2) ifall Transport kommer acceptera lång-id i framtiden, och i så fall när.
Själv föredrar jag att inspektera alla id från och med nu och klassificera dem som antingen lång-id eller kort-id, istället för att överraskas nästa gång och vänta okänd tid på ett eventuellt svar från SL.
Jag orkar däremot förmodligen inte skicka nya anropsförsök med alternativt id om det första misslyckas — inte minst eftersom det inte är möjligt att identifiera ifall anropet faktiskt misslyckas, som du säger.
Har deployat en likande lösning som identifierar och konverterar mellan lång-id och kort-id beroende på vilket api jag använder. Känns givetvis inte optimalt med tanke på den stora brist på information samt att vi utvecklare får agera QA för de nya api:en. Detta gör det väldigt svårt att lita på att detta är fullständig lösning, men vad kan man göra... speciellt när vissa gamla url:er sägs sluta funka om ett par dagar.
Med tanke på att de själva verkar vilja gå över till lång-id överallt och att de själva sagt att "nya Departures" ska använda lång-id känns det snopet att de inte ens har stöd för det här just nu, samtidigt som vi ska implementera detta innan slutet av månaden. Potentiellt kan det finnas lång-ids som är inte bara är 4 siffror + padding, vilket innebär att en konvertering till kort-id kan ge ett helt annat resultat.
För de som har appar och tjänster ute måste de alltså i princip ha något ute om en vecka för att ge användare tid att uppdatera. Nu kan jag givetvis inte göra så om det finns fundamentala saker i api:et som inte fungerar som de ska. Enda sättet att släppa något som inte breakar i framtiden nu är att försöka båda ids som du säger, vilket vore sjukt.
Deadline sägs vara 31a mars och det vore snopet att släppa något som använder gamla ids (4 siffror) och sedan ändras det utan förvarning.
Jag har förstått det som att SL inte kommer ändra något mer på id:erna som används. Vi har lagt till dokumentation om hur man kan räkna om id:er mellan platsuppslag och SL Transport, även om jag skulle rekommendera att försöka få id:et i rätt format från början.
SL Platsuppslag, SL Närliggande hållplatser och SL Reseplanerare 3.1 fungerar alltså ihop med 9-siffriga id:ar (som typiskt börjar på 3001).
För SL Transport (/sites och /sites/<id>/departures) används de gamla, typiskt 4-siffriga id:er. För mobila applikationer skulle man kunna spara resultatet från /sites för att göra hållplatssökningar direkt på mobilen, något som typiskt fungar smidigare än lösningar som slår upp hållplatser på nätet. Jag förstår dock absolut att det är ont om tid och att stora anpassningar inte alltid är möjligt inom den tidsramen som finns kvar.
Angående responskoden har jag bett SL om de kan returnera HTTP 400, men har inte något definitivt svar på den frågan än.
Hälsningar,
Bert
För min del blir det tyvärr en blandning av nya och gamla ids oavsett hur jag gör. Även om jag skulle ersätta Stop Lookup och Nearby Stops 2 med en lokal lista av sites så måste jag konvertera dess ids till 3xx1xxxxx för route-planner.
Sites hade varit fantastiskt för oss mobil-utvecklare om den garanteras hållas uppdaterad och om det fanns en mekanik att fetcha nya sites från en timestamp så man alltid kan hålla den lokala listan uppdaterad utan att fetcha om allting varje gång.
Det stämmer att det är de gamla, typiskt 4-siffriga id:er som gäller för nya departures API:et. Jag håller med att det blir rörigt med olika id:er då många app:ar behöver flera end-points för olika funktioner, men tyvärr har det blivit så. SL har återkopplat att de kommer lösa detta när alla API:er ersätts med 1 nytt API, men det ligger lång i framtiden.
Hälsningar,
Bert