Korrekturen

Änderungsliste aus dem Bug-Tracker:

• 0000025: [SQL-Schema] Mehrsprachige Erfassung von Ländern – erledigt.
• 0000026: [SQL-Schema] Umstellung der Datentypen von Längen- & Breitengraden im MySQL-Schema – erledigt.

Aktualisierungen

Die SQL-Daten von Immobilienarten / Vermarktungsarten / Attributen wurden auf den aktuellsten Stand gebracht. Mit ImmoTool 0.9.11 kam es hier an einigen wenigen Stellen zu Änderungen.

Weitere Informationen & Downloads…

… sind im OpenEstate-Wiki hinterlegt.

OpenEstate-SQL v0.2

Es handelt sich um einen Entwurf!

Dieser Entwurf erhebt keinerlei Anspruch auf Vollständigkeit oder Korrektheit! Im Zuge der weiteren Entwicklung kann diese Spezifikation sich noch weiter verändern.

Was wurde geändert?

Datenstrukturen wurden auf den aktuellsten Stand gebracht

In den letzten Wochen wurden Erweiterungen an der Spezifikation vorgenommen – hauptsächlich im Zusammenhang mit Mehrsprachigkeit. Desweiteren gab es diverse Änderungen im Detail:

• Versions-Nummern für Immobilien & Ansprechpartner können erfasst werden.
• Foreign-Key-Definitionen wurden überarbeitet (bessere Kompatibilität mit dem SQL-Standard).
• Benennung von Tabellen & Feldern wurden mit der XML-Spezifikation angeglichen.
• Feld-Definitionen wurden korrigiert (Default-Werte, NOT NULL, Indizes, etc.).

SQL-Dumps können heruntergeladen werden

Erstmals können zwei SQL-Dumps heruntergeladen werden, um OpenEstate-SQL in eine Datenbank zu übernehmen. Neben den Tabellenstrukturen, steht ein zweiter SQL-Dump mit den automatisch generierten Spezifikationsdaten von OpenEstate zur Verfügung.

Weitere Informationen im Wiki

Weitere Informationen und Möglichkeiten zum Download finden Sie auf der Projektseite im OpenEstate-Wiki.

Update: Kurzfristige Korrektur

Ein Definitionsfehler hatte sich eingeschlichen, der mit Version 0.2b korrigiert wurde.

Wo finde ich die API-Dokumentation?

Die Dokumentation steht unter folgender Adresse zur Verfügung: http://media.openestate.org/OpenEstate-API/

An wen richtet sich die API-Dokumentation?

Primär sollen Entwickler angesprochen werden, die eigene Add-Ons / Module für das ImmoTool entwickeln möchten. Auf Grundlage der API-Dokumentation werden wir im OpenEstate-Wiki entsprechende Anleitungen verfassen und Beispielquelltexte hinterlegen.

Wie ‘stabil’ ist die API?

Da sich das OpenEstate-Projekt noch in einem frühen Entwicklungsstadium befindet, ist mit Änderungen & Umstellungen an der API zu rechnen. Für Modulautoren gibt es verschiedene Mechanismen, um Inkompatibilitäten zu vermeiden. Diese werden wir im OpenEstate-Wiki demnächst ausführlicher erläutern.

Wie ausführlich ist die API dokumentiert?

Die Dokumentation beschränkt sich momentan hauptsächlich auf die von javadoc erzeugten Ausgaben. Nach und nach werden weitere Dokumentationen zu Klassen / Methoden / Feldern hinterlegt werden.

Achtung: Aus lizenzrechtlichen Gründen sind die XML-Implementierungen von OpenImmo & ImmoXML nicht Bestandteil der API-Dokumentation!

Wie häufig wird die Dokumentation aktualisiert?

In der Regel wird die Dokumentation mit jeder Aktualisierung des ImmoTools neu erzeugt werden. Unter Umständen kann es auch Ausnahmen von dieser Regelung geben. Das Erzeugungsdatum wird in der API-Dokumentation dargestellt.

OpenEstate-SQL v0.1

Es handelt sich um einen Entwurf!

Dieser Entwurf erhebt keinerlei Anspruch auf Vollständigkeit oder Korrektheit! Im Zuge der weiteren Entwicklung kann diese Spezifikation sich noch weiter verändern.

Darf ich den Entwurf in meinem Projekt verwenden?

Es steht Ihnen frei unsere Entwürfe in Ihr Projekt zu übernehmen. Über eine Verlinkung des OpenEstate-Projektes im Gegenzug würden wir uns sehr freuen.  Als Bestandteil der Referenz-Implementierung werden wir in Zukunft Quelltexte bereitstellen, welche die OpenEstate-SQL-Datenstrukturen lesen & schreiben können.

Projektseite im OpenEstate-Wiki

Auf der Projektseite im OpenEstate-Wiki werden aktuelle Informationen hinterlegt.

Fragen, Kritik oder Anmerkungen?

