Bulkimports in PHP beginnen vaak met een CSV die door een klant is aangeleverd, een export van een leverancier of een extract uit een legacy-systeem. Het risico ontstaat wanneer ze worden behandeld als het simpelweg lezen van een bestand gevolgd door invoegingen in de database. Een rij kan een geldig formaat hebben en toch een duplicaat creëren, een bedrijfsregel schenden, actuele informatie overschrijven of twee keer een extern effect veroorzaken.
Een import moet worden ontworpen als een operationeel proces met een gedefinieerde cyclus: ontvangst, analyse, validatie, voorvertoning, bevestiging, uitvoering, beoordeling en herstel. Deze aanpak stelt productteams in staat te begrijpen wat wordt toegevoegd, operationele teams in te grijpen bij uitzonderingen en IT-teams de impact van foutieve gegevens te beperken.
Behandel de import als een bedrijfsproces
Het bestand is niet zelf de bron van waarheid: het is een verzoek om de status van de applicatie te wijzigen. Daarom is het raadzaam een importentiteit te creëren met een eigen identificatiecode, de gebruiker of het systeem dat deze startte, ontvangstdatum, datatype, contractversie, bestand of veilige referentie ernaar, globale status en samenvatting van de resultaten.
De globale statussen moeten een operationele situatie uitdrukken, niet alleen een boolean. Bijvoorbeeld: ontvangen, geanalyseerd, in afwachting van bevestiging, in verwerking, voltooid, voltooid met incidenten, gestopt of geannuleerd. Een import met 9.800 geaccepteerde rijen en 200 afgewezen rijen is niet noodzakelijk een mislukking; het kan een uitvoering zijn die voltooid is met incidenten als de afgewezen rijen geïsoleerd en toegelicht zijn.
Er moet ook worden besloten welke gevolgen bij de import horen. Een bestelling aanmaken, een catalogus bijwerken of contacten aanmaken kan berekeningen, auditing of meldingen vereisen. Het scheiden van de primaire persistentie van neveneffecten vermindert het risico dat een herpoging herhaalde berichten verstuurt of integraties ongecontroleerd uitvoert.
Definieer een invoercontract voordat bestanden worden geaccepteerd
Het importcontract specificeert wat er naar verwachting wordt ontvangen en hoe het wordt geïnterpreteerd. Het moet het toegestane formaat, de codering, het scheidingsteken, headers, gegevenstypen, verplichte velden, datumformaat, normalisatieregels, groottelimieten en het maximale aantal rijen bevatten. Als spreadsheets worden geaccepteerd, moet ook het relevante werkblad worden gedefinieerd en hoe lege cellen, formules en automatisch geconverteerde waarden worden behandeld.
De velden die het bronsysteem met het doelsysteem verbinden, verdienen bijzondere aandacht. Een stabiele externe identificatiecode, zoals de klantcode in het bronsysteem, heeft de voorkeur boven het gebruik van het regelnummer of een naam als referentie. Er moet duidelijk zijn of deze identificatiecode een record aanmaakt, een bestaand record bijwerkt of dat beide bewerkingen zijn toegestaan.
Scheid validatielagen
Structurele validatie beantwoordt mechanische vragen: kan het bestand worden gelezen?, bestaan de vereiste kolommen?, heeft de datum een toegestaan formaat?, is het bedrag numeriek?, voldoet de rij aan de lengtelimiet? Deze laag moet problemen die de interpretatie van de gegevens verhinderen vroeg detecteren.
Domeinvalidatie past bedrijfsregels toe: een status is mogelijk niet toegestaan, een einddatum kan niet voorafgaan aan een begindatum, een percentage moet binnen zijn bereik blijven of een combinatie van velden kan incompatibel blijken. Tot slot verifiëren controles tegen bestaande gegevens referenties, rechten, uniciteit en toegestane overgangen. Bijvoorbeeld dat een leverancierscode bestaat, dat de gebruiker bevoegd is om voor die organisatie handelingen uit te voeren of dat een record niet is geblokkeerd.
Deze scheiding verbetert de meldingen en de diagnose. Het is niet hetzelfde om een ontbrekende kolom te melden als een niet-bestaande referentie of een niet-geautoriseerde wijziging. Bovendien moeten domeinregels vanuit de applicatie en vanuit de importmodule worden hergebruikt om te voorkomen dat de import een snelkoppeling wordt die normale controles omzeilt.
Bekijk wijzigingen vooraf en bevestig een expliciete intentie
De voorvertoning mag geen exacte uitvoering beloven als gegevens tussen de analyse en de bevestiging kunnen wijzigen, maar moet wel een verifieerbare schatting bieden. Toon het totale aantal gelezen rijen, geldige rijen, rijen met waarschuwingen, afgewezen rijen, geplande aanmaakacties, geplande updates en records die niet zullen wijzigen.
Waarschuwingen zijn bedoeld voor gevallen die aandacht vereisen, maar een rij niet automatisch ongeldig maken: bijvoorbeeld een genormaliseerd telefoonnummer, een beschrijving die volgens een bekende regel is afgekapt of een leeg optioneel veld. Waarschuwingen mogen afwijzingen niet verbergen. Elk resultaat heeft een stabiele code, een begrijpelijke melding en, wanneer dat veilig is, de ontvangen waarde en de genormaliseerde waarde nodig.
De bevestiging moet aan een concrete versie van de analyse gekoppeld zijn. Als de gebruiker het bestand vervangt, rijen in een interface corrigeert of relevante parameters wijzigt, moet het systeem de eerdere voorvertoning ongeldig maken en een nieuwe analyse vereisen. Zo wordt voorkomen dat een samenvatting wordt bevestigd die de daadwerkelijke import niet meer vertegenwoordigt.
Verwerk in batches zonder dubbelzinnige statussen
Alle rijen binnen één enkele transactie verwerken lijkt veilig, maar kan locks te lang vasthouden, uitvoeringslimieten overschrijden of een incidentele fout omzetten in een kostbare rollback. Daarentegen kan één rij per transactie verwerken te veel overhead veroorzaken en het coördineren van gerelateerde bewerkingen bemoeilijken.
De werkeenheid moet worden gekozen op basis van de afhankelijkheid tussen records, het volume en de kosten van terugdraaien. In veel gevallen maakt een kleine, afgebakende batch het mogelijk om wijzigingen progressief vast te leggen. Elke batch moet start, voltooiing, aantal behandelde rijen en resultaat registreren. De worker moet kunnen worden hervat zonder afhankelijk te zijn van een open HTTP-sessie: de import wordt vanuit de interface bevestigd, maar de uitvoering gebeurt als achtergrondtaak.
Vermijd volledige bestanden in het geheugen te houden. Lees sequentieel, normaliseer elke rij en sla een werkrepresentatie of een validatieresultaat op wanneer dat nodig is voor auditing en hervatting. Leg limieten op voor grootte, rijen, tijd en gelijktijdigheid. Een onverwacht groot bestand mag de resources die het dagelijkse werk bedienen niet blokkeren.
voor elke openstaande batch:
batch markeren als in_verwerking
voor elke rij in de batch:
openstaande validaties toepassen
persisteren of naar quarantaine sturen
resultaat per rij registreren
batch vastleggen
batch markeren als voltooidAls een worker wordt onderbroken, volstaat het niet om de batch blind opnieuw uit te voeren. Er is een vergrendelingsmechanisme met verval of herstel nodig, en de status per rij moet het mogelijk maken om het openstaande te onderscheiden van wat al is bevestigd.
Isoleer fouten in quarantaine en bewaar bewijs
Quarantaine maakt het mogelijk dat ongeldige rijen de geldige niet blokkeren zonder uit het proces te verdwijnen. Een rij in quarantaine moet het bronnummer of de bronidentificatiecode, de ontvangen gegevens onder toegangscontroles, de genormaliseerde gegevens indien aanwezig, foutcodes, het moment van detectie en de beoordelingsstatus behouden.
Niet alle fouten krijgen dezelfde behandeling. Een bestand zonder vereiste header is een bestandsfout en kan de volledige analyse stoppen. Een verwijzing naar een niet-bestaande leverancier kan een rijafwijzing zijn. Een tijdelijke storing van de database of een integratie is een technische fout die opnieuw kan worden geprobeerd en mag niet als gegevensfout worden gelabeld.
De operationele interface moet het mogelijk maken om op reden te filteren, alleen geautoriseerde incidenten te exporteren en te begrijpen welke correctie wordt verwacht. Corrigeren binnen de applicatie kan nuttig zijn voor enkele gevallen; voor veel records is het doorgaans beter beheersbaar om de incidenten te downloaden, ze in de bron te corrigeren en een nieuwe import in te dienen. Bewaar in beide gevallen de geschiedenis: het wijzigen van een rij in quarantaine mag de oorspronkelijke waarde of de oorspronkelijke reden niet wissen.
Garandeer idempotentie en voorkom duplicaten
Idempotentie betekent dat het herhalen van een bewerking met dezelfde intentie het resultaat niet meer dan één keer wijzigt. Dit is essentieel omdat herpogingen voorkomen: er treedt een time-out op, een proces herstart of een operator bevestigt opnieuw na een onzekere reactie.
Een idempotentiesleutel kan worden opgebouwd uit het importtype, de doelorganisatie en een stabiele externe identificatiecode. Deze moet worden ondersteund door uniciteitsbeperkingen in de database wanneer het model dit toelaat; eerst controleren en daarna invoegen elimineert de race conditions tussen gelijktijdige workers niet.
Definieer voor updates een expliciet beleid: velden vervangen, alleen niet-lege waarden toepassen, conflicten afwijzen of een verwachte versie van het record vereisen. De laatste optie helpt detecteren dat een gebruiker de gegevens na de voorvertoning heeft gewijzigd. Gebruik een bestandsvingerafdruk niet als enig mechanisme: dezelfde inhoud kan een andere intentie vertegenwoordigen en een gecorrigeerd bestand kan veel al verwerkte rijen behouden.
Traceerbaarheid, herpogingen en selectief herstel
Het resultaat per rij is het centrale element voor support en herstel. Registreer een status zoals openstaand, verwerkt, afgewezen, in quarantaine, opnieuw te proberen of overgeslagen; de externe identificatiecode; de batch; redencodes; tijdstempels; en een referentie naar het aangemaakte of bijgewerkte record. Bescherm persoonsgegevens en geheimen: traceerbaarheid moet voldoende zijn voor onderzoek, niet een willekeurige kopie van gevoelige informatie in logs.
Herpogingen moeten selectief zijn. Probeer tijdelijke technische fouten automatisch opnieuw met limieten en progressieve wachttijd; probeer een geschonden domeinregel niet onbeperkt opnieuw. Wanneer een ontbrekende referentie of een ongeldig gegeven is gecorrigeerd, verwerk dan alleen de overeenkomstige rijen in quarantaine opnieuw. Wanneer een batch faalt, ga dan verder vanaf de openstaande rijen en gebruik de al verwerkte rijen als bewijs van voortgang.
Test voordat u de flow in productie neemt lege bestanden, gewijzigde headers, onverwachte coderingen, duplicaten binnen hetzelfde bestand, duplicaten tegenover de database, onderbrekingen tussen batches, hervattingen en onvoldoende rechten. Bulkimports in PHP zijn betrouwbaar wanneer hun gedrag bij fouten met dezelfde precisie is ontworpen als hun normale werking.
