agreed to:
we should also see that they coming from another side and do have another control of solution design control
we can design our XAMLs and also can separate it into the layers
Presentation - Ui-Interaction
Logic - Decisions, Data Evaluations…
Data Access - DB Queries, API Calls, Integration Service
But compared to programming languages, we differ in the technical possibilities, such as implementing a business domain model with its derived business classes using XAMLs.
When retrieving data from UI (e.g. Table Data Extraction) our Data Source is not a Datatable but the UI. So just to mention an example that shows us that we also have to adapt concepts to the RPA World.
Lets elaborate more on the statement:
we can design our XAMLs and also can separate it into the layers
Mission:
- extract Data
- evaluate Data and compute its Flow Logic rule outcomes
- click in Ui on the related uiElements (e.g a OK Button, a Cancel Button)..
Separated XAMLs:
- a forefront caller XAML offering the Functionality of taking out a car from the car pool
- RetrieveCarPoolData.xaml
- FindCarByCriterias.xaml
- TakoutCarFromPool.xaml
vs.
a single XAML e.g. modelling all steps in one
Also lets keep in mind:
- a few sentences will not be enough to elaborate all in depths
- in RPA implementations we also compromise and balance other factors like
- skill set of users, doing the implementation
- given technical capabilities (Studio, Studio Web, Studio X, Workflow Foundation…)
- Project Coding Guidelines
- … and others