Migrating from Traditional to Reactive
As OutSystems does not provide automatic tool to convert applications from traditional web to reactive, probably you will keep in touch to the same questions that appeared to me:
- should I fix the actual errors before migration?
- what metrics should I use to create an estimative?
- what change in the development?
My experience helped me to answer these question and I am sharing the answers to help you get success in your engagement too.
Evaluate the architecture
You will not want to transfer problems to your new code, right? Yes, but you don’t need to fix all kind of errors in your system. Usually architectural problems are the most common to be solved. You need to evaluate if there are cyclical references or undue access between the layers of your application. You can use the Discovery tool to check the quality of your system and if the fixes worked properly.
Is it the right moment to do the changes? In my humble opinion, the answer is: YES because you are creating a good foundation to compare and test against the new version. Besides, in architectural terms, modules from core and library layers are reusable and the target will be modules from end user layer.
Define development metrics
Long story short, in the beginning I thought that I could use the menu options as reference to generate metrics. It didn’t work well. The best alternative I found is the number of screens and I disregarded the number of web blocks because they are reused in other screens.
The next step is to calculate the average of time to deliver. You can choose any module and start the conversion to reactive during a specific period. I will use 10 business days because it will be better to do calculation but you can work during one week if you want. The main goal is to count how many complete screens you have created during this period and put your data in a spreadsheet as can be seen in the picture below.
It is possible to see in the picture that during 10 business days, 7 screens were created. If I use rule of 3, I can reach the following conclusion: 7 screens is for 10 business days and, in the same way, 28 screens is for x business days. The calculation is: 7x=28*10 => x=280/7 => x=40. You will see as 30 the estimated number of business days (Governance_Workflow) because 10 business days were already used to create the reactive code.
From this point forward it is possible to generate a spreadsheet (according picture below) that could give me a general view of the project.
Now we have all information needed to generate a general project view. Once you add all modules duration, it is possible to have the total business days estimated. The project might need to run on different number of iterations depending on the quantity of developers available. According the days used in each iteration it is possible to have an estimative of screens that will be delivered. This number will help you select a set of specific UI Flows avoiding code fragmentation that could delay the delivery to the next iteration. The example in the picture also regards that it will be needed to run 3 iterations once 3 screens will remain after 2 iterations.
The last but not least, theme need to be created to the new system, testers need to be regarded to deliver a code with quality and the time to deploy the system between the environments need to be regarded in the planning. Don’t forget to mention them.
Tips for development
Maybe you would like to see the differences between traditional web and reactive applications. I already wrote an article about this subject (it can be seen here) and, I added more tips here that can save you more time.
General approach: it is up to you find your best way to do the migration but I found some benefits using this approach: reuse aggregations and actions (it is possible to copy them) available into preparation, change to the widget tree option to select and copy all possible widgets to the new screen. It was wealthy to use scaffolding in the case of pagination and search creation because these 2 “functions” use different approach in reactive way. The next step is to fix all errors and put the remaining additional logic.
Popup screens: popup screens are now a component added into the owner screen. You will not see the option to create parameters as usually you see in the traditional web approach. The workaround I used to handle this was the use of web blocks. You define it with all needed parameters and add it to the popup panel where you possibly will need to do some adjustment once the max-width of screen is 500 pixels. Use popup-content class to add a scroll bar and/or popup-dialog class to change the screen size. Don’t forget that this approach implies that you control the close and notify, so create the events needed to control them. If you screen becomes a mess due to the big quantity of popup screens, use the following css code “.popup-backdrop { -servicestudio-position: relative; }” to display the popup content below the popup widget. You will face a logical error when you don’t pass the parameter using a table because you will always have the last register at the end. I. created a web block to control the close.
Master/detail scaffolding: you will not have more the master/detail scaffolding. You can use the master/detail UI pattern to show your data but, at least for me, it is not the same thing. Master/detail scaffolding have more features than the its peer UI.
Debugging constraints: now you don’t have the option to debug expressions and ifs in the screen because breakpoints can only be placed in action flows.
Facade: to improve its performance, screens are protected to access the server directly. You need to set data actions to get calculated values or formatted fields that can be reused as output parameters. The same applies to BPT, make a reference to a server action encapsulating bpt code. Depending on the way you will use this new approach you can have performance issues. The next topic is an example of it.
Formatting fields/poor performance: usually list screens need to present formatted data and imagine that you would like to use DateTime_PrettyFormat that is a server function available in the RichWidgets. A data action will be needed to invoke DateTime_PrettyFormat (in a for each) and store the formatted date in a text field associated to the aggregate. This way you have all information available in the same place when displayed in the screen. Possibly you have more than 1 server action in the data action and service studio will provide you a performance issue warning and it will really occur because you will see the system literally “drawing” when the screen be displayed. A possible workaround would be to pass the aggregate as parameter but regarding the increase of workload it will not be interesting to do that. My best shot was to convert DateTime_PrettyFormat as a client function. I had only to open a clone of RichWidget and copy DateTime_PrettyFormat and TranslatableFormatMonthDateDate in the client actions folder in the logic tab of my application. Pretty easy, hum ?
List_BulkSelect: my attempt to convert it failed. Even if you put a name in a table widget (it is not mandatory), it will not be available as parameter. In other words, in the reactive context, you access directly the aggregate and not indirectly through a table widget and as consequence, you will have to try another strategy to make a bulk processing.
Email: only traditional web app can send and handle email widgets. You need to reuse them in the reactive app. Make a reference to the module that has email widget or associate a call to a BPT.
Advanced SQL: it is only accessible now in a data action. So, you will need to create output parameters to access its list. As advanced SQL doesn’t have automatic control of pagination and other optimisations like aggregate, you will need to manually create them once you display data from it on the screen.
Miscelaneous: input widget doesn’t have “text lines” option and you will need to use the Text area widget to enable multi-line text. Don’t forget to set “No” in the “Built-in Validation” option after creating a close button. Now you only need to set the “-” sign in the empty text option in reactive dropdown widget instead of add zero and “-” sign in the special list.
Conclusion
Migrating to reactive can be done in a strategic and purely programatic way. From the strategic perspective, it was presented a simple way to get a rule of thumb to grasp an estimative to your customer, for instance. From the development perspective, it is possible to learn based on previous experience on commercial projects. Both contributions can be used as foundation to increase the software development speed and quality. I hope you enjoyed this article and have a nice week.