Need to add functionality to an old coding language? Why not think outside the box!
Of course, it’s always fun to start a new project. To choose the architecture and technologies with the current and future needs of the client top of mind is always rewarding for us!
However, not all of these projects start from scratch –or are born from the context of a redesign. It can happen that a client has an application that contains certain baggage and that he simply wants to add functionality or which can also imply that the technology may be aging.
Need to add functionality to an old coding language? Why not think outside the box!
In these cases, the vision that was valid at the beginning of the project may not have followed the evolution of the company, and the structure of the project may make it difficult to use the best programming techniques such as TDD (test-driven development).
At DONE, we experienced a similar situation. In this case, the project was coded in the classic ASP language. We’re not talking about ASP.Net here, but its ancestor, which was born in 1996. Even though the language itself was aging, the project still had good value for the client, which is why it was still in use at the time – and still is today.
Our mission
We were asked to develop an interface that sends requests to partner systems in XML and JSON.
Our Challenges
The first problem, which we anticipated, was that JSON did not exist when ASP was launched, so our chances of finding a library to do the job were pretty low. Furthermore, the structure of the data that needed to flow from ASP to JSON was very complex, so it was also out of the question to build this string from concatenated bits of text. Moreover, even if we could have adapted to the language, the fact that few developers are familiar with ASP today would have increased the development time considerably.
Our Solution
Rather than trying to adapt to a 27 year old language, the solution we chose was to develop the functionality in a recent language that we know well – and that lives on the cutting edge: Net Core, or C#.
The real challenge was to get past the virtual “barrier” between the program developed in ASP and the one in C#. With the right development tools, once the barrier was crossed, we knew that the rest of the project would be very easy.
Step One : Isolate The Code
The first step was to isolate our code in an ASP file.. This file would serve as an interface to our C# project, which would make the actual JSON call to the partner systems. We wanted the call to be as simple as possible from the classic ASP point of view, and to hide all the complexity on the .Net side.
Our best bet was to facilitate communication between the two systems via simple web requests.
Here is what the call looked like:
We chose to instantiate an “MSXML2.ServerXMLHTTP” object to generate a Web call that would contain the request number to be transferred to the partner’s server. We then passed this variable through a JSON string. Since this JSON was very minimalist, it was easy to create, even in ASP, by simply concatenating text strings. The important thing was to make the transition to our more modern language as fast and simple as possible. It could also have been transferred as a query string.
All the information required to build the payload was in the database, which was to be read directly by the new application. We stored the URL to be called as the name “REQUEST_SENDER_URL” in a configuration file, where all future important configurations would be stored.
That’s it! The bulk of the complexity was finished; the portion written in the old language was done.
Step Two : Generate Complex Data Structure
Now that the first, most difficult step was complete, our next task was to ensure that, on the other side of this call, that we would recognize a standard C# controller to receive the required information (the ID of the data to be sent) in order to generate the complex data structure (either JSON or XML depending on the selected partner) and return a response (yes or no) from the partner in question for this request.
Since we were now in familiar territory, we were able to save a lot of time and use much more reliable software. For the JSON construction, it was easy to proceed by building a simple class and using the JsonSerializer object (System.Text.Json.JsonSerializer.Serialize()) to do the conversion.
In the case of the XML to be created, once again, it was easy to create a class that would represent this object and to transform it with a method that would use the “XmlSerializer” provided by the language.
The Advantages Of Our Approach
This saved us a lot of work compared to if we tried to use classic ASP. In the end, the generated request was more than a hundred lines long!
Another advantage of using a newer language for this portion of the application was that we were able to test the new code thoroughly using unit tests and integration tests. Since the use of automated tests was not yet common practice during the lifetime of the classic ASP, the tools to run them did not exist.
Bottom Line: Using A Hybrid Approach Saves Time
A hybrid solution brings us a key advantage; a recent piece of code ready to be used in a different context. It’s worth noting thatIf the ASP code were to be redesigned in the future, all of this logic would already be done, which means that the outdated language would not have to be converted – greatly reducing the cost of future projects.
If other features were developed over time, this could also be done section by section until the entire application was transferred to a new language. Of course, it would have been more complex if a visual part of the application had to be redone, but it would still have been relevant to find a way to proceed in order to get all these benefits.
In our opinion, it is often worthwhile to think outside the box and segment the functionality in a newer language, rather than in an older language. This will result in a solution that is more maintainable, more stable and also more economical for the customer, now and in the future.
Make an appointment with our team to discuss it!
Look at our other divisions Pyxis
