Webservice und Datentyp Option

Hallo zusammen,

bin ich eigentlich der erste der auf die Falle des Datentyps Option reingefallen ist?

Nehmen wir Tabelle 27 Item, das Feld 21 Costing Method. Wird das über einen Pagewebservice veröffentlicht gibts als mögliche Auswahl im Webservice "FIFO", "LIFO", ... soweit korrekt.

Hat man nun beim Anlegen der Option in der Tabelle statt "FIFO,LIFO,.." nun "FIFO, LIFO, ..." stehen kommt als Auswahl im Webservice "FIFO", "_LIFO", "_..." raus.

In NAV selber ist das ja wohl nicht so relevant, da in der DB ja eh nur die Index-Nr. gespeichert wird.

Dumm wird es v. a. wenn irgendwann einer mal die Option in der Tabelle umbenennt und aus "FIFO" dann "First In First Out" wird. Das fängt dann der Entwickler der den Webservice nutzt an den Fehler zu suchen.


Volker

Aber was willst du damit sagen? Es ist doch immer problematisch, wenn man vorhandene Options umbenennt. Deine Feststellung lautet also: wenn jemand auf der Design-Ebene Quark produziert, haben andere unter Umständen Streß damit. Das ist allerdings schon immer so.

Im speziellen Fall der WebServices: in der WSDL sind nicht umsonst die Optionswerte enthalten. Da ich es aber nicht praktikabel finde diese jedes Mal abzufragen, habe ich mir angewöhnt zu prüfen, ob die von mir gewünschten Werte vorhanden sind. Bei einem WebService gehe ich davon aus: wenn jemand die Option 2 auf Option 3 verschiebt, dann wird das schon seinen Grund haben und meine Anwendung, die den WebService anspricht verwendet automatisch die geänderte Option. Das gilt natürlich für Input über einen WebService.

Beim Konsumieren eines WebService sollte man immer eine Whitelist mit den erwarteten Werten anlegen. Sollte dann jemand die Option umbenennen, schlägt der Fehler sofort an der richtigen Stelle auf. Whitelists sind bei solchen Interaktionen eh immer Pflicht.

Also eigentlich sehe ich jetzt nicht das Problem darin. Aber vielleicht habe ich irgendeinen Aspekt auch noch nicht richtig erfasst.

Hi Tim,

1. Problem: Führendes Leerzeichen in einem der Optionwerte ergibt im Webservice "_"
2. Problem: Umbennen eines Wertes führt auch zu einem Umbennen der im Webservice angebotenen Auswahlmöglichkeiten, wobei der Index der WErte ja gleich bleibt.
3. Problem (Das ist jetzt neu): Wenn ich eine Option (Optionstring = 1kg,1l,1m3,1m2,100g,100ml) in der Tabelle anlege bekomme ich im Webservice folgende Möglichkeiten: _x0031_00g, _x0031_00ml, _x0031_kg, _x0031_l, _x0031_m, _x0031_m2, _x0031_m3. Die Logik dahinter erschließt sich mir jetzt aber noch nicht. und mit solch kryptischen Werten kann ich ja nur schwer jemanden arbeiten lassen.

Volker

1. Problem: Führendes Leerzeichen in einem der Optionwerte ergibt im Webservice "_"

Nicht nur das führende Leerzeichen, sondern alle Leerzeichen werden ersetzt. Ebenso wie die Zeichen ."\/', die üblicherweise auch unter Datei, Datenbank, Ändern auf dem Reiter Integration im Feld Zeichen entfernen angeführt sind. Die Frage ist doch: warum soll überhaupt ein Leerzeichen am Anfang eines Optionstrings stehen. Ist doch absolut unüblich (es sei denn es ist das einzige Zeichen und damit eine "leere" Option).

2. Problem: Umbennen eines Wertes führt auch zu einem Umbennen der im Webservice angebotenen Auswahlmöglichkeiten, wobei der Index der WErte ja gleich bleibt.

