Hilfestellung zum MDE-Toolkit

Vorbemerkungen

Generell ist zu sagen, dass es in diesem Bereich 3 Quellen für die Ursache des Problems geben kann:

• Technik
• Anpassung für die Clients
• Datenbankprobleme in Professional-ERP

Dieses Dokument ist keine Anleitung ein MDE-Projekt in Betrieb zu nehmen, sondern setzt eingentlich voraus, dass die komplette Installation erledigt war und auch das Produkt schon einen „Regelbetrieb“ hinter sich hat. Also nur auf Probleme eingeht, die durch Veränderungen, Fehleingaben und technische Probleme eingeht.

Vokabular

Um von denselben Begrifflichkeiten zu sprechen, sollen hier die Grundlegenden Begriffe erläutert und gegeneinander abgegrenzt werden.

Probleme beim Start

Fehler gleich beim Start

Sofort nach dem Start von Professional-MDE kommt eine Fehlermeldung und das Programm wird wieder geschlossen

Hier liegt der häufigste Grund darin, dass es die SWSMDE.ini nicht gibt, oder bei einer Verweis-Ini diese nicht existiert oder auf einem Laufwerk liegt, das momentan nicht im Zugriff ist.

Keine Verbindung mit dem Server

Das Programm versucht immer wieder eine Verbindung mit dem Server herzustellen, springt aber immer wieder die Meldung keine Verbindung zurück.

Hier gilt es zuerst den verantwortlichen Webservice aus der SWSMDE.ini heraus zu finden. Die verantwortliche Zeile ist WEBSERVICE=.

Den String ab dem Gleichheitszeichen kopiert man in die Zwischenablage.

Nun startet man einen Webbrowser und versucht die Seite des Webservice (aus der Zwischenablage) aufzurufen. So sieht man, ob das Gerät denn den Webservice erreichen kann.

Bei Erfolg bekommt man je nach Version des Webservice die folgende Seite im Browser angezeigt.

Sollte hier ein Problem vorliegen, so kommt eine Seite wie die Folgende:

In diesem Fall wäre der erste Schritt zu versuchen den IIS (Internet-Information Server) neu zu starten.

Hierzu ist die Eingabeaufforderung als Administrator zu starten.

Der Befehl für den Neustart des IIS ist:                  IISRESET

Derselbe Befehl kann auch gesplittet werden in einen Stopp (IISRESET /STOP) und in einen Start (IISRESET /START)

System bleibt immer bei der ersten Tabelle stehen

Der Client baut die Verbindung auf, bleibt aber gleich bei der ersten Tabelle stehen und macht lange nichts, verbindet sich neu und steht erneut bei der ersten Tabelle.

In diesem Fall funktioniert der Handshake zwischen dem Client und dem Webservice nicht.
Eine mögliche Ursache sind die INI-Einstellungen für den Webuser und das Webpasswort. Die Einstellungen hierfür müssen in beiden INI’s (Client und Webservice) identisch interlegt sein.

Synchronisations Abbrüche

Synchronisations Abbruch - nachvollziehbar immer an derselben Stelle

Syncabbrüche in einzelnen Tabellen kommen immer durch nicht sauber formatierbare XML-Strings, die für den Austausch zwischen Client und Webservice zum Einsatz kommen.

Als Ursache kommen zu meist:

• Sonderzeichen in Texten
• Ungültige Datumswerte (kleiner 01.01.1900 oder größer 31.12.2200)
• Werte, die die Formatvorgabe überschreitet (zB bei N(5,2) der Wert 1234,5)

Das Fehlerbild ist, dass immer an derselben Tabelle / Stelle die Statuszeile gelb wird:

Wichtig hier sind folgende Informationen:

• Welche Tabelle
• Welches ist der Zeitstempel, ab dem Versucht wird Tabelle noch zu synchronisieren

Vor allem der zweite Wert ist bei PC-Clients schwer herauszufinden, da der Sync zu schnell geht. Aus einem Infodialog geht das nicht hervor, da dies pro Gerät und Abfrage unterschiedlich ist. Der Wert könnte aus der Professional-MDE Tabelle MDETABLE aus dem Feld SYNTIMEST ermittelt werden. Dies ist im Normalfall umständlich bis unmöglich.

Eine Möglichkeit ist es die SQL-Protokollierung auf dem Webservice einzuschalten.

Hier ist der SWSWEB.INI folgende Zeile mit passendem Ziel einzutragen bzw. zu aktivieren:

PROT=E:\TEMP\WEB.TXT

In der Tabelle wird dann das Problem protokolliert. Leider aber nicht der Datensatz.
Wertet man die entsprechende Zeile aus, so hat man das relevante Datum ab dem es zu den Problemen kam.

Methode 1: Sichtkontrolle

Am besten kopiert man sich den String aus dem Protokoll komplett heraus und lässt das SQL-Statement im DBC ausführen.

Diese Methode funktioniert nur, sofern die Datenmenge übersichtlich ist und wenn der Fehler erkennbar ist. Es gibt eben auch unsichtbare Sonderzeichen.