Hinweise jeder Art können als Kommentar hier im Blog oder via Ticketsystem mitgeteilt werden.

Wie funktioniert der Schnittstellenimport?

Der allgemeine Ablauf

Das ImmoTool gibt seinen Anwendern eine halbautomatische Lösung zum Import von Schnittstellendaten an die Hand. Die Daten werden automatisch importiert, ohne dass der Anwender sich über Dinge wie FTP, XML, ZIP oder Base64 Gedanken machen müsste. Vom Datenempfänger (in der Regel ein Immobilienportal) muss lediglich eine Schnittstellen-Datei (XML oder INI) heruntergeladen, die vom Anwender direkt ins ImmoTool importiert werden kann.

Teilnahme erwünscht!

Jeder Portalbetreiber, Software-Entwickler, Franchiser, etc. ist dazu eingeladen diesen Mechanismus in seinem Angebot umzusetzen. Reduzieren Sie damit unnötigen Supportaufwand und bieten Sie Ihren Kunden eine zuverlässige und problemlose Schnittstelleneinrichtung!

Unter welchen Lizenzbedingungen kann diese Spezifikation verwendet werden?

Die Schnittstellen-Spezifikation kann unter den Bedingungen der LGPL-Lizenz (siehe inoffizielle Übersetzung) frei verwendet werden. Die Implementierung des Standards ist mit keinerlei Lizenzkosten oder Verpflichtungen für Sie verbunden! Details entnehmen Sie bitte den Lizenztexten oder können via Ticketsystem erfragt werden.

Schnittstellen-Dateien

Die Datei sollte so einfach wie möglich gestaltet werden, um den Implementierungsaufwand so gering wie möglich zu halten. Aus diesem Grund haben wir uns dazu entschieden die Daten durch einfache Paare aus Key=Value abzubilden. Für die Zukunft ist es angedacht, die Schnittstellen-Spezifikation in den OpenEstate-Standard zu integrieren.

Beispiel einer Schnittstellen-INI

# Diese Datei wurde automatisch von iHanse.de erzeugt.

# Allgemein
title=iHanse.de
active=true
limit=0

# Export
export=openestate_xml
export.imagemode=file
export.zipped=true

# Transport
transport=ftp
transport.ftp.host=import.ihanse.de
transport.ftp.port=21
transport.ftp.path=/
transport.ftp.user=*********
transport.ftp.pass=*********
transport.ftp.anonymous=false
transport.ftp.passive=false

Beispiel einer Schnittstellen-INI.
Hinweis: Damit eine solche Datei vom ImmoTool importiert werden kann, muss der Dateiname auf ‘.properties’ oder ‘.ini’ enden.

Beispiel einer Schnittstellen-XML

  Diese Datei wurde automatisch von iHanse.de erzeugt.

  
  iHanse.de
  true
  0

  
  openestate_xml
  true
  file

  
  ftp
  import.ihanse.de
  21
  /
  *********
  *********
  false
  false

Beispiel einer Schnittstellen-XML.
Hinweis: Damit eine solche Datei vom ImmoTool importiert werden kann, muss der Dateiname auf ‘.xml’ enden.

Schnittstellen-Datei in Java einlesen

java.io.File xml = new java.io.File( "import.xml" );
java.util.Properties p = new java.util.Properties();
if (xml.getName().toLowerCase().endsWith( ".xml" ))
  p.loadFromXML( new java.io.FileInputStream( xml ) ); // XML-öffnen
else
  p.load( new java.io.FileInputStream( xml ) ); // INI-öffnen

Schnittstellendatei in ein Java-Properties-Objekt einlesen.
Durch Verwendung der Java-Properties können die Schnittstellen-Formate mit wenigen Zeilen Java-Code eingelesen und weiterverarbeitet werden.

Dokumentation der verwendbaren Keys

Eine Schnittstellen-XML-Datei ist momentan ein einfaches Key-Value-Mapping. Die unterstützten Keys werden im Folgenden zusammengefasst.

Allgemeine Parameter

title (String)
Ein frei wählbare Bezeichnung der Immobilien-Schnittstelle. In der Regel sollte hier der Name des Empfängerportals angegeben werden.

active (Boolean)
Die Immobilien-Schnittstelle kann nach dem Import in der Software aktiviert / deaktiviert werden. In der Regel sollte hier ‘true’ gewählt werden.

limit (Integer)
Welches Immobilienkontingent ist beim Empfängerportal gebucht. Dieses Limit wird beim Datenexport von der Software nicht überschritten. Wenn 0 angegeben wurde, findet ein unlimitierter Immobilientransfer statt. In der Regel sollte hier das gebuchte Kontingent des Anbieters im Portal eingetragen sein.

Parameter zum Datenexport

export (String)
Dieser Wert gibt an, in welchem Format die Immobiliendaten exportiert werden sollen. Mögliche Werte sind:

• openestate_xml: Zum Export im OpenEstate-XML-Format
• openimmo_xml: Zum Export im OpenImmo-XML-Format

