The client is one of the largest privately owned manufacturers of vinyl products, thermoplastic elastomers, colorants, engineering thermoplastics, esters, and other specialty compounds. With over a century of global manufacturing expertise, the company has a huge clientele across industries such as building and construction, consumer, electrical and electronics, transportation, medical, and more. The client specializes in providing engineering solutions customized for the client’s industry requirements.
Because it is a manufacturer, the client must be able to respond quickly to the daily demands of many customers. To help address customer issues, the client wanted a faster, robust and modified system.
Below are the major challenges faced by the client:
- The client had recently updated its ERP system, but the new updates were not supported by RPG. Therefore, the client wanted to migrate from RPG to Java.
- The existing RPG programs were dependent on an IBM iSeries operating system that created an obstacle to easy modernization and the client wanted a modified platform based on a modern technology such as Java.
- There is no automated tool that simply migrates the code from RPG to Java and finding a developer(s) who is/are skilled in both these languages is a tedious task. The client was looking for a third party service provider who had experienced developers with knowledge of both RPG and Java.
Our team suggested to properly release the RPG code from i-Series dependency by re-engineering the RPG code prior to migration. This helped us assess the code in depth and develop modernization plans quickly.
The RPG code was using work files to store temporary data. This is temporary data storage requires data base connectivity multiple times. Our team removed it from Java by storing data in lists, arrays, or maps prior to processing.
Our programmers optimized the code by executing the join query in Java to fetch the required data. This optimized the code efficiently and allowed us to achieve our goals more quickly.
Programmers.io suggested that the constraints be stored in an external configuration file so that any changes done in the config file did not affect the Java code. Hence, maintaining the code’s flexibility and encouraging relocation.
Our team used HashMap to avoid any unnecessary iterations within the some code.