pvrqualitasag/IcarAdeSpezTransDE

Package index
Search the pvrqualitasag/IcarAdeSpezTransDE package
Functions
1
Source code
1
Man pages
1
Home
/
GitHub
/
pvrqualitasag/IcarAdeSpezTransDE
/

In pvrqualitasag/IcarAdeSpezTransDE: 

### # specify knitr options
knitr::opts_chunk$set(echo = FALSE, results = 'asis')

### # clean cache with references
knitcitations::cleanbib()
options("citation_format" = "pandoc")

### # initialize section counter
robjSecEnum <- rqudocuhelper::SectionEnumerator$new()

### # init abbreviation Table
r6obj_abr <- rmddochelper::R6ClassTableAbbrev$new()
r6obj_abr$setColHeader(pvColHeader = c("Abkürzung", "Bedeutung"))

### # init translation table
r6obj_transl <- rmddochelper::R6ClassTableAbbrev$new()
r6obj_transl$setColHeader(pvColHeader = c("Original", "Übersetzung"))
r6obj_transl$setAbbrFile(psAbbrFile="TRANSLATION")
r6obj_transl$setQuote(pbQuote=FALSE)

Qualitas Logo

\fcolorbox{black}{white}{ \parbox[t]{1.0\linewidth}{ \centering \fontsize{12pt}{20pt}\selectfont % \vspace*{0.5cm} % 

    \hfill Übersetzung

    \vspace*{0.5cm} 
}

}

\vspace*{0.5cm}

\fcolorbox{black}{white}{ \parbox[t]{1.0\linewidth}{ \centering \fontsize{25pt}{40pt}\selectfont % \vspace*{0.7cm} ICAR Spezifikation \ Automatisierter Austausch\ von Tierdaten \

    \vspace*{0.7cm} % Space between the end of the title and the bottom of the grey box
}

}

\vspace*{1cm}

\begin{center} \includegraphics[width=0.5\textwidth]{png/Pedigree.png} \end{center}

\vspace{5ex} {\centering \small \hfill \begin{tabular}{l} Peter von Rohr \ FB EDV, Qualitas AG \ \verb+http://www.qualitasag.ch+ \ \verb+peter.vonrohr@qualitasag.ch+
\end{tabular} }

\pagebreak

\tableofcontents

\pagebreak

### # change to new package
r6objDocStat <- rmddochelper::R6ClassDocuStatus$new()
# r6objDocStat$setProject("ICAR-ADE-SpUe")
# r6objDocStat$setStatus("Erweiterung Kap 4.2 Datenaustausch")
# r6objDocStat$setVersion("0.0.910")
# r6objDocStat$setDate("05.07.2016")

# r6objDocStat$setStatus("Servicebeschreigung: GetHerdList")
# r6objDocStat$setVersion("0.0.911")
# r6objDocStat$setDate("06.07.2016")

# r6objDocStat$setStatus("Servicebeschreigung: UpdateAnimal")
# r6objDocStat$setVersion("0.0.912")
# r6objDocStat$setDate("07.07.2016")

# r6objDocStat$setStatus("Abschluss Kap 4.2 Datenaustausch")
# r6objDocStat$setVersion("0.0.913")
# r6objDocStat$setDate("12.07.2016")

# r6objDocStat$setStatus("Anhang zu Webservice und Referenzen")
# r6objDocStat$setVersion("0.0.914")
# r6objDocStat$setDate("13.07.2016")

r6objDocStat$set_current_status(psVersion = "0.0.915",
                                psStatus = "Neue Version von rmddochelper",
                                psProject = "ICAR-ADE-SpUe",
                                psDate = "03.08.2016")

r6objDocStat$set_current_status(psVersion = "0.0.916",
                                psStatus = "Abkürzungen mit rmddochelper",
                                psProject = "ICAR-ADE-SpUe",
                                psDate = "29.08.2016")
r6objDocStat$set_current_status(psVersion = "0.0.917",
                                psStatus = "Übersetzungstabelle mit rmddochelper",
                                psProject = "ICAR-ADE-SpUe",
                                psDate = "29.08.2016")
r6objDocStat$set_current_status(psVersion = "0.0.918",
                                psStatus = "zusätzliche Erklärungen",
                                psProject = "ICAR-ADE-SpUe",
                                psDate = "07.09.2016")

### # include the table
r6objDocStat$include_doc_stat(psTitle = "# Dokumentenstatus")

\pagebreak

Erklärungen

Dieses Dokument basiert auf Version 1.8 (Final release vom 20.11.2015) der ICAR Spezifikation ``Animal Data Exchange''. Technische Fachbegriffe wurden sinngemäss übersetzt und mit dem englischen Begriff in Klammern versehen und am Schluss dieses Dokuments in einer Übersetzungstabelle aufgelistet. Diagramme wurden per Screen-shots aus dem Originaldokument kopiert und mit Zusatzinformation in Deutsch versehen. Ergänzende Bemerkungen des Übersetzers sind mit geschweiften Klammern {} gekennzeichnet.

\vspace{1ex}

robjSecEnum$displayNumSection("# Ausgangslage")

ICAR r r6obj_abr$add_abbrev(psAbbrev="ADE", psMeaning="Animal Data Exchange") steht für die Spezifikation des automatisierten Austauschs von Tierdaten vom r r6obj_abr$add_abbrev(psAbbrev="ICAR", psMeaning="International Committee for Animal Recording"). Der Datenaustausch wird anhand von folgenden Bestandteilen definiert.

  1. r r6obj_transl$add_abbrev(psAbbrev="business requirements", psMeaning="Anforderungen") und technischen Spezifikationen
  2. Datenbeschreibung zur Verfügung gestellt als Dateien, welche konsistent sind mit den Empfehlungen vom r r6obj_abr$add_abbrev(psAbbrev="W3C", psMeaning="World Wide Web Consortium") für r r6obj_abr$add_abbrev(psAbbrev="XML", psMeaning="eXtenible Markup Language") Schemas, r r6obj_abr$add_abbrev(psAbbrev="UNCEFACT", psMeaning="United Nations Center for Trade Fascilitation and Electronic Business") und r r6obj_abr$add_abbrev(psAbbrev="ISO", psMeaning="International Organization for Standardization")
  3. Spezifikationen von Interfaces zur Verfügung gestellt als Dateien, konsistent mit den Empfehlungen von W3C für XML Schemas, UNCEFACT und ISO

Die Anforderungen können unterteilt werden in

Für einen bestimmten Datenaustausch enthalten die spezifischen Anforderungen

Datenbeschriftungen beinhalten

Die technische Implementation behandelt die Umsetzung der Anforderungen auf verschiedene Arten

{Eine Übersicht der verschiedenen Komponenten ist im folgenden Diagramm gegeben.

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "DiagrammSpezScope")

Ein Problem dieser Spezifikation ist, dass Prozesse des Projektablaufs und auch organisatiorische Fragen nicht sauber von den technischen Aspekten des Datenaustauschs getrennt sind. Diese Vermischung erschwert das Verständnis erheblich. }

\pagebreak

robjSecEnum$displayNumSection("# Beschreibung des automatisierten Tierdatenaustauschs")

{Dieser Abschnitt enthält folgende Punkte

In den folgenden Unterabschnitten werden die einzelnen Punkte noch genauer beschrieben.}

robjSecEnum$displayNumSection(paste("##", r6obj_transl$add_abbrev(psAbbrev="Background", psMeaning = "Hintergrund")))

Aktuell ist der ATDA zwischen Geräten und externen Informationssystem nicht möglich oder nur über spezialisierte Softwareprogramme (sogenannte Middleware) möglich. Diese Middleware basiert auf lokalen meist proprietären und veralteten Standards. Das folgende Diagramm zeigt die aktuelle Situation bezüglich ATDA

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "OrgSpezDiagramm1")

Die Middleware ist teuer in der Implementation und im Unterhalt. Meistens müssen diese Systeme mit manuellen Interventionen bedient werden. Diese Middleware basierten Systeme sind häufig langsam und sind sehr aufwändig zu optimieren. Daraus folgt auch, dass die Übermittlung von grossen Datenmengen nicht möglich ist.

