Keine Preisauskunft nach Fahrplanwechsel auf S6 (Bern - Köniz)

[tobiaszurbriggen]

Auf folgender Strecke Bern - Köniz mit der S6 werden nach dem Fahrplanwechsel keine Preise mehr auf der BLS Mobil App angezeigt.

Wir erhalten folgende Fehlermeldung beim Offer:

{"code":"GENERAL_ERROR_NOVA","description":"Nova Error occured while doing action: Calling novaShopAdapter.getOffersByTrip with GetOffersByTripQuery(base=GetOffersByQueryBase(mediaTypeCodes=[E_TICKET], productIDs=[], classTypes=[KLASSE_1, KLASSE_2, KLASSENWECHSEL], classTypeCode=null, productListCode=null, travellers=[Traveller(reference=null, tkId=null, reductionTypes=[HTA], travellerTypes=[PERSON, HUND, VELO], personBirthDate=1988-03-07, personFirstName=null, personLastName=null, age=null, genderIsMale=false, genderIsFemale=false)], isMultiOfferRequest=false), productTypeCodes=[SINGLE_TICKET, MULTI_JOURNEY], trip=null, tripOJP=TripOJP(legs=[LegOJP(originUicCode=8507083, originDepartureTime=2024-12-25T14:44, destinationUicCode=8507000, destinationArrivalTime=2024-12-25T14:54, intermediateStopsUicCode=[8507091, 8507082], productCategory=S, operatorRef=33, trainNumber=15653)], tripId=ID-5A504334-F074-46EA-BC5D-A94331AE95B3), returnTrip=null, mediaTypeCodes=[E_TICKET]), with error: Für die angefragte Strecke konnte kein Angebot ermittelt werden, da kein passender Weg gefunden wurde.","errorDomain":"NOVA","domainError":[{"code":"33001","description":"Für die angefragte Strecke konnte kein Angebot ermittelt werden, da kein passender Weg gefunden wurde."}],"clientRelevantDescription":false}

Bis vor dem Fahrplanwechsel erhalten wir noch normale Offers für die S6

Request
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:erstelleAngebote xmlns:ns1="http://nova.voev.ch/services/v14/base" xmlns:ns2="http://nova.voev.ch/services/v14/vertrieb" xmlns:ns3="http://nova.voev.ch/services/v14/vertriebsbase"> <ns2:angebotsRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ns2:kundenSegmenteGruppieren="false" xsi:type="ns2:StreckenBasierterAngebotsRequest"> <ns2:clientIdentifier ns1:kanalCode="981" ns1:leistungsVermittler="33" ns1:verkaufsGeraeteId="999" ns1:verkaufsStelle="19651" ns1:vertriebsPunkt="19651"/> <ns2:correlationKontext> <ns1:correlationId>9077788c-edc9-45f1-9f38-ddb60412083a</ns1:correlationId> </ns2:correlationKontext> <ns2:traegerMedium>E_TICKET</ns2:traegerMedium> <ns2:reisender> <ns2:ohneTkid> <ns2:reisendenTyp>PERSON</ns2:reisendenTyp> <ns2:geburtsTag>1989-03-05</ns2:geburtsTag> <ns2:ermaessigungsKarteCode>HTA</ns2:ermaessigungsKarteCode> </ns2:ohneTkid> </ns2:reisender> <ns2:reisender> <ns2:ohneTkid> <ns2:reisendenTyp>HUND</ns2:reisendenTyp> <ns2:geburtsTag>1989-03-05</ns2:geburtsTag> <ns2:ermaessigungsKarteCode>HTA</ns2:ermaessigungsKarteCode> </ns2:ohneTkid> </ns2:reisender> <ns2:reisender> <ns2:ohneTkid> <ns2:reisendenTyp>VELO</ns2:reisendenTyp> <ns2:geburtsTag>1989-03-05</ns2:geburtsTag> <ns2:ermaessigungsKarteCode>HTA</ns2:ermaessigungsKarteCode> </ns2:ohneTkid> </ns2:reisender> <ns2:angebotsFilter xsi:type="ns3:TaxonomieFilter"> <ns3:produktTaxonomie>Basistaxonomie</ns3:produktTaxonomie> <ns3:taxonomieKlassePfad> <ns3:klassenName>Einzelbillette</ns3:klassenName> </ns3:taxonomieKlassePfad> </ns2:angebotsFilter> <ns2:angebotsFilter xsi:type="ns3:TaxonomieFilter"> <ns3:produktTaxonomie>Basistaxonomie</ns3:produktTaxonomie> <ns3:taxonomieKlassePfad> <ns3:klassenName>Mehrfahrtenkarte</ns3:klassenName> </ns3:taxonomieKlassePfad> </ns2:angebotsFilter> <ns2:klasse>KLASSE_1</ns2:klasse> <ns2:klasse>KLASSE_2</ns2:klasse> <ns2:klasse>KLASSENWECHSEL</ns2:klasse> <ns2:hinFahrtVerbindung ns2:externeVerbindungsReferenzId="ID-5A504334-F074-46EA-BC5D-A94331AE95B3"> <ns2:verbindungsSegment ns2:abfahrtsZeit="2024-12-25T14:44:00" ns2:ankunftsZeit="2024-12-25T14:54:00" ns2:ausstieg="8507000" ns2:einstieg="8507083" ns2:verwaltungsCode="000033"> <ns2:verkehrsMittel ns2:gattungsCode="S" ns2:verkehrsMittelNummer="15653"/> <ns2:zwischenHalt>8507091</ns2:zwischenHalt> <ns2:zwischenHalt>8507082</ns2:zwischenHalt> </ns2:verbindungsSegment> </ns2:hinFahrtVerbindung> </ns2:angebotsRequest> </ns2:erstelleAngebote> </soap:Body> </soap:Envelope>

