Leverantörsfiler är sällan stabila kontrakt. Kolumner byter namn, decimalformat varierar, bilder saknas och lager kan betyda olika saker beroende på källa. Om dessa variationer kopplas direkt till Shopify blir varje körning en potentiell produktionsförändring.
Separera inläsning från publicering
Den viktigaste arkitekturprincipen är att inte göra import och Shopify-uppdatering till samma odelbara steg. Ett säkert flöde har separata faser: hämta källan, tolka och validera, normalisera till en intern modell, berika och granska, beräkna avsedd förändring och först därefter publicera.
Separationen gör att fel i en fil kan stoppas innan butiken påverkas. Den gör det också möjligt att visa en diff: vad kommer faktiskt att ändras om körningen godkänns?
Ett praktiskt produktflöde
1. Inläsning med återstartspunkt
Stora filer ska kunna bearbetas i delar. En beständig återstartspunkt behöver visa exakt var den senaste hållbara skrivningen slutade. Då kan processen återupptas utan att börja om eller hoppa över rader.
2. Mappning som egen profil
Kolumnmappning ska inte hårdkodas för varje fil. Spara en profil per leverantör och identifiera schemaförändringar. AI kan föreslå mappning, men osäkra förslag bör parkeras för granskning.
3. Gemensam intern modell
Normalisera valuta, lager, produktstatus, varianter och identiteter innan Shopify-logik används. Det minskar kanalberoendet och gör framtida integrationer möjliga utan att hela importen måste byggas om.
4. Avsikt före effekt
Beräkna den avsedda förändringen som ett uttryckligt objekt: produkt, fält, gammalt värde, nytt värde, orsak och källa. En unik idempotensnyckel gör samma operation säker att försöka igen.
5. Verifiering efter publicering
Ett lyckat API-svar är inte hela sanningen. Läs tillbaka relevant tillstånd och jämför med den avsedda effekten. Registrera avvikelsen som ett separat driftproblem.
Behörighet och tenantgränser
Shopify-sessionen bekräftar butikskontext, men den interna dataplattformen måste också upprätthålla tenantisolering. Klientens butiksvärde får aldrig ensamt avgöra vilka poster som kan läsas eller ändras. Använd serververifierad identitet och databasskydd som RLS där det passar.
Tokens ska behandlas som känsliga driftuppgifter: krypterade i vila, aldrig loggade och inte exponerade till webbläsaren. En återanslutning ska vara tydlig och avgränsad, inte en dold fallback.
Vad verksamheten behöver kunna se
Operativ transparens är lika viktig som synklogiken. Teamet behöver se vilken fil som användes, hur många rader som accepterades, vilka produkter som väntar på beslut, vilka externa effekter som lyckades och vad som behöver återställas.
När flödet är byggt på detta sätt kan automationen ökas stegvis. Stabila leverantörsprofiler och låg-risk-fält kan gå automatiskt, medan nya scheman, stora prisförändringar eller osäkra kategoriseringar kräver granskning.