Änderung an PUT /Documents/{documentKey}/Positions/{documentPositionIdentifier}

[ghost]

Hallo liebes SL-API-Team,

leider musste ich feststellen, dass mit SL-Version 22.1.6 das Property StoreInformation ersatzlos verschwunden ist. Es ist nun nicht mehr möglich, den Lagerplatz einer Position per API zu verändern.

Unserer Meinung nach, ist es ein Unding, bestehende APIs zu verändern. Natürlich können Fehler behoben und der Funktionsumfang erweitert werden. Aber bestehende Funktionen einer API-Route, die für sehr viel Zeit und Geld in diverse Projekte integriert wurden, können nicht einfach gestrichen oder geändert werden. Wer kommt denn für den Aufwand auf, dies überall anzupassen? Für solche gravierenden Änderungen sollte eine neue Version (v2) der API bereitgestellt werden, um das weitere Nutzen der "alten" Funktionen zu ermöglichen.

Können Sie mir dennoch weiterhelfen und mir ein Tipp geben, wie ich den Lagerplatz einer Position ändern kann? Ist es möglich, dass diese API-Route wieder die StoreInformation zurück erhält?

VG Morris

[MatthiasGuse]

Hallo,

wir sind dabei den Wegfall der Funktion nachzuvollziehen.

Können Sie bitte kurz erklären, was Sie konkret in Ihrer Anwendung tun? Haben Sie einen lagernden Beleg? Wollen Sie bei einer bereits getätigten Lagerung den Lagerplatz ändern? Oder wollen Sie einfach nur in der Belegposition einen Lagerplatz eintragen, unabhängig einer Lagerung?

Viele Grüße

[ghost]

Hallo,

danke für die Rückmeldung.

In unserer Anwendung, wird ein Beleg mit den Positionen mit der Menge 0 und ohne Lagerplatz erstellt, da diese Informationen zu dem Zeitpunkt noch nicht bekannt sind. Anschließend weist ein Lagermitarbeiter mit einem mobilen Gerät die Menge und den Lagerpatz zu.

VG Morris

[MatthiasGuse]

OK.

Ich denke dann könnten Sie die Funktion POST /Documents​/{documentKey}​/Positions​/Store nutzen. Wenn Sie von Menge 0 aus kommen, sollte das meiner Meinung nach funktionieren. Das Model der Lager Informationen ist identisch zu dem, was Sie bisher genutzt haben: DocumentPositionStoreInformationUpdate.

Viele Grüße

[MatthiasGuse]

Noch kurz zur Erklärung der Funktion POST /Documents​/{documentKey}​/Positions​/Store:

Mit dieser Funktion wird die angegebene Position um die angegebene Menge erhöht. Es ist also nicht die absolute Positionsmenge anzugeben, sondern nur die Menge um die die Position erhöht werden soll.

[ghost]

Hallo Herr Guse,

zunächst möchte ich mich für Ihre robuste und schnelle Hilfe sehr bedanken. Wir und auch der betroffene Kunde wissen das sehr zu schätzen. Hierfür ein großes Lob. ;-)

Ich konnte mit Funktion POST /Documents​/{documentKey}​/Positions​/Store das Problem lösen.

Dennoch würde ich mir wünschen, dass Änderungen an der API abwärtskompatibel sind. Alternativ kann eine 2. API parallel entwickelt werden. Die Kunden haben verschiedenste Versionen der SelectLine im Einsatz. Es ist dann nur mit extremen Aufwand möglich, Software zu entwickeln, die bei einen möglichst großen Kundenkreis funktioniert. Weiterhin entstehen nicht kalkulierte Kosten, wenn bei einem SL-Update die Software angepasst werden muss.

Ich hoffe dass dies in Zukunft Berücksichtigung findet und möchte mich nochmals für Ihre Hilfe sehr bedanken.

VG Morris

[konrad79]

Wir können Ihr Problem mit den Updates aus Entwicklersicht nachvollziehen. Allerdings haben wir die gewünschte Versionierung der API exakt durch die Programmversionen realisiert. Bei uns heißen die APIs halt nicht "v1" oder "v2" wie man es von zentral gehosteten APIs wie Google&Co kennt ... sondern "v21.1" und "v22.2" etc.

Der große Unterschied zwischen zentral gehosteten APIs und deren Versionierung zu uns ist, dass man bei zentral gehosteten APIs als Entwickler/Nutzer keinen Einfluss auf die Zeitpunkte der Updates hat - daher werden dort meist mehrere ältere Versionen einer API über einen längeren Zeitraum unterstützt. Bei uns hat ja jeder Kunde es selbst in der Hand, wann er eine Version und damit die API updatet.