Moderne Datenzentren machen es möglich grosse Datenmengen zu verarbeiten. Eine steigende Anzahl an Gerätschaften und Sensoren produziert eine exponentiell wachsende Menge and Daten. Diese enormen Datenmengen können nur noch durch automatisierte und standardisierte Prozesse verarbeitet werden.

Eines automatisierter Austausch von grossen Datenmengen in Echtzeit hätte die folgenden Vorteile:

  1. Neue Merkmale für die Selektion in Nutztierpopulationen
  2. Verbesserung der Tierüberwachung durch die Zusammenfassung von Daten von verschiedenen Quellen, wie zum Beispiel Geräte, Labors, ...
  3. Verbesserung der Kalibrierung von Geräten zur Verbesserung der Messgenauigkeit
robjSecEnum$displayNumSection("## Ziele des Tierdatenaustauschs")

Das primäre Ziel ist die Etablierung eines direkten, permanenten zuverlässigen Services zum Austausch von grossen Datenmengen zwischen Geräten und externen Informationssystemen. Der Service soll folgende Eigenschaften aufweisen: 

robjSecEnum$displayNumSection("## Strategien zur Erreichung der Ziele")

robjSecEnum$displayNumSection("### Inhalt des ATDA")

Die Ziele des ATDA können durch ein Framework mit folgenden Bestandteilen oder Eigenschaften erreicht werden

  1. Architektur zur Unterstützung des Datenaustauschs
  2. Standards für Nachrichten und Daten
  3. Tools zur Erleichterung der r r6obj_transl$add_abbrev(psAbbrev="implementation", psMeaning="Umsetzung")
  4. Reaktiver Unterhaltsprozess

Die vorgeschlagene Architektur basiert auf einem Service-orientierten Ansatz, in welchem das externe Informationssystem als Provider dem Gerät als Client verschiedene Services zur Verfügung stellt. Das folgende Diagramm zeigt die vorgeschlagene Modellarchitektur

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "OrgSpezDiagramm2")

Die im obigen Diagramm gezeigte Architektur kann durch verschiedene Informationstechnologien implementiert werden. Diese Technologie-Standards sind in diesem Dokument beschrieben. Diese Standards beinhalten

Die Tools, welche die Umsetzung vereinfachen sollen, beinhalten

{Aufgrund der Email von Bert van 't Land vom 13.05.2016 ist diese Webseite unter: \url{https://icar-web.atlassian.net/wiki/display/ADE/ICAR+ADE+public+information} erreichbar. Von dort können ohne Login die Spezifikation und die WSDL-Dateien heruntergeladen werden.}

robjSecEnum$displayNumSection("### ADE Implementation")

Das nachfolgende Diagramm beschreibt den Prozess der Umsetzung des ICAR-ADE Projekts.

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "OrgSpezDiagramm3", pnPaperWidthScale = 0.5)

Der oben beschriebene Prozess der Projektumsetzung wird durch eine r r6obj_transl$add_abbrev(psAbbrev="business need", psMeaning="Nachfrage") ausgelöst. Die Anforderungen sollen das Resultat einer Zusammenarbeit zwischen ICAR und Gerätehersteller sein. Diese sind unabhängig von der Technik oder Technologie, welche zur Umsetzung verwendet wird. {Hier ist gemeint, dass die Anforderungen unabhängig von der Technologie sind.}

{Hier liegt wahrscheinlich ein Grund, weshalb das Projekt eingefroren ist. Die hauptsächliche Nachfrage nach einer Lösung bezüglich des Datenaustauschs liegen bei den Bauern und bei den Zuchtorganisationen. Die Melkanlagenanbieter dagegen haben eigene Tools für den Export ihrer Daten und sind zusätzlich am Aufbau von cloud-basierten Datenspeicherkapazitäten. Somit ist die Nachfrage nach einer Lösung für den automatisierten Datenaustausch seitens der Melkanlagenanbieter nicht sehr gross. In der oben gezeigten Darstellung (Diagram 3) wird angenommen, dass alle beteiligten Parteien (Bauern, Melkanlagenanbieter und Zuchtorganisationen) gemeinsame Bedürfnisse und Anforderungen formulieren können. Diese bilden dann die Basis für den weiteren Verlauf des Projekts. Da diese gemeinsame Basis nicht oder noch nicht existiert, stagniert das Projekt.}

Zwei Arten der Umsetzung werden hier berücksichtigt.

  1. W3C und UNCEFACT Standards, als bevorzugte Lösung
  2. ISO (17532 2007) / REST, oder andere Alternativen

{Die beiden Arten der Umsetzung entsprechen in Diagram 3 den beiden grau hinterlegten Boxen, welche "XML Implementation" und "Alternative Protocols (upcoming)" als Überschrift haben. Es ist korrekt, dass an dieser Stelle beide Umsetzungsarten erwähnt sind. Ein konkreter Umsetzungsvorschlag wird aber nur für die erste Variante gemacht. Was in den kommenden Abschnitten mit W3C Implementierung bezeichnet wird, ist in Diagramm 3 mit "XML Implementation" gekennzeichnet. }

Die W3C Implementierung besteht aus

  1. Technische Beschreibung eines Datenelementes als XSD Datei basierend auf UNCEFACT Datentypen
  2. Spezifikation des Interfaces als WSDL Datei
  3. Basierend auf der WSDL
    • Umsetzung des Clients durch den Gerätehersteller
    • Umsetzung des Servers durch den Betreiber des Datencenters

{Implizit wird hier eine Verteilung der Projektaufgaben vorgenommen. Die Melkanlagenanbieter werden mit der Umsetzung eines Clients betraut. Der Server soll von einem Betreiber eines Datencenters umgesetzt werden. An dieser Stelle wird also auch schon eine Client-Server-basierte Architektur vorausgesetzt.}

robjSecEnum$displayNumSection("## Kontext (Business Context)")

{In diesem Abschnitt werden die im Schema verwendeten Begriffe definiert.}

Das nachfolgende Diagramm beschreibt den Kontext

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "OrgSpezDiagramm4")

\pagebreak

{Begriff: r r6obj_transl$add_abbrev(psAbbrev="Service Provider", psMeaning = "Dienstanbieter")}

