Building and Testing Best Practices

Think Like a Robot, Not a Human

In an ideal world, a robot completes the same tasks every day without interruption or fail. However, in the real world, robots sometimes get stuck.

Robots typically get stuck due to the following reasons.

Scenario How to plan for the scenario

A robot doesn't understand an element in a user interface (UI)

Remember that a robot interacts with an application differently than a human does. Build your robot intentionally for the robot's requirements.

For example, many people interact with software using their vision. When people encounter issues, they often click around and troubleshoot to find a way forward. Robots don't have these abilities. A robot can do only what it's programmed to do, nothing more or less. While building a robot, thinking about its actions programmatically, rather than visually, helps you build more effectively.

The UI or HTML for a page changes

The robots in Oracle Integration are continually evolving to better handle these scenarios. Additionally, you can use global targeting in your actions so that you can more quickly update fields when needed.

Define Inputs Using Robot Connections

When defining an action's input, such as the URL for a browser, use the values that you defined in a robot connection whenever possible.

Specifying a value one time in the robot connection and pointing to that variable lets you isolate this information. When you need to update the value in the future, you need to update only the robot connection, rather than every robot that uses the connection.

Future-Proof Your Robots

Don't hard-code data unless you need to. Instead, future-proof a robot by using placeholder values.

See Alternatives to Hard Coding Data.

Keep the Canvas Tidy

You build your robot in the canvas. Keep the canvas organized so that you can find information quickly. For example, use clear names for actions.

For more guidance, see Quick Start for Building Robots.

Create Naming Conventions

When performing UI-based automation, you must provide names for a variety of components, including robots, the environments that the robots run on, and the actions that the robots perform.

The names of some objects, such as robots, robot connections, and environment pools, can include spaces. Other more programmatic objects, such as variables and input parameters, cannot include spaces in their names.

If your organization doesn't have them yet, create naming conventions. Then, follow the conventions so that everyone understands the components at a glance and can update a robot quickly and confidently.

Test in Real-World Conditions

Test a robot early and often using real-world conditions.

See Run and Test a Robot.

Use Screenshots to Help with Testing

When you add an action to a robot, you have several options for capturing screenshots, including capturing a robot's view before and after completing an action. The screenshots are helpful when troubleshooting a failed robot instance.

For example, if a robot's credentials don't have the appropriate access, a robot might not be able to see the field it needs to update. A screenshot of the missing field can help you quickly troubleshoot any issues that the robot encounters in the user interface.

See Capture Screenshots in Robots.