Lasst uns ein Import Modul erstellen

Was soll ein Import Modul können? Aus meiner Sicht muss es:

  • Es muss die Möglichkeit schaffen, pro Fima einen Importer zu definieren.
  • Ein Importer bekommt einen Link auf eine Import Datei.
  • Das Format der Import Datei wird von YAWIK vorgegeben. Es sollte ein JSON Format sein, welches durch das Job Entity definiert ist
  • Der importer muss feststellen können, dass eine Anzeige gelöscht wurde
  • Der Importer muss Anzeigen zwecks indizierung einlesen.

Die JSON Files selbst werden per scrapy crawler generiert.

Ich freue mich auf eure Ideen

Bei Import-Modul denke ich an den Import von strukturierten Daten (XML, CSV, JSON) z.B. aus anderer Recruiting-Software, von Jobbörsen oder Dienstleistern. Wenn ich den Link zu Scrapy verfolge, scheint es mir aber eigentlich um etwas anderes zu gehen (Abgreifen von Job-Anzeigen direkt von den Webseiten der Arbeitgeber).

Was wir auf jeden Fall bräuchten wäre ersteres: Wir haben Kunden, die uns XML-Daten aus ihrer Recruiting-Software zugänglich machen, die wir mehrmals täglich importieren und auswerten. In diesem Fall sollte das Import Modul einigermaßen generisch angelegt sein, so dass dann einzelne für jeden Kunden die spezifische Übersetzung des XMLs oder JSONs etc. in unsere Datenstruktur erfolgen kann. Das sieht dann so aus:

Kunden-XML -> Fetchen per HTTP(S) -> Umwandlung in unsere Daten-Struktur (in unserem Fall per XSLT) -> Auswertung (was ist neu/geändert/gelöscht).

Ist es das, was auch Dir vorschwebt?

Die Daten von Kunden sind mehr oder weniger strukturiert. Manchmal sagen
die aber auch nur, nehmen sie die Anzeigen von unserer Homepage. Das
Umwandeln von einem XML in eine andere Struktur per XSL ist auch eine
Kunst für sich.

Aus meiner Sicht sollte YAWIK das Ziel Format definieren und das Mapping
übernehmen.

Scrapy übernimmt das Einsammeln der Daten und die Umwandlung in ein
definiertes Format. Im einfachsten Fall ein Feed mit Job Entity als JSON.

Das Import Modul muss sich keine Gedanken über das Protokoll,
Authentifizierung oder das Format machen. Es kann davon ausgehen, dass
die Daten vorliegen. Programmiert werden muss nur das Mapping von
Kategorien und die Definition von Default Werten.

Die Aufgabenstellung “Hole mir die Daten unter XYZ ab und wandel Sie mir
in genau dieses Format” lässt dich prima mit scrapy erledigen. Und es
gibt viele die das können. Auch wenn Kundendaten in Form von XML oder
CSV vorliegen, müsste man zielich viel programmieren.

Das Import Modul kann man mit Sicherheit erweitern, so dass es CSV
importieren kann. Ich glaube aber der Aufwand ist größer, als jemanden
zu finden und das CSV in das JSON umzuwandeln.

D

Ich stimme @cbleek zu.

Wir sollten uns darauf konzentrieren, den Import EINES Formats zu ermöglichen und die nötige Umwandlung von Middleware erledigen lassen.

Ja, über EIN Format zu gehen ist natürlich sinnvoll. Ich wollte ja nur sicherstellen, dass ein Import Modul so angelegt wird, dass dann Plugins/Middleware für verschiedene Formate verwendet werden können. JSON ist im Job-Segment echt noch kein verbreitetes Format. Solange daran gedacht ist, dass über Middleware auch XML verarbeitet werden kann, bin ich voll einverstanden.

Bei uns funktioniert die Import-Funktion folgendermaßen:
Nachdem das XML gefetcht und in unsere Struktur umgewandelt wurde (das wäre dann vor dem Import Modul), werden neben den eigentlichen Anzeigen-Daten folgende Metadaten in einer (MySQL-)Tabelle gespeichert:

  1. “datensatz zuerst gesehen” (Timestamp): Wann ist der Datensatz erstmalig in diese Tabelle importiert worden
  2. “datensatz zuletzt gesehen” (Timestamp): Wann wurde der Datensatz letztmalig vom Kunden geholt
  3. “letzter live Abgleich” (Timestamp): Wann wurden Änderungen am Datensatz das letzte Mal in die “live” Datenbank übertragen
  4. “ID der Anzeige in der live DB”
  5. “Kunden-ID der Anzeige”: Diese ID wird auch in der live DB hinterlegt
  6. “Rohdaten Hash”: MD5 der Datei beim Kunden
  7. “Unser Daten Hash”: MD5 in unserer Datenstruktur (wird ebenfalls in der live DB hinterlegt, so dass Abweichungen zwischen den live Daten und der Import-Tabelle nachvollzogen werden können).

Wird eine ungeänderte Anzeige (identische 6) vorgefunden, so wird lediglich (2) aktualisiert.
Ansonsten wird ein neuer Datensatz angelegt, wobei (5) als Schlüssel dient, um zu erkennen welcher Anzeige in der live Datenbank mit dem Datensatz verbunden ist.
Wird eine Anzeige in der live Datenbank gefunden, die nicht mehr aktuell beim Kunden gefunden wird (älterer Timestamp von 2), oder wird eine Änderung von (6) oder (7) festgestellt, so erhalten wir eine entsprechende Info-Mail.