Break your robot into multiple files

There are multiple ways to implement a producer-consumer robot. You could cram all the code inside a single tasks.robot file, which would work (technically). Sometimes, less (files) is not more (maintainability), though.

RPA Artificial Intelligence Marketing Demystified!

Maintenance-wise, it might be better to split the robot into logical parts. Need to update the producer logic? Find the producer file. Consumer logic - consumer file. Easy peasy! Breaking code down into smaller pieces is a software development best practice.

How do you know how to structure your code beforehand? Well, you don't! But you can still have a high-level guess and start with that guess. The structure will evolve while you write more code. This is expected and totally fine, don't worry. Code. Refactor. Code. Refactor. Rinse and repeat.

Refactoring fresh and even old existing code is recommended. Learn more in the OpportunisticRefactoring article by Martin Fowler.

Instead of a single long robot file, you decide to split the robot into three robot files. One file for the producer robot, another for the consumer robot. The third file will contain all the things needed by both of the robots (such as libraries or variables):

• producer.robot
• consumer.robot
• shared.robot

You rename the tasks.robot file (generated by the template) to producer.robot to communicate the robot's role. You change the name of the task to Produce traffic data work items and add high-level documentation:

producer.robot:

Next, you copy the producer.robot file and rename the copy to consumer.robot:

consumer.robot

Finally, you create a placeholder file for the shared settings and code. Shared means something needed by both the producer and the consumer robot. Instead of duplicating the same thing inside both robots, place that in another file that can be then imported. Initially, there is nothing to share (yet):

shared.robot: