We recently upgraded to Robotics R25. Since I’m having to restructure our projects, I’m wondering if adding error messages to every automation (besides events) would be best practice?
Previously, I used the Events/Functions/Procedures folder structure and only returned error messages in my procedures. Functions returned only values like strings, lists, true/false, etc. without a message.
I noticed when unchecking the “empty automation” option, the default template for automations in R25 includes an error message and true/false result. I’d like to use the default automation template, but that means I would probably need to write error messages for every failure point. Which is a lot because I put a ton of checks like IsCreated, IsEnabled, InputAllowed, NotNull, etc. on all of my controls and inputs to avoid getting exceptions (instead of merely hiding exceptions with a try/catch or the SupressErorrs property).
The most recent R25 release, (25.1.27) introduces custom template automations, giving you greater flexibility to design templates that match your specific workflow and preferences.
For any automation where you plan to write unit tests, the default automation is the recommended starting point. To see this in practice, check out the InsuranceDemo sample project (available via the Help menu) — it demonstrates how to use the Result and Message outputs to diagnose why an automation failed.
If you’re upgrading from v19 to R25, a significant number of enhancements are waiting for you. Before diving into those changes, it’s best to migrate your existing v19 project first and confirm everything is working as expected — then layer in additional modifications from there.
We converted one project successfully to R25 and another is in progress. Since one project has been successfully upgraded, I’m now thinking about how to convert automations to reusable to components, and possibly eliminating multiple exit points from our procedures along with possibly adding more error messages.
In addition to setting standards for error messages, I’m also wondering how to best use the new application methods. Right now, I feel like application methods should be basic extensions of built-in methods. For example, I built a StartAndWaitForStarted method and StopAndWaitForStopped method that combine the Start/Stop and WaitFor events. I’m also thinking of using the applications methods as a “model”. Like adding methods for GetUserID, SetPassword, GetCustomerFirstName, SetCustomerAddress, etc. that just get or set values.
Moving your projects from v19 to R25 can be done two ways.
The first option is a straight upgrade, which combines all of your individual v19 projects into a single R25 project. Each v19 project is stored in its own folder, and the upgrade process merges them.
The second option gives you more control. Upgrade your standalone projects one at a time and deploy each as a project asset. Then, when you upgrade the v19 solution, select “use project assets if available” in the upgrade wizard. The result mirrors your v19 solution structure as closely as R25 allows.
Application assets and utility assets are for building reusable components, but they come with an important constraint: public methods in an asset cannot access anything outside the asset’s scope. This means converting existing automations can be difficult if they reference external scope or share state across projects. Plan for that work before you start.
Large monolithic utility library projects are hard to version and maintain. Utility assets give you a better approach: build small, targeted assets where each one performs a single function. Your utility library becomes a collection of independent assets, each versioned separately and carrying no dependencies on other utilities.
A good starting point is your existing utility projects. Breaking them apart into focused assets pays off quickly and gives you a clear pattern to follow as you migrate the rest of your work.
Hope this helps - let me know how your journey is progressing,
Jeff
When working with application assets, think of application methods as a way to perform a specific task within an application – nothing more. They should not contain business logic. Keeping business logic out of application assets is what makes them reusable across projects and teams.
For example, an asset might contain one method to perform a customer search and another to return customer details. The consumer of that asset uses those methods and applies their own business logic on top. If the application changes – say, customer details move to a different screen – only the application method needs to be updated. The consumer is insulated from that change as long as the method signature stays the same.
If you need to change the interface for an application method, create a new method instead.
One constraint worth keeping in mind: you can only have one application asset per application. That makes it important to be deliberate about which methods you expose. Focus on the interactions your asset consumers are most likely to need rather than trying to cover every possible use case up front. And since you only get one asset per application, protecting your existing method signatures is critical. A breaking change affects every consumer of that asset, which is exactly why adding a new method is a better path than modifying an existing one.