Zur Implementierung der REST-Schnittstelle in Java bietet\nSpring eine Vielzahl von Annotationen. Die klassischen REST-Methoden werden\nbeispielsweise durch @GetMapping, @PostMapping oder @PutMapping abgebildet. Bei\nPost und Put k\u00f6nnen Daten als String innerhalb der Pfadvariablen\n(@PathVariable) oder als komplexere Datenstruktur (JSON) im Request Body\n(@RequestBody) \u00fcbergeben werden. Da Spring allerdings nicht mit einem Array von\nJSONs zurechtkommt, m\u00fcssen die empfangenen Daten, \u00fcber ein Zwischenobjekt\n(Wrapper) entgegengenommen werden. Die Funktionalit\u00e4t dieser Methoden wurde\nmithilfe der Anwendung \u201ePostman\u201c getestet, damit die sp\u00e4tere Kommunikation mit\nden beiden Frontends optimal abl\u00e4uft:<\/p>\n\n\n\n Das Mapping zwischen JSON Format und Java Objekt wird von\nSpring \u00fcbernommen, sofern die Namensgebung identisch ist. <\/p>\n\n\n\n Die Kommunikation in Richtung MQTT Broker wurde \u00fcber Eclipse\nPaho realisiert. Damit k\u00f6nnen Daten wie Strings oder JSON Dateien an die\njeweilige Topic des MQTT Broker \u00fcbermittelt werden. Der MQTT Server konnte\nerreicht werden und testweise die ersten Nachrichten gepublisht werden. Zur\n\u00dcberpr\u00fcfung der Funktionalit\u00e4t wurde \u201eMQTT.fx\u201c verwendet:<\/p>\n\n\n\n Pfadberechnung<\/strong><\/p>\n\n\n\n Innerhalb dieses Themenblocks ist eine mathematische\nHerangehensweise an die Problemstellung vorteilhaft. Das Ergebnis der\nBerechnungen im Backend soll die schnellste Route zu einem oder mehreren\nArtikeln sein. Um dieses Problem zu l\u00f6sen, wird ein Netz ben\u00f6tigt, dass alle\nNetzkanten, Wegpunkte und Artikel enth\u00e4lt. Innerhalb des Verwaltungsfrontends\ngeschieht die Pflege dieser Elemente aber separat voneinander und die Laufwege\nund Positionen von elektronischen Etiketten sind nicht in einem einzigen Netz\nvereint. Deshalb muss dies mithilfe eines Algorithmus erfolgen. <\/p>\n\n\n\n \n \n \nDaf\u00fcr muss f\u00fcr jedes elektronische Etikett ein neuer Wegpunkt im Netz\nder Laufwege eingef\u00fcgt werden. Somit muss der k\u00fcrzeste Weg eines Punktes (ESL)\nzu der n\u00e4chsten Kante berechnet werden. Jeder Laufweg kann mit einer Funktion\nf(x) = m*x + r abgebildet werden. Da der k\u00fcrzeste Weg von einem Punkt zu einer\nGeraden immer die Orthogonale ist, kann mithilfe des negativen Kehrwert von m eine\nneue Funktion aufgestellt werden. Der Schnittpunkt beider Funktionen ist der\nPunkt, an dem ein neuer Punkt im Netz eingef\u00fcgt werden muss (nur bei k\u00fcrzester\nL\u00e4nge). Die Abbildung zeigt 3 m\u00f6gliche Orthogonalen (lila), wobei nur ein neuer\nPunkt eingef\u00fcgt wird. Dieses Vorgehen muss f\u00fcr alle elektronischen Etiketten\nwiederholt werden.<\/p>\n\n\n\n Das neu berechnete Netz wird in der Datenbank durch zwei\nneue Entit\u00e4ten abgebildet, damit die Eintr\u00e4ge des Marktes nicht \u00fcberschrieben\nwerden und gegebenenfalls eine \u00dcberpr\u00fcfung der Ergebnisse erfolgen kann.\n\nZur weiteren Berechnung des schnellsten Wegs zu einem\nbestimmten Artikel war der Algorithmus von Dijkstra anf\u00e4nglich sehr vielversprechend.\nDieser kann allerdings leider nur bei einem einzigen Artikel angewandt werden.\nWerden mehrere Artikel gesucht, spricht man innerhalb von Operations Resarch\nvom Traveling Salesman Problem. Dieses Optimierungsproblem ist in der\nMathematik lange bekannt und soll nun in Java abgebildet werden. Meist werden\nhierbei alle m\u00f6glichen Pfade berechnet und sich schlussendlich dann einfach f\u00fcr\nden Pfad mit geringstem Kantengwicht entschieden. Dieses Vorgehen ist\nallerdings sehr ressourcenhungrig. Eine Berechnung mithilfe dieser Algorithmen soll\ninnerhalb der n\u00e4chsten Wochen erfolgen.\n\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":" Das Backend der Smart Indoor Navigation soll nicht nur die Entit\u00e4ten und Repositories enthalten, sondern auch die Kommunikation mit den beiden Weboberfl\u00e4chen und den Pies erm\u00f6glichen. Au\u00dferdem soll innerhalb des Backends die Berechnung des schnellsten Laufwegs erfolgen. Dieser Blogpost behandelt<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[],"_links":{"self":[{"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/posts\/897"}],"collection":[{"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/comments?post=897"}],"version-history":[{"count":1,"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/posts\/897\/revisions"}],"predecessor-version":[{"id":1139,"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/posts\/897\/revisions\/1139"}],"wp:attachment":[{"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/media?parent=897"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/categories?post=897"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.iot-embedded.de\/iot-2019\/wp-json\/wp\/v2\/tags?post=897"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"http:\/\/www.iot-embedded.de\/iot-2019\/wp-content\/uploads\/sites\/4\/2019\/06\/post.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/www.iot-embedded.de\/iot-2019\/wp-content\/uploads\/sites\/4\/2019\/06\/fx.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/www.iot-embedded.de\/iot-2019\/wp-content\/uploads\/sites\/4\/2019\/06\/pfad.jpg\")
<\/figure>\n\n\n\n