Knowing that we should avoid hard code in programming. But sometimes it has advantages.
Since the applications in the mainframe are stable and we do lots of activities based on the position, in my opinion, it’s better to hard code such info in the project. It makes the code more easy to understand, and debug as well. Otherwise, we may have too many settings in the config file and the key name will be a little too long to state clearly what it is.
@postwick @ppr @ClaytonM, may I get your opinions on this? Thank you.
Hi
I usually wont appreciate to go with hardcoding
though it is easy while developing and testing, it may not stand in same way for a long run
suppose if changes needs to be done, then those number of changes has to be included to code and publish newly everytime
Ofcourse it is fine if its a major change but for minor changes it is not recommended
But nothing is written on stone that it has to be always through config without hard coded value.
you can still do with optimal approach. use hard code where you see the activity wont come across any frequent changes
if an activity or a logic is expected to get changed often then have those parameters in config to keep it dynamic
Cheers @healsko_ho
Hi Palaniyappan,
Thank you for your input. In the mainframe, we have multiple input fields on multiple pages. That makes so many rows in the config! Just want to gather more opinions on how to find the balance between hard code and config.
we can differentiate between centralized and hardcoded.
When extracting a series of fields in Mainframe we also have the option to define an extraction config on the top / in a good location of the XAML and can use it for the extraction. Here we can balance the flexibility and avoid redundancy as we consume this extraction config within a loop and can handle it with one dynamized activity.
We used this technique often and were not forced to put all into config file (e.g. Config.xlsx, REF). Also we had the option to externalize this part configs separately.
Deciding the different techniques can be done by baselining it to a few criteria which will be used for the decission making:
- number of extraction field
- complexitiy and redundancy
- change rates on the extraction needs
- development team skills and preferences
Here we can confirm and do like the statement:
Yes you have to hard code lots of things when doing mainframe automation, specifically field and data positions. Typically I use Move Cursor to go to the field I want, Send Keys to populate it. The Move Cursor requires hard-coding the position. And yes, since mainframes are stable in this way, it’s fine to do this.
This is mainframe. Stuff doesn’t move.
Sometimes hard code can’t be avoided, especially in mainframe. As my client’s case, UiPath’s wait xx activities don’t work well but throw exceptions. I have to build a simple check text workflow to see proper page with specific wordings exists or not, then continue.
Agreed with Peter that if the company policy forbids the hard code, stores such config in another file (json, csv,.etc) except the ref config xlsx file is better.
I do think config files are overused sometimes. I think it’s best to centralize the tasks and variables, so that debugging and making updates is handled reliably that doesn’t impact existing jobs. - Library packages are good for this. So, hardcoding should be avoided if it would require multiple changes for a single value change.
In regards to Mainframe interactions, you could create a Library activity for each screen. And, within the xaml for each screen you would map out the coordinates for each field in variables (ie arrays) for that particular screen. You could do this in a config as well, but I don’t know if it’s really needed, since you would be making the update in a single xaml, re-publishing, and updating the project(s) to the new version of the Library package.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.