Organisationen {im Diagramm mit `Service Providers'' bezeichnet und im folgenden mit Dienstanbieter übersetzt} stellen den Besitzern der Melkgeräte verschiedener r6obj_transl$add_abbrev(psAbbrev="Services", psMeaning="Dienste")` zur Verfügung. Der Zweck dieser Dienste ist

``Organisationen'' können Organisationen zur Aufzeichnung von Milchdaten, Zuchtorganisationen und andere Datenbankanbieter sein.

+-------------------------------------------------------------------------------------------------------+ | Für den Rest dieses Dokuments werden diese Organisationen als ``Dienstanbieter'' (Service provider) | | bezeichnet. | +-------------------------------------------------------------------------------------------------------+

Der Eigentümer der Melkausrüstung und der Dienstanbieter müssen folgendes aushandeln

Diese Punkte müssen vertraglich geregelt werden.

{Begriff: r r6obj_abr$add_abbrev(psAbbrev="milking equipment", psMeaning = "Melkausrüstung")}

Die Melkausrüstung besteht aus einer Sammlung von Hardware-Komponenten und aus Softwareprogrammen, welche mindestens folgende Funktionen umfassen:

  1. Messung der Milchmenge und von anderen r r6obj_abr$add_abbrev(psAbbrev="milk characteristic", psMeaning="Milchparametern") {Hier ist nicht klar, was gemeint ist}
  2. Abfüllen von Milchprobenfläschchen und Registrierung der Verbindung zwischen Fläschchen und Tier
  3. Abspeichern der Melkresultate
  4. Verbinden zu, senden an und empfangen von Daten von externen Informationssystemen

Die Melkausrüstung kann noch andere Funktionalitäten haben, welche von ATDA unabhängig sind. Melksysteme können als verschiedene Gerätetypen wie Roboter, elektronische Milchmesssystem, ... vorkommen. {Diese Aussage steht sehr isoliert da und mir ist nicht klar, was damit gemeint ist.}

+-------------------------------------------------------------------------------------------------------+ | Für den Rest dieses Dokuments werden Melksysteme als ``Ausrüstung'' (Equipment) bezeichnet. | +-------------------------------------------------------------------------------------------------------+

{Begriff: r r6obj_abr$add_abbrev(psAbbrev="milking operator", psMeaning="Melker / Melkoperator")}

Die Melkausrüstung wird durch einen Melker bedient und überwacht.

+-------------------------------------------------------------------------------------------------------+ | Für den Rest dieses Dokuments wird der Melker (Melkoperator) als ``Operator'' bezeichnet. | +-------------------------------------------------------------------------------------------------------+

Der Operator ist angestellt und abhängig vom Besitzer der Melkausrüstung. Der Operator hat Berechtigung zum Ausführen folgender Tätigkeiten

Verschiedene Personen können die Rolle des Operators übernehmen, so zum Beispiel Bauern, Angestellte auf Bauernhöfen, Techniker von Dienstanbietern.

{Begriff: r r6obj_transl$add_abbrev(psAbbrev="information system", psMeaning="Informationssystem")}

Der Dienstanbieter betreibt ein Informationssystem, welches die Dienste anbietet. Das Informationssystem besteht aus Servern, Datenbanken und Softwareprogrammen, welche nicht Teil der Melkausrüstung sind. Das Informationssystem ist über eine Netzwerkverbindung zur Melkausrüstung verbunden. Das Informationssystem hat minimal folgende Funktionen:

  1. Empfang und Verarbeitung von Anfragen des Melksystems
  2. Aktualisierung der Datenbank mit den Informationen des Melksystems
  3. Lieferung der Resultate des Milchanalyselabors, welches die vom anfragenden Melksystem gesammelten Proben analysiert hat

Das Informationssystem vom Dienstanbieter kann andere Funktionen unabhängig von ATDA erfüllen.

+-------------------------------------------------------------------------------------------------------+ | Für den Rest dieses Dokuments wird das Informationssystem des Dienstanbieters als | | ``Informationssystem'' bezeichnet. | +-------------------------------------------------------------------------------------------------------+

{Die Spezifikation für das zu Informationssystem sind durch die Datentypen in den XSD-Dateien und durch die Interfacebeschreibungen in der WSDL-Datei gegeben. }

robjSecEnum$displayNumSection("# Generelle Spezifikation")
robjSecEnum$displayNumSection("## Generelle Spezifikationen des Datentransports")
robjSecEnum$displayNumSection("### SOAP/XML Web Services")

Für den Datentransport wurde der Standard SOAP/XML Version 1.2 nach W3C gewählt. Eine Beschreibung dieses Standards ist unter http://www.w3.org/TR/2007/REC-soap12-part0-20070427/ verfügbar. Da für den Design-Prozess ein ``top-down'' Ansatz gewählt wurde, hat ICAR ADE schon Dateien mit WSDL und XSD Dateien vorgegeben, welche schon eine komplettes Set an Definitionen für den Datenaustausch bilden. Basierend auf diesen Definitionen können SOAP-Webservices erstellt werden. Die meisten modernen Programmiersprachen (wie Java, .NET {dies sollte wahrscheinlich C# heissen, weil .NET ist keine Programmiersprache für sich}) bieten Tools an, welche die Erstellung von Interface-Klassen zur Verbindung zwischen Datentransport-Layer und Prozess-Layer vereinfachen.

Bei jeder Veröffentlichung einer neuen Version der ICAR ADE Spezifikationen wird ein Set von WSDL/XSD Dateien zum Download von der ICAR Webseite angeboten.

Die WSDL/XSD Dateien beschreiben folgende Aspekte des Transport-Protokolls

{Eine kurze Übersicht zu WSDL und XSD ist im Anhang zu finden.}

Die folgende Tabelle gibt eine Übersicht über den Inhalt der angebotenen Definitionsdateien

+--------------------------------+-----------------------------------------------------------------------------+ | Dateinamen, Schema Namen | Beschreibung | +================================+=============================================================================+ | .XSD | XML Schema Dateien, welche die Definitionen der ICAR ADE XML | | | Datenstrukturen enthalten | +--------------------------------+-----------------------------------------------------------------------------+ | ICAR_.XSD | Definitionen von Datenelementen, welche von der ICAR ADE Grupppe erstellt | | | wurden | +--------------------------------+-----------------------------------------------------------------------------+ | ISO_.XSD | Definitionen von Datenelementen, welche vom ISO Standard abgeleitet wurden | +--------------------------------+-----------------------------------------------------------------------------+ | UNECE_.XSD | XSD Dateien, welche vom UNCEFACT Projekt zur Verfügung gestellt werden | | | siehe unter http://www.unece.org/cefact/xml_schemas/index.html | +--------------------------------+-----------------------------------------------------------------------------+ | UnqualifiedDataType_13p0.XSD | XSD Datei, welche die Definition der unqualifizierten UNCEFACT Datentypen | | | enthalten. Diese Datentypen erweitern die Standard XSD Datentypen mit | | | zusätzlichen Attributen. Diese werden in den ICAR und UNCEFACT | | | Definitionen anstelle der Standard XSD-Typen verwendet. | +--------------------------------+-----------------------------------------------------------------------------+ | CODE | XSD Datei mit Definitionen von Codes | +--------------------------------+-----------------------------------------------------------------------------+ | wsMrAde.wsdl | Beschreibung des ICAR ADE SOAP Dienstes. Diese definiert ein Set von | | | Nachrichten-Paaren, welche alle aus einer Anfrage und einer Antwort | | | bestehen | +--------------------------------+-----------------------------------------------------------------------------+ | ADE_v1p8.xsd | Hauptdatei (entry point) der Definitionen der Datenstrukturen des ICAR ADE | +--------------------------------+-----------------------------------------------------------------------------+

In der ICAR ADE Spezifikation sind Definitionen von Daten und Protokollen durch die kommerzielle Software XMLSPY von ALTOVA (http://www.altova.com/documents/XMLSpyPro.pdf) illustriert. Als Beispiel wurde für den Dienst ``GetHerdListRequest'' folgendes Diagramm erstellt. 

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "GetHerdListRequestDiagram")

Die in den Diagrammen verwendeten Symbolen haben folgende Bedeutung

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "XMLSpyDiagSymbol")