Die Antwort von NOVA Partnermanagement ist folgende:

Die Fehlerursache ist der falsche UIC-Code der Zwischenhaltestelle "Bern, Europaplatz". Meines Wissens gilt ab 15.12.2024 nur noch der UIC-Code 8504108 für alle Linien.

Hier die Anfrage aus dem SBB-Webshop, die funktioniert:

<ns2:hinFahrtVerbindung> <ns2:verbindungsSegment ns2:abfahrtsZeit="2024-12-25T14:44:00" ns2:ankunftsZeit="2024-12-25T14:54:00" ns2:ausstieg="8507000" ns2:einstieg="8507083" ns2:verbindungsAbschnittsIndex="0" ns2:verwaltungsCode="000033"> <ns2:verkehrsMittel ns2:gattungsCode="S" ns2:verkehrsMittelNummer="15653"/> <ns2:zwischenHaltContext ns2:tripContext="PLANNED" ns2:uicCode="8507091"/> <ns2:zwischenHaltContext ns2:tripContext="PLANNED" ns2:uicCode="8504108"/> </ns2:verbindungsSegment> </ns2:hinFahrtVerbindung>

SBB-Webshop macht die Anfrage an NOVA mit dem UIC-Code 8504108. BLS macht die Anfrage mit dem UIC-Code 8507082, der ab 15.12.2024 nicht mehr funktioniert.
Wie wird diese Anfrage an NOVA auf der Seite BLS generiert? Könnten Sie bitte prüfen, ob Sie den richtigen UIC-Code an NOVA übergeben?

@u233336 Könnt ihr bitte das dringende Thema anschauen? Es scheint gemäss NOVA hier ein Problem mit dem UIC-Code zu geben. Das Problem ist, dass die S6 eine BLS Strecke ist und der Fahrplanwechsel kurz bevor steht. Hier noch das NOVA Ticket dazu https://flow.sbb.ch/browse/NOVAEXT-8922

Danke und Gruss Tobias

[u233336]

Hallo zusammen

Ich habe die beiden Issues mit Matthias untersucht. Dabei sind wir zum folgenden Schluss gekommen:

• Beide Issues haben mit grosser Wahrscheinlichkeit die gleiche Ursache, nämlich den Bahnhof Bern Europaplatz
• Bei unseren Ausgaben scheint alles korrekt zu sein
• Die Modellierung vom Bahnhof Bern Europaplatz ist sehr seltsam und für solche Fehler anfällig:

Was heisst das nun für euch:

• Die Haltestelle mit der DiDok ID 8507082 wird von NOVA nicht mehr akzeptiert, sprich NOVA darf nicht mehr mit der Haltestelle 8507082 innerhalb eines Fahrweges angefragt werden
• Für Bern Europaplatz wird nur noch die Haltestelle mit der DiDok ID 8504108 akzeptiert

In unserer Modellierung in der TripResponse sieht das wie folgt aus:

<TripResult> ... <Leg> ... <StopPoint> <siri:StopPointRef>ch:1:sloid:7082:0:562230</siri:StopPointRef> <StopPointName> <Text xml:lang="de">Bern Europaplatz</Text> </StopPointName> <PrivateCode> <System>EFA</System> <Value>109026:0:2</Value> </PrivateCode> <ParentRef>8504108</ParentRef> <TopographicPlaceRef>23006351:1</TopographicPlaceRef> </StopPoint>

