JSON mit Messwerten -> Datenarchiv?

[saegefisch]

Ziel: Web-Frage (edomi-Standard: http-get) liefert JSON zurück mit Liste von x Messwerten zu timestamps >> in Datenarchiv zu den gelieferten timestamps die Messwerte schreiben

Vielleicht steh' ich total auf dem Schlauch und interpretiere den ganzen Sack an JSON-LBS falsch, aber mir scheint, damit kann man wunderbar (statisch) strukturierte Daten verarbeiten, aber für eine Liste von einer unbekannten Anzahl Messwerten scheinen sie mir ungeeignet. Wie löst man das am besten?

Bin für Hinweise auf bestehende Standards und LBS sehr dankbar. Oder auch die Erkenntnis, dass ich nichts übersehen habe und die edomi-Welt noch einen weiteren LBS braucht... Lieben Dank schon mal vorab!

Beispiel (Auszug Kopf und z.B. 3 Messwerte):

{

"displayFieldName": "MESSDATUM",
"fieldAliases": {
"MESSSTELLE_ID": "Mst.-ID",
"KURZNAME": "Kurzname",
"BEZEICHNUNG": "Name",
"MESSDATUM": "Datum",
"ABSTICH": "Abstich (m unter MP)",
"NN": "Wasserspiegel (m ü. NN)",
"GOK": "Wasserspiegel (m unter GOK)",
"TEMPERATUR": "Wassertemperatur (°C)",
"ESRI_OID": "ESRI_OID"
},
"fields": [
{
"name": "MESSSTELLE_ID",
"type": "esriFieldTypeInteger",
"alias": "Mst.-ID"
},
{
"name": "KURZNAME",
"type": "esriFieldTypeString",
"alias": "Kurzname",
"length": 7
},
{
"name": "BEZEICHNUNG",
"type": "esriFieldTypeString",
"alias": "Name",
"length": 50
},
{
"name": "MESSDATUM",
"type": "esriFieldTypeDate",
"alias": "Datum",
"length": 8
},
{
"name": "ABSTICH",
"type": "esriFieldTypeDouble",
"alias": "Abstich (m unter MP)"
},
{
"name": "NN",
"type": "esriFieldTypeDouble",
"alias": "Wasserspiegel (m ü. NN)"
},
{
"name": "GOK",
"type": "esriFieldTypeDouble",
"alias": "Wasserspiegel (m unter GOK)"
},
{
"name": "TEMPERATUR",
"type": "esriFieldTypeDouble",
"alias": "Wassertemperatur (°C)"
},
{
"name": "ESRI_OID",
"type": "esriFieldTypeOID",
"alias": "ESRI_OID"
}
],
"features": [
{
"attributes": {
"MESSSTELLE_ID": 4711,
"KURZNAME": "123456",
"BEZEICHNUNG": "MUSTERHAUSEN",
"MESSDATUM": 1578268800000,
"ABSTICH": 3.21,
"NN": 171.91,
"GOK": 2.48,
"TEMPERATUR": null,
"ESRI_OID": 153
}
},
{
"attributes": {
"MESSSTELLE_ID": 4711,
"KURZNAME": "123456",
"BEZEICHNUNG": "MUSTERHAUSEN",
"MESSDATUM": 1578873600000,
"ABSTICH": 3.0800000000000001,
"NN": 172.03999999999999,
"GOK": 2.3500000000000001,
"TEMPERATUR": null,
"ESRI_OID": 154
}
},
{
"attributes": {
"MESSSTELLE_ID": 4711,
"KURZNAME": "123456",
"BEZEICHNUNG": "MUSTERHAUSEN",
"MESSDATUM": 1579478400000,
"ABSTICH": 3.2400000000000002,
"NN": 171.88,
"GOK": 2.5100000000000002,
"TEMPERATUR": null,
"ESRI_OID": 155
}
}
]
}

[jonofe]

Vielleicht steh' ich total auf dem Schlauch und interpretiere den ganzen Sack an JSON-LBS falsch, aber mir scheint, damit kann man wunderbar (statisch) strukturierte Daten verarbeiten, aber für eine Liste von einer unbekannten Anzahl Messwerten scheinen sie mir ungeeignet. Wie löst man das am besten?