Methode 2: Empirisch das Problem finden

Alternativ kann man auch versuchen das Feld zu bestimmen, indem man aus der Abfrage in der MDE-Verwaltung die Felder schrittweise verringert. Sobald man das fehlerhafte Feld entfernt hat funktioniert der Sync wieder. Nach dem erneuten Einfügen bleibt der Sync wieder stehen.

Diese Methode macht aber nur bei kleinen Tabellen mit vielen Feldern Sinn, da ja mit jeder Änderung an der MDE-Abfrage die Tabelle neu aufgebaut wird. Sind hier viele Tausend Sätze drin, so wird diese Methode sehr zeitaufwändig!

Methode 3: Webservice nutzen

Hierzu muss man auf dem Server, wo der Webservice installiert ist diesen aufrufen. Das geht dann auch mit http://localhost/SWSSeb/SWSWebService.asmx (Standardinstallation vorausgesetzt)

Hier wählt man die Funktion GetCursor aus.

Den Testdialog füllt man nun mit den aus dem Web-Protokoll ermittelten Daten aus. User und Passwort entnimmt man der INI des Webservice.

Hier ist das Verhalten nun etwas unterschiedlich, je nach Fehlerart:

Ist es ein Numerischer Überlauf, so wird nichts angezeigt. Man kann aber durch Feldreduktion auf das Feld kommen. Über die Zeiteinschränkung hat man dann nu eine kleine Zahl von zu untersuchenden Datensätzen. Der Fehler ist in der Regel dann schnell sichtbar.

Bei Sonderzeichen werden die Daten dann angezeigt, allerdings schlägt die Formatierung in das typische XML-Aussehen fehl. Der letzte angezeigte Datensatz (in Sonderfällen auch der darauffolgende nicht mehr angezeigt) ist dann der Datensatz, der die Probleme verursacht.

Synchronisations Abbruch - An verschiedenen Tabellen / Stellen

In diesem Fall wird die Statusleiste immer mal wieder gelb. Auch wird nicht immer dieselbe Tabelle angezeigt. Zeitweise läuft der Sync auch wieder komplett durch.

Der Grund ist hier immer in der aktuellen Last des Webservers zu suchen. Dies muss man sich so vorstellen. Die Anfragen werden vom Webservice zwar parallel in mehreren Tasks abgearbeitet. Dauern aber einzelne Prozesse zu lange, so kann es zu einem „Stau“ der Abarbeitung kommen. Das heißt, der Client bekommt in der Zeit, auf den er auf die Antwort wartet kein Feedback. Dies zeigt er dann als Syncabbruch an.

Sollte dies vermehr auftreten, so kann man die Timeout-Einstellungen des überprüfen und ggf. an die Gegebenheiten des Webservice anpassen.
Mögliche Parameter in der INI wären:

IIS

Hohe Last des IIS

Sollte der IIS eine hohe Last aufweisen führt ein Neustart des PC / Servers zur Lösung.

Sonstige Fehlerquellen

Warum muss MDEID eindeutig und numerisch sein

Die einzelnen MDEID in der INI der Clients müssen eindeutig pro Gerät sein, denn darüber identifiziert die Jobverarbeitung,

• woher die Datensätze stammen und wie diese zusammengehören
• wenn Gruppen definiert wurden, welcher Prozess für dieses Gerät verantwortlich ist

Warum sollte die MDEID dreistellig sein

Die Vorgabe, dass die MDEID 3-stellig ist nicht notwendig. Gibt aber die Möglichkeit genügend MDE in Gruppen zu verwalten.

100-299                MDE
300-499                ADM-Tablets
900-999                Interne Test-PC

Allerdings muss man in dem Fall mit der Zahl 100 beginnen. Alle Nummern darunter würden durch das Abschneiden der führenden Null wieder die Gefahr beinhalten, dass zwei MDE verwechselt werden können:

Aus 21 würden die ID 2100000… erstellt
Aus 210 würden die ID 21000000… erstellt.

Wo definiere ich die MDEID

Die MDEID wird auf jedem Client in der SWSMDE.INI definiert.

Zudem können zusätzliche Informationen auch in der MDE-Verwaltung hinterlegt werden.
Hier werden die Informationen auf dem 3. Register „Geräte“ eingetragen und Sync-Informationen dargestellt.

Dort wird das Gerät mit identischem Namen und Nummer angelegt. In einem Beispiel wäre das zB der Name 500 und die Nummer 500.

Bezüglich der weiteren Angaben ist nun nur noch die Gruppe wichtig. Diese entscheidet über den Kommunikationsweg der Jobverarbeitungen.
Das ist beim Einsatz von Gruppen zwingend notwendig vor der Erstsynchronisation des neuen MDE bzw. Tablets.

Würde am Tablet nachträglich zur ersten Sync die MDEID in der INI verändert werden, dann würde der Datenbestand und auch das Letzte Syncdatum eventuell gar nicht mehr zusammenpassen. In dem Fall ist immer das MDE komplett neu aufzubauen.