Disponibilité & utilisabilité en pratique du flux SIRI de Boulogne-sur-Mer

[thbar]

Follow-up https://app.frontapp.com/open/msg_29z4mfti?key=Wi5KuRNx5aSsm8-zv396dYals-O6wUHX

Je constate deux soucis pour la découvrabilité et la réutilisabilité du flux SIRI de Boulogne-sur-Mer:

https://transport.data.gouv.fr/datasets/horaires-theoriques-et-temps-reel-du-reseau-de-transport-marineo

1. Le flux est indiqué comme indisponible (alors que ce n'est pas le cas)

En pratique le flux est opérationnellement fonctionnel (modulo le problème 2).

Je vais préparer une PR pour corriger ce point et passer à "available".

2. Absence de requestor_ref

Le lien "try me!" pointe actuellement vers:

https://transport.data.gouv.fr/tools/siri-querier?endpoint_url=https%3A%2F%2Fsaes.ratpdev.com%2Fctb&requestor_ref=&query_template=LinesDiscovery

(requestor_ref à blanc).

Si j'entre des requestor_ref classiques sur l'opération CheckStatus (qui est normalement tout le temps autorisée), j'obtiens actuellement ceci (https://transport.data.gouv.fr/tools/siri-querier?endpoint_url=https%3A%2F%2Fsaes.ratpdev.com%2Fctb&requestor_ref=opendata&query_template=CheckStatus):

HTTP response body

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header/>
  <soap:Body>
    <ns1:CheckStatusResponse xmlns:ns1="http://wsdl.siri.org.uk">
      <CheckStatusAnswerInfo xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns3="http://datex2.eu/schema/1_0/1_0" xmlns:ns4="http://www.ifopt.org.uk/ifopt" xmlns:ns5="http://www.siri.org.uk/siri">
        <ns5:ResponseTimestamp>2024-10-31T09:07:45.563+01:00</ns5:ResponseTimestamp>
        <ns5:ProducerRef>CTB</ns5:ProducerRef>
        <ns5:ResponseMessageIdentifier></ns5:ResponseMessageIdentifier>
        <ns5:RequestMessageRef>Test::Message::02c8676f-d373-49ba-b6c1-02650778dadf</ns5:RequestMessageRef>
      </CheckStatusAnswerInfo>
      <Answer xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns3="http://datex2.eu/schema/1_0/1_0" xmlns:ns4="http://www.ifopt.org.uk/ifopt" xmlns:ns5="http://www.siri.org.uk/siri">
        <ns5:Status>false</ns5:Status>
        <ns5:ErrorCondition>
          <ns5:OtherError/>
          <ns5:Description>UNAUTHORIZED_ACCESS Subscriber unknown: [opendata]</ns5:Description>
        </ns5:ErrorCondition>
      </Answer>
      <AnswerExtension xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns3="http://datex2.eu/schema/1_0/1_0" xmlns:ns4="http://www.ifopt.org.uk/ifopt" xmlns:ns5="http://www.siri.org.uk/siri"/>
    </ns1:CheckStatusResponse>
  </soap:Body>
</soap:Envelope>

On va aller à la pêche au requestor_ref concernant ce deuxième point.

[Brewennn]

@thbar je te fais suivre cette issue #4254 sur les resquestor ref pour info, @AntoineAugusti avait détecté 19 JDD sans requestor_ref

[thbar]

Bien vu, j'avais vu passer effectivement. Je vais me concentrer sur le point 1 déjà pour le moment (Boulogne n'étant pas le seul flux concerné) et j'ai une idée pour aller traiter plus correctement la suite.

[thbar]

@Brewennn je traite le premier point avec un "hot-fix" ici #4284

[thbar]

Pour le premier point (label "indisponible"), c'est traité, il vient de disparaître @Brewennn :

Pour le sujet plus large des requestors_refs, on va travailler côté #4254 (ou via une sous-issue peut-être).

Je clôture.