· Hub for the NS Community ·
Dear community member,
With the developers' conference approaching and another month behind us, we have plenty of news to share. We hope you enjoy it, and look forward to seeing you on March 12th!
The Dutch Tax Administration (DTA) is interested in expander training to facilitate the integration of expander development within the organization. In recent years, most expander bundles have been created by external employees who could work with the technology. Today the need for expander building has grown, the Competence Center Normalized Systems (CCNS) has recognized the need to educate more in-house developers and management has expressed interest in workshops on expander development.
The DTA is currently transitioning from mainframe and IPAS servers to an OpenShift-based solution for its entire organization. As early adopters, CCNS is contributing to this transition by providing a standardized solution for deploying applications on the OpenShift platform.
Recently, CCNS has been actively involved in business development within DTA, exploring new ways to enhance the software environment. For challenges such as fraud detection, prevention, and the exchange of large volumes of diverse data, DTA is also exploring the potential of evolvable software and the benefits of Normalized Systems.
Additionally, CCNS is preparing for its first developers' conference for the NS community, scheduled for March 12th at De Knoop in Utrecht.
As healthcare shifts towards prevention rather than merely treating illnesses, access to structured, citizen-controlled data is becoming increasingly important. The WellData project, an Interreg-funded initiative, aims to leverage data-driven insights to support citizens, healthcare professionals, and policymakers in making proactive health decisions.
The main principles of NS, interoperability, privacy, and evolvability— are necessary for SOLID and FHIR, hence they perfectly align. That's why we are contributing our expertise in scalable data platforms to WellData, ensuring citizens can retain control over their health data while benefiting from personalized, preventive care.
Our role in WellData
By combining SOLID, FHIR, and evolvable software principles, we are helping to reshape preventive healthcare, ensuring that citizens remain in control while benefiting from better health insights and timely support.
The Rejuvenation team utilizes the Prime Radiant to track applications, expanders, and their dependencies in real time. This includes monitoring applications, expanders, pipelines, deployments, microRadiant plugins, and repositories.
Beyond dependency tracking, the Prime Radiant provides insights into custom code volume and placement across application layers, element usage, and the expanders applied in each version. All data is recorded over time, enabling historical analysis.
To ensure data currency, NSX projects incorporate an additional step in the Jenkins pipeline, automatically transmitting relevant information to the Prime Radiant.
A dedicated Angular dashboard, built with Angular expanders, visualizes key metrics such as application and expander dependencies, project-specific custom code history, element usage trends, and expander bundle file generation.
This provides valuable insights into NSX software development, and we are only beginning to explore its full potential.
For the rebuilding of the BN-applications of rijkswaterstaat it is necessary to apply an NSX model to their existing oracle database. This poses a challenge for the NSX models since they make some assumptions about the database-NSX model relation that might not necessarily hold true for existing databases. The issues that arose as well as their solution(s) are discussed. Keep in mind that the discussion is rather technical.
Problem 1: Existing Oracle database support
NSX does have default support for Oracle databases already. But some settings have to be
tweaked.
Solution
First off, we need to change the `businessLogicSettings` to reflect our oracle database.
Second, we will need to change the jdbc in the tomee config / docker compose files to
point to our new oracle database.
Problem 2: dataElement name, table name mismatch
The NSX model expects a specific syntax to represent its dataElements, fields, etc.
Using this syntax, it will link the dataElements to their corresponding tables. An
existing database might not follow these syntax rules, creating a mismatch between the
dataElement names and table names. E.g. you have a table named MSB_BN_SOORTEN in the
database but the dataElement is named MsbBnSoorten in the NSX model
Solution
Model options exist already to deal with these kinds of mismatches in the current
jpa-data-expanders: Link
Problem 3: User Keyword
The NSX model wants users to be inside the ACCOUNT.user table in the database in case
you are using the account component.
However, having a table called User is not possible in oracle, as it is a keyword.
Solution
Using sql-server-expanders alongside the sql-expanders resolves this issue.
Furthermore, we have chosen to put the NSX base components in a different oracle
database to keep the original database as intact as possible.
Problem 4: Linkfields and Primary keys
The NSX model assumes every table corresponding to a dataElement in the model contains
an ID column. Furthermore, it assumes the ID column represents the primary key of the
table. Consequently, every linkField (foreign) is linked to their target using this ID
column. However, when connecting to an existing database, having this ID column is not a
guarantee. Furthermore, it's possible for foreign key relations to be linked using other
unique columns rather than solely the ID column.
Solution 1
If allowed, the easiest option would be to add an ID column to every table and update
the foreign key relations to use this ID column. For our project, we wanted to make the
least amount of changes to the database as we could get away with. Because adding an ID
column and changing the foreign keys had an impact on other applications using the same
database.
Solution 2
Our solution consisted of (creating our own or) updating the `jpa-data-layer-expanders`.
I extended the expanders, adding support for defining the primary key in the NSX model,
as well as defining the targetField that a linkField (foreignKey) is referencing.
Problem 5: ExternalId's
The application had to be built making use of the angular frontend expanders. These
expanders mainly communicate with the backend using the rest api. In doing so, it makes
use of externalId's to represent the dataElements. These might not necessarily be
present in the existing database structure.
Solution 1
Since it was the easiest solution, that had no impact on existing applications running
on the same database, we were allowed to simply add externalId columns to all the needed
tables
Solution 2
Use a different api instead of the rest-api for the angular expanders to communicate
with the backend that don't rely on externalId's
Last but not least, some more exciting news from the NS lab in Prague! Here we got an update of the doctorate on Dissertation Report: Advancing API Evolvability.
The dissertation research is in the area of API Evolvability, specifically focusing on API Migration, aiming to contribute to automation of the necessary changes for API consumers when the consumed APIs evolve.
We began by exploring existing literature on API Migration, identifying multiple approaches that leverage Static Code Analysis and Artificial Intelligence, including Natural Language Processing (NLP) and Machine Learning (ML).
Next, we examined standardized API documentation formats such as OpenAPI Specification and API Blueprint Specification. Based on our investigation, we implemented a formal transformation of API Blueprint documents into OpenAPI Specification, which we published in the article: Semantic Analysis of API Blueprint and OpenAPI Specification.
Additionally, we analyzed API Consumers, API Providers, and API Changes to develop an ontological API model, published in:Towards Evolvable APIs through Ontological Analysis
Finally, we have designed a new approach to API Migration based on:
Kind community regards and see you next month!
