SQL-adapter och polling
SQL-polling är inte bara en connectorfråga. Målflödet måste bevisa vilka rader som är nya, när de anses behandlade och vad som händer om databasanropet lyckas men nästa steg misslyckas.
Kartlägg nuvarande kontrakt
Dokumentera pollningsfråga eller stored procedure, intervall, sortering, batchstorlek, transaktionsgräns och hur BizTalk markerar en rad. Ta med lås- och timeoutbeteende samt vilket konto som används. Utan detta går det inte att skilja en avsiktlig semantik från ett gammalt workaround.
Välj trigger eller explicit schema
Logic Apps connectoröversikt använder en SQL-trigger som exempel på polling. För stora record sets beskriver Microsoft i stället stored procedure och servernära bearbetning som sätt att styra resultatets storlek och struktur. Välj efter volym och kontrollbehov, inte bara efter att en trigger finns i designern.
Känn connectorns gränser
Microsoft dokumenterar att SQL-connectorns stored procedure-timeout är kortare än två minuter och föreslår bland annat completion trigger, state table eller server-side jobs för längre körningar. En befintlig BizTalk-procedure som tar flera minuter är därför en designfråga före migrering.
Gör behandlingen idempotent
Använd status, watermark eller en separat outbox så att samma rad kan läsas igen utan dubbel affärseffekt. Definiera när markeringen skrivs i förhållande till kö eller mottagarsystem. Om två pollare kan överlappa ska låsning och ordning testas under last, inte bara i ett manuellt lyckat test.
Flytta inte databasen av reflex
SQL Server kan ligga kvar medan integrationen flyttar, förutsatt att nätverk och autentisering är lösta. Connectorn stöder flera autentiseringsmodeller, inklusive Microsoft Entra och managed identity i dokumenterade scenarier. Kontrollera den faktiska servertypen och connectorvarianten innan målbilden låses.