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.
Initial scenario
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).
Implementation in Legacy
Description:
- A text file with JSON text is read in.
- The text content is used for a JSON deserialization
Details:
- Text is encoded in Windows-1252
- Deserialisation into a dictionary (Key=string, Value=String)
Visuals
Prototype Migration Steps
Preparation
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.
Conversion pre-processing
In this case, no pre-adjustments or code adjustments are made
Conversion processing
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.
Conversion with the conversion tool
- 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
Details
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:
Legacy | Windows | Comment |
---|---|---|
UiPath.System.Activities 19.10.1 |
Upgraded to Version 21.10.6 | Upgrade due to non-Windows compatible source package version |
UiPath.UIAutomations.Activities 19.11.5 |
Upgraded to Version 21.10.9 | Upgrade due to non-Windows compatible source package version |
UiPath.WebAPI.Activities 1.4.0 |
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 |
Execution Test
When debugging the conversion result, the following error occurs:
Error Message
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'))
Conversion Result
With UiPath.System.Activities Version Level 2019.10.1
The conversion
- 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
Conversion post-processing
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.
Fix unsupported encoding name
Similar as described here the following fixing will be done:
Fixing Steps:
- Add an Invoke Method activtiy above the read text file activity
- TargetType:
System.Text.Encoding
- Method:
RegisterProvider
- Parameter: IN |
EncodingProvider
|System.Text.CodePagesEncodingProvider.Instance
- TargetType:
Result Validation
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:
Conversion Result
The conversion has been successful.
Final steps
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.
Conclusion
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.
Side note
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.
Visuals
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
Credits
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.
References
Questions
For questions on your specific case or migration topic open a new topic and get individual support.