The devil is not so terrible as it is painted: how we transferred the development of CFT-Bank to the CFT Platform IDE (Admin 2.0)

Financial companies are looking for the best solutions that optimize internal development processes, develop IT infrastructure in accordance with business requirements and allow them to bring the best competitive products to the market. So, two years ago we set out on the path of transferring the development of CFT-Bank to the CFT Platform IDE. There are rumors among colleagues in the shop that this is a process of incredible complexity, which is why they do not dare to get down to business. Using our example, we will prove that this is quite a lifting process for your team.

In most cases, the software development process at NSD is characterized by the presence of several development teams that maneuver between projects, dealing with different modules of one or even different systems. In our work, we constantly have a large number of improvements and we have to keep several dev and test circuits with different versions of the system. Thus, there is always a need to access a centralized repository of code with support for versioning, ensuring automatic build and installation. For many years, the CFT-Bank system did not have such opportunities.

This created unnecessary costs for preparing assemblies, merge changes, etc. There were often cases of corruption of the program code, because only the developers themselves could monitor the correctness of the version and of one or another software component in a completely manual mode. However, it was impossible to change the approach to development for the CFT-Bank system due to the existence of an uncontested development environment for this system, which was 15 years behind in its interface and capabilities.

The solution to our problems was proposed by CFT with the launch in 2018 of a new development platform for its systems, which is called CFT Platform IDE (aka Admin 2.0, or A2 for short).

Key differences of the new development platform

Outwardly, the developer gets an environment implemented on the basis of the Eclipse Platform, which is much nicer than the archaic Data Dictionary Administrator.

For comparison, editing code in the old environment (Data Dictionary Administrator):

Editing the code in Admin 2.0:

But the main advantage of the new development platform for us is the ability to store the program code of the system, as well as screen forms, type descriptions and other things in the form of many text files. This is what allows you to upload the code to the version control system (in our case, Git) with all its capabilities, which we lacked earlier when developing for CFT-Bank.

Thus, CFT-Bank developers now have the opportunity to comfortably track the history of changes for each object, including not only the revision time, but also the comparison of the old and new versions through an embedded component or using any external tool such as Araxis Merge. To those who are not familiar with CFT-Bank, this will seem surprising, but previously one could only dream of this, keeping the history of changes only in the form of comments in the code.

A pleasant bonus was the ability to syntactically check the code without connecting to the database, as well as convenient navigation (transitions to called procedures by clicking at the place of call), quick contextual search in the project.

I would like to note that the new admin turned out to be, in a good sense, more picky about syntax in the code. Among our local improvements, very strange expressions were identified, for example, something like:

• ::MAIN_DOCUM instead ::[MAIN_DOCUM],
• select md(md%id: rSelf) in ::[MAIN_DOCUM] all where md.[IN_FOLDER]=this bulk, and in the compiled PL / SQL code there is no word bulk, what is with it, what is compiled the same without it,
• Pragma macro(’Ошибка!’) instead Pragma error(’Ошибка!’)…

It is not clear how the Vocabulary Administrator “digested” this without errors. Moreover, if the first 2 examples are harmless garbage, then the last one is an obvious error that will lead to incorrect operation of the program.

And another feature of Admin 2.0 is, thanks to the integration with Git, the functionality of obtaining a list of changes based on a comparison of 2 branches.

This allows you to deploy these changes to the target database. Then changes from the database can be unloaded using the same list of items using the old Project Manager to the mdb file, if they need to be transferred for installation to a database where the developer does not have direct access. However, a more interesting option is to prepare and deploy changes in a new format. It is a zip archive containing text files with code, as well as some meta information. A side effect is the ability to view and even change the code in the transmitted delivery without installing it into some kind of database, which was impossible in the case of the mdb format. But the most important thing is to save in this new format from the Git repository and deploy to the Admin 2.0 database in a non-interface mode, which allows you to configure auto-build and auto-installation, i.e. finally talking about CI / CD as applied to CFT-Bank revisions. True, I plan to cover this topic in detail in the next article.

Features of the transition to a new platform

Material question

The first thing I had to face was getting workplace licenses… For each developer’s workplace, a separate license is required, which is immediately tied to both the PC hardware and the user account. If your company also has several isolated networks where there are servers with CFT-Bank, and development is underway on them, then you will need to buy several Admin 2.0 licenses for one developer. The cost of one license at the time of this writing is 125 USD / month, or about 8 thousand rubles. at the internal rate. There is currently no charge for the initial purchase. Licenses are distributed in the form of files, not smart keys, which makes it easy to deploy the environment even on a virtual station.