{Als Alternative zu XMLSPY lassen sich die XSD- und die WSDL-Dateien auch in Eclipse (https://eclipse.org) visualisieren. Eine kurze Anleitung dazu ist im Anhang dieses Dokuments aufgeführt.}

robjSecEnum$displayNumSection("### Alternative Transport Protokolle")

Abgesehen von SOAP gibt es andere internationale Transport Protokolle. Als Beispiel gibt es den ISO-Standard ADIS/ADED, welcher in ISO 17532(2007) beschrieben wurde. {Diese Standards wurden offenbar in ISOagriNET verwendet. r r6obj_abr$add_abbrev(psAbbrev="ADIS", psMeaning="Agricultural Data Interchange Syntax") ist eine Datenbeschreibungssprache und r r6obj_abr$add_abbrev(psAbbrev="ADED", psMeaning="Agricultural Data Element Dictionary") ist ein Daten-Dictionary.}

Bei den Transportprotokollen hat REST basierend auf dem r r6obj_abr$add_abbrev(psAbbrev="HTTP", psMeaning="Hypertext Transfer Protocol") unter Verwendung von XML, Jason {müsste eingentlich r r6obj_abr$add_abbrev(psAbbrev="JSON", psMeaning="JavaScript Object Notation") heissen} und anderen Technologien zum Datentransport eine grössere Verbreitung gefunden.

Der Einfachheit halber fokussiert die ICAR Spezifikation zuerst auf SOAP/XML. Die Integration von alternativen Protokollen wird auf später verschoben.

robjSecEnum$displayNumSection("### ICAR Typen und Codeliste")

Alle Datenelemente, welche durch die ICAR ADE Spezifikation erzeugt wurden können innerhalb der WSDL/XSD Dateien durch den Präfix ``icar:'' erkannt werden. Alle Datenelemente basieren auf UNCEFACT Datentypen. Eine Beschreibung dieser Datenelemente ist in den nachfolgenden Abschnitten gegeben.

robjSecEnum$displayNumSection("### Externe Datenelemente")

Das Ziel des ICAR ADE Standards ist es, wo immer möglich auf andere schon vorhandene Standards von ISO, r r6obj_abr$add_abbrev(psAbbrev="IANA", psMeaning="The Internet Assigned Numbers Authority") oder UNCEFACT abzustützen.

UNCEFACT Daten Typen

Die WSDL/XSD Definitionen von ICAR ADE verwenden die UNCEFACT Basisdatentypen. Die UNCEFACT Datentypen basieren auf den XSD Basistypen, wobei die XSD Typen durch zusätzliche Attribute und Restriktionen erweitert wurden. Diese sind in der Datei UnqualifiedDataType_13p0.xsd'' definiert. Diese Datentypen sind mit dem Präfixudt:'' gekennzeichnet.

Die folgenden UNCEFACT Typen werden verwendet um die Typen einer Dateneinheit (data item) zu definieren.

+------------------------+--------------------------+-------------------+-----------+ | Name | Beschreibung | Kommentar | XSD Typ | +========================+==========================+===================+===========+ | udt:CodeType | Zeichenkette (String) | Code verweist | String | | | welche verwendet wird | auf Aufzählung | | | | einen Wert | | | | | darzustellen oder zu | | | | | ersetzen | | | +------------------------+--------------------------+-------------------+-----------+ | udt:DateType | spezifisches Datum | Repräsentation | String | | | auf der Zeitachse | welche aufgrund | | | | | des Transport | | | | | Protokolls | | | | | definiert sind | | +------------------------+--------------------------+-------------------+-----------+ | udt:DateTimeType | spezifischer Zeitpunkt | Repräsentation | String | | | auf der Zeitachse | welche aufgrund | | | | | des Transport | | | | | Protokolls | | | | | definiert sind | | +------------------------+--------------------------+-------------------+-----------+ | udt:IDType | String für eindeutige | | String | | | Identifikation einer | | | | | Objektinstanz | | | +------------------------+--------------------------+-------------------+-----------+ | udt:MeasureType | Numerischer Wert | Messungen sind | Dezimal | | | bestimmt durch die | mit einer | | | | Messung eines Objektes | Einheit versehen | | | | | eine Auflösung | | | | | und falls nötig | | | | | ein Bereich mit | | | | | Minimum und | | | | | Maximum | | +------------------------+--------------------------+-------------------+-----------+ | udt:NameType | Wort zur Bezeichnung | | String |
| | einer Person, eines | | | | | Ortes einer Sache oder | | | | | eines Konzeptes | | | +------------------------+--------------------------+-------------------+-----------+ | udt:BinaryObjectType | Base64 codierte | z.Bsp. für zip | String | | | binäre Daten | komprimierte | | | | | Daten verwendet | | +------------------------+--------------------------+-------------------+-----------+ | udt:TextType | Genereller Typ für Text | | String | +------------------------+--------------------------+-------------------+-----------+ | udt:IndicatorType | Boolsche Variable oder | | Boolean | | | wahr oder falsch | | | +------------------------+--------------------------+-------------------+-----------+

UNCEFACT Codierung

+-----------------------------+---------------------------------------------------------------------------+ | Codierung | Beschreibung | +=============================+===========================================================================+ | AgencyIdentificationCode | Liste von Organisation verantwortlich für die Betreuung von Codierungen | | | welche als Wert des Attributs 'listAgencyID' im UNCEFACT Datentyp | | | udt:CodeType verwendet werden | +-----------------------------+---------------------------------------------------------------------------+ | CharacterSetEndcodingCode | Liste von Zeichencodierungen, welche als Werte für Attribute | | | 'encodingCode' im UNCEFACT Datentyp xsd:base64Binary verwendet werden | +-----------------------------+---------------------------------------------------------------------------+ | MeasurementUnitCommonCode | Set von Einheiten, welche als Werte für das Attribut 'unitCode' im | | | UNCEFACT Datentyp udt:MeasureType verwendet werden. | +-----------------------------+---------------------------------------------------------------------------+

ISO Codierung

+-----------------------------+----------------------------+ | Codierung | Beschreibung | +=============================+============================+ | ISO3AlphaCurrencyCode | Währungscode | +-----------------------------+----------------------------+ | ISOTwoletterCountryCode | Zweistelliger Ländercode | +-----------------------------+----------------------------+

IANA Codierung

+-----------------------------+-----------------------------------+ | Codierung | Beschreibung | +=============================+===================================+ | CharacterSetCode | IANA Zeichencodierung | +-----------------------------+-----------------------------------+ | MiMEMediaType | Liste von IANA MIME Media Typen | +-----------------------------+-----------------------------------+

robjSecEnum$displayNumSection("## Datenaustausch")
robjSecEnum$displayNumSection("### Austauschparameter")

Die Ausrüstung sollte für den Operator ein Interface anbieten, über welches folgende Austauschparameter abgefragt werden können. Für eine bestimmte Diestleistung geht es dabei um folgende Parameter:

Für einen bestimmten Dienstanbieter sollten die ausgetauschten Parameter gleich sein über alle angebotenen Dienstleisungen. 

robjSecEnum$displayNumSection("## Zugang zur Dienstleistung")

Da die Services nicht permanent verfügbar sind, sollte keine Anfrage geschickt werden, bevor nicht die folgenden Voraussetzungen überprüft sind

robjSecEnum$displayNumSection("### Datenübertragung")

Neue Daten sollten sobald als möglich verarbeitet werden. Solange Daten beim Dienstanbieter noch nicht verarbeitet werden konnten, soll der Client keine neuen Daten senden. Bei asynchroner Verarbeitung muss der Client auf eine Bestätigung (ticket) von Dienstanbieter warten.

Bestätigungen sollen nur zu vorgegebenen Zeiten an das Informationssystem geschickt werden. {Diese Aussage ist mir nicht klar. Entweder steht diese einfach isoliert da und dann ist aber nicht klar, weshalb Bestätigungen an das Informationssystem geschickt werden. Aus dem Kontext des vorangegangenen Abschnitts schickt das Informationssystem des Dienstanbieters Bestätigungen an den Client und nicht umgekehrt}

Meldungen oder Nachrichten (message), welche den syntaktischen Anforderungen nicht genügen, dürfen nicht gesendet werden.

Sobald Daten in einer Anfrage (request) integriert sind und von einer Antwort (response) beantwortet werden, sollen die Daten als gesendet betrachtet werden.

Dienstanbieter (Service providers) und Clients (consumers) sollten Datenupdates und Löschungen verarbeiten können. Der Dienstanbieter muss auch berücksichtigen, dass der Client die Updates als Neuerfassung von Daten deklariert, da der Client nicht wissen kann, welche Daten schon vorhanden sind. {Der Client kann die History der Operationen nicht wissen, deshalb macht die Operation des Updates aus Sicht des Clients keinen Sinn.}

Die Vorbereitung einer Anfrage (request) gemäss den gestellten Anforderungen (business requirements) sollte unabhängig von der Zusammenstellung einer Nachricht (message) deren Syntax von der gewählten Technologie (SOAP) abhängt, gemacht werden.

robjSecEnum$displayNumSection("### Verschlüsselung")

Die Datenübertragung soll verschlüsselt sein. Verschlüsselung wird hier nicht beschrieben. Datentransport soll über verschlüsselte Protokolle (HTTPS) erfolgen.

robjSecEnum$displayNumSection("### Komprimierung")

Zur Minimierung der Netzwerkauslastung sollen grosse Nachrichten komprimiert werden. Zur Verhinderung der Begrenzung der Kompression bei http wird ein spezifischer Kompressionsmechanismus (Siehe Abschnitt "Nachrichtendesign") entworfen.

robjSecEnum$displayNumSection("## Datenverarbeitung")

Dienste können in "real time" oder "verzögert" (time differed) angeboten werden. Antworten sollen innerhalb von wenigen Sekunden geschickt werden. Alle Requests und alle Antworten sollen von der Ausrüstung und vom Informationssystem gespeichert werden. Die Anforderungen für Updates auf der Datenbank kann sich zwischen Dienstanbietern unterscheiden. Alle Anfrage, welche nicht konform sind zu den folgenden Bedingungen sollen nicht verarbeitet werden. Folgende Konformitätsbedingungen sollen berücksichtigt werden:

robjSecEnum$displayNumSection("## Verifizierung der Benutzerrechte")

Benutzerrechte für die angebotenen Dienste sollen mit üblichen Funktionalitäten, wie Authentifizierungs-Schlüssel oder Benutzernamen/Passwort sichergestellt werden.

robjSecEnum$displayNumSection("## Spezifizierung der Anfrage")

Jede Anfrage soll aus drei Teilen bestehen

  1. Einzelner Message Header (siehe Einheit MessageHeader vom Typ ADEExchangedDocumentType im Abschnitt Datenbeschreibung). Der Sender einer Anfrage erstellt ein eineindeutige Nachrichten-ID (Typ ADEExchangedDocumentType.Identifier). Siehe "Best Praxis für MessageId Creation" weiter unten
  2. Eine Standard-Abfrage (siehe StandardRequest)
  3. Spezifischer Request, welcher entweder aus einem Ticket oder einer spezifischen Nachricht für einen bestimmten Dienst besteht oder eine gezippte spezifische Nachricht ist. 
rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "OrgSpezDiagramm5")

robjSecEnum$displayNumSection("## Spezifizierung der Antwort")

Jede Antwort soll aus drei Teilen bestehen:

  1. Nachrichten-Header
  2. Standard Antwort
  3. Spezifischen Antwort
robjSecEnum$displayNumSection("## \"Best Praxis\" für die Erstellung einer Nachrichten-Id")

{Das sollte wahrscheinlich "Best Practice" heissen}

Nachrichten-Ids von Clients und Dienstanbietern sollten global eindeutig sein, damit eine einfache Identifikation jeder Nachricht möglich ist. Dies vereinfacht die Rückverfolgbarkeit der Nachrichten und hilft bei der Fehlersuche.

Nachrichten-Ids sollten auf einer Kette von folgenden Bestandteilen bestehen

Es existieren verschiedene Tools in verschiedenen Programmiersprachen zur Erzeugung solcher IDs. (Z. Bsp. Guid.NewGuid() in C# {oder in Java existiert die Klasse UUID in java.util. Siehe http://stackoverflow.com/questions/2982748/create-a-guid-in-java oder http://kodejava.org/how-do-i-generate-uuid-guid-in-java/})

robjSecEnum$displayNumSection("## Behandlung lokaler Anforderungen (local requirements)")

Der ICAR ADE Standardisierungs-Prozess kann nicht all lokalen Anforderungen berücksichtigen. In erster Linie soll eine gemeinsame Basis geschaffen werden.

"Lokal" steht hier stellvertretend für nationale Standards. Es soll aber möglich sein, lokale Erweiterungen basierend auf speziellen Abmachungen zwischen Clients und Dienstanbietern hinzuzufügen.

Erweiterungen, welche die bestehenden Spezifikationen erweitern können auf zwei Arten hinzugefügt werden

  1. Lokale Kodierungslisten: Lokale Kodierungen für alle Einheiten des Typs udt:CodeType für welche ICAR noch keine akzeptierte Kodierung anbietet
  2. Lokale zusätzliche Daten: Liste von Schlüssel-Wert Paaren spezifische für eine Entität, welche für lokal benötigte Datenelemente verwendet werden.

Lokale Variationen sollten auf ein Minimum beschränkt werden, da diese der Bestrebung von ICAR entgegenlaufen einen globalen Standard zu etablieren. Lokale Unterschiede führen zu erhöhter Komplexität und zu zusätzlichen Kosten.

robjSecEnum$displayNumSection("### Lokale Kodierungen")

Lokale Kodierungen müssen für Elemente des Typs udt:CodeType im lokalen Kontext geliefert werden, z.Bsp. Rassencodes. Kontrollen und Validierungen müssen in separaten Programmen umgesetzt werden. Die Sicherstellung der Gültigkeit liegt in der Verantwortung der Entwickler.

Der Service GetLocalCodeList soll den Herstellern die Pflege und die Integration von lokale Kodierungen erleichtern. (Siehe den Abschnitt "Technische Services" für mehr Details)

robjSecEnum$displayNumSection("### Zusätzliche lokale Daten")

Zusätzliche von der ICAR Nachrichten-Spezifikation nicht vorgesehene Daten können über die Erweiterung LocalAdditionalData hinzugefügt werden. Dabei handelt es sich um Code/wert-Paare vom Typ udt:textType. Die Überprüfung der Korrektheit der Daten liegt in der Verantwortung der Entwickler oder Dienstanbieter. Die ICAR wsdl/xsd Definitionen können nur die XML Struktur überprüfen nicht aber den Inhalt.

robjSecEnum$displayNumSection("## Gemeinsame Komponenten")

Dieser Abschnitt beschreibt die Komponenten, welche von allen Services verwendet werden, welche im Abschnitt "Beschreibung der Dienste" beschrieben werden.

robjSecEnum$displayNumSection("### ADEEXCHANGEDDOCUMENTTYPE")

Die Komponente (entity) ADEExchangedDocumentType beinhaltet Informationen zu generellen Aspekten der Nachricht. Diese wird vom Datenelement MessageHeader verwendet. Das nachfolgende Diagram stellt die Komponente schematisch dar.

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "ADEExchangedDocumentType")

ADEExchangedDocumentType enthält folgende Bestandteile:

robjSecEnum$displayNumSection("### ADEPARTYTYPE")

Die Komponente ADEPartyType beinhaltet den Namen und die Identität der Partei, welcher entweder Sender oder Empfänger der Nachricht sein kann. Diese Komponente wird verwendet von SenderParty und RecipientParty. Im nachfolgenden Diagramm ist die Komponente AdePartyType dargestellt

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "AdePartyType")

