The Major Limitations Associated with ODC

ODC Studio is the OutSystems Developer Cloud’s low code visual development tool introduced back in November 2022. This new visual programming tool promises to accelerate development because the infrastructure of both development platforms (for building and developing apps) and the independent runtime are live in the cloud. However, it brings some challenges for developers who are used to program using and accustomed to developing in OutSystems 11. In this article some questions/limitations concerning ODC will be addressed.

Note: ODC is not a complete feature set yet. Therefore, it is normal that some of these features exposed aren’t available nowadays, but they may become available soon. It is important and relevant to note that OutSystems also took some time to get, refine and polish OutSystems 11.

Hotfixes

A hotfix is an urgent measure taken to address a critical issue outside the normal flow. More or less common (but not ordinary), some fixes need to be sorted in other stages beside development stage. Nowadays (meaning, in OS11), a developer can easily access the remaining environments, such as TST/QA or PRE-PROD and do a small change and hotfix, and after that, merge back and propagate that change back to the development chain. However, in ODC things change: Developers can only develop (have your screens and logic) in the DEV stage, which makes it impossible to do hot fixes as we are used to.

To solve this problem, meaning, to do a hotfix, a good suitable strategy might be something similar to the proposed one:

• Open, on DEV environment, the same revision number that is being used in Production (or on the environment where the hotfix is needed).
• Do the hotfix and publish in DEV.
• Push to stage here the new version is required.
• Open the previous revision from DEV (that contained the most up-to-date code before the hotfix) and merge it with the last version (that contained the hotfix).
• Publish in DEV.

This simple way is suitable for short and quick hotfixes, however, it fails/brings problems if the versions have entity changes.

Entities

Because ODC is relatively new, tests with huge amounts of data and entities still haven’t been performed.
As all developers familiar with the way ODC works, each Web App is an isolated container, and developers can reference entities from other apps. However, it is still not clear if the performance is affected when we start making queries joining’s entities, composed by millions of records from multiple Web Apps.

Anyway, it should not matter that two entities are defined in different containers (Web Apps), since the generated SQL statement will be executed on the database server, not in the app containers. Each Runtime stage has an isolated Amazon Aurora Serverless database.

Library App Static Entities

As presented in the documentation, Static Entities have slightly different behavior as in OS11, depending on where they were defined. A Static Entity is mapped to a database table when it is defined inside a Web App, like it happens on OS11. However, when defined inside of a library, the corresponding data table does not exist, acting as an enumerator.

In our Web App, we can still use in the consumer app aggregates and SQL queries the record attributes of a public static entity from a library, but the possibility of considering the identifier of a public library static entity as a foreign key in entities in a consumer module was taken way.

Suppose the following scenario, where you wish to filter a certain entity using a status (for example) considered as static entity defined in a library. To do that, you need to define an attribute on the entity of the consumer with the type of set as integer, because it is not possible to directly assign the static entity identifier to the entity created on the consumer. So, in the end, no database relation is established.

Therefore, you need to define that static entity on the Web App, not in a library if you want to iterate over the records of a static entity.

AI Mentor Studio

AI Mentor Studio is a powerful tool designed by OutSystems that allows monitoring technical debt. It provides the ability to visualize architecture and identify potential issues, assisting developers to follow the best practices and avoiding common pitfalls. Also, by leveraging AI Mentor Studio, organizations can proactively manage technical debt throughout the entire development lifecycle.

This tool is very useful, known, and quite used by developers and tech leaders when programming in OS11. However, this feature (or a similar one) is still not available in ODC.

Personal Environments

Currently, OutSystems does not provide free personal environments with equal/same usage rules as OS11.

Nowadays, if someone wants to try and test this new tool, they should schedule and register themselves in an open slot using the following link: https://www.outsystems.com/ODCTraining/Schedule. If there are no more slots, they can toggle a button that allows them to receive an email as soon as new slots are available. That will ensure that they will have access to a 2-week ODC environment to do training and practice.

If you want and are interested in doing a project using exclusively ODC, you can ask for a paid version and sign a commercial trial.

In conclusion, it is evident that ODC is still a “work in progress” and not yet a fully comprehensive tool. It is important to recognize, as stated before, that these points might be implemented in future versions due to the commitment to refinement and polishing measures that OS is considering.

WRITTEN BY:

Ana Agostinho | OutSystems Developer
(Originally posted on: https://esystemsnordic.medium.com/ eSystems Nordic)