This post is currently in a preview version and will be further updated in the near future.
In this part of the [InfoSet] - LegacyToWindows Migration series, a prototypical legacy-to-Windows migration is demonstrated. For this purpose, a legacy modeling is converted with the automatic converter tool. Afterward, the conversion result will be post-processed in order to get it executable.
An existing implementation is used for a prototypical code conversion to evaluate the feasibility of the migration and the work steps in practice. Typical for such a scenario is that the modeling was done in the past (2019) and the code conversion is done with a newer UiPath Studio version (2022.10.X).
- A text file with JSON text is read in.
- The text content is used for a JSON deserialization
- Text is encoded in Windows-1252
- Deserialisation into a dictionary (Key=string, Value=String)
The artifacts / UiPath Studio projects used for the prototypical migration are backed up in such a way that the practical evaluation can be aborted at any time and started from scratch.
Furthermore, it is ensured that the migration result can be transferred to the source code management without mixing with previous versions or productive artifacts.
In this case, no pre-adjustments or code adjustments are made
In a first step, the automatic conversion is triggered and care is taken that the result is a new UiPath Studio project. Then the result is further inspected and checked for its executability.
- Click convert to Windows
- Ensure that “Create a new project” is activated
- Edit Name, Location according to the preparations and definitions
- Click Convert
Conversion Result Inspection
At first glimpse, the result seems to be valid and does not show any warnings. In a more in-depth review, the following is noted:
|Upgraded to Version 21.10.6||Upgrade due to non-Windows compatible source package version|
|Upgraded to Version 21.10.9||Upgrade due to non-Windows compatible source package version|
|Upgraded to Version 1.9.2||Upgrade due to non-Windows compatible source package version|
|Deserialize JSON activity
offers TypeArgument within the activity properties
|is missing||reduced advanced property display support by the combination of particular UiPath Studio and Package Version|
When debugging the conversion result, the following error occurs:
Read Text File: One or more errors occurred. ('windows-1252' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. (Parameter 'name')) ('windows-1252' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. (Parameter 'name')) ('windows-1252' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. (Parameter 'name'))
With UiPath.System.Activities Version Level 2019.10.1
- has not been successful
- needs follow-up work.
UiPath.System.Activities Version Level 2023.X.Y - PREVIEW
There are several indications that the revised Read Text File Activity will use the customized encoding without having to perform an
CodePagesEncodingProvider registration beforehand. The conversion would therefore have been successful.
Do not perform a careless package update, as this may lead to other problems
The conversion was not successful and needs to be reworked. A first cross-check with the information on code conversion mapping sets offers the chance to find an already known case and to get assistance.
Similar as described here the following fixing will be done:
- Add an Invoke Method activtiy above the read text file activity
- Parameter: IN |
The revised result of the migration conversion is debugged and tested for executability. A breakpoint at the very bottom of the comment activity will pause the execution and the result can be tested further.
Check fixed runtime exception:
Check Deserialisation Result:
The conversion has been successful.
After the successful completion of the prototypical migration, the result / UiPath Studio project is saved according to the previously defined conventions. This source code should be clearly separated and distinguishable from all subsequent developments.
The following conclusions can be gained from this exemplary migration prototype:
- The provided automatic conversion tool performs part of the conversion.
- Pre- and/or post-processing may be necessary.
- The result of the migration conversion can only be meaningfully evaluated after successful execution, as some problems only occur at runtime.
- Since solutions/workarounds exist for some conversion mapping problems, these can be dealt with directly in the post-processing and do not require further problem analysis.
- Strict management of the different partial results of the migration conversion should always be given so that a step back or a step repetition is possible at any time.
- When converting older artifacts, it should always be ensured that code migration and code renewal do not mix and lead to uncontrollable blockers.
The migration prototype allows for initial practical experience at a controllable scale. This approach provides a way to get familiar with potential problems in conversion mapping.
In this particular demo case, it would have been possible to update the referenced package UiPath.WebApi.Acitvities to a higher version in a subsequent code renewal. The Deserialize JSON activity would then also offer the TypeArgument again.
Upgraded to UiPath.WebAPI.Acivities V 1.16.2
Due to the strict separation of code migration and code renewal, the various referenced packages were not upgraded to higher versions, and no additional redesigns were made. In other situations, changing package versions can lead to side effects or unresolved activities. Therefore, it is recommended to check this separately and rather limit the scope of a prototypical migration at the beginning
Fortunately, during the development of this prototype migration demo, it was discovered that an expected conversion blocker no longer occurs, as it is now handled by UiPath. Many thanks to @Yoichi for his collaboration in cross-checking this finding.
Also thanks to @Roman-Routinuum for a review and collaboration in pointing out package upgrades by the conversion tool.
For questions on your specific case or migration topic open a new topic and get individual support.