AdePartyType enthält folgende Bestandteile

robjSecEnum$displayNumSection("### STANDARDREQUESTTYPE")

Die Komponente StandardRequestType repräsentiert den Standardinhalt einer Anfrage. Zwei verschiedene Typen von Authentifizierungen sind möglich, entweder Token-basierte oder Benutzernamen/Passwort basierte. Die Komponente wird vom Datenelement StandardRequest verwendet.

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "StandardRequest")

StandardRequestType enhält folgende Bestandteile

robjSecEnum$displayNumSection("### STANDARDRESPONSETYPE")

Die Komponente StandardResponseType stellt den Inhalt einer Antwort dar. Dieser Type wird vom Datenelement StandardResponse verwendet.

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "StandardResponse")

Bestandteile von StandardResponseType:

robjSecEnum$displayNumSection("### ERRORTYPE")

ErrorType beinhaltet die Art des Fehlers bei einer Anfrage. Dieser Typ wird vom Datenelement RequestProcessingError

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "ErrorType")

ErrorType hat folgende Bestandteile:

robjSecEnum$displayNumSection("### TICKETRESPONSETYPE")

Der Typ TicketResponseType repräsentiert ein Ticket, welches verwendet wird um eine Antwort zu bekommen. Dies wird bei der asynchronen Verarbeitung benötigt. Dieser Type wird von SpecificRequest und SpecificResponse vom Datenelement TicketResponse verwendet

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "TicketResponse")

Bestandteile von TicketResponseType

robjSecEnum$displayNumSection("### ZIPMESSAGETYPE")

ZipMessageType ist ein Wrapper fuer den Transport von komprimierten Daten

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "ZipMessage")

Bestandteile von ZipMessageType

robjSecEnum$displayNumSection("### LOCALADDITIONALDATATYPE")

Der Typ LocalAdditionalDataType ist ein Container für Paare von Codes und Werten für lokale Daten ausserhalb des Gülitgkeitsbereichs der ICAR Spezifikation. Es wird verwendet durch LocalAdditionalData

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "LocalAdditionalData")

Bestandteile 

robjSecEnum$displayNumSection("### TIMEPERIODTYPE")

TimePeriodType ist ein Wrapper für den Transport von Zeitpunkten (Beginn- und Endzeitpunkt)

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "TimePeriod")

Bestandteile:

\pagebreak

robjSecEnum$displayNumSection("# Beschreibung der Dienste (Service Description)")