Dennoch versuchen wir, Routen nicht einfach von einer auf die nächste Version abzukündigen. Vielmehr markieren wir Routen als "veraltet" oder "depricated", die wir planen zu entfernen oder durch neue Routen zu ersetzen. Dies versuchen wir jetzt schon immer mit einigen Versionen Vorlauf in den technischen Dokumenten anzukündigen. Damit weiß man schon weit im Voraus, dass und wie man seine Anwendungen auf Basis der API anpassen muss für zukünftige Versionen.

Danke für Ihr Feedback Konrad Mühler

[Micha-Richter]

Hallo Konrad,

um es direkt und offen zu schreiben: ich finde deine Argumentation der "API-Versionierung anhand der SL-Versionsnummer" haarsträubend und vollkommen an der Realität vorbei :( Kein Kunde wird akzeptieren, dass er alle 3 Monate seine externe Programmierung überarbeiten oder zumindest überprüfen lassen muss, nur weil er ein Update der SL einspielt. Von den Kosten für dann vielleicht notwendige Anpassungen und Aktualisierungen der beteiligten externen Systeme mal ganz abgesehen.

Mit der vorherigen Abkündigung bestehender Routen geht ihr doch einen guten Weg! Wenn ihr uns Externen dann den entsprechenden Vorlauf lasst (würde ich persönlich bei 4 Versionen = 1 Jahr sehen), kann sich jeder drauf einrichten. Dafür hat man seine Kunden ja auch in der Wartung.

Es wäre schön, wenn ihr da mitgehen könntet und uns damit auch eine tolle Wertschätzung entgegenbringen würdet.

Viele Grüße Micha

[konrad79]

Hallo Michael,

dann haben wir uns da missverstanden: Der von dir beschriebene Weg ist genau der, den wir versuchen zu gehen! Nicht von jetzt auf gleich Routen abkündigen sondern mit Vorlauf von mehreren Versionen entsprechend als deprecated markieren und sie dann erst auslaufen lassen. Das uns da manchmal Sachen durchrutschen und auch Fehler passieren, liegt in der Natur der Softwareentwicklung. Da stellt die API keine Ausnahme dar. Wir glauben aber, dass wir mit Tools wie dem API-Update-Helper und der Doku der API generell euch da gute Tools an die Hand geben, diesen Prozess transparent und nachvollziehbar für euch zu gestalten.

Und es ist ja nun auch nicht so, dass wir zu jeder Version alles immer neu machen und breaking changes einbauen. Ja, die API unterliegt einer Evolution und es werden immer wieder neue Dinge hinzukommen, Dinge umgebaut werden und Dinge wegfallen. Das passiert mal aus der API selbst heraus - oft aber auch durch Anpassungen an den Programmen hinter der API, meist der Warenwirtschaft.

Wenn wir z.B. mit einer Warenwirtschaft ein neues Lager ausliefern, dann werden auch die API-Funktionen, die davon betroffen sind, entsprechend angepasst sein müssen. Und dann können wir nicht noch 1 Jahr lang in allen neuen Versionen auch das alte Lager unterstützen. Das kennt ihr aber auch bei Anpassungen in den Programmen seien es Maskenanpassungen, Makros oder die Toolbox.

Wir versuchen unser Bestmöglichstes, die jeweiligen Änderungen umfassend zu dokumentieren, euch darüber zu informieren - und bei großen Änderungen dies auch weit im Vorfeld zu kommunizieren.

Darüber hinaus hoffen wir (und sehen das auch hier), dass wir euch auf dem Wege der Diskussion hier im Forum unkompliziert weiterhelfen können.

Viele Grüße Konrad

[Micha-Richter]

Hallo Konrad,

danke für deine schnelle und ausführliche Reaktion!

Vielleicht noch als Anmerkung dazu: ich denke, dass viel Stress einfach dadurch entsteht, dass die API so "dicht" an den Interna der Wawi hängt und deren Strukturen z.T. extrem kleinteilig offenlegt. Dass sich dadurch häufige Änderungen ergeben, ist einleuchtend. Aus meiner Sicht(!) wäre es besser, über die API eine Abstraktion der Wawi-Objekte und deren Funktionen anzubieten und damit die Schnittstelle viel länger stabil zu halten. Das käme sicher beiden Seiten entgegen. Ein neues Lager in der Wawi muss dann keine breaking changes in der API verursachen, da sich die grundlegenden vorhandenen Mechanismen nicht ändern (ihr nehmt ja vermutlich auch keine Funktionalität weg, sondern baut im Gegenteil weiter aus).

just my usw ;)

Micha

[MatthiasGuse]

Ich mache dann hier mal zu ;-)

Danke für eure Kommentare!

Viele Grüße