Prior to purchase, you can agree on the provision of test licenses. In our case, 6 licenses were obtained with a validity period of 4 months on a free basis. Conditions are discussed with a personal manager individually.

Setting up workplaces and databases

The server part of the IDE can be installed during working hours, but it will be more correct if at the time of installation the CFT program objects are not open for editing, because the main thing in the update is the new mechanism of corresponding locks.

The client part is, in fact, Eclipse with CFT Platform IDE extensions, installed without PC administrator rights. Only the JRE must be installed in advance at least version 8. Access to IDE updates on the CFT website is now open, without authorization. You can configure updates directly through the site, or from a local network. For example, from a network folder or using a repository manager like Nexus. We chose the option of a network folder as the easiest to configure, it does not require Internet access from all workplaces, it is reliable, which is important when configuring heavy updates, and flexible due to the ability to upload updates according to your own schedule.

Uploading local application code

To create a project that Admin 2.0 will work with, we need to upload from the database to a folder with a set of text files the description of the objects that are our local modifications, as well as, relatively speaking, links to objects on which our modifications depend.

I note that with a large volume of a local application, the development environment starts to slow down, so in such a situation it will be necessary to divide the source code into an asset and an archive. Fortunately, we fit into the limit with a considerable amount of locale. However, it is worth considering the amount of RAM of workstations. According to the documentation, at least 16GB is required, although for some time some of our developers managed to work on 8GB of memory, it was only necessary to adjust the memory size of the java application in the eclipse.ini file.

As for the unloading, the procedure is not complicated, since all the necessary scripts, such as for calculating the volume of the application, for obtaining a list of objects, and others are included in the package.

Code adaptation

The adaptation consisted in complementing what the script did not collect, for example, not all references to tables in pure Oracle were loaded, some TBPs with complex subordination – in isolated cases, the types of references or arrays were not loaded. I also had to clean up the code a bit (see examples above). But the most important thing is tweak the code for new features:

• all simple views were automatically converted to pl / plus (since Admin 2.0 does not support simple views). At the same time, this often happened with errors that needed to be eliminated (for example, since calling interface packages is now not supported directly, it was necessary to redo calls in the pl / sql style (like Z $ MAIN_DOCUM …) to pl / plus (like: :[MAIN_DOCUM]…));
• in Admin 2.0, support for inline-inserts of pl / sql code was removed – constructs in curly braces {}, and only recently this support was returned;
• Admin 2.0 does not support the expression between in sql queries, which we used in several views (which is strange, since this is a standard construction, including for pure pl / sql);
• errors that have appeared in “dead” pieces of code. We had several procedures where part of the code was cut off using return, or if false, or by the IF_DEF macro. The optimizer or macrocompiler cut off code that was no longer analyzed for errors. Some of these pieces have become invalid, because the called procedures and the TBP used have changed, the compiler just did not see them. Admin 2.0 began to “pay attention” to these pieces as well.

Result

There were no serious problems with adaptation. We were fortunate enough to “take a closer look” with our code. In the process, we identified shortcomings in the IDE and even in the technological core (in the compiler), which CFT has now fixed.

CFT specialists rendered a great help to us, who promptly responded to the problems that arose, and in case of slowing down the implementation process on our part, they stimulated and supported our interest in every way. After all these preparatory steps, we easily set up the integration of Eclipse with Git and dumped the code of the current version into it.
We needed to create a development regulation, since CFT-Bank developers had to get used to working in a completely different style: correctly marking commits, working in the correct version, etc. The working method itself began to comply with the general development standards in an IT company.

Despite the initial decrease in development speed, Admin 2.0 was immediately received with great enthusiasm in our team. For 1-2 months of active work, everyone got used to the new environment, and the efficiency increased.

Admin 2.0 is still under active development today, but it is a much less crude product than it was 2 years ago. For example, only recently there was support for working with access groups, which is still working with errors. Also, deployment in interfaceless mode may fail if there are macros in the code. CFT eliminates most of the shortcomings that we fix within a month. During these 2 years, we have used a great opportunity to influence the development of Admin 2.0. Today, companies that have conceived such a transition will be able to go this way much faster.