{Die in diesem Abschnitt beschriebenen Dienste können in vier Gruppen eingeteilt werden.

  1. Melkvorgang
  2. Tierbewegungen
  3. Reproduktion
  4. Technische Dienste

Für den Austausch von Milchleistungsdaten sind vor allem die Dienste der ersten Gruppe relevant. Die Dienste rund um die Bewegungen der Tiere zwischen Standorten werden umgesetzt, um unterschiedliche Datenbestände zwischen ISMs und zentralen Datenbanken abzugleichen.}

robjSecEnum$displayNumSection("## Melkvorgang (Milking)")

robjSecEnum$displayNumSection("### Gemeinsame Komponenten (Common Components)")

MilkCharacteristicsType

Die Komponente {Wahrscheinlich ist hier Datenkomponente gemeint} Characteristics beinhaltet eine Liste von Characteristika eines Gemelks

{Diese Formulierung macht so noch keinen Sinn. Vermutlich wird hier folgende Bedeutung impliziert: Characteristics steht für eine Sequenz oder eine Liste von MilkCharacteristicsTypen. Die MilkCharacteristicsTypen sind eine Art von generischen Datentypen oder Datenrecords, welche für jedwelche Art von Messungen verwendet werden können. Diese MilkCharacteristicsTypen bestehen aus zwei Komponenten.

  1. ein Messwert
  2. ein Code, welcher den MilkCharacteristicsTypen referenziert.

NB: Was hier fehlt und was, z.Bsp. in den Data Dictionnaries der Melksystemanbieter vorkommt, ist die Angabe des Messzeitpunktes.}

Ein Charakteristikum vom Typ MilkCharacteristicsType wird als Synonym für ein Resultat einer Messung oder Klassierung von einer Milchprobe erhoben auf dem Hof oder im Labor. Dieser Typ kann auch zur Erfassung von Umweltbedingungen verwendet werden.

Das Charakteristikum wird durch einen eineindeutigen Code identifiziert, welcher auf die Definition nach der Codierungsliste "ICAR_MilkCharacteristicCode" referenziert. Eine bestimmte Anzahl solcher Definitionen ist von ICAR (Tabelle "Milk Characteristics Codes") vorgegeben. Diese Definitionen können aber auch durch lokale Charakteristika ergänzt werden.

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "MilkCharacteristics")

Bestandteile:

MilkCharacteristicsLocalType

Analog zu MilkCharacteristicsType ist dies ein Container für lokal verwendete Charakteristika, welche nicht im "ICAR Milk Characteristics Codes" aufgelistet sind. Komponenten sind

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "LocalMilkCharacteristics")

robjSecEnum$displayNumSection("### Beschreibung des Dienstes UpdateMilkingResult")

{Die nun folgenden Beschreibungen von Anfragen und Antworten beginnen häufig mit dem Satz, dass eine entsprechende Nachricht, eine Anfrage oder eine Antwort konsistent sei mit der entsprechenden generellen Spezifikation. Da diese Aussage sehr oft wiederholt wird, wird diese im folgenden nicht immer wieder angefügt. Falls explizite Abweichungen von generellen Spezifikationen erwähnt sind, sind diese auch aufgeführt.}

Zweck

Dieser Dienst (Service) soll dem Eigentümer der Melkausrüstung erlauben, dass ein externes Informationssystem sich registriert für

{Damit das externe Informationssystem Daten von der Melkausrüstung beziehen kann muss sich dieses zuerst beim Eigentümer der Melkausrüstung registrieren. Der hier beschriebene Service soll für diese Registration zuständig sein.}

Beschreibung der Anfrage

Diese Nachricht wird verwendet, um neue oder geänderte Daten von Melk-Ereignissen zum Dienstanbieter zu übermitteln

rqudocuhelper::insertOdgAsPdf(psOdgFileStem = "UpdateMilkingResultRequest")

{Dieses Diagramm wurde aus Auschnitten aus dem Original zusammengesetzt, damit es noch lesbar ist}

AnimalMilkingResults

beinhaltet die wesentlichen Eigenschaften für ein bestimmtes Gemelk (milking)

{Hier ist nicht klar, was mit Label gemeint ist. Bei der Datenübertragung ist es entscheidend, wer die Identität vergibt. Werden die Identitäten von jedem Betrieb vergeben, dann sind diese nur innerhalb des Betriebes eindeutig. Auf einem zentralen Informationssystem müssen die Betriebs-spezifischen Identitäten noch mit einer Betriebskennung ergänzt werden.}

{In der folgenden Darstellung sind die als nicht-optional deklarierten Komponenten einer AnimalMilkingResult Entität dargestellt. Mit Ausnahme der Entität Characteristics sind alles atomare Entitäten, d.h., diese haben keine weiteren Unterkomponenten.}

rmddochelper::insertOdgAsPdf(psOdgFileStem = "AnimalMilkResultMandatory")

Characteristics Diese Entität beinhaltet die Gemelk-Eigenschaften, welche während eines Melkvorgangs aufgezeichnet werden. Diese sind im Abschnitt "Gemeinsame Komponenten" beschrieben.

Beschreibung der Antwort

Die Antwort UpdateMilkingResultResponse dient zur Übermittlung und zum Empfang von Melk-Resultaten, wie sie vom Dienstleistungsanbieter verarbeitet werden.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "UpdateMilkingResultsResponse")

robjSecEnum$displayNumSection("### Dienstbeschreibung GetMilkingLabResults")

Zweck

Damit Betriebe Analyseresultate von externen Informationssystemen für Herdenmanagement oder Gerätekallibrierung bekommen können. Der Link zwischen Proben und den Analyseresultaten muss durch das Informationssystem der Aufzeichnungsorganisation (Serviceanbieter) zur Verfügung gestellt werden.

Beschreibung der Anfrage

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetMilkingLabResultRequest")

{Die im obigen Diagramm gezeigten Komponenten wurden schon einmal erkärt oder sind selbst-erklärend. Da dieser Service nicht in erster Priorität umgesetzt wird, verzichten wir auf eine weitere Beschreibung.}

Beschreibung der Antwort

{Die Antwort ist sehr ähnlich zu AnimalMilkingSample.}

robjSecEnum$displayNumSection("## Austausch von Tierdaten")

robjSecEnum$displayNumSection("### Anforderungen, Dienste und Nachrichten")

Eine korrekt geführte Liste aller Tiere in der Herde (im folgenden als Tierliste bezeichnet) ist eine Voraussetzung für eine zuverlässige Aufzeichnung von Tierdaten. Tierlisten auf der Melkausrüstung und auf dem Betriebs-Management-System (BMS) (farm management system) {dieser Begriff taucht hier zum ersten Mal auf und wurde nicht genauer definiert} weisen sehr wahrscheinlich Unterschiede auf. Gründe für solche Unterschiede sind

Der Business-Prozess Austausch von Tierdaten (Exchange of Animal Data) soll folgende Aufgaben erledigen:

Der Tierdatenaustausch stellt verschiedene Methoden zur Verfügung, welche helfen sollen die Daten auf der Melkausrüstung und im Betriebs-Managment-System synchron zu halten.

robjSecEnum$displayNumSection("### Gemeinsame Komponenten")

AnimalIdentityType

Diese Entität kann offizielle oder alternative Tier-Identifikationen beinhalten. Als primäre Identitäten {analog zu primary keys auf der Datenbank} sollen nur offzielle Identitäten verwendet werden. Alternative Identitäten werden nur verwendet um Veränderungen von Namen oder Betriebs-internen Nummern zu erkennen. Auf dem IS der Melkausrüstung werden oft Betriebs-interne Nummern oder Namen verwendet, welche nicht eindeutig sein müssen und wieder verwendet werden. Die Verwendung solcher Betriebs-internen Identitäten können zu Fehlern bei der identifikation von Proben führen.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "AnimalIdentityType")

{Die Bestandteile von AnimalIdentityType sind}

\pagebreak

AnimalCoreDataSetType

Diese Entität beinhaltet die Kern-Charakteristika eines Tieres.

{Die folgenden Darstellungen sind aus der Originalgraphik zusammengesetzt}

rmddochelper::insertOdgAsPdf(psOdgFileStem = "AnimalCoreDataSetType")

{Sire, RecipientDam und GeneticDam sind Instanzen von AnimalIdentityType}