Ich würde das mit dem JSON-Extractor LBS machen.
In deinem Fall zunächst das ARRAY extrahieren und dann das Ergebnis (welches auch JSON ist) auf einen weiteren JSON Extractor mit dem fortlaufenden Index 0,1,2,3,4,5,6,7,8,9 als Selector. Ich gebe zu, das ist nicht die 100% Lösung, denn du solltest vorab zumindest wissen wie viele Elemente maximal im Array vorhanden sein können. Aber es ist zumindest ein Workaround ohne einen neuen LBS entwickeln zu müssen. Sieht dann ungefähr so aus:

json.PNG
Am Ende kommen dann die einzelnen JSON Array Elemente raus, aus denen du dann die Daten genauso extrahieren kannst und in ein Datenarchiv schreiben kannst.

[saegefisch]

Lieben Dank, André. Das werde ich mal so versuchen. Da ich einen Zeitraum bei der Anfrage mitgeben kann, werde ich wohl grob die Anzahl Messwerte zumindest begrenzen können, aber es bleibt eine Krücke, weil meine Datenquelle tatsächlich in unterschiedlicher Frequenz Daten liefert; mal wöchentlich, mal seltener.

Aber erstaunlich...wir machen hier schon 4 Jahre edomi, es gibt einen Sack an ähnlichen LBS zu JSON, aber JSON-Messwerte unbekanntem Umfangs hat offenbar noch niemanden beschäftigt. Denn das ist durchaus ein sehr natürliches Habitat für JSON in der IT...

Vielleicht mach' ich da mal was...aber erst mal gehe ich Deinen Vorschlag.

Nachtrag: Das KO vom, HTTP-GET mit dem Ergebnis liefert mir im LBS erst mal direkt ein "INVALID JSON" an A1... muss mal analysieren gehen...
Nachtrag 2: Wenn man es richtig macht, ist es nicht mehr INVALID, sondern MATCH...

[saegefisch]

Update: So....es hat wunderbar funktioniert: Mit einer Logik mache ich die Erzeugung der URL mit einem Zeitintervall und den HTTP-GET, Extraktion und Schreiben in Archiv nur abhängig vom Setzen eines BIS-Datums und einer Intervallgröße von x Tagen z.B. "-90 days". Bei wöchentlichen Werten sind dann ~ 12 Werte zu erwarten. Die JSON-Extraktion habe ich für 20 Werte gebaut und deckt damit ein Quartal gut ab. Das Intervall ist also für eine Quelle so zu wählen, dass 20 Werte nie überschritten werden. Im Wesentlichen damit mit edomi-Bordmitteln und den ohnehin von mir verwendeten LBS für JSON und Datenarchiv wunderbar gelöst. Und kein neuer LBS nötig...sehr schön!

Nochmal lieben Dank für den Lösungsansatz, André!

Die initiale Beladung eines Jahres in das Datenarchiv ist mit 4 manuellen Aufrufen im Liveview zu den 4 Quartals-Ultimos erledigt.
Der regelmäßige Aufruf erfolgt täglich (wöchentlich würde bei der Quelle reichen) und setzt lediglich das BIS-Datum auf das aktuelle Datum und löst damit die gesamte Logik aus.

Falls jemand auch am Thema "Beschaffung Grundwasser-Messwerte" Interesse hat - für Hessen gibt es das hier:

http://gruschu.hessen.de/arcgis/rest/services/gruschu/Auswertung/MapServer/4/query?f=json&where=(MESSSTELLE_ID%20IN(<DeineStation>)%20AND%20(MESSDATUM%20%3E=%20%271.1.2019%27%20AND%20MESSDATUM%20%3C=%20%2731.03.2019%27))&outFields=*&orderByFields=MESSSTELLE_ID%20ASC%2CMESSDATUM%20ASC

So sieht es aus mit Grundwasser (dieser Threat) und Regenmengen auf Tagesbasis vom DWD (anderer Threat):
grundwasser.PNG

Logik für JSON-Messdaten - hier Grundwasserhöhen
json2.JPG

daten2.PNG

[saegefisch]

jonofe Hi André, zum JSON-Extractor LBS 19001208 hätte ich noch einen Verbesserungsvorschlag und bin gespannt, ob der Bedarf nachvollziehbar und sinnvoll ist:

