The OutSystems Model: Abstracting low-code into a visual language

OutSystems Advocacy Team — Wed, 14 Aug 2024 20:22:34 +0000

This post was written by César Afonso. When he's not enjoying a fine wine, running, or spending time with family and friends, César is most likely telling everyone that he loves technology almost as much as he loves OutSystems. He gets to exercise this passion on a daily basis as an OutSystems R&D Engineering Manager.

What is the OutSystem Model?

Abstraction Layers equals Speed

Looking at programming languages, we’ve been adding abstraction layers to speed the delivery of new products for a few decades now. Assembly and even raw C have become more rare and chosen for specific use cases where resources are limited, performance is key or critical systems. Abstraction layers bring, amongst other benefits (like ease of maintenance), speed. Speed to deliver. By abstracting developers from things like memory management, it allows them to focus on solving the real problem.

Even if you look at other areas, abstraction layers are everywhere (like cloud to abstract all the infrastructure hurdles).

The OutSystems Language — A visual abstraction layer

OutSystems adds a visual abstraction layer on top of text based programming languages, namely C#. The example below illustrates this with a very basic example. When using an “if” element in OutSystems, it will get translated into an “if” in C#, which will then be compiled to Intermediate Language and so on.

The above happens when you publish your application — OutSystems generates C# code that then gets compiled. But what happens when you Save? How do we store what you are actually doing in ODC Studio?

Materializing the language — The Model

The Model is the concrete representation for the OutSystems Language. It is this representation that is manipulated by the OutSystems platform components, like ODC Studio. Our Models have an in-memory representation (as C# class instances) and an xml-based persistent representation. Lets look at how that action gets stored in this xml-based representation.

You can see that there’s lots of information. The name of the Server Action, the modification dates, a hash, the parameters it expects. This is just a small piece that gets stored in the OML (OutSystems Model Language).

The OML is a compressed file composed of several fragments. The above section is part of a fragment called UserActions.xml. There are dozens of fragments for different purposes.

All these fragments contain the OutSystems Model.

Caveats

You might be asking why xml. Mainly because xml is very descriptive and we need that for such a complex/expressive model. The other reason is that when we built this 20 years ago, there were not that many good options.

Another question that has appeared a couple of times in OutSystems Forums (Examples like this and this to integrate with CI/CD — Code analysis) is: why can’t we manipulate the model directly? Why can we only use the Language itself in IDEs and not manipulate the Model directly?

The main reason is that it would be very hard to manipulate this XML directly. Even with validators, XLSTs or similar, it would not be a good experience. Why not a Model as a Service? Well, that’s the topic for the next episode. Stay tuned.

Low-code developers, what was your career journey?

OutSystems Advocacy Team — Mon, 15 Jul 2024 19:00:59 +0000

Beginner and experienced low-code developers -- how did you get into low-code? What previous experience did you have?

Many low-code developers have a traditional software development background, while others started in tech with low-code.

We're also curious what low-code tool you use for development. Let us know in the comments!

Tackling side projects and Sunday football with OutSystems

OutSystems Advocacy Team — Wed, 08 May 2024 12:53:59 +0000

This post was written by Luís Marques. Luís Marques is a Mechanical Engineer turned Solution Architect at OutSystems, where he has been nurturing his inner developer since his early days as a Technical Support Engineer.

How I started “playing” with OutSystems

People hear about OutSystems for the first time under different contexts and in various circumstances. Some start working at a company that already uses the platform, or because they’re evaluating it as the next technology for their teams to adopt, or they simply read about it or some friend told them how easy and quick it is to build a meaningful application with OutSystems.

In my case, to put it simply, it was because I started working at OutSystems. I learned what the high-level platform capabilities were while studying for the interview (as one should do for any interview). Although I got pretty comfortable with the capabilities of OutSystems, it was only on my first day that I had my first contact with the platform and Service Studio.

I started exploring Service Studio and I quickly realized that I could build anything that I wanted with OutSystems. The training that OutSystems offers, to anyone who wants to start learning the platform, is incredibly rich, detailed, and easy to follow. And please note that my background is in Mechanical Engineering and my experience with software development was close to zero. After doing the training, I couldn’t wait to start developing more applications.

Then I realized that, in order to keep using the platform and keep that enthusiasm high, you need to have a use case that really excites you and makes you want to go back to Service Studio every day. Once you have that, it’s very easy to keep the excitement because the platform allows you to make so much progress in such a short amount of time without having to do all the tedious tasks that developers usually have to face.

I felt that anything was possible with OutSystems, but sometimes that actually makes it harder to find that exciting use case. So, I decided to start putting a lot of my ideas — simple, complex, sometimes a bit stupid — into OutSystems applications. I’ve created a flight tracker application, an app to keep track of my expenses, multiple apps to increase my productivity at work, and more recently, the “Sunday Football” app. This last one is the one I want to talk to you about, to show that anyone can really put any idea into practice and start building something that is exciting while learning all the ins and outs of the OutSystems platform.

Why did I create the “Sunday Football” app?

After reading what I just wrote above, one could think that I’m always behind a screen building my next OutSystems application. But, surprise surprise, that is not true. I have a few hobbies and playing football with friends (or soccer, as my fellow American colleagues would say) is one of them. I play on a regular basis on Sundays, in London (yes, even when it’s raining).

One of the regular players started putting all the results in an Excel sheet and we ended up being quite competitive about it, always trying to reach the top of the table. Obviously, we were constantly pushing him to keep the Excel file up-to-date, which sometimes would take weeks (some people don’t understand the competition spirit!) because he was the only one keeping it on his own computer.

After one of those matches, I asked my friend to send me that Excel file and decided to start my new project — the “Sunday Football” application.

“Started from the bottom”

For the ones who are familiar with the platform, you would know that from an Excel file, you can very quickly import/bootstrap the data into an OutSystems application and create a base data model for the app. That’s how I started. From the Excel file I extracted the matches’ data (with all the past results) and the players’ data (the player information and what matches each one already played). Two days later, I had the first version of the web application running and I could share it with the whole group.

The funny thing is, when you start developing one of these applications that have no planning and no clear end goal defined, you have the freedom to continuously explore any ideas and features that you want to implement as you go.

Quickly we started having more ideas and everyone started giving feedback and challenging me to add more features.

One of the first improvements added was the mobile Progressive Web App, which allows all the players to easily access the app from their mobile phones. This is particularly important as it allows us to consult and change the teams when we arrive at the pitch and it also keeps things exciting because immediately after the match we can submit the score and see the updated table instead of having to wait weeks like we used to!

The initial goal was to simply mimic what we had in the Excel file. Therefore, the first iteration of both web and mobile apps only included a table screen with a list of all players and their statistics, and a screen with a list of all matches.

Adding Features

Following the feedback and enthusiasm from the group, I kept developing new functionality on a daily basis. The next was the creation of a detail screen which, by clicking on the name of the player on the table, allows anyone to track the progress of that individual player. This included the history of all goals for and against, the history of the points per match, list of all matches played, etc. — which keeps players focused on improving their numbers.

While gathering and consolidating all this individual data, I also decided to create a Player Performance Index. This is a metric that compares all the players and gives them a rating based on their statistics. This was something new because before, we were simply tracking the amount of points that each player had, which is not as relevant when players don’t have the same amount of matches played. This way, we can now compare the different players based on a fairer calculation.

On top of that, I’ve implemented the match registration functionality. This allows us to register ourselves for the next match using the app. We have around 50 people in the group, but obviously, only 14 can play (we play 7-a-side) at a time. The registration process was basically a WhatsApp message in the group, with a list of the available players. Whoever wanted to join the next match would have to copy that list, add the name to it, and message the whole group with the updated list again, which was a bit cumbersome. Now, we just need to go to the app, search by our own name and click “Register”.

Weekend after weekend, more people started realizing the value that “Sunday Football” was bringing, and also saw how much we could do and improve in such a short period of time. This really opened the door for more ideas to start flowing.

We realized that with the data we had and with the creation of the Performance Index, it would probably be a good idea to start selecting the players for each team based on their statistics. Up until that point, we would get to the pitch and two players would choose the teams. The goal was to try to have more balanced teams and more exciting matches. Indeed, the app now includes a team generation engine and we’re using the suggested teams every Sunday. And, I’m not sure whether it’s a coincidence or not (no, it’s not), but we started having a lot more draws. In fact, prior to the creation of the app, there was never a draw.

“Now we here”

A couple of weeks after I started its development, the “Sunday Football” application ended up with the following functionality:

Web and Mobile (PWA) applications;
Championship table screen;
Screen with a list of all past and future matches;
Screen detail with statistics of each individual player;
Player registration for upcoming matches;
Player Performance Index;
Team generation engine, based on each player’s performance;

The best thing is that, what started as another OutSystems personal project allowing me to further improve my development skills and to keep interacting with Service Studio, ended up having a real impact on our Sunday Football matches. Everyone is now a bit more competitive and putting more effort on their performances, without losing the friendly spirit and fair play. All the matches are more balanced and exciting, which makes it more fun… after all, that’s why we play every weekend.

And that’s how I’m still playing with OutSystems and playing football every Sunday.

Create your own free personal environment to start building with OutSystems.

Forem: OutSystems Advocacy Team