Aber das ist doch auch gut und richtig so. Oder was würdest du erwarten? Du möchtest doch auch, dass ein neuer Wert im WebService erscheint, oder nicht? Wenn "FIFO" bisher Wert 2 ist und nach einer Änderung der Datenbank Wert 3 ist, dann erwarte ich von deinem Programm, dass es den WebService vor der Änderung mit Wert 2 und nach der Änderung mit Wert 3 befüllt. Da sollten aus meiner Sicht niemals feste Integerwerte verwendet werden. Macht man ja innerhalb NAVs auch nicht.

3. Problem (Das ist jetzt neu): Wenn ich eine Option (Optionstring = 1kg,1l,1m3,1m2,100g,100ml) in der Tabelle anlege bekomme ich im Webservice folgende Möglichkeiten: _x0031_00g, _x0031_00ml, _x0031_kg, _x0031_l, _x0031_m, _x0031_m2, _x0031_m3. Die Logik dahinter erschließt sich mir jetzt aber noch nicht. und mit solch kryptischen Werten kann ich ja nur schwer jemanden arbeiten lassen.

Das würde ich tatsächlich für ein Bug halten, da Zahlen nur in hexadezimalen Unicode konvertiert werden, wenn sie am Anfang stehen (wenn du einen Buchstaben vor deine Optionen packst, sieht alles normal aus). Aber vielleicht gibt es auch etwas entsprechendes in der XML- bzw. WSDL-Konvention. Müsste ich jetzt nachforschen. Andererseits ist es ja auch kein Problem, solange man diese Logik kennt und wieder gegen eine Whitlist prüft.
Ich könnte mir vorstellen, dass hier intern geprüft wird, ob das erste Zeichen a..z bzw. A..Z ist und wenn nicht, wird es konvertiert.

Hi Tim,

bei Problem 2 bin ich anderer Meinung. NAV speichert ja nicht die Bezeichnung der Option in die Datenbank, sondern nur den Index. Folgendes passiert nun: Der Optionstring "FIFO,LIFO" wird innerhalb NAV geändert in "FirstIn,LIFO". Das ändert an den Daten in der Datenbank nichts. Dort steht in den Tabellen nachwievor 0 bzw 1. Nur für den Anwender hat sich der angezeigte Name geändert. Nehmen wir nun an der Optionstring wird erweitert und heitßt nun "FirstIn,LIFO,FIFO" (ist sinnfrei, bitte nur als Demo verstehen). Damit hat FIFO den Index 2. Selbst wenn Du nun gegen eine Whitelist in deinem Program prüfst, bekommt man dort evtl. Index = 0 für FIFO statt korrekt Index = 2.

Zu Problem 3 bin ich einen kleinen Schritt weiter: Der Datentyp Option in NAV wird als Enum in .Net übersetzt. Soweit ich das bis jetzt sehe, können Enum-Werte (per Design) nicht mit Zahlen beginnen. Evtl. muss man sich in dem Fall das führende Leerzeichen im Optionstring, das zu einem "_" in den Enum-Werten übersetzt wird zu Nutze machen.

Volker

Edit: das mit dem führenden Leerzeichen klappt. Aus " 100g" wird nun "_100g"
Ähnliches könnte auch für das ein oder andere Sonderzeichen in den Optionstrings gelten, wenn man http://msdn.microsoft.com/de-de/library/81ed9a62.aspx als Grundlage ansieht.

Hmm, irgendwie sehe hier kein "Problem". Also zumindest kein anderes als das, was man eh in jedem Entwicklungsbereich hat. Die meisten gängigen Programmiersprachen (die ich kenne) erlauben keine Sonderzeichen, Zahlen oder ähnliches an erster Stelle eines Bezeichners. Deshalb die Umsetzung in den Unterstrich oder in die hexadezimale Unicode Repräsentation der Zahlen, wie beispielsweise _x<2 byte hex wert>_.

Das "Problem" 2 gibt es ebenfalls überall. Habe ich 2 unabhängige Definitionen eines Parameters (gerne Enum) und rufe die Funktion einer unabhängig kompilierten DLL mit einem erweiterten oder geänderten Enum auf, dann funktioniert das auch falsch.

Wenn jemand die Verpackung ändert, erkenne ich auch erst beim probieren, dass mir jemand Bananenmilch in meinen Vanillemilchbecher gepackt hat. Ich trinke sie dann vielleicht auch, aber komisch ist das dann schon...