Der konkrete Fahrweg eines Trips () ist innerhalb der Legs () abgebildet. In unserer Ausgabe ist der Fahrweg gleisscharf modelliert, was bedeutet, dass Fahrwege, die bei Bern Europaplatz vorbeifahren, korrekterweise an der Haltekante mit der SLOID ch:1:sloid:7082:0:562230 vorbeifahren. Der «Parent» dieser Haltekante ist jedoch die DiDok ID 8504108 8504108, so wie wir es auch ausgeben.

Wenn ihr nun aber für eure NOVA Anfrage die SLOID ch:1:sloid:7082:0:562230 parsen solltet (eine Unterstellung von meiner Seite), dann wird aus der SLOID die DiDok ID 8507082 generiert und NOVA darum nicht korrekt angefragt. Das führt dann zur Fehlermeldung.

Es gibt nun also zwei Lösungen:

1. Die Parentbeziehung bei der Fahrwegextraktion korrekt abbilden oder
2. Für die NOVA Anfrage jede DiDok ID 8507082 mit der DiDok ID 8504108 ersetzen.

Ich denke, da solltet ihr einen schnellen Fix machen bei euch, damit die Kund:innen auch ab dem kommenden Sonntag Tickets kaufen können.
Weshalb diese Haltestelle so seltsam modelliert ist, bzw. wer es zugelassen hat, dass es 2 Haltestellen Bern Europaplatz mit unterschiedlichen DiDok IDs hat, bleibt wohl ein Geheimnis. Aber vorerst müssen wir damit leben.

Bei Fragen stehe ich zur Verfügung.
LG Christoph

[tobiaszurbriggen]

Hallo zusammen

Vielen Danke noch für eure Antwort zum Thema. Wie ich bereits mit Christoph telefonisch besprochen habe, konnten wir von unserer Seite aus nun einen Hotfix einspielen, bei welche die neuen UIC Codes richtig gemappt werden.

Aufgrund des Fixes werden nun auf der PROD auch wieder für beide (S3 sowie auch die S6) Angebote erstellt. Im ersten Workaround können wir das nun gerne so belassen, aber müssen dann später gemeinsam schauen, wie wir das ganze handhaben wollen.

Aber diese Ticket kann somit geschlossen werden.
Danke euch und LG Tobi

[terencebls]

Bezüglich der ParentRef, ich habe ein Response angeschaut und scheint nicht dabei zu sein:

Ein Beispiel:

<LegIntermediate>
									<siri:StopPointRef>ch:1:sloid:7082:0:562230</siri:StopPointRef>
									<StopPointName>
										<Text xml:lang="en">Bern Europaplatz</Text>
									</StopPointName>
									<NameSuffix>
										<Text xml:lang="en">ALTERNATIVE_TRANSPORT</Text>
									</NameSuffix>
									<PlannedQuay>
										<Text xml:lang="en">2</Text>
									</PlannedQuay>
									<EstimatedQuay>
										<Text xml:lang="en">2</Text>
									</EstimatedQuay>
									<ServiceArrival>
										<TimetabledTime>2024-12-17T12:49:00Z</TimetabledTime>
										<EstimatedTime>2024-12-17T12:49:54Z</EstimatedTime>
									</ServiceArrival>
									<ServiceDeparture>
										<TimetabledTime>2024-12-17T12:49:00Z</TimetabledTime>
										<EstimatedTime>2024-12-17T12:50:30Z</EstimatedTime>
									</ServiceDeparture>
									<Order>10</Order>
								</LegIntermediate>

[u233336]

Hallo @terencebls
Vielleicht haben wir uns falsch verstanden. Die ist sehr wohl in der TripResponse, nämlich unter ...:

<Place> <StopPoint> <siri:StopPointRef>ch:1:sloid:7082:0:562230</siri:StopPointRef> <StopPointName> <Text xml:lang="de">Bern Europaplatz</Text> </StopPointName> <PrivateCode> <System>EFA</System> <Value>109026:0:2</Value> </PrivateCode> <ParentRef>8504108</ParentRef> <TopographicPlaceRef>23006351:1</TopographicPlaceRef> </StopPoint> <Name> <Text xml:lang="de">Bern Europaplatz</Text> </Name> <GeoPosition> <siri:Longitude>7.40716</siri:Longitude> <siri:Latitude>46.94383</siri:Latitude> </GeoPosition> </Place>

Dort ist für den StopPoint Bern Europaplatz mit der SLOID ch:1:sloid:7082:0:562230 die ParentRef 8504108 gesetzt.

[terencebls]

Ah es ist ganz "oben" bei der TripResponseContext?

Ja dann sollten wir das so machen können.

Andere Frage: wie ist bei eine LIR abfrage? müssen wir auch dort irgendwo ein parent holen, oder kommt direkt dort der parent ?