export.imagemode (String)
Dieser Wert gibt an, in welchem Format die Bildanhänge aufbereitet werden sollen. Mögliche Werte sind:

• file: Die Bilder werden als separate Dateien ausgeliefert.
• base64: Die Bilder werden im Base64-Format in die Export-Datei integriert. (Insofern die Schnittstelle in export dies unterstützt.)
• disabled: Keine Bildanhänge werden ausgeliefert.

export.zipped (Boolean)
Die erzeugten Exportdateien sollen zu einer ZIP-Datei zusammengefasst werden.

Parameter zum Datenexport via OpenImmo-XML

export.openimmo.agent_id (String)
In der erzeugten OpenImmo-XML wird dieser Wert im XML-Element /openimmo/anbieter/anbieternr eingetragen. Einige Datenempfänger benötigen diese Information zur automatischen Verarbeitung.
Diese Option wird nur verwendet, wenn export = openimmo_xml gewählt wurde.

export.openimmo.openimmo_agent_id (String)
In der erzeugten OpenImmo-XML wird dieser Wert im XML-Element /openimmo/anbieter/openimmo_anid eingetragen. Einige Datenempfänger benötigen diese Information zur automatischen Verarbeitung.
Diese Option wird nur verwendet, wenn export = openimmo_xml gewählt wurde.

export.openimmo.techn_mail (String)
In der erzeugten OpenImmo-XML wird dieser Wert im XML-Attribut /openimmo/uebertragung/@techn_email eingetragen. Einige Datenempfänger benötigen diese Information zur Versendung von Fehlerprotokollen.
Diese Option wird nur verwendet, wenn export = openimmo_xml gewählt wurde.

Parameter zum Datentransport

transport (String)
Der Art des Transport wird hier angegeben. Mögliche Werte sind:

• ftp: Transport der erzeugten Daten via FTP
• http: Transport der erzeugten Daten via HTTP-POST

Parameter zum Datentransport via FTP

transport.ftp.host (String)
Hostname / IP-Adresse des FTP-Servers.
Diese Option wird nur verwendet, wenn transport = ftp gewählt wurde.

transport.ftp.port (Integer)
Port-Nr des FTP-Servers.
Diese Option wird nur verwendet, wenn transport = ftp gewählt wurde.

transport.ftp.path (String)
Zielpfad auf dem FTP-Server.
Diese Option wird nur verwendet, wenn transport = ftp gewählt wurde.

transport.ftp.user (String)
Login-Name zur Anmeldung am FTP-Server.
Diese Option wird nur verwendet, wenn transport = ftp gewählt wurde.

transport.ftp.pass (String)
Login-Passwort zur Anmeldung am FTP-Server.
Diese Option wird nur verwendet, wenn transport = ftp gewählt wurde.

transport.ftp.anonymous (Boolean)
Anonymen FTP-Transfer aktivieren. (kein Login nötig)
Diese Option wird nur verwendet, wenn transport = ftp gewählt wurde.

transport.ftp.passive (Boolean)
Passiven FTP-Transfer aktivieren.
Diese Option wird nur verwendet, wenn transport = ftp gewählt wurde.

Parameter zum Datentransport via HTTP

transport.http (String)
Die Art der HTTP-Anfrage wird hier spezifiziert:

• put: Sendet einen HTTP-PUT-Request. (siehe auch mod_actions, mod_put)
• post: Sendet einen HTTP-POST-Request.

transport.http.url (String)
URL zum HTTP-/HTTPS-Server.
Diese Option wird nur verwendet, wenn transport = http gewählt wurde.

transport.http.user (String)
Benutzername zur Basic Authentifizierung.
Diese Option wird nur verwendet, wenn transport = http gewählt wurde.

transport.http.pass (String)
Passwort zur Basic Authentifizierung.
Diese Option wird nur verwendet, wenn transport = http gewählt wurde.

transport.http.anonymous (Boolean)
Keine Authentifizierung am HTTP-Server durchführen (anonyme Übertragung).
Diese Option wird nur verwendet, wenn transport = http gewählt wurde.

Parameter zum Datentransport via HTTP-POST

transport.http.post.multipart (Boolean)
Dateiübertragung als multipart/form-data durchführen.
Diese Option wird nur verwendet, wenn transport = http und transport.http = post gewählt wurde.

transport.http.post.multipart.key (String)
Name der Variablen im Uploadformular bei multipart/form-data-Übertragungen.
Diese Option wird nur verwendet, wenn transport = http und transport.http = post gewählt wurde.

Fragen oder Probleme?

Bei Unklarheiten, Fehlerhinweisen oder Korrekturbedarf, helfen wir Ihnen gern weiter – eine Mitteilung via Ticketsystem oder ein Kommentar hier im Blog genügt.

Letzte Änderungen

• 22.06.2009: Spezifikation erstmaligst als v1.0 veröffentlicht.