API Falscher Datentyp

M

mgosx

Mitglied
Hallo zusammen,
ich bin gerade am Testen der neuen Api und habe 2 Probleme / seltsames Verhalten festgestellt:

1. Unterschiedliches Verhalten bei Datensatz und Datenquelle
Ich habe 1 Datenquelle und 1 Datensatz, in beiden ist ein Feld: istLieferbar als Bool definiert und wird durch eine Unterabfrage auf 0 oder -1 gesetzt.
Beim Endpoint der Datenquelle wird richtig true bzw. false zurückgeliefert.
Beim Endpoint des Datensatzes wird hingegen -1 bzw. 0 zurückgeliefert.

2. Falscher Datentyp (abhängig von Feldname)???
Ich hatte ein Feld AdrGewicht als Dezimal mit 2 NKS angelegt. Im Datensatz wird das Feld richtig als Dezimal ausgegeben, in der Datenquelle wird es als String ausgegeben. Wenn ich das Feld in der Datenquelle umbenenne in GewichtAdr wird es richtig als Dezimal ausgegeben.

Vielleicht hat jemand von Euch auch solche Probleme.

Gruss Mark
 
Heute eine weitere Besonderheit ...

Ohne Änderung im AppDesigner war (vielleicht ein Dienstneustart) auf einmal ein Dezimal-Feld ein Stringfeld.
Lösung: Feld in Datenquelle umbenennen, neu im Endpoint einfügen und es geht wieder. (Mal schauen wie lange)
 
Ich habe versucht die beiden Fälle nachzustellen:

Zu (1): Sowohl bei Datenquellen als auch bei Datensätzen geht bei mir -1 und 0 für boolesche Felder über die Leitung (mit Fiddler geprüft). Ich kann Ihre Beobachtung also nicht nachvollziehen. Verwendet man die Vorschau im AppDesigner wird bei beiden true und false angezeigt, was daran liegt, dass im AppDesigner der empfangene Payload (json) wieder in einen DataContainer anhand des Schemas deserialisiert wird.

Zu (2): Auch das kann ich nicht bestätigen. Für Werte von Dezimalfelder werden bei Datenquellen als auch bei Datensätzen Dezimalwerte übertragen. Eine Veränderung des Datentyps von Dezimal in String kann ich ebenfalls nicht beobachten. Mit dem Namen des Feldes, hat es nichts zu tun. Der Name wird nur für das Mapping zwischen dem Feld des Endpunktes und dem Feld in der Datenherkunft verwendet.

Wichtig bei der Vorgehensweise ist, dass man zuerst Datenquellen und Datensätze anlegen muss, danach die Endpunkte. Eine Veränderung der Datenschicht wirkt u.U. sich erst bei Neustart des ApplicationServers, da das Schema der Endpunkte im ApplicationServer gecacht und nicht bei jeder Anfrage neu erstellt wird.

Senden Sie bitte Ihre Metadaten Lösung an den Support oder hängen Sie sie bitte an einen evtl. bestehenden Vorgang an. Weitere Informationen zur Nachvollziehbarkeit wären ebenfalls hilfreich.
 
Leider ist die Metadaten Lösung sehr gross und verwendet auch ein paar benutzerdefinierte Felder und Tabellen, daher ist eine Weitergabe und Reproduzierbarkeit bei Sage recht schwierig.
Das Problem ist, dass die o.g. Fehler sich nicht alle reproduzieren lassen.
Letzte Woche haben wir die Lösung ausgerollt um es auch unabhängig vom Testsystem (und ohne häufige Änderungen) zu testen und zu nutzen.

Eine Sache hat sich im sich im Livebetrieb bestätigt:
- nach einer gewissen Zeit (irgendwas zwischen 8 h und 24 h, meistens am nächsten morgen festgestellt) hat sich von einem Endpunkt die Definition verändert, er liefert eine andere JSON-Datenstruktur.
- wenn man dann den Application Server Dienst neu startet oder den Cache neu aufbaut, wird auch die "richtige" JSON-Datenstruktur wieder zurückgegeben.
Hier die JSON-Daten:

Zuerst die fehlerhaften Daten:
JSON: 
{
    "$url": "https://sage.fischar.de:5493/sdata/ol/apiWarenausgang.xxx.Fischar/Fischar;1/eptWarenausgangListe.xxx.Fischar/",
    "$descriptor": "ol eptWarenausgangListe.xxx.Fischar",
    "$resources": [
        {
            "$updated": "2022-08-15T11:58:54+02:00",
            "$descriptor": "WarenausgangApi",
            "CustomFields": [],
            "matchcode": XXX Hauptanschrift",
            "gewicht": 104.4000,
            "belegdatum": "2022-08-04T00:00:00+02:00",
            "liefertermin": "2022-08-04T00:00:00+02:00",
            "istLieferbar": false,
            "lagerMemo": null,
            "inKommissionierung": 0,
            "adrGewicht": "0,0000",
            "belid": 1172213,
            "belegnummer2": "2022-15346"
        }
    ]
}



