Zapier -> wie werden Objekte gespeichert?

[internet]

Hallo,

ich versuche zu verstehen, wie Zapier (Zapier.com) im Hintergrund funktioniert.
Primär geht es darum, wie die durchgereichten Objekte gespeichert werden in der Datenbank, sodass zu einem späteren Zeitpunkt wieder darauf zugegriffen werden kann.

Nehmen wir das Beispiel mit dem Video:

1) Eine neue Datei wird in einen bestimmten Ordner bei Dropbox hochgeladen
2) Die Datei wird in Google Drive hochgeladen

Was ich nun gerne verstehen würde, wie das Objekt durchgereicht wird.
Wenn der ganze Ablauf in einer Transaktion abläuft, würde ich es ja noch verstehen.

Dann habe ich einfach ein Objekt:

private Object object;

Nun kann es aber ja sein, dass der nächste Step in dem Workflow erst nach Tagen durchgeführt wird.
Dann werde ich

private Object object;

nicht mehr im Speicher haben.

Daher frage ich mich, wie wird später wieder auf das Objekt zugegriffen, primär auch: wie wird das in der Datenbank gespeichert?

Ich könnte mir vorstellen, dass ich eine Datenbanktabelle haben:

AutomationRelatedObject

• ID
• uniqueName
• ObjectType
• ObjectId
• AutomationCreatedId (ID des Workflows, in der das Objekt zum ersten Mal genutzt wurde).

Prinzipiell könnte ich mir das so vorstellen.
Aber dann braucht es ja einige Funktionen um immer wieder auf das Objekt zugreifen zu können.
In dem Beispiel oben, brauche ich ja dann wiederum einen Aufruf auf die Dropbox API um das entsprechende Objekt zu laden, denn ich denke nicht, dass Zapier das File in deren App wiederum persistiert?

Vielleicht hat jemand ein paar Ideen Anregungen 🙂

 

[LimDul]

Im Detail gibt es zig Möglichkeiten. Es wird nicht "das Objekt" gespeichert. Sondern es werden die notwendigen Informationen gespeichert. Das wird zum großen Teil über API-Callbacks laufen, z.B. in dem Beispiel das Dropbox sich bei Zafier meldet es wurde was hochgeladen. Und daraufhin läuft eine Logik, das nach Google Drive transferiert.

Der Fokus auf die Datenbank ist meines Erachtens vollkommen falsch. Es geht hier um Prozess-Automatisierung. Das heißt der Fokus muss auf dem Prozess liegen (der wird gespeichert) nicht irgendwelche Dateien. Und was da persistiert wird ist stark abhängig was an Informationen die jeweiligen APIs brauchen/liefern. Das heißt man muss sich sowas hier anschauen: https://www.dropbox.com/developers/documentation/http/documentation und vor allem hier: https://www.dropbox.com/developers/reference/webhooks

 

[internet]

Ich glaube dann hast du mich falsch verstanden.
Mir geht es nicht darum das Objekt physikalisch zu speichern, sondern wie du selbst sagtest die Infos zum Objekt zu speichern.
Wie könnte das in der Datenbank dann aussehen? Wie sollte die Tabelle aussehen…?
Sodass ich von jedem Prozess des Workflow entsprechend zugreifen kann.
Wie weiß mein aktueller Prozess auf welches Objekt er zugreifen muss?

Mir ist quasi nicht klar, wie die Beziehung in der Datenbank hier modelliert wird zu dem Prozess zu diesem Objekt.

 

[LimDul]

So wie entsprechend notwendig. Die beiden Links sind dafür schon gut: https://www.dropbox.com/developers/reference/webhooks & https://www.dropbox.com/developers/documentation/http/documentation

Eine Datei in Drop Box hat eine eindeutige ID. Genau die speichert man - ggf. mit Metadaten, die man nicht extra jedes abrurfen will

 

[mihe7]

Wie weiß mein aktueller Prozess auf welches Objekt er zugreifen muss?

Ich verstehe die Frage irgendwie nicht wirklich. Theoretisch musst Du gar nix speichern, weil Du die Informationen ja über den Webhook mitgeteilt bekommst bzw. ermitteln kannst.

 

[internet]

Ok, allgemein gefragt:
Die Frage ist wie Zapier oder ein anderes Automatisierungstool für SQL Tabellen hat um die Infos zu den einzelnen Workflows zu speichern.

