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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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
- -- Mit freundlichen Grüßen Tilo Werner - - Systemadministration - _______________________________________________ TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig E-Mail: t.werner@traso.de Internet: https://www.traso.de _______________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJTkkcXAAoJEFfjOJdKpi1EOroP/A7pSmXDchmVtFzxkmHZvp/X uwIohOJhL37CxsMO8C/LRQ7WpUan3TOFUPMMGkmURjnwTdTwimlWv+rjDZCIX7Jx C+6fsou1QDtOKxYY2fHOo0U6OKaTmYGd0O5rTgMHJE+VS977Wz1TI9cpy4McwzVT 4tstVuffvQ2YVGk6yJqagAsicGYQtkJRHDzQnE3Jr7YD/yUzKKUV2FnDLQf8pXMD 5rUk93c59f9ydnRAyN2p1hjQngmzWv5CJrkQfP1xIK+3rQn8xaK514TtasNBX5Di G9X/GIrsR98Gld6grPjgo1RNPZ8mxyawe2ElJYv15e9vX3EhpX3Z9FmitP1iMmF4 vck7MZq0Ltish37gvu9zuAlDbUTxveQYDIfQVK9S7j0RhPcjGg9fz4F26pcWtYcg 3JdVf8/ee6O9TztLmuySQu8A20LDCvC8/G5QToH52JeDGbixEJbKYZZ4xVAbVNCk qqsTIKbotICo2s8Mb59xUBeD27mXdJ20iyZqbDH6Wb2lSGmtxolmDcOjp+2XJYdM IC4+5tpatT8Q4cYtYBcCxlO3zhwa9ZJbqAey1TtAFSaloqPhaxDHCbqXSRfyu3rd kIkQflt/XgfdWD6BHozOQAcDl7tbabHx3OQnQhxZVFlEffbwMxATjmepdwtnSOz+ C82pABjjv7SYo5oHqPWk =TvlB -----END PGP SIGNATURE-----
Hallo, Ach, ich vergaß, ganz wichtig: Es muss irgendwas im Netzwerk sein ... oder die Datenbank. :-P VG SRK Am 07.06.2014 00:56, schrieb Tilo Werner:
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
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
-- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Stefan - --- 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. - --- Kannst du da in etwa raus finden, ab wann dieser Fehler vermehrt auftritt. Ich hatte Änderungen am Kinderalter-Handling beim Sejourimport und in der cache-Berechnung vorgenommen. Die Änderungen sind am Mittwoch live gegangen. Bei der Änderung geht es grundsätzlich um das mergen aller gegebenen Kinderalter-Bereiche auf das höchste Alter. Sören 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
- -- - -- Sören Pestner - - Entwickler - TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig telefon: +49 341 909 87 509 email: s.pestner@traso.de Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTkuobAAoJEEVkNmrneQJZ5QYH/Rhs84Lc5h9WKmiRMZGqc+DS dIhuu+VZvx/UbWipkEl2CY0ncbdpXubpFXZuJ28wv/XQLq/ldx0SF72ekT//6ipY CCDy+JKYnQn3kwMd1fTf9shv8Rk2zpo5ytT8XBjRge+NvkjoCT+wHMGzsKOMUnMv byTZHuQSFT+0NpJr/tZoOEib+1KE9yzn5lTzxhWCdg8jsn8Ec/WwfN1D2xRn294G uVuSgI0Vh2iFI9hG/N0yqIyVSYxCuD3H/FoN+NQsJPNI+gDT0iKbzj9LB6JqRVB0 AK9dQ4EkQuBSF7R8b72mL9OOLRdjvc9FpDtaJhRxbtu3yjBEWURKxtWrIy1glRw= =GkDu -----END PGP SIGNATURE-----
Hallo Sören, 1. Der Fehler bei ETS4 ist leider nicht genauer zurück zu verfolgen: Die Angabe stammt aus den DebugLogs, die leider nach 24h "wegfliegen" ... in welchen Urlaub auch immer. 2. <kein Provider>: Es scheint mit so zu sein, dass LMX ein LTS-Hotel mit dem externen Code anfragt, die externen Codes bei LMX und LTS stimmen weitgehend überein ... die hotel_codes weichen aber von den externen Codes ab. @Jen: Bei den 3 betroffenen Hotels ist es aber so, dass dort das Matching bei LTS nicht fertig gestellt wurde => die Hotels stehen auf "unbearbeitet". Bei LMX sind die Hotels "erledigt" (werden also angefragt), bei LTS gibt es dann aber keine anfragbaren Ergebnisse. Könnte der Support ggf. mit LTS darüber sprechen? Am 07.06.2014 12:31, schrieb Sören Pestner:
Hallo Stefan
--- 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. ---
Kannst du da in etwa raus finden, ab wann dieser Fehler vermehrt auftritt. Ich hatte Änderungen am Kinderalter-Handling beim Sejourimport und in der cache-Berechnung vorgenommen. Die Änderungen sind am Mittwoch live gegangen.
Bei der Änderung geht es grundsätzlich um das mergen aller gegebenen Kinderalter-Bereiche auf das höchste Alter.
Sören
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
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
-- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Stefan. - ----- <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. - ------ Wie wird bei einem LMX Request - Eingang der Request an LTS gestellt. Fragen wir dort mit dem bei LMX hinterlegten Externen Code an oder mit dem Provider Hotel-Code. Was wird ggf. noch übermittelt. Dann könnte ich per query solche Anlage Fehler feststellen. 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
- -- - -- Sören Pestner - - Entwickler - TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig telefon: +49 341 909 87 509 email: s.pestner@traso.de Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTkvE4AAoJEEVkNmrneQJZHkYIAIspX4Lv8H5stZ3+C7j61yqI LNI2renacvtWERwAIA+C/czQu0TKz76alrguLDMv4cQEpcGHEEFdQCKUgAN/4k8j becI3hVIEctQ59mOXa3w0j/yD2FDN681W9D0EkjGvGnKRaEqW/YK2NlJh7VzLKAw 2CRbDXghdRJsqY+ft5TFdg4O+O26xB922BLB+aL9R9HHIkwc2t27eO7eEB0FItAe Wx5oFfsmX+qFTYvhZapHrmb8L0uvUJ+ROHZZnyVM+dKoLkfeQY4NEm5A0u4BaJUI 7ulTMSrKf+kIk3s+exwJsZI6a4aCDZ5TULlHjjUJ/M0mgdK8SMznFGTS2HQe0Og= =/aG6 -----END PGP SIGNATURE-----
Hallo zusammen, hier ein paar Anmerkungen von mir dazu. 1. Die Feststellung, dass wir gestern bei SESP die Quote von ca. 50% Fehlern auf ca. 20% Fehlern reduziert haben - Lag an: ??? Ist weiter unklar - hat sich aber heute bestätigt 2. Die Änderung von sejour, die gestern bei SAYT vorgenommen werden sollte, - hat entweder nicht stattgefunden - oder hat keine entsprechenden Effekt gehabt 3. Zu Stefany Kommentaren siehe unten Mit freundlichen Grüßen Haiko Gerdes - Geschäftsführer - ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 7 418 // Fax: +49 341 90 98 749 Mobil: +49 172 610 2849 Internet: http://traso.de E-Mail: h.gerdes@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 Von: team [mailto:team-bounces@lists.traso.de] Im Auftrag von Stefan Rank Kunitz Gesendet: Samstag, 7. Juni 2014 00:17 An: Haiko Gerdes; 'Team' Betreff: [Team] Untersuchungen LTS/Sejour BA-Quote 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? [HGE:] Hier könnten die Probleme auftreten, weswegen Rene den RateplanInterpreter neu geschrieben hat. Bzw. evtl. auch Performance Probleme, weswegen Krisztian die Hotelpreiserfassung neu machen will. * 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). [HGE:] Wenn wir da Probleme haben, da hat Sngül angeboten diese sehr schnell zu analysieren. Bitte an Songül schicken und RSR max. in cc: Die Buchungsschnittstelle liegt in unserer Verantwortung mit sejour, da brauchen wir LTS nicht. * 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. [HGE:] Verstehe ich auch nicht, aber es gibt auch erfolgreiche mit SAYT,SAYT, die Quote ist da eher gleich. Ist also nicht die Ursache. * <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. [HGE:] AYTCIN gibt es bei LTS. Dort fehlte der Wert bei Export, den habe ich gesetzt und jetzt müsste AYTCIN klappen BJVSKY fehlte der externe Code im LTS, müsste jetzt gehen ADBAHC – keine Ahnung So ... Leider kann ich an dieser Stelle nicht mehr tun, weil ich für weitere Untersuchungen besonders Jen und Nadine brauche. [HGE:] Ziel 1 sollte sein, so schnell wie möglich Sejour Systeme auf LMX umzustellen, - ich vermute, dass dann >50% der Probleme s.o. gelöst sind Probleme, die dann noch auftreten bitte an Songül schicken, die sollen und wollen helfen. 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
participants (4)
-
Haiko Gerdes -
Stefan Rank Kunitz -
Sören Pestner -
Tilo Werner