Processes Vs Libraries Vs B0ts
Process: A Specific Process created in UiPath
Library: A reusable body of code created using UiPath, or .NET
Bot: A casual name for a collection of Processes and libraries which produces business value
Library: A reusable body of code created using UiPath, or .NET
Bot: A casual name for a collection of Processes and libraries which produces business value
What's an API? How about an RPI?
API: "Application Programming Interface", i.e something easy to automate
RPI: "Robotic Programming Interface" - i,e something easy to automate
RPI: "Robotic Programming Interface" - i,e something easy to automate
Dispatchers, Performers and Reporters
Don't put everything into a single process.
-> You lose all opportunity for reuse
-> If it fails, you lose everything.
Dispatchers
-> Get transactions, and put them into a Que
-> Can use Orchestrator Ques
-> Or files, Or a database.
-> often, these only need to run once, and performers will have hours of work.
-> Ultimately, prepares Transactions
Performers
-> Execute Transactions
-> Must be horizontally salable (Bumblebee needs to complete 90 hours of work in 10 hours)
-> Ultimately, converts Transactions into Result Data.
Reporters
-> Report results of transactions
-> Should be flexible: Maybe people want a spreadsheet. Maybe they want email alerts. Maybe they want a Skype message.
Or a Splunk Dashboard. Or a Database record.
-> Sometimes, these needs will change, or be different for different people. You might need multiple reporters. So keep this different from the Dispatcher and the Performer.
-> Ultimately, explains the Result Data to the Business
-> You lose all opportunity for reuse
-> If it fails, you lose everything.
Dispatchers
-> Get transactions, and put them into a Que
-> Can use Orchestrator Ques
-> Or files, Or a database.
-> often, these only need to run once, and performers will have hours of work.
-> Ultimately, prepares Transactions
Performers
-> Execute Transactions
-> Must be horizontally salable (Bumblebee needs to complete 90 hours of work in 10 hours)
-> Ultimately, converts Transactions into Result Data.
Reporters
-> Report results of transactions
-> Should be flexible: Maybe people want a spreadsheet. Maybe they want email alerts. Maybe they want a Skype message.
Or a Splunk Dashboard. Or a Database record.
-> Sometimes, these needs will change, or be different for different people. You might need multiple reporters. So keep this different from the Dispatcher and the Performer.
-> Ultimately, explains the Result Data to the Business
Naming
Testing, QA, Validation
Waiting
Static Waits
-> What happens if every single wait condition is managed with a fixed value?
-> How does slow bot performance impact Development? QA? Production?
-> What happens if every single wait condition is managed with a fixed value?
-> How does slow bot performance impact Development? QA? Production?
Dynamic Waits
-> Do this always. There is always something to wait for.
-> Except when there isn't. Occasional "Smart Waits" that for very quick actions (Like screen rendering or a small file being written) are ok.
-> I have made it this far in my RPA career without ever using a static wait that was more than 0.5 seconds long in production.
-> Do this always. There is always something to wait for.
-> Except when there isn't. Occasional "Smart Waits" that for very quick actions (Like screen rendering or a small file being written) are ok.
-> I have made it this far in my RPA career without ever using a static wait that was more than 0.5 seconds long in production.
The RE Framework
Study Tip:
Because the RPA Developer exam is largely multiple choice, learning the literal names of the various stages in the RE Framework will help you get a better score. Do I think it's actually useful? Not really. But certs are nice.