Dass die Objekte (wie Videodatei) etc. nicht gespeichert werden, sondern immer dann per API (zB von Dropbox) abgerufen werden, ist mir klar 🙂

 

[LimDul]

Allgemeine Antwort: So wie notwendig. Es gibt 1000 und eine Möglichkeit. Man modelliert sein Datenmodell - daraus ergeben sich die Tabellen.

Ich gehe davon aus, dass so ein Tool wie Zafir vermutlich über 100 Tabellen hat, wenn nicht deutlich mehr.

Es gibt eine Prozess-Definition, die auf beliebig viele Tabelle aufgeteilt ist, vermutlich mit einer Root Tabelle und zig Assoziationen/Kompositionen dran.

 

[internet]

Ich gehe davon aus, dass so ein Tool wie Zafir vermutlich über 100 Tabellen hat, wenn nicht deutlich mehr.

Kann ich mir nicht vorstellen. Das hat eine geringe Anzahl von Tabellen. Die Infos für den jeweiligen Workflow werden m.E. als JSON Objekt in der Datenbank abgelegt.

Siehe auch bei N8N:

Understand the database | Deploy | n8n Docs

Understand the n8n database structure

docs.n8n.io

 

[LimDul]

Genau das meine ich mit zig Möglichkeiten. Ich kann es rein SQL ausmodellieren, dann habe ich viele Tabellen und ein strukturiertes SQL Modell. Ich kann auf nosql setzen. Oder auf was beliebiges dazwischen. Das sind alles valide Ansätze, die auf DB Ebene komplett unterschiedlich aussehen. Deswegen ist die Frage in der Form nicht zu beantworten

 

[mihe7]

@internet Du brauchst Dir doch bloß mal so ein Tool gedanklich modellieren. Machen wir es uns mal einfach: das Ding stellt einen Endpoint für Webhooks zur Verfügung, dabei muss der Workflow identifiziert werden. Die URLs könnten dann z. B. so aussehen: http://localhost/wh/<workflow-id> (localhost ist hier natürlich nur ein Stellvertreter)

Wie funktioniert so ein Tool? Letztlich ist es ein Sammelsurium aus Plugins. Ein Workflow ist nun einfach eine Abfolge von Schritten, wobei jeder Schritt von einem Plugin bearbeitet wird.

Heißt: Du brauchst im Endeffekt nur eine plugin-unabhängige Möglichkeit, den Workflow, die Schritte und das zuständige Plugin zu identifizieren, das könnte z. B. eine Workflow-ID + Schritt-ID + Plugin-ID sein.

Nehmen wir mal an, die Dropbox meldet ein Ereignis auf http://localhost/wh/421. Dann wird der Workflow 421 geladen, der aus, sagen wir mal, drei Schritten besteht: für Schritt 1 ist das Dropbox-Plugin zuständig, das ist der Trigger. Dieses Plugin könnte aus dem JSON, das Dropbox übermittelt, z. B. die URIs der neuen Dateien auslesen. Die Info geht nun an Schritt 2. Dort ist es z. B. das Google Drive Plugin. Ein Upload usw. Und Schritt 3 gibt dann eine Meldung an einen Instant Messenger aus, z. B. Whatsapp.

Das Plugin bekommt natürlich mit, um welchen Workflow und Schritt es sich kümmern soll. Wie das Plugin die Konfiguration speichert, muss die Anwendung im Prinzip nicht interessieren. D. h. das Plugin kann die Konfiguration so speichern, wie es für das Plugin am geschicktesten ist. So kann das Google Drive Plugin für den Worfklow 421, Schritt 2 speichern, dass die Datei bei mihe7s Google Drive im Verzeichnis backup abgelegt werden soll. Für Workflow 421, Schritt 3 wird das Whatsapp-Plugin verwendet, dort wird eine schöne Nachricht konfiguriert.

Das ist natürlich nur sehr schemenhaft, aber es zeigt, dass man es im Prinzip so weit abstrahieren könnte, dass man die Datenhaltung der Konfiguration der einzelnen Workflow-Schritte den Plugins überlassen werden kann.

