Kunden und ihre Probleme...

Eigentlich ist dieser Eintrag eher was für den Sysadmin, aber warum nicht auch hier ;-)
Gestern hatte ich ein Kundenerlebnis der besonderen Art.

Wir haben bei uns Applikationen laufen an die Kunden sich per TCP/IP verbinden. Aber nicht via Internet sondern per dedizierten Leitungen. Auf ihrer Seite Firewalls, auf unserer Seite Firewalls, verschiedene Abteilungen die da beteiligt sind; die Applikationsentwickler, die Nutzer, die Netzwerker. Auf beiden Seiten natürlich.

Normalerweise geht das bei einem Neuanschluß recht einfach - wir haben dafür Checklisten gebaut so dass unsere Netzwerker schon sagen können was sie brauchen, wir das dem Kunden erklären, uns von den Netzwerkern des Kunden schonmal die Telefonnummer geben lassen (direkt geht schneller) und der Kunde bekommt natürlich die Protokollspezifikationen, damit seine Applikation überhaupt mit unserem Serversystem ordentlich reden kann.

Gestern nachmittag wurde ich von unserem Applikationsteam angerufen - ich sollte dringend in eine Telefonkonferenz dazukommen; ein Neukunde behauptet unser Testsystem wäre nicht in Ordnung. Nun gut. Die Applikationsleute fragen noch nach ob ich englisch kann (ich sagte erst im Scherz ich könne es nicht und mein Kollege überlegte dann fieberhaft wie gut er übersetzen kann :-)

Als ich dazukomme gibt es gerade eine Diskussion zwischen unserem Netzwerker und deren Applikationsentwicklern weil diese versuchen sich an unsere Applikation zu verbinden. Eine gute Idee - aber ich schaue kurz nach und sehe dass sie bereits mit allen 3 notwendigen Ports verbunden sind. Das bedeutet aber dass es nutzlos ist sich neu verbinden zu wollen; die Ports sind ja bereits belegt. Also muss unser Kunde erstmal seine Applikation ausschalten.

Nachdem dies passiert ist geht auch der telnet-Versuch. Was jetzt erst klar wird; der Kunde scheint zu erwarten dass unsere Applikation sowas wie ein "Hallo!" schickt; diese wartet aber (richtig laut Protokoll) darauf dass der Kunde sich via Username und Paßwort direkt identifiziert. Nachdem ich das dem Kunden erklärt habe (zwischendurch gabs noch Probleme mit seiner Fireweall, die wohl Verbindungen nicht sauber abbaut) schlage ich vor, dass er einfach via telnet nochmal sich an uns ranhängt und ich auf dem Port "mitlausche" um zu sehen ob überhaupt Daten ankommen - das bezweifelt der Kunde bisher nämlich. Ein typischer Kunde halt; er denkt dass er alles richtig gemacht hat und nur wir falsch arbeiten. Okay, darf er gerne denken.

Mit dem tcpdump sehe ich dass der Kunde wirklich bei uns ankommt und Daten überträgt - damit fällt unseremm Netzwerker schonmal ein Stein vom Herzen, diesem hat der Kunde nänmlich nicht geglaubt dass netzwerkmäßig alles klappt.

Warum aber schweigt sich unsere Applikation gegneüber dem Kunden aus? Nun muss ich doch noch tiefer in die tcpdump-Trickkiste greifen und den Datenstrom nicht nur als Statistik sehen sondern den Inhalt mir anzeigen lassen. Als erstes fällt mir auf dass die XML-Nachricht an sich okay aussieht - aber das Paßwort was mitgeliefert wird sieht künstlich aus. Eine kurze Rückfrage bei der Applikationsabteilung bestätigt dass das Paßwort falsch ist - quasi das erste Mal wo wir dem Kunden zeigen können dass er nicht genau gearbeitet hat.Kurz danach ist das Paßwort richtig gesetzt, aber unsere Applikation reagiert trotzdem nicht; nicht einmal Einträge in die Debug-Logfiles. Normalerweise ist das ein Zeichen dafür dass das Protokoll nicht eingehalten wird; irgendwo ist da noch ein Fehler.

So gut kenne ich das Protokoll nicht, aber ich erinnere mich daran dass wir schonmal einen Kunden hatten der die Nachricht falsch abschloß. Ich frage die Applikationsabteilung und auch die müssen erst einmal in die Spezifikation gucken (die der Kunde natürliuch auch hat). Und tatsächlich: in der Spezifikation steht drin dass die Nachrichten mit einem Nullbyte abgeschlossen werden müssen - der Kunde hat aber gedacht, den Message-Tag abzuschliessen reicht. Nachdem ich hier auch noch die Entwickler des Kunden korrigieren konnte klappte plötzlich auch die Verbindung.

Auch wenn der Kunde noch längst nicht soweit ist sich ans Produktivsystem zu verbinden - erstmal sind wir an allem schuld bis zum Beweis des Gegenteils. Immerhin kann er jetzt nicht mehr viel (netzwerkmäßig) falsch machen und die Applikationslogik muss er dann selbst kennen.

(Der Kolleg ein der Applikationsabteilung erzählte mir am Ende des Gesprächs dass der Netzwerker und er schon 2 Stunden mit dem Kunden am telefonieren gewesen sind weil sie Fehler suchten und suchten... ich glaub ich bin froh das sich erst so spät dazugekommen bin....
Vote for articles fresher than 7 days!
Derzeitige Beurteilung: none, 0 Stimme(n) 299 hits

Trackbacks

Trackback specific URI for this entry

This link is not meant to be clicked. It contains the trackback URI for this entry. You can use this URI to send ping- & trackbacks from your own blog to this entry. To copy the link, right click and select "Copy Shortcut" in Internet Explorer or "Copy Link Location" in Mozilla.

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA