Considering building an RPA scripting language

Six months ago, I built a DSL for doing E2E test automation called SchnauzerUI. Although I don't know if more than a handful of people will ever use it (it served a very specific purpose for me so I'm fine if they don't), I would call the project a success.

I am now considering taking on a much larger project: A general purpose scripting language for doing RPA. I'd now like to take a moment to outline why I would do such a thing, and what it might look like.

As of today, robotic process automation is dominated by graphical tools. Tools like Power Automate and UI Path let users compose prebuilt plugins together to form long chain processes. Users can also set pre-built triggers for said events, like http requests, emails, or even getting a teams message.

This state of affairs seems strange, because no-code tools did not consume the larger software engineering sector like many people predicted. We still write software with a programming language because it's simply the best way to build complex software.

There are of course many libraries in popular programming languages and even some custom programming languages aimed at doing RPA. One excellent language is called TagUI, and it provided a huge amount of inspiration for SchnauzerUI (the aforementioned web automation DSL). The major feature missing from TagUI (imo) is a system for triggers/events.

I think many factors contribute to this niche being relatively unfilled. RPA scripting is generally not efficient, and seen as a last resort for when there aren't good options for interacting with software programmatically (I mean APIs). It's also kinda hard to do in the cloud, because visual automation requires special software to help the server pretend it has a monitor and keyboard plugged in, so building on popular cloud services is tricky.

Despite these barriers, I could see deriving huge value from an RPA focused scripting language. The rest of this post will be some thoughts on what such a language would be and the possible challenges involved in implementing it.

First off, the language would need to have a huge amount of resources built in and pre-configured with sane defaults. I'm talking a web browser, database, mail server, job scheduler, CSV/Excel reading and writing, and http client and server. All of these would be provided by the language runtime (which would actually be a constant background process), and the language would treat these services as first class citizens, meaning it would have dedicated syntax for interacting with them. That's a lot of very different looking syntax. I'm tempted to say that it should have projectional editing, but I'm afraid it'd turn into another GUI based tool very quickly. And these are just the defaults. You would also need a thoughtfully designed plugin system which allowed plugin designers to take advantage of language syntax (similar to the way rust language syntax takes advantage of trait implementations).

As far as syntax, I have no idea yet what it should look like. For organizational purposes, it may be nice to have a "triggers" page, where all the events and their triggers are declared. This would serve a similar function to a routes file in a web framework. A web dashboard where events could be manually triggered and scheduled would probably be good as well.

One candidate for a way to build this would be wasmcloud. It has a concept of platform/vs application development and a clean separation between actors (which would be our automation business logic) and providers (which would be our set of services).

Thanks for reading this post, which was really more of a note to self. Feel free to comment!