Bezogen auf meine kleine Kritik zu deiner Mail bzgl. der Cache-Anfragen
von LTS ist diese Analyse das bisher Beste, was ich hier zu lesen
bekommen habe.

+1

lg,
Tilo

PS: Ich mag es sehr, dass so ausführend hier auf der Team-Liste
Probleme besprochen werden.

Am 07.06.2014 00:16, schrieb Stefan Rank Kunitz:
> Hallo Haiko,

> Ich habe nun ENDLICH wieder einen nutzbaren Internetzugang und habe
> mir nun das LTS-Problem angesehen. Zur Untersuchung habe ich die
> BA-Logs von LTS nach dem responseCode=573 gefiltert und dann VIELE
> Beispiele manuell per debugLogs untersucht. Da die Fehler /
> Probleme sich sehr schön nach Provider gruppieren lassen, sortiere
> ich meine Ergebnisse auch so:

> * ETS: Bei diesen Angeboten handelt es sich um eigen-erfasste
> Hotels. Die Bearbeitungen vieler Anfragen an diesen (internen)
> Provider brechen mit der Meldung ab, dass der alte
> RatePlansInterpreter "OTA_RatePlansInterpreter::getPrice" keine
> RatePlans findet. Ich werde am Dienstag mit Jen, Nadine und
> Krisztian besprechen, was das genau bedeutet und wo die Probleme
> liegen können. Ansätze: Hatten wir ggf. in letzter Zeit Probleme
> bei der Ablage eigen-erfasster Hotels? Wurde an der Oberfläche zur
> Erfassung oder an der nachfolgenden PAC-Erzeugung gearbeitet?
> Könnten dies Altlasten aus früheren Problemen in der
> Eigen-Erfassung sein, die nach einem "Bearbeiten" und "Speichern"
> (Überschreiben des StatusQuo) gelöst wären? * ETS4: Hier haben wir
> das gleiche Problem wie bei ETS. Darüber hinaus haben wir in
> anderen Fällen dieses Problem: "no matching child rate found for
> child age 12" Auch hier bespreche im am Dienstag im Team an, wo
> GENAU das Problem ist und wie WIR oder RSR (falls es um inhaltliche
> Pflege geht) das Problem lösen können. * SAYT: Es scheint
> Änderungen bei Sejour an der Response auf den 2ten Request gegeben
> zu haben. Wir können die Antwort in vielen Fällen nicht mehr lesen
> und beenden deren Bearbeitung mit der Meldung "Knoten TABLE ist
> nicht enthalten oder leer. Abbruch.". Es scheint sich also um ein
> Problem in der XML-Verarbeitung zu handeln, es wird eine andere
> Struktur erwartet als SAYT liefert. Ich werde mit RSR/TSC und
> Songül nachsehen, was genau das Problem ist und habe dazu Requests
> und Responses gesichert (siehe Anhang). * SAYT,SAYT: Ich habe noch
> nicht ganz verstanden, warum es Hotels gibt, bei denen wir
> scheinbar SAYT doppelt und parallel anfragen ... so steht es aber
> in den Logs. Dabei brechen wir immer eine der beiden Anfragen ab
> mit "Kein auswertbares XML. Abbruch." => Ich denke, der
> Buchungskern ist nicht darauf vorbereitet, dass für ein konkretes
> Angebot die selbe Schnittstelle doppelt losgeschickt wird, das
> Problem könnte in der Datei-Ablage der Response liegen ... ich
> untersuche das am Dienstag im Code. Ferner kläre ich mit Jen,
> warum der Buchungskern das eigentlich versucht ... stehen die
> Hotels ggf. doppelt in der Datenbank? Der 2te der parallelen
> SAYT-Anfragen endet dann mit Auswertungen der Art "1SIDARC: Die
> gesuchte Zimmerart stimmt nicht mit der Art des Zimmers
> "3ADL_FLSV2" ueberein." und "Für das Zimmer "F03" konnte kein
> passendes Angebot selektiert werden. Abbruch.". Könnte dies ein
> Matching-Problem sein? Das bespreche ich mit Jen und Nadine am
> Dienstag. * <kein Provider>: LTS bekommt eine größere Anzahl an
> Anfragen (heute 500) zu Hotels, die bei uns nicht gefunden werden.
> Wir haben das Hotel nicht und fragen damit auch keine Schnittstelle
> an. Das Problem betrifft (am heutigen Tag) diese externen
> Hotel-Codes: BJVSKY, AYTCIN, ADBAHC Dies könnte ein
> Matching-Problem (von HotelCodes) sein. Wahrscheinlicher ist aber,
> dass die Produktkataloge von LMX und LTS nicht so GANZ auf einander
> abgestimmt sind und bei LMX noch Hotels im PAC stehen, die LTS
> schon rausgeworfen hat. Abschließend könnten die Hotels bei LTS
> auch aus anderen Gründen nicht für eine Provider-Anfrage ausgewählt
> werden (zum Beispiel wenn der Haken zum "Nur Hotel export" in den
> Hoteldaten fehlt). Dies werde ich am Dienstag mit Jen untersuchen.

> So ... Leider kann ich an dieser Stelle nicht mehr tun, weil ich
> für weitere Untersuchungen besonders Jen und Nadine brauche.

> Vielste Grüße aus dem Sessel in den Süden SRK

> -- Mit freundlichen Grüßen

> Stefan Rank-Kunitz - Entwicklung -
> ________________________________________________________ TraSo
> GmbH

> Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 909 87 45 /
> Fax: +49 341 909 87 49

> E-Mail: s.rank-kunitz@traso.de Internet: http://www.traso.de

> ________________________________________________________
> Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig,
> HRB 21850



> _______________________________________________ team mailing list
> team@lists.traso.de https://lists.traso.de/listinfo/team