Bij webtaken van een Agent ontstaan fouten vaak op vier punten: elementlokalisatie, wachttijden en time-outs, statusopslag en blokkering door de omgeving. Idempotente stappen, gerichte retries, duurzame statusopslag en een geïsoleerde omgeving per taak maken het slagingspercentage veel stabieler.
Wanneer je begint met webautomatisering, lijkt de aanpak vaak eenvoudig: leg de workflow vast en laat het script draaien. De logica ziet er goed uit, maar taken mislukken toch af en toe en accountstatussen vertonen soms afwijkingen. De eerste reactie is de code controleren, maar bij verder onderzoek blijken de problemen meestal op vier plaatsen te zitten.
Een paginawijziging maakt lokalisatie ongeldig
De meeste scripts zoeken elementen met selectors. Zodra een selector hard is vastgelegd, kan vrijwel elke wijziging aan de pagina hem breken: een knop krijgt een andere class, één woord in de tekst verandert, een sectie gaat van server-side rendering naar asynchroon laden of een element wordt in een nieuwe container geplaatst. Tijdens een A/B-test kan dezelfde pagina voor verschillende accounts zelfs een andere structuur hebben.
Meestal zie je dat een element niet wordt gevonden, een klik op de verkeerde plek terechtkomt of een gelijknamige besturing op een andere positie wordt aangeklikt. Dit soort fout is geen netwerkfluctuatie en verdwijnt niet door een paar keer opnieuw te proberen.
Een praktische aanpak is minder afhankelijk te zijn van absolute paden. Gebruik bij voorkeur toegankelijkheidsattributen, stabiele zakelijke ID's of relatieve relaties tussen elementen; maak voor hetzelfde paginatype alternatieve selectors klaar, zodat automatisch kan worden teruggevallen wanneer de primaire selector faalt. Bevat de pagina een iframe of Shadow DOM, schakel dan eerst naar de juiste context, anders zal de lokalisatie mislukken.
Wachttijden en time-outs zijn verkeerd afgesteld
Is de wachttijd te kort, dan kan een element als mislukt worden beoordeeld voordat het klaar is met renderen, waardoor het op een scriptbug lijkt. Is hij te lang, dan loopt de duur van één taak onnodig op, daalt de throughput en kunnen lange time-outs de werkelijke fout verbergen.
Expliciete waits zijn betrouwbaarder dan een vaste sleep: wacht op een concrete voorwaarde, bijvoorbeeld het verschijnen van het doelelement, het terugkomen van een request of het verdwijnen van een laadanimatie. Time-outbudgetten moeten in lagen worden ingesteld, met afzonderlijke grenzen voor een stap, een pagina en de hele taak, en geleidelijk worden aangescherpt in plaats van overal dezelfde waarde te gebruiken.
Maak ook onderscheid tussen wachten tot de pagina bruikbaar is en wachten tot het zakelijke resultaat is gegenereerd. Voor het eerste is wachten tot de DOM gereed is meestal genoeg; voor het tweede moet je mogelijk wachten op een API-callback of een wijziging in statustekst op de pagina. Wachten op het verkeerde signaal kan een bewerking succesvol laten lijken terwijl de gegevens niet zijn weggeschreven.
Halverwege een taak met meerdere stappen raakt de voortgang verloren
Taken zoals registratie, bestellen en publiceren bestaan al snel uit meer dan tien stappen. Als het proces halverwege stopt door een time-out, browsercrash of herstart van de host, en de status alleen in het geheugen staat, moet de volgende run opnieuw beginnen of de vorige stap nog een keer indienen.
Dubbele uitvoering is vaak lastiger te onderzoeken dan een gewone mislukking: dezelfde handeling wordt twee keer uitgevoerd, het bovenliggende systeem krijgt een extra record en de herkomst is moeilijk terug te vinden.
De oplossing is elke stap een persistentiepunt te geven. Schrijf na iedere voltooide stap de voortgang samen met de unieke taak-ID naar duurzame opslag; na een herstart ga je verder vanaf het laatste succesvolle punt. Daarvoor is geen complex framework nodig: een bestand of één statusrecord is voldoende.
Blokkering door de omgeving lijkt op een codefout
De eerste drie soorten problemen zitten in de taak zelf, maar een andere soort komt uit de omgeving. Een site kan browserkenmerken, toegangsverkeer en netwerkherkomst combineren om de bron van verkeer te beoordelen. Als dat verkeer verdacht lijkt, kan de site een verificatiepagina, lege inhoud of simpelweg een time-out teruggeven. In taaklogs lijkt dit bijna hetzelfde als een uitvoeringsfout.
Veelvoorkomende oorzaken zijn:
- De locatie van het uitgaande IP, de tijdzone en de taal komen niet overeen
- Alle taken versturen requests vanuit dezelfde browseromgeving, waardoor de requestdichtheid per tijdseenheid duidelijk hoger ligt dan bij echte gebruikers
- De omgeving verandert vaak of het account logt herhaaldelijk opnieuw in
Vier maatregelen die het slagingspercentage verhogen
- Maak elke stap idempotent. Controleer vóór uitvoering of de voorwaarde al is vervuld, zodat herhaling geen extra neveneffecten veroorzaakt. Leesoperaties zijn van nature idempotent; schrijfoperaties hebben een unieke identifier of deduplicatiesleutel nodig.
- Classificeer fouten. Tijdelijke fouten, zoals een element dat nog niet is gerenderd, netwerkfluctuaties of een API die 5xx teruggeeft, kunnen met backoff opnieuw worden geprobeerd. Deterministische fouten, zoals een beperkt account, ongeldige parameters of een ontbrekende doelresource, worden niet beter door extra retries; beëindig ze zodat ze geen concurrency-capaciteit blijven innemen.
- Sla status regelmatig duurzaam op. Bewaar voortgang, tussenresultaten en de huidige stap, zodat een taak na herstart doorgaat waar hij stopte in plaats van opnieuw bij stap één te beginnen.
- Isoleer de runtime-omgeving per taak. Geef elk account of elke taak een eigen browseromgeving, zodat Cookies en lokale opslag niet worden gedeeld, fingerprintkenmerken redelijk verschillen en tijdzone en taal aansluiten op de regio van het uitgaande IP.
De vierde maatregel wordt vooral belangrijk wanneer het aantal taken groeit. Als tientallen of honderden taken gelijktijdig draaien, bepaalt de omgevingslaag de bovengrens van de stabiliteit en ook hoe groot de impact is wanneer er iets misgaat. PurpleMark biedt in zulke scenario's de mogelijkheid om geïsoleerde omgevingen op aanvraag te maken en in batches terug te nemen, zodat elk account zijn eigen omgeving heeft en taakstatussen elkaar niet vervuilen.
Deze inhoud is uitsluitend bedoeld voor technisch onderzoek en het delen van ontwikkelpraktijken. Gebruik de betreffende technologieën op een legale en conforme manier en houd u aan de servicevoorwaarden van het doelplatform.
