On GitHub there is a new version in preparation for version 1.5.
Would love to know what are main new features of this upcoming version. Is there already some documentation out?
Will it be possible to open process files from version 1.3 with 1.5?
1 Like
I’ll try and keep it short
OpenRPA 1.4 was a significant overhaul that involved rewriting all UI event handling. The goal was to enhance OpenRPA’s responsiveness and resolve the UI’s occasional lockups in specific scenarios. Additionally, this update transitioned OpenRPA from saving data as raw files on the file system to using LiteDB for data storage. With OpenRPA 1.4, premium openflow users can now also benefit from more detailed reporting of spans and performance data.
It’s uncertain whether OpenRPA 1.5 will ever see the light of day as a Windows application utilizing Microsoft Workflow Foundation (WF) as the user interface. WF was created by Microsoft and released in .NET 3.5. In .NET 4.0, Microsoft completely rewrote WF and made it even better, and it improved even more with the release of 4.5. In 4.6, Microsoft added support for C# expression and better async support. This was in July 20, 2015. Since then, Microsoft has stopped updating it, despite many people begging them to port WF to .NET Core. After a few years of ignoring people, they finally decided to put it in the grave at the end of 2019. Shortly thereafter, they allowed the open-source community to pick it up and continue developing it as CoreWF. However, they quickly transferred ownership to UiPath, who renamed it UiPath.CoreWF and kept the UI closed source for themselves. This was a terrible move on Microsoft’s part, that left all the users of this platform hanging and looking for an alternative
For a while, my plan was to migrate everything to Node.js and implement it in Node-RED. However, the Node.js Foundation made a decision that impacted us all. They allowed the core developers of Node-RED to create a company and compete with all the other companies that had chosen Node-RED. This move was particularly upsetting because many of us had selected Node-RED because it was owned by a foundation and, therefore, we didn’t have to worry about the sudden addition of a commercial model around the product. But unfortunately, this is exactly what happened.
I was interested in Elsa Workflow as an alternative to NodeRED. Elsa is an open-source workflow system implemented in .NET Core, with a web front end and similar interfaces and models as Microsoft’s Workflow Foundation. The designer was clunky, and I found myself clicking a lot, but overall it seemed promising. However, the creator of Elsa has plans to commercialize the platform by offering orchestration services, which made me hesitant to rely on it as another potential NodeRED disaster. I considered creating my own workflow engine, but my UI/UX skills are lacking, and I cannot afford to hire someone to help.
While discussing the future of OpenRPA with my wife, who is supportive enough to allow me to continue working on the project without getting paid, she suggested that I turn it into a UI testing framework. At first, I didn’t fully grasp her idea, but upon further reflection, it made a lot of sense. By creating an abstraction layer between the UI automation technologies and the UI/Workflow/Recorder, I could potentially serve two markets simultaneously.
I developed a plan to separate the different technology stacks such as SAP, Mainframe, image, windows, browsers, Java and so on, into their own NPM packages. For technologies that couldn’t be migrated to Node.js, I would create a bridge using Named Pipes. This approach would enable me to build an “OpenRPA” application that would be cross-platform and work on any operating system, at least for technologies like browser automation, image, and Java.
Also, I had long wanted to rewrite the API for OpenFlow to be more efficient and cleaner than using JSON over WebSockets. To achieve this, I decided to explore Google’s Protocol Buffers as an alternative. With this approach, I could use the same code and protocol between different packages on the local machine and between programming languages and OpenFlow. By using a programming language-agnostic protocol like proto3, I could quickly create SDKs for different programming languages and ensure a consistent look and feel across languages.
While working on that, some of my paying customers expressed interest in running actual code in OpenFlow instead of only NodeRED workflows. Since I wanted to distance myself from NodeRED and also allow other workflow engines to be a part of the platform, the idea of agents was born. This involved the option to deploy packages with source code in multiple different programming languages or workflow engines into OpenFlow, or simply run them as agents remotely while still being orchestrated by OpenFlow.
Currently, I have almost completed the proto definitions and have incorporated several communication methods such as named pipes, TCP sockets, web sockets, GRPC, and REST to connect with OpenFlow and utilize Protobuf3. Moreover, I have successfully implemented GRPC and websockets for JavaScript in browsers, NodeJS, Python, and .NET Core. Currently, I am focusing on enhancing the distribution process of code packages to remote agents and agents operating in docker/kubernetes.
Once that is completed I can shift my focus towards making the different components of OpenRPA more future-proof by packaging them as libraries that can be used from code. Once this task is complete, I can explore the possibility of adding a code generator/recorder or even a new workflow engine on top of it. So OpenRPA 1.5 will be a type of agent or an combination of different type of agents and not just a single Windows Application like now
Regarding the future direction, I am particularly interested in the concept of a Chrome extension rather than relying solely on webdrive/selenium. My intention is not to compete with existing solutions such as pixiebrix or AutomaApp/automa, but rather to create something similar that is connected to OpenFlow. The potential benefits of having the ability to control processes from the browser and/or control the browser from OpenFlow are quite appealing, and this approach may help solve the challenge of creating a recorder that works with both an extension for assisted automation and web driver for unattended automation using frameworks such as tagui/robotframework/pupperteer or any other suitable automation framework.
8 Likes
@indigos the above is both some historic information and some general idears about the roadmap for openrpa in general.
There is no timeline, but it has the highest priority for me.
1 Like
Good Job ,
I believe that it is necessary to enlarge the community to make OpenRpa the best Open source tools.
For example you open a discussion on the roadmap where each user describes the features to add
And finally, following a rating system you define the priorities to this version.
3 Likes
I have a few questions I’d like to ask you.
Q1. Will OpenRPA be developed using .Net 4.8.1 or .Net Core in the future?
Q2. Will workflow designed in version 1.4 be compatible with version 1.5?
Thank you for your assistance.
hey
Well, i still havent decided on all details, but
- No, It will most likely be done in NodeJS or go lang
- No, but I will keep openrpa 1.4 a live for as long as I can. So far current version will be supported by microsoft until 2027 and i can always bump openrpa up to 4.7 or 4.8 ( not sure if 4.8 is possible ) being in 4.6 is mostly to support XP/Vista/server 2012
At some point i will maybe try and see if i can migrate most of the activities to elsa workflow, if I manage to do that, then you will be able to import raw openrpa workflow into that.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.