På denna sida
Två kundföretag har båda ett fält som heter ”active”. Hos det ena betyder det att kunden har köpt något under senaste året. Hos det andra betyder det att serviceavtalet fortfarande gäller. En delad anslutning kan flytta båda fälten korrekt. En gemensam regel som behandlar dem som samma affärstillstånd kan vara fel för ett av företagen. Det är ett illustrativt exempel, ingen rapport från en driftsättning.
Ett samtal om delade plattformar och lokal driftsättning beskriver ett företag som återanvänder mycket infrastruktur men ändå gör omfattande arbete i varje kundmiljö. Procentsiffrorna gäller just det företaget. Den allmänna arkitekturfrågan är var delad teknik slutar och lokal betydelse börjar.
Skilj transportkontrakt från affärskontrakt
Ett transportkontrakt kan säga: autentisera mot källan, läs ändrade poster, bevara identifierare, försök igen säkert och visa fel. Det beteendet kan byggas en gång och testas gång på gång. Det är värdefullt eftersom varje integration behöver en pålitlig väg för data.
Ett affärskontrakt säger vilken post som bestämmer, vad en status betyder, när en åtgärd är tillåten och vem som kan rätta ett misstag.
- Delad transport identitet · omförsök · händelse-ID
lämnar giltig händelse
- Lokal policy betydelse · samtycke · tid
avgör om åtgärden är tillåten
- Tillåten åtgärd skrivning · granskning
registrerar resultatet
Affärskontraktet beror på arbetsflödet. Det kan använda samma källa och mål som hos ett annat företag och ändå behöva ett annat svar.
Ta en anslutning mellan butik och e-postplattform. Plattformen kan ta emot händelser, ta bort dubbletter och ge ett granskningsspår. Arbetsflödets ägare måste definiera om ”subscribed” betyder tillstånd för ett visst marknadsföringssyfte, om ett köp stoppar en varukorgspåminnelse och hur ändrat samtycke påverkar meddelanden som redan köats. Det är inte anslutningsfunktioner som går att gissa ur fältnamn.
Den illustrerade Tajo-mappningen kopierar tre fält direkt. En viktig fråga saknas: ingen rad definierar tillstånd för marknadsföring. Återanvändning av transporten sparar arbete, men den som äger arbetsflödet måste fortfarande ange vilken status som tillåter vilken åtgärd. En tydlig fältmappning kan visa luckan utan att fylla den.
Granska en synkronisering innan den körs
Synkronisera kunduppdateringar med min e-postplattform.
Kundsynkronisering
| Källfält | Målfält | Regel |
|---|---|---|
email | EMAIL | Direkt |
first_name | FIRSTNAME | Direkt |
last_name | LASTNAME | Direkt |
Syntetisk förhandsgranskning godkänd
3 fält mappade · Inga skrivningar till målsystemet
Illustrativ layout baserad på Tajos mappningsverktyg. En syntetisk förhandsgranskning och ett sparat utkast aktiverar ingen synkronisering.
| Delat lager | Lokalt lager |
|---|---|
| Autentisering och uppdatering av token | Vilken användare som får nå arbetsflödet |
| Händelsetransport och omförsök | Vilken händelse som räknas som affärsövergång |
| Stabila identifierare och borttagning av dubbletter | Vilka poster som gäller samma verkliga kund |
| Loggar och återhämtningspunkter | Vem som löser ett omtvistat tillstånd och hur |
| Kontraktsvalidering | Vad fältvärden betyder och när de får leda till handling |
Tabellen visar en designgräns. Den påstår inte att alla system kan delas upp så prydligt.
Återanvändning går sönder när den döljer oenighet
En allmän plattform får ofta ett inställningsfält för varje undantag. Först verkar det bevara återanvändningen. Sedan kan ingen avgöra om en inställning är tekniskt val, juridisk gräns eller affärsbeslut. Den delade kärnan blir en fjärrkontroll för val den inte äger.
Leta efter en stabil invariant. ”Tillämpa aldrig samma källhändelse två gånger på samma målpost” kan ligga i en delad motor. ”Skicka rabatt när kunden blir aktiv” kan inte delas innan någon äger definitionen av ”aktiv”, tillåten målgrupp och erbjudandepolicy. Motorn kan köra en godkänd policy men ska inte hitta på en.
Gränsen hjälper också underhåll. Om ett API ändras kan plattformsteamet uppdatera adaptern och testerna. Om definitionen av en berättigad kund ändras kan affärsägaren uppdatera policy och testfall utan att transporten skrivs om. En tydlig gräns låter varje ändring nå den som har befogenhet över den.
Återanvänd teknik utan att sudda ut mening
Lokala regler kostar ibland extra. En plattform utan återanvändbara kontrakt blir en samling specialskript. Börja därför med att se återkommande mekanismer innan du abstraherar återkommande betydelser. En bra delad byggsten kan ta emot ett typat villkor, händelsetid och gräns för åtgärder medan affärsdefinitionen av villkoret förblir lokal.
Testa gränsen med verkliga fall. Ta en normal händelse, en dubblett, en sen rättning och indragen behörighet. Fråga vilket lager som ansvarar för varje svar. Om ett fel inte går att tilldela döljer abstraktionen ägarskapet. Om ett nytt företag tvingar en delad ”active”-typ att rymma flera orelaterade betydelser är typen för bred.
Den kompletterande artikeln om driftsättning undersöker om en förmåga fungerar i ett verkligt flöde. Här är frågan vad som kan byggas en gång utan att radera vad arbetsflödet betyder.
Gränssnittet mellan lagren ska vara tydligt nog att avvisa ett dåligt antagande. En delad motor kan kräva händelse-ID, källtid, aktör och angivet syfte innan den tar emot en begäran om åtgärd. Det lokala arbetsflödet kan ge policyn som avgör om åtgärden är tillåten. Saknas syftet ska motorn vägra. Är policyn tvetydig måste den lokala ägaren reda ut den. Det bevarar återanvändning utan att lämna affärsbefogenhet till generell kod. Dokumentera kontraktet med ett tillåtet och ett avvisat exempel och testa båda när något lager ändras.
En återanvändbar anslutning ska göra lokal betydelse lättare att uttrycka och säkrare att köra. Den får aldrig få två olika löften att se likadana ut bara för att deras fält har samma namn.
Vanliga Frågor
Vad bör en integrationsplattform oftast återanvända?
Stabil teknik som autentiseringsmönster, transport, idempotens, omförsök, loggar och kontraktskontroller kan ofta delas när kraven under ytan är lika.
Vad måste vara specifikt för ett företag?
Fältbetydelse, styrande källa, samtyckesregler, tidskrav och vem som får agera på en status måste fastställas för företaget och arbetsflödet.
Hur testar team gränsen?
Försök beskriva ett nytt arbetsflöde med befintliga byggstenar. Om det ändrar affärsbetydelsen eller gömmer undantag i allmänna inställningar, håll logiken lokal och gör gränssnittet tydligt.