montanajava
commented
6 months ago LIST_d_DRA_2023-09-19_eCH-0263_V1.0.0_Rückmeldungen_öffentliche_Konsultation.docx Vom 18.10.2024:
Hallo Alican, liebe Projektmitarbeitende aus dem Projekt digiFlux
Vielen Dank für Eure Anfrage zum Thema metaIngredient und typeOfProduct.
Die Arbeitsgruppe hat in der Sitzung von 2023-09-19 auf eine Anfrage von Ryan (Feedback 2)
Produkt HofRec: Auf Stufe Produkt HofRec wird noch ein Attribut benötigt, in dem bei betriebsspezifischen Produkten die ID des Standardprodukt eintragen werden kann. Vorschläge zur Benennung:
- metaProduct (Aktuelle Benennung in der digiFLUX Umsetzung)
- manureFertilizerReferenceProduct
folgenden Vorschlag:
Zusätzliche Felder: typeOfProduct (STANDARD, FACILITY_SPECIFIC, META_PRODUCT), Referenz (bei typeOfProduct = FACILITY_SPECIFIC auf STANDARD referenzieren, bei STANDARD auf META_PRODUCT referenzieren), choice zwischen ingredient / metaIngredient.
sowie auf Feedback 4
Im Produktkatalog digiFLUX werden je HofRec Produkt minimal und maximalwerte je Inhaltsstoff definiert (0-1). Diese Werte wurden nicht in den eCH aufgenommen, mit der Begründung, dass dies Produktkatalog-interne Attribute sind und nicht in den Standard gehören. Unser Vorschlag ist aber, diese doch aufzunehmen. So könnten die Attribute auch via Schnittstelle an FMIS zur Verfügung gestellt werden und diese können die min / max Werte beim Erstellen von neuen Produkten in ihren Applikationen berücksichtigen. Wenn es für Produkte keine Min / Max werte gibt, bleiben die Felder leer.
folgenden Vorschlag gemeinsam erarbeitet:
Vorschlag: Zusätzliche Felder: typeOfProduct (STANDARD, FACILITY_SPECIFIC, META_PRODUCT), Referenz (nur bei typeOfProduct = FACILITY_SPECIFIC), choice zwischen ingredient / metaIngredient. facilitySpecific und required in neues Element metaIngredient zügeln. Zusätzlich min/max/default in metaIngredient. Erklären: Irgendein Produkt, das vom Benutzer angepasst wird, ist FACILITY_SPECIFIC.
Die Vorschläge wurden gemeinsam erarbeitet und einstimmig angenommen. An den Sitzungen waren die Vertreter vom digiFlux-Projekt Anja und Ryan anwesend.
Die folgenden mir bekannten UseCases werden hiermit abgedeckt:
- Validierungen bei der Erstellung von betriebsspezifischen Produkten (typeOfProduct=FACILITY_SPECIFIC_PRODUCT). Die Validierungsregeln können durch Schnittstellen an FMIS gesendet werden.
- Erstellung eines Standardprodukts, d.h. ein Produkt bei dem Standardwerte, die vom BLW definiert werden, übernommen werden. Dies kommt bei dem Fall zum Einsatz, wo ein/e Bewirtschafter/in nicht sein/ihr eigenes Produkt definieren möchte (typeOfProduct=STANDARD_PRODUCT).
- Schaffung und Pflege von Produkttemplates (typeOfProdukt = META_PRODUCT). Ein MetaProduct erlaubt die Definition:
- Von Ingredients, die pflichtmässig vorhanden sein müssen
- Von Ingredients, die optional sind
- Von jeweiligen Min-, Max-, und Default-Werten
- Von der zulässigen Einheit
- Alle Produkte egal welchen Typs unterliegen einem Lifecycle, wo die Gültigkeit (von/bis) definiert wird.
Die Arbeitsgruppe nahm darüber hinaus Feedback entgegen, wo die die Verwendung des bereits vorhandenen Template-Attributs «required» bei Nicht-Template-UseCases zu Verwirrung führte. Min, Max und Default wären ebenso im gleichen Sinne problematisch.
Die Anregungen aus dem Projekt digiFlux und die daraus erarbeiteten Vorschläge beinhalten folgende Vorteile:
- Klare Trennung zwischen Definition und Implementierung (vergleichbar wie Klasse und Instanz, Tabelle und Record, XSD und XML in anderen technischen Domänen).
- Beseitigung der Unklarheiten
- Ermöglichung leichterer Verifizierung je nach Fall
- Entfernung von Attributen aus der Entität Ingredient, die für Produkte anderer Produktfamilien nicht zum Tragen kommen und auch dort bei den Lesern zu Verwirrung führten.
Der Nutzen der Anpassung ist einerseits die Ermöglichung einer Validierung, wie Du korrekt sagst. Darüber hinaus ist die klare Kommunikation des Zwecks eines jeglichen Attributs ein Anliegen gewesen. Es ist meine Meinung, dass diesem Anliegen mit dem Input von Ryan und dem daraus erarbeiten Vorschlag entsprochen wird. Es ist nicht unwichtig zu erkennen, dass es einen wesentlichen Unterschied zwischen ManureRecyclingProducts diverser Typen gibt. Der Zweck eines jeden Typs soll auf Anhieb erkennbar sein. Diese Unterschiede existieren vermutlich bei Betriebsmitteln anderer Produktfamilien, aber wir sehen sie nicht, weil die Herkunft in Systemen ausserhalb von digiFlux herrührt. Diese Unterschiede werden mit dem Vorschlag explizit ans Licht gebracht, anstatt implizit nur durch das Vorhandsein und Nichtvorhandensein eines Attributs und durch Lesen der Dokumentation erkennbar belassen. Die Dokumentation wird in diesem Sinne um einiges leichtgewichtiger und schnittiger.
Zusätzlicher Background: Bei Betriebsmitteln überhaupt haben wir bekanntlich Entitäten pro Productfamily geschaffen, obwohl wir auch dort ursprünglich versuchten, alles in einer Entität unterzubringen. Die Schwierigkeiten im Umgang mit unterschiedlichen Anforderungen an die Kardinalität der Attribute (null (unter bestimmten Umständen), not-null (unter anderen Umständen)), und die wuchtig werdenden Attributenbeschreibungen wogen uns dazu, sie zu unterteilen. Dieser Architekturansatz wurde nun bei Ingredient verwendet.
Ich weiss jedoch auch ganz genau, dass man praktisch alles so oder so lösen kann. Ich habe verstanden, dass diese Attribute und Funktionalität beim digiFlux-Produktkatalog in der einen Entität StandardProduct untergebracht werden. Das Projekt digiFLUX wünscht nun, die in der Arbeitsgruppe erarbeitete Lösung erneut anzupassen, was wir selbstverständlich (in Absprache mit der Arbeitsgruppe) tun können. Unsere Empfehlung ist aber die Verwendung der in der Gruppe erarbeiteten Lösung.
Falls wir etwas falsch verstanden haben, können wir auch gerne ein kurzes Meeting organisieren, um das Thema zu besprechen.
Ich danke für die Geduld, bis hierhin gelesen zu haben.
Viele Grüsse
Steve
P.S. Als Anlage lege ich das Dokument des Feedbacks aus der öffentlichen Konsultation
lars-steffen
Offene Diskussion zu Metaproduct
Auswirkung u.a.
--> Punkt muss ASAP geklärt werden Aktuell als 0-1 vorhanden, und kann als kleine Änderung bis März noch vorgenommen werden können.