\pagebreak

ArrivalCoreDataSetType

Diese Entität beschreibt den Zugang eines Tieres zu einem Standort (location) {damit ist wahrscheinlich ein Betrieb oder eine Herde gemeint}.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "ArrivalCoreDataSetType")

{Die einzelnen Komponenten sind wie folgt definiert}

\pagebreak

DepartureCoreDataSetType

Diese Entität beschreibt den Abgang eines Tieres von einem Standort.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "DepartureCoreDataSetType")

{Die einzelnen Komponenten sind wie folgt definiert}

\pagebreak

AnimalDescriptionType

Diese Komponente enthält die Beschreibung eines Tieres, aktuell sind darin Kern-Daten (core data), erweiterte Daten (extended Data) und Bewegungsdaten (movement data) enthalten. 

rmddochelper::insertOdgAsPdf(psOdgFileStem = "AnimalDescriptionType")

{Dieser Datentyp ist aus vorher definierten Komponenten zusammengesetzt. Die einzelnen Komponenten sind wie folgt definiert.}

\pagebreak

MovementRequest

Die Entität MovementRequest dient dazu optionale Parameter, welche die Grösse des Resultats einer Bewegungsantwort (movement response) bestimmen. Als Beispiel wird diese Entität in den Nachrichten GetArrival und GetDeparture verwendet. {Aus dieser Formulierung wird die Bedeutung der Entität nicht klar. Offenbar ist das einfach die Datenstruktur, welche bei den genannten Services GetArrival und GetDeparture zurückgeliefert wird.}

rmddochelper::insertOdgAsPdf(psOdgFileStem = "MovementRequest")

{Die im Diagramm gezeigten Komponenten sind wie folgt definiert.}

robjSecEnum$displayNumSection("### Servicebeschreigung: GetHerdList")

Zweck

Erlaubt es dem Besitzer der Melkanlage eine Tierliste zu bekommen, inklusive Bewegungsdaten, Reproduktionsdaten wie z. Bsp. die letzte Abkalbung oder die letzte Besamung. Die Resultate können durch die Angabe von Suchparametern, wie Standort, Geschlecht oder Zeitperiode eingegrenzt werden.

Anfragebeschreibung

Die Nachricht GetHerdListRequest wird verwendet für Anfragen nach einer Herdenliste {Liste aller Tiere in einer Herde} für einen bestimmten Standort im BMS. 

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetHerdListRequest")

Die Eingrenzung des Resultats wird über optionale Parameter gemacht.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "HerdListRequest")

{Die Komponenten sind wie folgt definiert}

\pagebreak

Antwortbeschreibung

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetHerdListResponse")

Der Container HerdListMessage beinhaltet die Beschreibung des Standorts (Location) und eine Liste von Tierbeschreibungen {im Container} HerdListAnimalDescription vom Typ AnimalDescription. 

robjSecEnum$displayNumSection("### Servicebeschreigung: UpdateHerdList")

Zweck

Erlaubt dem Eigentümer der Melkanlage Änderungen in der Herdenliste, inklusive Bewegungsdaten und Reproduktionsdaten an den Dienstanbieter zu übermitteln.

Anfragebeschreibung

Die Nachricht UpdateHerdListRequest ist konsisten mit den allgemeinen Spezifikationen für Anfragen.

Der Container HerdListMessage beinhaltet eine Standortangabe (Location), eine Liste von Tierbeschreibungen, welche an den Dienstanbieter übermittelt werden sollen.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "UpdateHerdList")

Antwortbeschreibung

Die Nachricht UpdateHerdListResponse wird verwendet um den Status der Verarbeitung der Herdenlistendaten durch den Dienstanbieter zu empfangen.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "UpdateHerdListResponse")

robjSecEnum$displayNumSection("### Servicebeschreigung: GetAnimal")

Zweck

Der Dienst GetAnimal ermöglicht es der Melkausrüstung Tierinformationen vom BMS zu erhalten

Anfragebeschreibung

Die Nachricht GetAnimalRequest macht eine Anfrage für Tierinformationen, welche auf dem BMS gespeichert sind.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetAnimalRequest")

Antwortbeschreibung

Die Nachricht GetAnimalResponse enthält die Informationen des Tiers, welches durch den Parameter AnimalIdentifier spezifiziert wird.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetAnimalResponse")

AnimalMessage enthält die Beschreibung des angeforderten Tieres.

robjSecEnum$displayNumSection("### Servicebeschreigung: UpdateAnimal")

Zweck

Der Dienst UpdateAnimal erlaubt es der Melkausrüstung Informationen an das BMS zu schicken.

Anfragebeschreibung

rmddochelper::insertOdgAsPdf(psOdgFileStem = "UpdateAnimal")

AnimalListMessage entspricht einer Liste von AnimalData {hier sollte es wahrscheinlich AnimalDetail heissen} Komponenten vom Typ AnimalListMessageType, welche die Details der Tiere, welche aktuell durch die Melkausrüstung verwaltet werden.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "AnimalDetail")

\pagebreak

Antwortbeschreibung

Nachricht UpdateAnimalResponse wird verwendet den Verarbeitungsstatus für Daten eines Tieres vom Dienstanbieter zu erhalten.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "UpdateAnimalResponse")

robjSecEnum$displayNumSection("### Servicebeschreigung: GetArrivals")

Zweck

Der Service GetArrivals erlaubt es dem Eigentümer der Ausrüstung Informationen über Zugänge eines Tieres zu einem bestimmten Standort zu erhalten.

Anfragebeschreibung

Die Nachricht GetArrivalsRequest wird verwendet die Liste von Zugängen von Tieren, welche auf dem BMS gespeichert sind, zu erhalten.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetArrivalsRequest")

Das Resultat der Anfrage kann durch die Angabe weiterer Parameter in der Entität MovementsRequest eingegrenzt werden.

Antwortbeschreibung Die Nachricht GetArrivalsResponse gibt eine Liste von Zugangsdaten, welche auf dem BMS registriert sind und welche durch verschiedene Parameter eingeschränkt werden können.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetArrivalsResponse")

robjSecEnum$displayNumSection("### Servicebeschreigung: UpdateArrivals")

Zweck

Der Dienst UpdateArrivals dient der Registrierung von neuen oder geänderten Ereignissen von Zugängen von Tieren zu Standorten im BMS.

Anfragebeschreibung

Eine Liste von Zugangsereignissen wird dem Dienstanbieter übermittelt.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "UpdateArrivalsRequest")

rmddochelper::insertOdgAsPdf(psOdgFileStem = "AnimalArrivalType")

{Folgende Komponenten sind in einem ArrivalDataSet enthalten}

Antwortbeschreibung

Die Nachricht UpdateArrivalsResponse wird verwendet den Status eines Zugangs zu einem Standort, welcher vom Dienstanbieter verarbeitet wird, zu empfangen.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "UpdateArrivalsResponse")

robjSecEnum$displayNumSection("### Servicebeschreigung: GetDepartures")

{Analog zu GetArrivals}

Zweck

Der Dienst GetDepartures erlaubt es dem Besitzer der Melkanlage eine Liste von Abgängen von Tieren von einem Standort zu erhalten.

Anfragebeschreibung

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetDeparturesRequest")

__Antwortbeschreibung

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetDeparturesResponse")

robjSecEnum$displayNumSection("### Servicebeschreigung: UpdateDepartures")

{Analog zu UpdateArrivals}

robjSecEnum$displayNumSection("## Austausch von Reproduktions-Ereignissen")
robjSecEnum$displayNumSection("### Anforderungen, Dienste und Nachrichten")

Die Überwachung und die Kontrolle der Reproduktion ist sehr wichtig in der Nutztierzucht. Dies basiert auf der Registrierung und auf der Analyse der folgenden Ereignisse

Bauern müssen

Genaue Überwachung der Reproduktion verlangt die Erfassung und die Übermittlung der Zeit zusätzlich zum Datum, in welchem das Ereignis auftritt.

robjSecEnum$displayNumSection("### Dienstbeschreibung: GETREPRODUCTIONEVENTS")

Zweck Erfassung der Reproduktions-Ereignisse.

