RPA is sold on demonstrations of a robot filling in forms. That is what people picture.<\/p>\n
It is also the least reliable thing RPA does<\/strong>, and in well-built automations it is often a small part of the whole.<\/p>\n Much of what production RPA actually does:<\/strong><\/p>\n Downloads a file. Extracts an archive. Checks the file is what it should be. Sends it somewhere. Logs the outcome. Fails cleanly when something is wrong.<\/p>\n None of that involves a screen.<\/strong> And all of it is work somebody currently does by hand.<\/p>\n The most common thing production automations do, and the least discussed.<\/p>\n Downloading.<\/strong> Not always by navigating a site \u2014 often by making an HTTP request directly to a URL, which is faster and far more reliable than driving a browser.<\/p>\n Extracting archives.<\/strong> Data is frequently published as a ZIP containing one or more files.<\/p>\n Finding the right file.<\/strong> An archive may contain several. Picking the newest by modification time<\/strong> is a common and sensible rule.<\/p>\n Validating.<\/strong> Does the file exist? Is it the expected type? Does it have content?<\/p>\n Moving it on.<\/strong> To another system, an API, or a folder something else watches.<\/p>\n FIGURE 1: A FILE-HANDLING AUTOMATION<\/p>\n Download<\/p>\n Extract<\/p>\n Find and validate<\/p>\n Hand off<\/p>\n Worth being explicit, because this is where a lot of unnecessary fragility comes from.<\/p>\n If a file has a direct URL, request it.<\/strong> Do not open a browser, navigate to a page, and click a link.<\/p>\n Three reasons:<\/strong><\/p>\n Reliable.<\/strong> No layout to change, no element to move, no popup to interfere.<\/p>\n Fast.<\/strong> No browser to start, no page to render.<\/p>\n Debuggable.<\/strong> An HTTP request either succeeded or returned a status code that tells you why not.<\/p>\n Navigate only when there is no direct URL<\/strong> \u2014 when a login is required, or the link is generated per session.<\/p>\n And when you must navigate, do as little as possible.<\/strong> Get to the file and stop.<\/p>\n An automation that downloads a file has to give it to something.<\/strong><\/p>\n A common and sensible pattern:<\/strong> upload the whole file in one request to a workflow tool or an API endpoint, and let that handle the contents.<\/p>\n Why the whole file rather than row by row:<\/strong><\/p>\n Fewer executions.<\/strong> A 500-row file sent row by row is 500 calls. Sent whole, it is one.<\/p>\n Less duplicate risk.<\/strong> A partial send that gets retried can produce duplicates. One file either arrived or did not.<\/p>\n Clearer failure.<\/strong> “The upload failed” is easier to reason about than “rows 1\u2013340 arrived”.<\/p>\n Cleaner separation.<\/strong> The automation’s job is getting the file. Understanding the contents is the next system’s job.<\/p>\n FIGURE 2: HANDING OFF A FILE<\/p>\n Whole file, one request<\/p>\n Row by row<\/p>\n Check before you send.<\/strong><\/p>\n Was a file found at all?<\/strong> The archive might have been empty, or the download might have produced an error page.<\/p>\n Does it exist on disk where you expect?<\/strong> Extraction can fail silently.<\/p>\n Is it the right type?<\/strong> A CSV that is actually an HTML error page is a classic failure \u2014 the download “succeeded” and returned the wrong thing.<\/p>\n Does it have content?<\/strong> A zero-byte file is not data.<\/p>\n Failing here is much better than failing later.<\/strong> A bad file caught before upload is a clear error. A bad file uploaded is a confusing problem in another system.<\/p>\n This is where RPA earns its place as an orchestration tool.<\/strong><\/p>\n Wrap each stage in try-catch.<\/strong> Download, extract, find, validate, upload \u2014 each its own protected block, so you know which one failed.<\/p>\n Log the error message and the stack trace.<\/strong> When it fails overnight, that log is what tells you what happened.<\/p>\n Re-throw so the job is marked failed.<\/strong> This matters more than it sounds.<\/strong> An automation that swallows an error and exits successfully is the worst outcome \u2014 the orchestrator records a success, nobody is alerted, and the data silently did not arrive.<\/p>\n A failed job is visible. A quietly-succeeded failure is not.<\/strong><\/p>\n FIGURE 3: ERROR HANDLING THAT WORKS<\/p>\n Try-catch per stage<\/p>\n Log message and stack trace<\/p>\n Re-throw so the job fails<\/p>\n Alert a named person<\/p>\n If your automation calls an API or uploads a file, check what came back.<\/strong><\/p>\n The status code.<\/strong> Success or failure, and which kind.<\/p>\n The response body.<\/strong> The receiving system may tell you something useful \u2014 how many rows it accepted, what it rejected.<\/p>\n Log both.<\/strong> A successful upload with a response saying “0 rows processed” is a failure wearing a success badge, and only the response body reveals it.<\/p>\n Still necessary, sometimes.<\/strong> A portal with a login and no direct file URL. A desktop application with no API. A system nobody can change.<\/p>\n But it should be the minority of what an automation does<\/strong>, and it should be confined to the smallest possible step.<\/p>\n A good design:<\/strong> screen work to get past the thing that requires it, then ordinary reliable methods for everything after.<\/p>\n When the site redesigns \u2014 and it will \u2014 you fix one step.<\/strong><\/p>\n RPA is not only screen automation, and in production it often mostly is not.<\/p>\n Downloading, extracting, validating and handing off<\/strong> is the bulk of the work, and it is far more reliable than clicking.<\/p>\n Use HTTP requests where a direct URL exists.<\/strong> Send whole files rather than row by row. Validate before handing off.<\/p>\n And re-throw errors so the job fails visibly.<\/strong> A swallowed error is a silent gap in your data that nobody discovers for weeks.<\/p>\n Somebody downloading and checking files every morning?<\/p>\n Get in touch. Most of that work is orchestration rather than screen automation \u2014 which makes it far more reliable than people expect.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The reputation problem RPA is sold on demonstrations of a robot filling in forms. That is what people picture. It is also the least reliable thing RPA does, and in well-built automations it is often a small part of the whole. Much of what production RPA actually does: Downloads a file. Extracts an archive. Checks […]<\/p>\n","protected":false},"author":3,"featured_media":9304,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-9303","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-robotic-process-automation"],"yoast_head":"\nWorking with files<\/h2>\n
\n
\n
\n
\n
Why an HTTP request beats a browser<\/h2>\n
Handing off to the next system<\/h2>\n
\n
\n
Validation before handing off<\/h2>\n
Error handling<\/h2>\n
\n
\n
\n
\n
Capturing the response<\/h2>\n
Where this leaves screen automation<\/h2>\n
The short version<\/h2>\n