Skip to main content

One of the most appealing aspects of Automation 360 is that it's not programming-language-specific. You don't have to be an expert at any specific programming language to be able to build robust, high-impact automations, making for an easy-to-learn, approachable platform. That said, while learning about the capabilities of Automation 360, you may have noticed that it also enables developers to leverage several programming languages (Java, Python, JavaScript, .NET, etc) from within a bot by leveraging language-specific packages and a customizable package SDK. In this blog post, we'll take a look at why you may want to hold off on some of that functionality and when/where it makes sense.

 

Out-of-the-Box Packages: Working with Interfaces

 

Automation 360 offers a wide range of out-of-the-box packages designed to enable automation developers to automate with/on various interfaces. These available packages enable automation developers to automate on top of existing user interfaces (recorder package), REST (REST Web Services Package) & SOAP (SOAP Web Service package) web services, and even Terminal applications (Terminal Emulator Package). When automating either a Graphical User Interface (GUI), Application Programming Interface (API), or Terminal Application, these built-in packages should be your first stop. Additionally, scripting languages or programming experience is not required to automate user interfaces and these built-in packages will meet your needs 99% of the time.

 

Out-of-the-Box Packages: Working with Variables

 

Automation 360 uses strongly typed variables that enable you to work with a variety of different data types. For each variable type, there’s a dedicated out-of-the-box package that can be leveraged to create, read, or update data from a variable of that type. In some cases these variable-specific packages enable you to do some complex manipulations that would otherwise need to be done with several lines of code or complex logic in other programming languages. Why does this matter? Because it’s important to know what’s available for solving a problem at hand before arbitrarily reaching for a custom script in another programming language. Need to read values from a dictionary? There are packages (loop and dictionary) that support that. Need to perform string manipulations? The String package has a TON of capabilities for extracting substrings, splitting strings, changing string case, and converting to other data types. Performing complex mathematical operations on numbers? Check the actions of the Number package to perform these calculations. No need to add the complexity of additional scripting languages to do your calculations.

 

Out-of-the-Box Packages: Working with Specific Applications

 

Beyond manipulating variables and automating user/application interfaces, Automation 360 comes out of box with a host of application-specific packages that enable it to interface with many popular business applications. Working with Salesforce and want to use the API instead of automating the UI? Great! There’s a package for that (Salesforce Package). Need to read from, insert data to, or update an Excel Spreadsheet? There are actually two Automation 360 packages that make interfacing with Excel/CSV files a breeze (Excel Basic and Excel Advanced Packages). Maybe you’re not using Excel, and your organization leverages Google Sheets instead. All good. The Google Sheets package enables developers to perform many of the same actions in Google Sheets documents. While we wont continue to go through every single application that has an out-of-box package, let the lesson sink in. Before you think you need to automatically turn to finding a Python or Java library to integrate within your bot in order to interface with a specific application/file type, be sure to check the capabilities that are already built into the platform itself. Automation 360 packages are being updated/added with each release so you’ll want to always check your Control Room with each release (or more specifically the release notes) to understand what new capabilities are available.

 

Bonus Tip: Check Automation Anywhere’s Bot Store

 

Did you know Automation Anywhere has a Bot Store? In addition to pre-built automations, it also offers a huge collection of Automation 360 packages built by employees at Automation Anywhere, as well as a host of Automation Anywhere partners and customers. These available packages can be a great way to explore some new solutions and quickly expand on the in-built capabilities of your Automation 360 Control Room. You’ll find all kinds of useful packages to perform operations like file conversions, advanced JSON parsing, selenium-based web automation, and Natural Language Processing (NLP) capabilities in the freely available Bot Store packages collection. Better still, most of the Automation Anywhere developed Bot Store packages have had their source code published, so if you’re interested to see how they work or add additional capabilities, you can find them on the Automation Anywhere GitHub page.

 

Conclusion & Actionable Takeaways

 

It can be tempting to see that all of these additional programming languages are supported by Automation Anywhere and want to go straight to those in order to solve problems. And while it's great that such language support exists, adding custom scripts can add complications to your automations and the Bot Runners that execute them. As your organization or team begins to deliver quick wins for your business, focus on building familiarity with, and delivering solutions based on, the existing (or Bot Store) package set as opposed to reaching first for Python/JavaScript integrations. It will keep your automations simpler, and will provide time for you to build a deep familiarity with the capabilities of the platform.

 

Actionable Takeaways:

  • Build a POC bot that leverages a package you have used before, but that may also be of value to your organization.
  • Check out Automation Anywhere’s Bot Store. There are a large number of freely available pre-built Automation 360 bots, as well as custom Automation 360 packages that you can install directly into your Control Room.
  • Review some of your recently developed automations. Were there things done in scripting/programming languages that could have otherwise been done with a built-in package? If so, work with your automation program lead/CoE to identify standards for when/where custom scripts should be used, how they should be shared, and how they should be maintained.
Be the first to reply!

Reply