Anforderung GetReproductionEventRequest ist kompatibel mit der allgemeinen Spezifikation von Anfragen.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "GetReproductionEventRequest")

Die Komponente ReproductionEventsRequest enthält die Parameter der Anfrage.

rmddochelper::insertOdgAsPdf(psOdgFileStem = "ParameterReproductionEventRequest")

Die Parameter beinhalten

robjSecEnum$displayNumSection("## Technische Dienste")

\pagebreak

robjSecEnum$displayNumSection("# Datenverzeichnis")

Die xsd-Dateien gelten als primäres r r6obj_transl$add_abbrev(psAbbrev="data dictionary", psMeaning="Datenverzeichnis"). Beschreibungen von Datenelementen müssen in den xsd-Dateien mittels xsd:document-Elementen zur Verfügung gestellt werden. Der folgende Ausschnitt gibt eine Beispiel für eine solche Beschreibung

rmddochelper::insertOdgAsPdf(psOdgFileStem = "XsdExample")

Aus den xsd-Dateien können html-Seiten erzeugt werden. In der Originalversion wurde das mit XMLSpy gemacht. Das Datenverzeichnis wird auf der ICAR-ADE Webseite publiziert werden.

\pagebreak

robjSecEnum$displayNumSection("# Anhang")

{Die folgende Übersichten zu den Themen WSDL, XSD und Web Service sind nicht Teil der ursprünglichen Spezifikation}

robjSecEnum$displayNumSection("## WSDL und XSD")

Hier wird eine kurze Übersicht zu WSDL (\url{https://de.wikipedia.org/wiki/Web_Services_Description_Language}) und XSD eingeschoben. Eine ausführlichere Beschreibung zum Thema Webservices ist in einem separaten Unterabschnitt des Anhangs zu finden.

WSDL ist eine Sprache zur Beschreibung von Netzwerkdiensten (Webservices). Die Sprache ist unabhängig von Plattform, Programmiersprache und Protokoll. Die beschriebenen Dienste tauschen Nachrichten auf der Basis von XML aus. WSDL beschreibt die angebotenen Funktionen, Daten, Datentypen und Austauschprotokolle eines Webservices. Es werden die Operationen definiert, welche von aussen zugänglich sind, sowie die Parameter und Rückgabewerte dieser Operationen. WSDL enthält funktionale Angaben zu

Beschreibungselemente sind:

XSD steht für XML Schema Definition und ist eine von W3C empfohlene Definition von Strukturen für XML-Dokumente.

\pagebreak

robjSecEnum$displayNumSection("## XSD/WSDL-Dateien in Eclipse")

Die graphischen Darstellungen der XSD- und WSDL-Dateien wurden in der Originalversion der Spezifikation mit dem kommerziellen Programm XMLSpy von Altova erstellt. Die open-source Entwicklungsumgebung Eclipse bietet auch gewisse Möglichkeiten XSD- und WSDL-Dateien graphisch darzustellen. Diese Möglichkeiten lassen sich einfach aufgrund des in Eclipse integrierten Beispiel-Projekts "Editing and Validating XML Document Example" aufzeigen.

robjSecEnum$displayNumSection("### Erstellung eines Beispielprojekts")

Ein Beispielprojekt wird mit dem Projekt-Wizard erzeugt. 

rmddochelper::insertOdgAsPdf(psOdgFileStem = "ExampleProjectWizard")

Durch das Öffnen des Beispielprojektes wurden Daten in den aktuellen Workspace von Eclipse kopiert. Im Unterverzeichnis "PublicationCatalogue" befindet sich die Datei "Catalogue.xsd"

rmddochelper::insertOdgAsPdf(psOdgFileStem = "ExampleProjectContent")

Durch einen Doppel-click auf "Catalogue.xsd" wird die Datei geöffnet. Der Dateiinhalt kann in zwei verschiedenen Ansichten betrachtet werden. In der "Source"-Ansicht erscheint der Dateiinhalt als XML-Datei. In der "Design"-Ansicht wird der Dateiinhalt graphisch dargestellt. In der graphischen Darstellung wird der Dateiinhalt in fünf verschiedene Sektoren unterteilt

  1. Directives
  2. Elements
  3. Types
  4. Attributes
  5. Groups
rmddochelper::insertOdgAsPdf(psOdgFileStem = "GraphCatalogueXsd")

Die unterstrichenen Elemente im oben gezeigten Screenshot sind aktiv und können per Doppel-Click noch weitere Informationen zum Vorschein bringen. Mit dem Home-Button oben rechts gelangt man wieder zurück zur ursprünglichen Ansicht.

\pagebreak

robjSecEnum$displayNumSection("## Web Service")

robjSecEnum$displayNumSection("### Motivation")

Durch den laufend steigenden Grad der Vernetzung kam schon früh der Wunsch auf Programme von einem Client aus auf einem Remote-Server ausführen zu können. Der Wunsch wurde einerseits durch die gesteigerte Effizienz, wenn Programme nur einmal geschrieben werden müssen und dann von vielen Clients ausgeführt werden können und andererseits können so auch zentralisierte Resourcen and verteilte Clients verfügbar gemacht werden.

robjSecEnum$displayNumSection("### Hintergrund")

Vorläufer von Webservices, die da hiessen r r6obj_abr$add_abbrev(psAbbrev = "RPC", psMeaning = "remote procedure call") oder r r6obj_abr$add_abbrev(psAbbrev = "RMI", psMeaning = "remote method invocation") hatten den oben formulierten Wunsch schon realisiert. Diese Ansätze waren aber wenig flexibel. Schliesslich wurden sie durch Web services abgelöst. 

robjSecEnum$displayNumSection("### Architektur")

Webservices orientieren sich an der sogenannten r r6obj_abr$add_abbrev(psAbbrev = "SOA", psMeaning = "serviceorientierten Architektur"). Der Begriff SOA ist nicht einheitlich definiert. Eine mögliche Definition, welche aus r knitcitations::citet("10.1007/978-3-8274-2550-8") entnommen wurde, lautet: "Unter einer SOA versteht man eine Systemarchitektur, die vielfältige und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachunabhängige Nutzung und Wiederverwendung ermöglicht." 

robjSecEnum$displayNumSection("### Web-Services Grundlagen")

r r6obj_abr$add_abbrev(psAbbrev = "SOAP", psMeaning = "Simple Object Access Protocol"), r r6obj_abr$add_abbrev(psAbbrev = "WSDL", psMeaning = "Web Service Description Language") und r r6obj_abr$add_abbrev(psAbbrev = "UDDI", psMeaning = "Universal Description Discovery and Integration") können als Grundlage oder als Basis eines Web-Service betrachtet werden. Diese stellen Umsetzungen der drei wichtigsten Komponenten einer SOA dar.

\pagebreak

if (!r6obj_abr$is_empty_abbr()) r6obj_abr$writeToTsvFile()

r6obj_abr$include_abbr_table(psAbbrTitle = "# Abkürzungen")

\pagebreak

if (!r6obj_transl$is_empty_abbr()) r6obj_transl$writeToTsvFile()
r6obj_transl$include_abbr_table(psAbbrTitle = "# Übersetzungen")

\pagebreak

References

sBibFile <- "IcarAdeSpezTransDe.bib"
if (!file.exists(sBibFile)) {
  knitcitations::write.bibtex(file=sBibFile)
  ### # replacements due to comilation errors
  fBibEntry <- file(description = sBibFile)
  vBibEntry <- readLines(con = fBibEntry)
  close(fBibEntry)
  ### # write substitutes references back to file
  cat(gsub("$\\mathplus$","and", vBibEntry, fixed = TRUE), "\n", file = sBibFile, sep = "\n")

}


pvrqualitasag/IcarAdeSpezTransDE documentation built on May 26, 2019, 11:34 a.m.

R Package Documentation

rdrr.io home R language documentation Run R code online

Browse R Packages

CRAN packages Bioconductor packages R-Forge packages GitHub packages

We want your feedback!

Note that we can't provide technical support on individual packages. You should contact the package authors for that.
GitHub issue tracker
ian@mutexlabs.com
Personal blog

 
Embedding an R snippet on your website

Add the following code to your website.

For more information on customizing the embed code, read Embedding Snippets.

Close