Schnittstelle zum Import von Daten eines Robots/Spider?

Das sollte weitgehend tun, was du dir wünschst.

Beim Löschen gibt es aber ein Problem.
Wenn etwas nicht existiert, kann es auch nichts triggern.
Du könntest löschen, wenn seit einer gewissen Zeit kein Update gewesen ist.
Das wirst du in einem eigenen Minimodul realisieren müssen. Vielleicht geht es auch mit den Bordmitteln von Rules.

Hallo Ronald,

danke für die Antwort. Mit Feeds habe ich bisher nur per CSV importiert.

Es wäre mir aber am liebsten wenn die Daten vom Bot in einer Datenbank zwischengespeichert werden.

Ich habe gerade nachgeschaut aber ein Import über SQL/Datenbank per Feeds scheint nicht möglich zu sein oder?

Grübelnde Grüße

oder export der Tabelle in eine CSV, und dann import.
Da gibt es viele Möglichkeiten. Im Extremfall ein eigenes Modul.

Feeds kann vieles vor allem auch in Kombination mit Zusatz-Modulen (siehe Feeds SQL). Im beschriebenen Szenario ist somit ein Umweg über CSV unnötig.
Es wäre sogar denkbar, daß Feeds direkt den Crawler unnötig machen könnte, aber da hänge ich mich jetzt nicht rein in eine Recherche.

Ich habe die letzten Tage am Perl-Spider gecodet und bin fast fertig. Die Fremdprofildaten werden gespidert, extrahiert, aufbereitet und standatisiert un dann in die Datenbank geschrieben.

Der Tip von Carsten war perfekt denn Feeds SQL ist super geiegnet für mein Vorhaben - damit bekomme ich diese Daten dann importiert und zu Nodes verarbeitet [Danke Carsten!].

Das Löschen der Profile, die auf den Ursprungsprofillisten nicht mehr vorhanden sind, werde ich höchstwahrscheinlich mit VBO machen [Execute arbitrary PHP script). Ich muss nur mal schauen ob man VBO auch über Cron steuern kann, ich meine, dass ich das mal irgendwo gelesen habe.

Danke für eure Hilfe!

Man kann Views mittels VBO als DB-Abfragen in Rules nutzen.
Event: Cron, Condition: evtl. Zeitraum, Action: Liste per Views laden, Loop auf Liste (ist wie wie foreach auf Array). Im Loop Bearbeitungs-Rule aufrufen.

Hallo Carsten,
vielen Dank für den Hinweis auf Rules und Views (in Zusammenhang mit VBO). Das hört sich sehr interessant an und das werde ich auf jeden Fall ausprobieren.

Ich hätte aber nochmal eine Frage zu Feeds SQL .... weißt Du zufällig ob man über den Query, den man dort verwendet, auch in die externe Datenbank (aus der ausgelesen wird) schreiben kann?

Ich möchte in jedem Datensatz, der von Feeds SQL schon ausgelesen wurde (in einer extra Spalte) die NID speichern (die der Node, der daraus in Drupal generiert wurde, hat).

Schritt 1: lies aus externen Datenbank den jeweiligen Datensatz aus
Schritt 2: Erstelle daraus den Node in Drupal
Schritt 3: Wenn Node fertig - nimm die NID und schreibe sie in eine extra Spalte in der externen Datenbank

Weißt Du ob soetwas möglich ist?

Danke schonmal und viele Grüße
Matthias

Ich habe selbst noch nicht mit "Feeds SQL" gearbeitet. Bei meinen komplexeren Import-Tasks schreibe öfter schnell mal eine Custom Import Funktion. Ich habe aber in der hiesigen Usergroup schon mal ein Vortrag gesehen, bei dem zusätzlich auch noch Tricks mit Feeds Tamper gezeigt wurden. Dazu gibt es auch noch eine PHP-Erweiterung, die vllt, das custom Programming stark reduzieren kann (wofür ich immer bin).

Hallo Carsten,

Feeds Tamper nutze ich - die PHP-Erweiterung allerdings noch nicht.

Steht Feeds Tamper die NID denn schon zur Verfügung wenn es die Daten aufbereitet - sprich - kann ich da schon auf die NID zugreifen und sie eventuell über PHP-Code (und INSERT) an die Datenbank senden? Ich dachte, dass das alles vorm Node speichern erfolgt und die NID noch nicht verfügbar ist oder liege ich da falsch?

Eine Entity ID wird erst vergeben, wenn das Object gespeichert wird. Da arbeitet dann Drupal mit der Datenbank zusammen. es könnte ja sonst parallele Prozesse geben, die separat hochzählen.
Wenn es bei Feeds keine Art Post Prozess nach Verarbeitung eines Datensatz gibt (weiß ich gerade nicht) dann könnten die Karten schlecht stehen, daß dieser Rückwert mit Feeds direkt bearbeitbar ist.
Wenn die Nicht-Drupal-Daten trotzdem eine eigene ID haben, die diese nachträglich aufspürbar machen, dann würde ich diese beim Node speichern z.B. in einem einem Standard-Feld, das man auch per GUI anlegen kann (kann ja auch versteckt sein).
Dann würde ich evtl. mit Rules eine Art Post-Process abbilden, der dann nach Speichern eines neuen Nodes operiert (evel. mit Condition auf gesetztes neues Hilfs-Feld), dann evlt. mit Custom PHP eine separate Funktion aufrufen zum Löschen in der zweiten DB. Als letzte Action könnte das Hilfsfeld auch wieder gelöscht werden.
Aber evtl. bietet auch Feeds hier noch Hilfen, die ich gerade nicht kenne.