Ganz so einfach wie dargestellt ist es natürlich nicht, denn man muss sich Gedanken machen, wie Informationen von einem Schritt an den nächsten weitergegeben werden. Wenn man sichs einfach machen will, dann könnte ein Plugin zum Beispiel Key-Value-Paare zur Verfügung stellen. Dann muss der folgende Schritt ggf. mappen.

Wenn beispielsweise der Trigger etwas wie "file_id": "28022309280929" liefert, bringt das dem Folgeschritt relativ wenig (kann man natürlich für Loggin-Zwecke verwenden). Der Trigger müsste dann schon auch etwas wie "file_url" liefern (das wäre eben die Aufgabe des Trigger-Plugins). Das Plugin im Folgeschritt muss dann mit URLs umgehen können, ansonsten muss man ggf. noch ein Plugin dazwischenpacken. Jedenfalls könnte das Plugin im Folgeschritt nun konfigurieren, dass die URL-Datei unter dem Key "file_url" des vorangegangenen Schrittes zu finden ist.

Das mal kurz überschlagen. Kann natürlich sein, dass ich hier essentielle Dinge übersehen habe.

 

[internet]

Vielen Dank für deinen ausführlichen Post. Das zeigt mir, dass ich nicht so ganz falsch in meiner aktuellen Implementierung liege.
Ich habe aktuell diese Datenbank - Tabellen:

• Automation
• AutomationTask
• AutomationTrigger

In Automation lege ich den ganzen Workflow inkl. Steps in einem JSON Format ab. Hierbei habe ich jedoch zwei Typen:
- Template und Execution.
-> Template ist quasi die Vorlage für einen Worklow
-> Execution ist die Kopie eines Templates, welches dann eben mit aktuellen Aktionsdurchführungen gespeichert wird (welcher Step wird gerade durchgeführt etc.)

AutomationTask habe ich eig. auch nur, dass ich diesen durch einen Schedule antriggern kann und dann in der Datenbank speichern kann (wann lief dieser Step etc.). Die Information könnte ich auch im JSON speichern, wäre dann aber nicht wirklich strukturiert in der DB.

AutomationTrigger dient mir die Trigger in einer Datenbank zu haben. Somit kann ich zB beim Anlegen eines Kunden meine Automation suchen, die daraufhin angestartet werden sollen.

Und Schritt 3 gibt dann eine Meldung an einen Instant Messenger aus, z. B. Whatsapp.

Offtopic: aber gibt es hier eine API? Das suche ich tatsächlich noch
Edit gibt es wohl wirklich: https://github.com/Bindambc/whatsapp-business-java-api#maven

Ganz so einfach wie dargestellt ist es natürlich nicht, denn man muss sich Gedanken machen, wie Informationen von einem Schritt an den nächsten weitergegeben werden. Wenn man sichs einfach machen will, dann könnte ein Plugin zum Beispiel Key-Value-Paare zur Verfügung stellen. Dann muss der folgende Schritt ggf. mappen.

Korrekt, das ist so quasi meine Eingangsfrage auch gewesen bzw. wie ich von einem anderen Schritt dann auf das Objekt vom vorherigen Schritt zugreifen kann.

So ähnlich habe ich es mir nun auch überlegt, dass ich dies zusätzlich als Array im JSON von "Automation" ablege.
Also ein Objekt wie:

public MyWorkflowObject{
   
    private String key; // eindeutiger Name, zB DROPBOX_FILE
    private Object value; // Wert, zB als JSON dann auch Informationen zum DropboxFile mit uniqueID etc.
    private String objectType; // ggf. Datentyp etc. speichern
    private String workflowId; // Workflow ID, in welchem das erste mal das Objekt erstellt / geladen wurde
}

In diesem Array liegen dann sämtliche Objekte, die innerhalb des Workflows aufgerufen werden.
Ggf. kann dieses Array zur Laufzeit auch erweitert werden.
Beispielsweise habe ich einen Workflow, der immer angestoßen (erstellt) wird, wenn ein Kunde erstellt wird.
Beim Anlegen des Workflow hatte ich noch kein Kundenobjekt im Array gespeichert. Dies füge ich nun hinzu oder update es (mit einer entsprechenden ID).

Zur Laufzeit und Abrufen des Objekts, kann ich ja dann einfach die Informationen nutzen, also:

• Ich suche ein Dropbox File -> Call an Dropbox API
• In "value" habe ich die FileId