Action Node

In n8n ziehst du einen Node (z. B. Slack) auf den Canvas. Jeder Node hat:

1. Resource: Was willst du ansprechen? (z. B. "Message", "Channel", "User").
2. Operation: Was willst du tun? (z. B. "Post", "Get", "Archive").
3. Parameters: Die Details (z. B. "Channel ID", "Text").

Beispiel: Du willst, dass n8n "Hallo" in Slack postet.

• Node: Slack
• Resource: Message
• Operation: Post
• Text: "Hallo Welt"

Du verbindest den Trigger (z. B. "Schedule Trigger - Alle 9 Uhr") mit dem Slack Node. Fertig.

1. Daten-Mapping & Expressions

Statische Werte ("Hallo Welt") sind langweilig. Action Nodes leben von dynamischen Daten. Du nutzt Expressions (JavaScript), um Daten vom Trigger zu referenzieren: {{ $node["Webhook"].json["body"]["user_name"] }}. Jeder Action Node iteriert standardmäßig über alle Items, die er bekommt. Wenn der Trigger 50 Datensätze liefert, führt der Action Node die Aktion 50 Mal aus (Batch-Processing). Achtung API-Limits! Hier brauchst du manchmal "Split In Batches" Nodes dazwischen.

2. Error Handling & Retries

Was passiert, wenn die Slack API down ist? Standardmäßig bricht der Workflow ab ("Error"). Im Tab Settings des Action Nodes kannst du einstellen:

• Retry on Fail: "Versuche es 3x alle 1 Sekunde erneut" (Exponentielles Backoff).
• Continue On Fail: "Ignoriere den Fehler und mach weiter" (Der Output enthält dann { "error": "..." }).
• Error Workflow: "Wenn das hier schiefgeht, starte Workflow B (Alerting Team)".

3. Credentials & Authentication Management

Der Action Node abstrahiert die Authentifizierung. Du wählst nur "Slack Wi-Fi Key" aus. Im Hintergrund führt n8n den OAuth2-Flow oder Header-Injection durch. Der Node selbst sieht im Code oft so aus (TypeScript): execute() { const credentials = this.getCredentials('slackApi'); ... axios.post(...) }.

Custom Nodes in TypeScript

Wenn die eingebauten Action Nodes nicht ausreichen, schreibst du deinen eigenen. In n8n werden Custom Nodes in TypeScript entwickelt. Ein Action Node erbt vom Interface INodeType und implementiert die execute() Methode. Du definierst die Parameter (z. B. Dropdowns, Textfelder) in der description Eigenschaft. Der Build-Prozess (oft via npm run build im n8n-nodes-starter Repo) kompiliert den Node, der dann in n8n geladen werden kann.

import { IExecuteFunctions, INodeExecutionData, INodeType, INodeTypeDescription, NodeOperationError } from 'n8n-workflow';

export class MyCustomAction implements INodeType {
    description: INodeTypeDescription = {
        displayName: 'My Custom Action',
        name: 'myCustomAction',
        group: ['transform'],
        version: 1,
        description: 'Does something awesome',
        defaults: { name: 'My Custom Action' },
        inputs: ['main'],
        outputs: ['main'],
        properties: [
            // ... UI properties hier
        ],
    };

    async execute(this: IExecuteFunctions): Promise<INodeExecutionData[][]> {
        // ... Business Logic & API Calls hier
        return [this.getInputData()]; 
    }
}

Der execute() Context und axios

Innerhalb der execute() Methode eines Action Nodes hast du Zugriff auf den Execute Context (this: IExecuteFunctions). Dieser Context bietet Helfer für fast alles. Wenn du eine API aufrufen musst, nutzt du idealerweise die integrierte this.helpers.requestWithAuthentication() (oder request für no-auth). Dies ist besser als nacktes Axios, da n8n so Dinge wie Zertifikate, Proxy-Einstellungen und Credentials automatisch managed. Sollte ein Fehler auftreten, wirfst du einen NodeOperationError, der sauber ins n8n UI geroutet wird.

Programmatic Triggers vs. Action Polling

Eine Action ruft aktiv eine Funktion auf. Wenn du darauf wartest, dass in System A etwas passiert, bist du eigentlich bei einem Trigger-Node. Hat System A keine Webhooks? Dann baut man oft einen Action Node, der als "Poller" fungiert. Er vergleicht den Zustand (z. B. "letzte gelesene ID") in einer Schleife via Schedule. Das ist teuer für die Infrastruktur, oft aber der einzige Weg für Legacy-APIs.