Unleashing the power of AI in UiPath Studio with UiPath Autopilot.

Editor's Notes

1. C:\Users\RusselAlfeche\OneDrive - QBotica\Documents\UiPath\CodedAutomation
2. C:\Users\RusselAlfeche\OneDrive - QBotica\Documents\UiPath\CodedAutomation
3. - Method decorators/entry point methods - touch a bit on - input and output arguments - code generation for employee class - inheritance The entry point method for both coded workflows and coded test cases is named Execute() and is attributed as either Workflow or TestCase. You can change the name of the method, as long as you attribute it to either Workflow or TestCase. You can only use one Execute() method ([TestCase] or [Workflow]) inside a file, that inherits the Coded Workflowclass. In this method, you can add input and/or output arguments, which are equivalent to In, Out or In/Out arguments in low-code automations. Go through the Working with Input and Output arguments tutorial to learn how to use arguments in coded automations. This entry point method serves as the starting point for running the automations. This makes coded workflows and test cases easy to identify as entry points due to their Execute() method. Coded automations inherit the CodedWorkflow partial class, creating a relationship of type CodedAutomationExample : CodedWorkflow. This means that the CodedAutomationExample class inherits attributes, methods, and functionality from the CodedWorkflow class. Essentially, it can access and utilize the features defined in the CodedWorkflow class, which provides a foundation for the coded automation, making it easier to build upon and customize the automation's behavior. The CodedWorkflow class is declared as a partial class, allowing you to extend its functionalities by defining the same partial CodedWorkflow class in a code source file. This way, you can add new fields and methods to further customize the behavior of your coded automations. You can use this approach to implement a Before and After interface, specifically for coded test cases. Additionally, the CodedWorkflow partial class inherits the CodedWorkflowBase class.
4. C:\Users\RusselAlfeche\OneDrive - QBotica\Documents\UiPath\CodedAutomation Demo1-Workflow.cs Phase 1 - rpa challenge - object repository - simple ui automation - uiautomation options (just show overload methods for now)
5. C:\Users\RusselAlfeche\OneDrive - QBotica\Documents\UiPath\CodedAutomation Demo1-Workflow.cs Phase 2 - use challenge.xlsx as an input - input and output arguments - use the employee class for the coded automation, instead of datatable I know we're making this more complicated as it normally would, doing these unnecessary complications, but the purpose of this is to show you when it would make sense to use coded automation vs low code. A good rpa developer would know when to use one vs the other, which in this case I'm not. - low code (readinputexcel.xaml) -> coded (employeesworkflow.cs) - code generation for employeeworkflow class - coded (rpa challenge wf.cs) -> lowcode (readinputexcel.xaml) Phase 3 - typeintooptions Bugs - casting reference types like datable as an output from the lowcode workflow - error when debugging interoperable workflows/coded automation
6. C:\Users\RusselAlfeche\OneDrive - QBotica\Documents\UiPath\CodedAutomation - source files - default services - creating new services - openaiservice gpt4-1106-preview model highlight native activity limitation vs openai new model using new service show first readinputexcel.xaml (uncomment generate chat completion activity) then show Demo2-VeryLongContextWorkflow.cs (comment generate chat completion activity in readinputexcel.xaml) - openaiservice image generation and tts model show Demo3-GenerateImage.xaml Coded automations inherit the CodedWorkflow partial class, creating a relationship of type CodedAutomationExample : CodedWorkflow. This means that the CodedAutomationExample class inherits attributes, methods, and functionality from the CodedWorkflow class. Essentially, it can access and utilize the features defined in the CodedWorkflow class, which provides a foundation for the coded automation, making it easier to build upon and customize the automation's behavior. The CodedWorkflow class is declared as a partial class, allowing you to extend its functionalities by defining the same partial CodedWorkflow class in a code source file. This way, you can add new fields and methods to further customize the behavior of your coded automations. You can use this approach to implement a Before and After interface, specifically for coded test cases. Additionally, the CodedWorkflow partial class inherits the CodedWorkflowBase class.