Mit der obigen Lösung schlagen ~12 Einträge gleichzeitig am letzten LBS 19000348 zum Schreiben im Archiv auf. Das scheint öfter mal zu Null-Werten zu führen. Es ist sporadisch, aber reproduzierbar (Selbe Quelle, selber TS, mal 0, mal korrekter Wert) - es kann also nicht an der Quelle liegen. Zudem habe ich beim ersten Auftreten noch einen Filter für alle 20 eingebaut, der Null-Werte gar nicht mehr weiter reichen würde. Im Liveview sehe ich auch alle Werte > 0, im Datenarchiv kommen dennoch immer wieder mal Nullen an

Vorschlag: Der JSON-Extractor bekommt einen zusätzlichen E13, in dem man optional eine kaskadiert-verzögerte Ausgabe in ms an A2-A11 sicher stellen kann.

• Default = leer/Null -> alles wie bisher
• E13 = 100ms -> A2 liefert sofort, A3, 100ms später, A4, 200ms später, A5 300ms...

Damit könnte man bei konkurrierenden Folgeverarbeitungen sicher stellen, dass es zu keinen Locks/Kollisionen kommt. Natürlich kann man das in der Folgeverarbeitung per Verzögerer einbauen, doch kann ich mir Vorstellen, dass dies auch für andere Konstellationen sinnvoll sein könnte und dann eine Lösung am LBS, der aus 1:10 Logik-Stränge macht praktisch wäre.

Was denkst Du...allgemein sinnvoll/praktisch und leicht lösbar oder mein Einzelschicksal? Ich kann mit beiden Antworten gut leben...

[jonofe]

Hi Carsten,
ich muss zugeben, ich habs noch nicht ganz verstanden, wo eine 0 ankommt, wo sie nicht ankommen sollte.
Wenn das nur im Archiv passiert, deutet das doch eher auf ein Problem im 348er LBS hin. Vielleicht habe ich es auch nicht komplett verstanden. Wenn ein LBS schnell neue Inputs bekommt, muss dieser natürlich über ein Queueing sicherstellen, dass alle ankommenden Telegramme verarbeitet werden.

[saegefisch]

In der Theorie zweifelsohne richtig...

Mir scheint, der 348 macht dies nicht und mir schien es die einfachere Option und vielleicht auch zur Entzerrung anderer json-Prozesse zweckdienlich.


ok, ok, habe verstanden...

...dann schaue ich mir mal den 348 an. Hast du einen kleinen Tipp/Stichwort, wie man am besten Queueing in PHP implementiert? Dann suche ich mir den Rest selber raus und spreche auch den Ersteller des 348 an.

[jonofe]

Der Punkt ist halt dass, wenn das Problem im 348 liegt, müsste dann jeder LBS, der potentiell Infos für den 348 liefert, durch eine Verzögerung ergänzt werden.
Falls der 348er das Schreiben ins Archiv über ein EXEC Skript macht, dann sollte man es vermutlich die Daten vom LBS Skript über logic_setInputsQueued an das EXEC Skript senden und dort mit logic_getInputsQueued solange aus der Queue lesen und ins Archiv schreiben wie Daten vorhanden sind. Dadurch gehen keine Daten verloren und es werden nicht durch zu schnelles Triggern des LBS schon laufenden Transaktionen im EXEC Teil beeinflusst.

[saegefisch]

Irgendwie haben mich diese WE die Bytes nicht lieb - alles fuzzy diese Tage... ein Update:

Meine Arbeitshypothese, dass die Schreibzugriffe sich vermutlich blockieren, war wohl eine falsche Hypothese; zumindest konnte ich ihn nicht erhärten, weil im Log kein Fehler auftrat.

Nach viel testen sieht es für mich eher so aus: Der LBS triggert mit dem Timestamp an E6. Durch die vorgeschaltete Logik scheint der eigentliche Messwert gelegentlich einen Hauch zu spät zu kommen und wird damit als Null im Archiv abgelegt, weil der Wert an E5 eben (noch) Null war, als E6 den LBS triggert und los lief.

Nun müsste man wohl im LBS 19000348 was einbauen, damit der LBS erst loslegt, wenn E5 und E6 einen neuen Wert haben.
Ich wähle für den Moment den einfachen Weg...Da ich mir zum Beladen der Daten eine Sequenz angelegt habe, konnte ich nun es einfach mehrfach laufen lassen - nun war es mal fehlerfrei. Und so bleibt es für den Moment auch, weil ich die historischen Daten ja eigentlich nie wieder lade.