UserPreferences

NlfFaq

Hier sollen Fragen gesammelt und beantwortet werden, die ISOagriNET betreffen.

Transaktion und Search-Request

Frage

ich habe mir ein Beispiel zum Search Request angeschaut:

Müssen wir die Nachricht wirklich mit TM, EN, ZN abschließen?

ANTWORT

ich halte es für wichtig, daß die RN-Zeile ausformuliert wird. Dies wird im ADIS-Standard gefordert. Die Frage ist allerdings, ob die Antwort wie gefordert mit der entsprechenden Definitionszeile zurückkommen muß. Normalerweise sind die resultierende DN-Zeile und RN-Zeile bis auf den Zeilentyp identisch zu halten. Fehlt dem Server die Kenntnis über ein Item, liefert er später in den Valuezeilen für diese Spalte Ausrufezeichen zurück. Fehlen ihm die Werte für eine Spalte, gibt er Fragezeichen in dieser Spalte zurück. Der Client sollte sich aber nicht darauf verlassen, daß die DN-Zeile der RN-Zeile entspricht. Gerade in ISOagrinNET, wo auch einfache Mikrocontroller zum Einsatz kommen, kann es aus Performance-Gründen für den Server sinnvoll sein, die DN/VN-Zeilen wie gespeichert, abzugeben. Ebenfalls halte ich es grundsätzlich für sinnvoll, immer Search-Lines zu definieren (Best Practice). Diese müssen vor den Request-Lines formuliert werden. Hier gibt es übrigens einen Fehler in der Anleitung vom LAV (s.a.http://www.lkv-nrw.de/index.php?id=303 unter Abschnitt Abfrage) . Search-Zeilen folgen nicht den Request-Zeilen, sondern werden vorher abgehandelt. Man sollte sich schon deshalb angewöhnen, Search-Zeilen zu schreiben, da das dem Server die Arbeit erheblich erleichtert. Insbesondere wenn es um große Datenbestände geht. Der Einsatz von S/R-Zeilen macht dann keinen Sinn, wenn es um komplexe Abfragen geht, dann sind named Queries vorzuziehen. Jetzt zur Frage:

In contrast to the start of a transaction, the end is always marked with the same line: A Transaction End line. Because the client initiates a transaction, it is up to the client to send the Transaction End line after issuing all necessary information. The receiver may have to process the transaction. The receiving end (server) then needs to interact with the client by sending back the requested information or possibly any error codes, comments or the like. After processing the transaction that was sent by the client and sending back any information (requested or not), the server then sends back the Transaction End line.

Das bedeutet, daß bei einer ISOagriNET-Session-Kommunikation (s.a. Abbild.3) der Client immer ein TN schickt. Der Server kann dann die Anfrage beantworten,schickt die DN/VN-Zeilen uns anschliessend ebenfalls ein TN. Danach kann der Client weitere Anfragen stellen

Anders ist es natürlich beim Filetransfer. Schicke ich hier ein Search-Request in einer einzelnen Datei, so habe ich keine Interaktion. Ich schicke bestenfalls ein TN und gehe dann zu meinem nächsten Service über, schicke weitere S/R-Anfragen, Queries oder weitere Daten (DN/VN). Die Datei schliesse ich dann zumindest mit einem ZN.

Frage Antwort Kommentar
Ich verstehe immer noch nicht, was "to the other MCC address" bedeuten soll. "MCC address" deute ich als den Kanal, wo man das Datagramm draufhustet. Was soll das "other" bei MCC address? Das muss näher beschrieben werden (haben ADIS und XML etwa parallel verschiedenen MCC Adressen??? steht das irgendwo?) Abschnitt 7.3 im DIS definiert eine Multicastadresse (224.111.234.123) mit 2 verschiedenen Ports. Port 2434 ist für ADIS/ADED vorgesehen, während Port 2435 für XML/ADED-Datenströme z.Verfügung steht
Wenn man Header-Daten sendet, ist dann ein Handshake per TN-Zeilen wirklich zwingend erforderlich? Oder sollte das zeitige Abklären, ob der Kommunikationspartner das Datadictionary kennt, eher optional sein oder ganz wegkommen? Es ist sinnvoll bei Abläufen innerhalb einer Transaktion immer gleich zu verfahren. Alles andere verwirrt. Zudem kann der Server während der Übertragung der Header-Zeilen prüfen, ob er in der Lage ist, korrekt zu reagieren. Und wir haben es im CD und DIS so festgelegt. Technische Änderungen sind nicht mehr erlaubt.
Search-Request ist immer SBC, aber nur in asynchronen Transaktionen könnte es sinnvoll sein, die Ergebnisse dem Request über RO und RP und RR zuordnen. Nötig ist das aber auch nur, wenn in der Zwischenzeit die TCP-Verbindung abgebaut wird (per ZN), andernfalls ist die Zuordnung über RO,RP und RR ebenfalls überflüssig, weil die bestehende TCP-Verbindung ja schon dafür sorgt, dass die Daten beim Richtigen Teilnehmer ankommen. Schmidt: Weiss der Client, ob der Server "immediate" senden kann??? Wenn ja, kann man die RO Zeile weglassen. oder man muss Verhalten festlegen (und in Kapitel 7.10 an verschiedenen Stellen erwähnen). Wie bereits bei der vorhergehenden Frage ist es auch hier sinnvoll Verfahren möglichst einheitlich zu beschreiben. M.E. ist es daher sinnvoll die Openanweisungen mit der Handle-Nummer immer zu Beginn von komplexen Abfragen zu setzen, da erst der Server entscheiden kann, ob er asynchron oder sofort antworten kann. Und auch hier gilt, das wir das im CD so festgelegt haben. Daher bitte nicht anrühren
Devices können mehrere Funktionen ausführen. Im Codeset Table A53 stehen diese Funktionen. Kann ich die beliebig kombinieren. DDevice3typ ist als 3 stellige Zahl angegeben. Ist das so sinnvoll? Nein, sinnvoll wäre hier ein 2 oder 4-stellige Integerwert mit 31 oder 15 bit gewesen(ohne negative Werte). Leider haben wir hier einen Fehler bei der Erstellung des CD's gemacht. Dies nach dezimal umzusetzen, hätte in Tabelle A52 einen 10-stelligen oder einen 5 stelligen Wert ergeben. Vielleicht können wir dies noch im DIS einpflegen.
Fragen von Goldmann Antwort von Friedrichs
1) Ist der Gebrauch der Entität 990054 für die DD-Definition (DH..VH) anstelle von 990001 bei ISOagriNET vorgeschrieben ( ich gehe davon aus) und sollte nicht Sender- und Receiver-Adress als Mandatory-Feld betrachtet werden und immer mit übertragen werden. Ehrlich gesagt, bin ich nicht sicher, aber ich denke, dass der 990001 so nicht zu gebrauchen war, und somit haben wir den 990054 erstellt. Korregiert mich, wenn ich falsch liege. (Friedrichs)
2) Welches DD soll im Header (DH…VH) angegeben werden. Hintergrund der Frage: Wenn Entitäten wie z.B: 610036 verwendet werden sind in dieser sowohl Items aus dem Internationalen-DD (1996) aus auch nationalen DD (AGRO2009) enthalten. (bin ich richtig in der Annahme, dass in diesem Fall "AGRO2009" angegeben wird) Die Angabe der DD-Version sehe ich nicht als wichtig an. Auch geräte mit unterschiedlichen DD- Versionen müssen sich unterhalten können.(Friedrichs)
2b) Was ist wenn eine Entität sowohl Items aus dem Internationalen, nationalen aus auch neue (z.B. für die Lüftungsbereich) noch nicht eingetragene Entitäten enthält - welches DD wird dann angegeben ? Ich denke, das ist zulässig, da nach den Vereinbarungen Items, die unbekannt sind nicht zum Fehler führen dürfen.
"SN/RN" Abfrage-Sequenz bei Seach-Request Kommunikationen über TCP/IP
3a) Ist die nachfolgende Abfrage-Sequenz richtig: Gerät 1: DH, VH, SN, TN Gerät 2: DH, VH, DN, VN…VN, TN Diese Variant scheint mir richtig Gerät 1: ZN Gerät 2 antwortet evtl. auch mit einem ZN oder muss in der Antwort von Gerät 2 "RN" verwendet werden Gerät 1: DH, VH, SN, TN Gerät 2: DH, VH, RN,VN..VN, TN Ein RN ist nicht vorgesehen. Gerät 1: ZN oder ??: ….. (kann "ZN" auch direkt vom Gerät 2 im Anschluss an "TN" gesendet werden) ZN beendet eine Session, also kappt die TCP/UP Verbindung. Der Partner quittiert das ZN wieder mit einem ZN u. löst den Socket auf. Ein RN vonm Gerät 2 ist nicht zulässig
3b) Aufbau des SN Befehls ist folgender Aufbau richtig (Leerzeichen nur zur besseren Darstellung) Beispiel: Feldlänge=3 Byte, Resolution=0, min = 0, max=999, maximal 100 Records SN <6byte Entität> <8byte Item> 030 000 999 000100 kann der Block "<8byte Item> 030 000 999" mehrmals für verschiedene Items innerhalb der Entität in die Abfrage eingebaut werden wie z.B: SN <6byte Entität> <8byte Item> 030 000 999 000 ... <8byte Item> 040 0000 9999 000100 Wer hilft?
3c) Wildcard: gibt es einen "Wildcard" Befehl für "alle Werte" oder sollte hierfür folgender Aufbau mit "search the first n records (und einem entsprechend hohen "max-Record"-Wert) verwendet werden SN <6byte Entität> <8byte Item> 030 ??? _ 001000 Wer hilft?
3d) kann die "SN" Abfrage auch auf Entitäten von Daten-Type "AN" (Texte) verwendet werden, wenn ja wie wird min, max definiert. Keine Ahnung! Wer hilft?