Nach Reorganisation sind sie wieder ok:
{
JSON: 
{
    "$url": "https://sage.fischar.de:5493/sdata/ol/apiWarenausgang.xxx.Fischar/Fischar;1/eptWarenausgangListe.xxx.Fischar/",
    "$descriptor": "ol eptWarenausgangListe.xxx.Fischar",
    "$resources": [
        {
            "$updated": "2022-08-15T12:02:48+02:00",
            "$descriptor": "WarenausgangApi",
            "CustomFields": [],
            "matchcode": "XXX Hauptanschrift",
            "gewicht": 104.4000,
            "belegdatum": "2022-08-04T00:00:00+02:00",
            "liefertermin": "2022-08-04T00:00:00+02:00",
            "positionenCount": 2,
            "istLieferbar": false,
            "lagerMemo": null,
            "inKommissionierung": 0,
            "adrGewicht": 0.0000,
            "belid": 1172213,
            "id": 1172213,
            "belegnummer2": "2022-15346"
        }
    ]
}

Fehler (immer die Gleichen):
Das Feld adrGewicht wird beim Auftreten des Fehlers in " gesetzt.
Es fehlen die Felder id und positionenCount.

Das Seltsame ist, dass nur ein Endpunkt und darin auch nur ein Feld (immer das selbe) betroffen ist.
Ich habe diesen gelöscht und mit neuem Namen angelegt (mit der selben Datenquelle), aber der Fehler tritt dennoch weiterhin auf.
Ich werde versuchen, diesen Endpunkt in eine eigene Lösung zu extrahieren und schauen, ob der Fehler dann auch noch auftritt. Wenn ja geht diese Lösung an Sage.

Aktuell helfen wir uns damit, den Cache im AppDesigner jeden morgen vor Arbeitsbeginn neu aufzubauen.

Korrektur:
- es sind mehrere Endpunkte betroffen (da diese verschachtelt aufgerufen werden, ist es mir nicht aufgefallen).
- es sind jedesmal beim jeweiligen Endpunkt die gleichen Felder, die fehlen oder verändert sind.
 
Zuletzt bearbeitet:
Hat sich die Schema-Datei (xsd) über Nacht enebfalls geändert bzw. gibt es eine neue Version?

Sie ist in folgender Datei zu finden.
%ProgramData%\Sage\ServerCache\<Datenbank>\<Mandant>apiWarenausgang.xxx.Fischar.<Sage100-Version>.<Metadata-Revision>.<Metadata-ChangedCounter>.<Database-Schema-Revision>.xsd

Sage100-Version:
z.B.: 90

Metadata-Revision:
Aktuelle Version der Metadaten-Struktur

Metadata-ChangedCounter:
Wert aus
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Sage\Office Line\9.0\Options\MetaDataDataRevision
Wird bei jeder Änderung an Metadaten hochgezählt.

Database-Schema-Revision:
"Value" aus Tabelle USysSetup
Mit Bedingung "Tree='Admin' AND Token='SchemaRevision' AND Property='RealTimeData'"
Wird bei jeder schematischen Änderung der Datenbank hochgezählt.

Gibt es mehrere Datenbanken mit/ohne die neuen Tabellen und Felder?
Es scheint nur Felder zu betreffen, die nicht in einer Standard-Sage100-DB existieren

Können Sie dem Customer-Support bitte die Metdaten-Lösung und die Anlageskripte für Tabellen und Felder zur Verfügung stellen.
Wenn die Lösung zu groß ist, dann bitte nur die relevanten Teile.
 
Es sind in anderen apiEndpoints auch Standardfelder betroffen, u.a Artikelnummer und BelId.

Das Problem tritt garantiert jeden Morgen auf.
Und nach der Reorganisation hält es dann für diesen Tag.
Abends gegen 24:00 geht es noch, morgens um 05:00 kommt der Fehler ( vorher nicht getestet).

Das Testen ist schwierig, da nur 1 Versuch alle 24h möglich ist. Werde aber heute und morgen früh die Revisionsnummern auslesen.
Und auch versuchen alle Abfragen und Api in eine neue Lösung zu kopieren.

Gibt es eine Möglichkeit per powershell den Metadatencache neu aufzubauen?

Dies wäre zumindest ein Workarround.
 
Ich glaube, ich habe die Ursache des Fehlers gefunden...

Ich verwende externe Feldnamen und bei den Problemfelder sind die Feldname und externer Name unterschiedlich.
Solange nur Gross- und Kleinschreibung betroffen sind, klappt alles.
Sobald jedoch der externe Name abweicht, gibt es nach einer gewissen Zeit Probleme mit dem Datentyp oder das Feld wird komplett vergessen.

Ich habe einen Teil meiner Abfragen/Endpoints umgestellt, so dass diese nun einwandfrei funktionieren, die nicht umgestellten Abfragen/Endpoints hingegen verursachen den Fehler!
 
Guten Morgen,

ich weiß nicht mehr wie relevant es ist, aber der Metadatenchache lässt sich per Powershell neu aufbauen.
Ich verwende dafür immer:
Code: 
Start-Process -FilePath "$SageSharedPath\Sagede.Shared.RealTimeData.Metadata.Exchange.exe" -Verb runAs -ArgumentList "/action=RebuildMetaDataCache" -Wait
 
Super vielen Dank,
mit ein wenig Glück sollte das Problem zwar erledigt sein, aber für Automatischen ist der Befehl auch in Zukunft eventuell gut.
 
Ich kann es jetzt nachvollziehen. Es geschieht, sobald der ApplicationServer gestoppt und neu gestartet wird und die o.g. xsd-Datei vorhanden ist. Löscht man sie vor dem Server-Neustart, funktionieren die Felder mit externen Namen auch. Ich werde das korrigieren.
 
Den genauen Termin, kenn ich nicht, aber die Regressionstest starten gerade. Die Auslieferung sollte dann noch im August erfolgen.
 
I know, aber in der WD gibt es ja parallel dazu immer "Hotfix Sage 100 (9.0.4.x) Stand xx.xx.20xx (Build xxxx) per LiveUpdate für Kunden ohne Internet"
 
Die Bereitstellung des Offline Update via WDB erfolgt laut Support i. d. R. immer einen Tag später, da die WDB den Eintrag erst mit Verzögerung anzeigt/listet. Daher ist es normal, dass das Online Update früher verfügbar ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben