Du hämtar ”produktposten”, sedan frågar någon efter rull-data, sedan efter utskriftskonfiguration, och plötsligt sitter du och syr ihop svar manuellt från två databaser. Det går långsamt. Det är skört. Och i samma stund som ett fältnamn ändras förvandlas din ”snabba uppslagning” till en miniincident.
Den här MySQL Postgres lookup-automationen träffar driftsansvariga först, eftersom de behöver konsekventa etiketter och konfigurationer snabbt. backendutvecklare dras in när svaren inte matchar. byråteam känner också av det när kundernas system är en stökig blandning av databaser. Målet är enkelt: ett felfritt svar varje gång.
Det här arbetsflödet använder n8n för att ta emot en webhook-förfrågan, fråga MySQL och Postgres, slå ihop resultaten och returnera ett enhetligt payload som dina verktyg (och människor) faktiskt kan lita på.
Så fungerar automationen
Hela n8n-flödet, från trigger till slutligt utdata:
n8n Workflow Template: MySQL + Postgres: ett korrekt svar per förfrågan
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Etiqueta Webhook Entrada"]
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/mysql.dark.svg' width='40' height='40' /></div><br/>Consultar Produto Info"]
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Buscar Config Impressao"]
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Carregar Dados de Rolo"]
n4@{ icon: "mdi:code-braces", form: "rounded", label: "Processar Retorno", pos: "b", h: 48 }
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Combinar Rolo e Produto"]
n3 --> n5
n1 --> n5
n4 --> n3
n0 --> n2
n2 --> n1
n2 --> n4
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n1,n3 database
class n0,n2 api
class n4 code
classDef customIcon fill:none,stroke:none
class n0,n1,n2,n3,n5 customIcon
Problemet: två databaser, två svar
När informationen finns både i MySQL och Postgres blir ”bara slå upp det” en flerstegsrutin. Någon frågar MySQL efter produktinfo, någon annan går mot Postgres för rull-data, och sedan slår du ihop det manuellt i ett kalkylblad, ett Slack-meddelande eller (värst av allt) i huvudet. Små skillnader smyger sig in: produkt-id är formaterat olika, ett system returnerar null, och plötsligt matchar inte etikettkonfigurationen produkten du försöker skicka. Det är inte svårt arbete. Det är distraherande arbete, och det stjäl tid från faktiska förbättringar.
Det blir snabbt mycket. Här är var det brukar fallera i riktiga team:
- Två separata uppslagningar betyder två chanser att kopiera fel id och skicka fel sak.
- Fältnamn matchar sällan mellan system, så folk ”översätter” kolumner olika varje gång.
- När förfrågningarna staplas blir ingenjörer mänskliga routrar i stället för att bygga.
- En schemaändring i någon av databaserna kan tyst ge felmatchade svar i flera dagar.
Lösningen: en webhook som returnerar en enhetlig post
Det här n8n-arbetsflödet ger dig en enda anropsväg som hämtar det du behöver från båda databaserna och returnerar ett konsekvent payload. Det startar när en webhook tar emot en inkommande förfrågan (tänk: ett etikettsystem, ett internt verktyg eller ett enkelt API-anrop från ett kalkylbladsskript). Därefter hämtar flödet först utskriftskonfigurationen, och använder sedan den kontexten för att fråga MySQL efter produktinfo och förbereda Postgres-frågan för rull-data. Resultaten slås ihop till ett objekt, och sedan standardiserar ett Function-steg strukturen så svaret blir förutsägbart. Samma indata, samma utdatafält, varje gång.
Arbetsflödet börjar vid en webhook-endpoint och hämtar direkt den konfiguration som behövs via HTTP Request. Med den konfigurationen på plats frågar det MySQL efter produktdetaljer och Postgres efter rull-relaterad data, och slår sedan ihop båda strömmarna. Till sist bearbetar det den kombinerade posten till ett strukturerat retur-objekt som det anropande systemet kan använda utan extra logik.
Det du får: automation vs. resultat
| Vad arbetsflödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att ditt team hanterar 20 etikett- eller fulfillment-uppslagningar per dag. Manuellt kanske du lägger cirka 5 minuter i MySQL, ytterligare 5 minuter i Postgres, plus några minuter för att stämma av fält—så säg 15 minuter per förfrågan. Det blir ungefär 5 timmar per dag av avbrottsdrivet arbete. Med det här flödet anropar beställaren en webhook, väntar kanske en minut på frågorna och sammanfogningen och får ett svar tillbaka. Du granskar fortfarande edge cases, men du slutar göra samma merge 20 gånger.
Det här behöver du
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- Åtkomst till MySQL-databas för frågor om produktinformation.
- Åtkomst till Postgres-databas för att hämta rull-data-poster.
- HTTP-endpoint eller API-nyckel (från din konfigurationstjänst) för att hämta utskriftskonfiguration.
Kompetensnivå: Medel. Du kopplar in inloggningsuppgifter, mappar några fält och testar med exempel på webhook-förfrågningar.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
En webhook tar emot förfrågan. Ditt verktyg skickar en identifierare (ofta en produktkod, rull-id eller orderkontext) till arbetsflödets webhook-URL. Det blir den enda ”källförfrågan” för allt som följer.
Utskriftskonfiguration hämtas först. Arbetsflödet anropar en extern endpoint med HTTP Request för att hämta print- eller etikettkonfiguration kopplad till förfrågan. Det svaret påverkar vilken data du slår upp härnäst, vilket minskar gissningar senare.
MySQL- och Postgres-uppslagningar körs och slås ihop. MySQL returnerar produktinfo. Postgres returnerar rull-relaterad data. n8n:s Merge-nod kombinerar båda så att du slipper jonglera två separata payloads.
Svaret normaliseras och returneras. Ett Function-steg städar upp den slutliga strukturen (namn, nästlade objekt, tomma fält) så att det anropande systemet får ett förutsägbart resultat som går att parsa. Om du använder detta som ett internt API är den konsekvensen hela poängen, helt ärligt.
Du kan enkelt ändra vilka MySQL-kolumner du returnerar (eller vilka Postgres-tabeller du frågar) utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: konfigurera webhook-triggern
Sätt upp den inkommande webhooken som startar arbetsflödet och tar emot payloads för etikettförfrågningar.
- Lägg till en Etiqueta Webhook Entrada-nod och ställ in Path på
emitirEtiqueta. - Ställ in HTTP Method på
POST. - Ställ in Response Data på
allEntriesoch Response Mode pålastNode. - Kopiera test-URL:en och planera att skicka en JSON-body som innehåller
id_produto_grade,id_movimentacao_detalheochrolos.
Steg 2: koppla in hämtning av konfiguration
Hämta utskriftskonfiguration innan ni förgrenar till databassökningar.
- Lägg till Buscar Config Impressao och ställ in URL på
http://localhost:1337/parse/config. - Aktivera JSON Parameters och ställ in Header Parameters JSON på
{"X-Parse-Application-Id": "iwms"}. - Koppla Etiqueta Webhook Entrada till Buscar Config Impressao.
- Notera den parallella körningen: Buscar Config Impressao skickar utdata både till Consultar Produto Info och Processar Retorno parallellt.
Steg 3: koppla databassökningar
Använd MySQL och Postgres för att hämta produkt- och rullinformation.
- Lägg till Consultar Produto Info med Operation satt till
executeQueryoch klistra in SQL-frågan exakt som i arbetsflödet, inklusive uttryck som{{$node["Etiqueta Webhook Entrada"].json["body"]["id_produto_grade"]}}och{{$node["Buscar Config Impressao"].json["params"]["bancoRelatorio"]}}. - Inloggningsuppgifter krävs: anslut era mySql-credentials i Consultar Produto Info.
- Lägg till Carregar Dados de Rolo med Operation satt till
executeQueryoch ställ in Query på=select * from "tecido_rolo" where "objectId" in ('{{$json["idRolos"].join("','")}}'). - Inloggningsuppgifter krävs: anslut era postgres-credentials i Carregar Dados de Rolo.
Steg 4: bearbeta och slå ihop payloaden
Extrahera rull-ID:n, hämta rullinformation och slå ihop den med produktdata.
- Lägg till Processar Retorno och behåll Function Code enligt det som är angivet för att mappa
rolostillidRolos. - Koppla Processar Retorno till Carregar Dados de Rolo så att rull-ID:na styr Postgres-frågan.
- Lägg till Combinar Rolo e Produto och ställ in Mode på
mergeByKey. - Ställ in Property Name 1 på
id_movimentacao_detalheoch Property Name 2 påid_movimentacao_detalhe. - Koppla Consultar Produto Info till input 1 och Carregar Dados de Rolo till input 2 på Combinar Rolo e Produto.
id_movimentacao_detalhe-värde innan ni slår ihop.Steg 5: testa och aktivera ert arbetsflöde
Validera webhooken och bekräfta att produkt- och rullinformation slås ihop korrekt.
- Klicka på Execute Workflow och skicka en POST-request till Etiqueta Webhook Entrada-URL:en med exempel-JSON som innehåller
id_produto_grade,id_movimentacao_detalheochrolos. - Bekräfta att Buscar Config Impressao returnerar parametrar som används av Consultar Produto Info och att Processar Retorno ger ut en
idRolos-array. - Verifiera att Combinar Rolo e Produto ger ut sammanslagna produkt- och rullfält med
id_movimentacao_detalhesom nyckel. - När allt är validerat, växla arbetsflödet till Active för användning i produktion.
Vanliga fallgropar
- MySQL-inloggningsuppgifter kan löpa ut eller kräva specifika behörigheter. Om det skapar fel, börja med att kontrollera n8n:s credential tester och dina MySQL-grants för användaren.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- HTTP Request-endpoints ändrar ofta headers eller kräver ny autentisering. Om konfig-hämtningen börjar ge 401/403, verifiera token och bekräfta att endpointen fortfarande accepterar ditt payload.
Vanliga frågor
Cirka 30 minuter om dina databasinloggningsuppgifter och test-id:n är redo.
Nej. Du kommer främst att koppla in inloggningsuppgifter och mappa fält i n8n. Att vara lite bekväm med att läsa JSON hjälper när du testar svar.
Ja. n8n har ett gratis alternativ för self-hosting och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in dina databas- och hostingkostnader (och eventuella HTTP-API:er du anropar, om de är betalda).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det är en vanlig justering. Du brukar justera MySQL-frågenoden (Consultar Produto Info), Postgres-noden (Carregar Dados de Rolo) och sedan strama upp den slutliga strukturen i Processar Retorno. Vissa team byter också fältnamn i ett Set/Edit Fields-steg så att nedströmsverktyg alltid får samma nycklar. Behåll samma merge-logik, ändra bara vad du matar in i den.
Oftast beror det på utgångna inloggningsuppgifter eller att MySQL-användaren saknar rättigheter att läsa tabellen du frågar. Uppdatera uppgifterna i n8n och bekräfta sedan host, port och tillåtna IP-adresser. Om det bara fallerar vid belastning, kontrollera anslutningsbegränsningar på databassidan.
På n8n Cloud Starter klarar du vanligtvis några tusen körningar per månad; högre planer går långt över det. Om du self-hostar finns inget tak för n8n-körningar, men din server och dina databaser har fortfarande begränsningar. I praktiken hanterar den här typen av två-frågor-och-merge-flöde en jämn intern användning utan problem, och du skalar genom att uppgradera VPS:en och trimma databasanslutningar.
Ofta, ja, eftersom det här arbetsflödet beter sig som ett ”API”: villkorslogik, flera frågor och en konsekvent svarsstruktur. n8n trivs med den stilen, och du straffas inte för förgreningar och sammanslagningar som i vissa verktyg. Zapier eller Make kan fortfarande fungera om du bara behöver en enkel tvåstegssynk, men multi-källa-merge blir snabbt klumpigt. Den andra stora skillnaden är driftsättning: self-hosting håller kostnaderna mer förutsägbara när volymen ökar. Om du vill ha hjälp att välja, prata med en automationsexpert.
När förfrågan kommer in returnerar du ett svar, inte en skattjakt. Sätt upp det en gång, och de ständiga ”kan du dubbelkolla det här?”-avbrotten börjar klinga av.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.