Forem: OutSystems

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.

Learn basic SQL concepts using visual low-code

Cecelia Martinez — Mon, 29 Jul 2024 19:53:41 +0000

SQL concepts are not always the easiest to learn – I know I’ve struggled with crafting queries and defining schemas myself! For some developers, it can be easier to understand SQL concepts visually. This is why I recommend using OutSystems – a visual, low-code platform – to help you learn common SQL concepts.

If you think that low-code is only for non-developers, think again! I was surprised to discover just how much engineering knowledge is required to build quality apps in OutSystems. The good news is that OutSystems removes the tedium of app development (think framework configuration, remembering syntax quirks, and repetitive boilerplate), so you can focus on making strategic technical decisions to build the right app for your users.

Under the hood, OutSystems uses SQL. This means that there is a direct relationship between the low-code data concepts in OutSystems and SQL. In this post, we’ll show examples based on a sample events platform application. If you’d like to build along, create a free OutSystems account, set up a personal environment, and install the development environment, Service Studio. (Check out the Getting Started guide here.)

Data Concepts in OutSystems

To better understand SQL concepts, we’ll take a look at the corresponding data concepts in OutSystems.

Entities
- Creating an Entity
- Relationships
- Static Entities
Bootstrapping Data
Displaying Data on Screens
- Drag-and-Drop
- Queries with Aggregates
CRUD Operations
Next Steps

Entities

We’ll start with the building block of data in OutSystems: Entities. An entity represents an object that corresponds to a business concept for your app. For example, an e-commerce app may have Products, Orders, and Customers. Each of these could be an entity in OutSystems.

In SQL, this corresponds to a table. When you visually create an entity in OutSystems, a SQL table is created.

Each entity has attributes, or properties, that contain additional information about the entity. These correspond to the concept of columns in SQL. Attributes must have a set Data Type, which can either be a primitive type like Text or Integer, or a reference to another entity. Attributes can be set to mandatory if needed.

The best way to understand entities and relationships is to see them visually represented in OutSystems, so let's create our first entity.

Creating an entity

Everything related to the data of your application is accessible from the “Data” tab in Service Studio. Here you see a folder named “Entities.” Right-click and select “Add entity to Database” to get started. We’ll name our first entity “Event.”

This creates a new table where we can define our entity attributes. By expanding the arrow next to our new entity, you’ll see a default Id attribute, as well as some built-in CRUD methods. (We’ll get to those later!)

Now you can right-click the entity and select “Add Entity Attribute.” We’ll add the attributes, or columns, and make sure each attribute has the correct data type. OutSystems infers the data type for you based on the name, but you can adjust that if needed. You can also mark if the attribute should be mandatory.

Here is our “Event” entity, with attributes for Title, Description, Date, StartTime, and EndTime.

In the new entity, you can see that the Id attribute has a red icon. This indicates that the Id is the Entity Identifier. This is the same as the concept of a primary key in SQL. The entity attribute or primary key uniquely identifies each record in a table.

Let’s repeat this process and create a “Venue” entity, with attributes for Name, Address, City, State, ZipCode (all with a text data type) and AllAges (a boolean).

Relationships

Every event needs to have a venue. We can demonstrate this relationship by adding an attribute to “Event” that references a specific “VenueId.” This is called a Reference Attribute, and you’ll see that the data type is automatically inferred as “Venue Identifier” by OutSystems.

In SQL, this is like adding a foreign key column to a table that references the primary key of another table. In this case, our Event entity is like the child table. The VenueId attribute on the Event entity is like a foreign key that references the primary key of the Venue entity.

Static entities

Static entities are read-only and are useful for holding predefined values that will not change. These are like static tables in SQL, and some examples could be role types, categories, or levels of priority. For our event app, each event should have an event type, but we want these to be predefined from the outset as either “meetup” or “workshop.”

So, we’ll create a static entity. Right click on the entities folder again and select “Add Static Entity to Database.. Name it “EventType,” then right-click the Records folder and add two records, one for each of our event categories.

Because static entities are read-only, which means developers can add new records in the future, users will not be able to update it from your app. We can add an entity attribute to “Event” called “EventTypeId” that references our new static entity. This is exactly what we just did for VenueId.

Now that we have entities defined, we can start adding data to our app.

Bootstrapping data

OutSystems enables you to manipulate data records in Service Studio. Simply double-click any entity to view, edit, and create new rows. But, the easiest way to set your app up with initial data is using the spreadsheet upload option. OutSystems will automatically map your columns in Excel to the attributes in your entity and add the rows for you.

I’ve generated some fake venues to populate our Venue entity and get our app started. To upload, right-click on the Venue entity, navigate to “Advanced,” and then “Create Action to Bootstrap Data from Excel.”

Confirm the mappings, click the green Publish button, and you’ll now be able to see the rows populated by double-clicking on the Venue entity.

Now that we have some data, let’s do something with it!

Displaying data on screens

We won’t get into building user interfaces too much in this post. However, I do want to demonstrate the relationship between your data model and the UI, as well as how easy it is to generate a visual representation of your data for your app’s end users.

Drag-and-drop

OutSystems can automatically generate screens (as in pages) based on your data model. This has been a game changer for me coming from traditional code, where scaffolding out pages was some of the most tedious parts of building an app from scratch.

First, navigate to the Interface tab in Service Studio. You’ll see an expanded UI Flows folder with a “MainFlow” inside. Again, we’ll explain more about UI in OutSystems in the future, but for now double-click where it says “MainFlow.” This will update the main window in Service Studio with instructions prompting you to “Drag and drop a screen or entity to create a screen.”

We’ll do the second option! Click back to the Data tab, click and hold the Venue entity in the list, and drag it onto the screen.

Double-click on the newly-created Venues screen. In the bottom half of the right sidebar, check the “Anonymous” option under Roles. This will let you view the screen in your browser without logging in to the application. (Note: This is only recommended for sample apps, for security reasons, it’s best to require users to log in for production.)

Click the green Publish button, and then “Open in browser” once the button changes to blue.

In the browser, we can see our Venues list populated with the data! OutSystems creates the UI components to display, search, and even paginate data.

Back in Service Studio, check “Anonymous” under Roles for the VenueDetail screen, just like we did for the Venues screen. Publish again and open in the browser. Now, click on either the “Add Venue” button or the name of any venue in our list.

This is the UI for editing existing and adding new venues. No more repetitive building of forms over and over! OutSystems even handles built-in form validation based on your data model, enforcing types, and mandatory fields.

Queries with aggregates

OutSystems uses what’s called Aggregates to create these screens. Aggregates are optimized SQL queries for fetching data from the database. If you expand the arrow next to the VenueDetail screen in the Interface tab, you’ll see a “GetVenueById” item with a grid icon. This is the aggregate we are using to query for the specific venue.

Double-clicking the aggregate opens a visual query editor. Here, you can explore the query sources, filters, and sorts. You can also set test data to validate the query returns what you expect. I encourage you to adjust some of the different values to better understand the relationship between the query builder and your data.

In the bottom of the right-sidebar, you can also see the executed SQL query generated by the aggregate.

We can also get information about the returned query, such as how many items were returned. Let’s update the Venues list screen to display how many venues there are.

Double-click the Venues screen to open the UI editor. In the left sidebar, you’ll see an option that says “Expression” with an x/y icon. Drag and drop this item right next to the title that says “Venue List” on the screen. This will open the Expression Editor.

In the Expression Editor, the available data from your application is in a tree format. Expand the “GetVenues” aggregate and select “Count.” Use this GetVenues.Count value to create an expression that shows the count value between parenthesis using JavaScript expression syntax.

Publish again and you’ll see the count in the browser next to the title. Aggregates are very powerful, and can be used to perform more complex filtering, joins from multiple data sources, and even calculated queries that generate attributes such as sums or groups of data rows.

Dig deeper into aggregates in the documentation here.

CRUD operations

One other data feature of OutSystems that’s important to mention are the built-in CRUD operations for all entities. You may have noticed these when we first created our Event entity.

CRUD (Create, Read/Get, Update, and Delete) operations are standard operations for working with data in an application, and correspond to SQL operations. These are automatically generated by OutSystems and can be used in the business logic of your app.

When we generated the Venues list and detail screens using our data model, OutSystems also created logic that uses these CRUD operations to add or update new venues to our database. We can trace this flow to see how the data moves across the full stack of our app.

In the Venue Details screen, the “Save” button on our form has a click handler that runs “SaveDetail.”

Digging into this “SaveDetail” Action (you can think of it like a client-side JavaScript function for now), we can see it leverages something called VenueCreateOrUpdate. Again, don’t worry too much about understanding this flow; the important thing to know is that our click handler calls a “function” SaveDetail, which then makes a call to our server using VenueCreateOrUpdate.

Finally, on our server, within the “VenueCreateOrUpdate” action, OutSystems is using the built-in CreateOrUpdateEvent operation to actually write the change to our database.

Having a solid understanding of your data model and how it’s used across the OutSystems app is important to ensuring your app has a strong data foundation early on. You can view the relationships between your data entities at any time in the “Entity Diagrams” section of the Data tab.

This diagram represents the relationships between the different entities – or tables – in your database, as well as references between tables based on keys.

Next steps

This has been a crash course on learning basic SQL concepts using OutSystems! I encourage you to use the free OutSystems personal environment to create an app and explore these data concepts yourself. You can use this Excel file with Venue data, or build something yourself from scratch!

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.

How I became low-code certified with OutSystems

Cecelia Martinez — Thu, 25 Apr 2024 17:22:18 +0000

This month, I followed in the footsteps of many other OutSystems developers and completed the exam to become a certified Associate Reactive Developer. This exam focuses on the fundamentals of OutSystems reactive web and mobile application development, and is for developers new to the OutSystems platform.

However, just because it is for new OutSystems developers, does not mean it’s an easy exam. Even with my traditional development experience, I had to study to be successful. Even though OutSystems is a low-code platform, it requires understanding of data structures and relationships, building component-based user interfaces, constructing business logic and control flows, and understanding events and application lifecycle management.

Here are some of my takeaways from preparing for the exam, and tips to help you prepare for and pass your own certification journey.

Note: I completed the OutSystems 11 certification, however, many of these same lessons apply to the Associate Developer ODC exam as well.

Understanding the Exam
- Exam Topic Breakdown
- Question Format
- Applied Knowledge
Learning the Material
- Developer School
- Online Training
- Hands-on Learning
Preparing for the Exam
- Question Practice
- What to Expect
- Test Tips
Continuing Your Journey

Understanding the exam

The first step in knowing what you’re getting yourself into! Even if you’ve taken certification exams before, each once will have its specific format and approaches to testing your knowledge of the material. Start by understanding what the exam will entail so you can best prepare.

Exam Topic Breakdown

The Exam Details on the certification page includes a PDF entitled “Detail Sheet”, which contains important information about the exam. The exam consists of 50 questions, and a 70% score (35 correctly answered questions) is required to pass.

Pay close attention to the Exam Topics breakdown chart in this document. I referred to it often, as it contains what percentage of questions are asked about certain topics. I used this to develop my study plan.

My strategy was to start with the topics that had the highest percentage of questions on the exam. These include Screen Widgets (16%), Aggregates (12%), Logic Flows & Exception Handling (10%), and so on. After my initial completion of the Developer School and Training (more on that later), I went back through the topics and ensured I had a strong understanding of the highest percentage topics before moving on to the next one. This meant I was spending my study time efficiently.

Question Format

It’s also important to know what to expect from the question format. This is where the sample exam, also included in the Exam Details, is helpful.

All questions on the exam are multiple choice, with four options and only a single correct answer. Many times, two or more of the options will seem very similar, or like they could both be correct. It is important to read the question and options very carefully to identify which answer is the right one.

Many questions will ask “Which of the following is correct?” or “Which of the following is the best way to do something?”, and these can be tricky. Sometimes an option will be correct, but it is not the best answer. Take your time and make sure you understand what the question is asking.

Applied Knowledge

The questions on the exam are focused on applied knowledge. This means that you will not see questions like, “What is an entity?” or “What are the three types of joins in an aggregate?” Instead, you will be presented with scenarios, and must apply what you learned about entities and joins to find a solution. You may be asked what is the expected output for a screenshot of an aggregate, or asked how to change a given logic flow to produce a different result.

This is why memorizing terms from the training is not enough. You will need to fully understand the concepts of OutSystems and get hands-on practice with building reactive web and mobile applications to be successful.

Learning the material

Fortunately, OutSystems provides you with all the resources you need to learn the material for the Associate Reactive Developer certification exam. Whether you prefer live training or online training, OutSystems has options for you. To complete the training, make sure to sign up for a free Personal Environment to explore the platform, complete exercises, and build applications.

Developer School

I attended an OutSystems Developer School to prepare for the exam. This free program from OutSystems is for those with previous development experience who want to learn OutSystems quickly and take the Associate Reactive Developer exam. It is a great option if you already have development experience and are committed to spending 35+ hours on live, remote training.

The training takes place over two weeks, and includes live instruction, a chance to ask questions of an OutSystems expert, additional exercises, and hands-on project work. It also includes a certificate voucher to take the exam for free as long as you meet the participation requirements. The voucher must be used within 30 days so you should be prepared to dedicate time to studying immediately after the school completes.

There are sessions every quarter in three regions. You can apply online here for an upcoming session.

Online Training

Everything covered in the exam is in the free online training under the “Becoming a Web Developer” Guided Path. I actually completed the training in addition to the Developer School to reinforce my learning and to complete the additional quizzes and exercises included in the online training.

I highly recommend completing the training even if you do attend a Developer School. The more you expose yourself to the material and gain hands-on experience with Service Studio and the OutSystems platform, the more you will understand how to actually apply the knowledge in a way that is needed to answer the exam questions.

Hands-on Learning

Speaking of hands-on learning, from my experience, only completing the exercises in the online training is not enough to truly cement the concepts in your brain. Especially if you only follow the how-to instructions. I highly recommend spending time in Service Studio building out applications on your own so that you can explore the platform and learn how to solve problems on your own.

Decide on an application you’d like to build, and work through the concepts you are learning in the training. Start by adding some data entities and creating relationships between them. Then create some screens using widgets, and display data with aggregates. Add form validation and use Client and Server actions to update data in your database. Create a block to reuse in your application, and leverage an event with a handler. Slowly add features to your application based on what you are learning at that time. This will build the experience you need to recall the information when you’re nervous during the exam.

For my study, I actually built a flashcard application to help me study. I wrote practice questions based on what I was learning, and then built an app in OutSystems to display the questions and answers, and keep track of my score. This helped to reinforce all the concepts I was learning and give me hands-on practice.

Preparing for the exam

As you get closer to the date of your exam, there are some tactical approaches to help you best prepare.

Question Practice

You’ll definitely want to get some practice answering questions in the same format as the exam. This is a little difficult because the sample exam included in the Exam Details only has 20 questions. However, I was able to pass the exam without using paid practice tests from other sites by creating my own practice questions.

Now that I have actually taken the exam, I realize that the practice questions I wrote did not quite match up with the difficulty of the real exam. However, by going through the process of writing questions, I forced my brain to think about the material in different ways, and how I would apply that knowledge in a test format. This helped me get additional practice answering test questions, even if they were not exactly the same as what ended up being on the exam.

What to Expect

If you are taking the exam via an online proctor, read the instructions very carefully, as there are strict security measures you must follow. You must have a dedicated space to take the exam where nobody will enter (including any pets!) You will also be expected to show your desk and the room on camera, turn out your pockets, and more. Do not take these requirements lightly – they can and will stop your exam for any suspected violations.

Keep in mind that once you start the exam, you will not be able to leave the camera or take a break until you are finished. You also cannot have any water or food, so make sure you are ready before starting.

Note: The exam experience may be different if you complete it at a testing center. Read the instructions when you schedule!

Test Tips

Once the exam begins, there is a tutorial that shows you how to use the exam platform. I recommend using the strikeout and flag features to your advantage during the test.

The strikeout feature lets you mark answer options that you think are incorrect. This does not actually prevent you from selecting it as an answer, it is just a visual cue to help you narrow down the available choices. I recommend using this to strike out the answer options that you know right away are wrong. This can help you focus on reading the questions carefully.

You can also flag questions that you’d like to return to before submitting the exam. This is helpful in two ways. First, you can mark questions that you aren’t confident in your answer, and then come back to review. This can be helpful in the beginning of the exam when you’re nervous, or, you may see something in a different question that jogs your memory about a topic covered in a previous question.

I also used the flag feature to help me keep track of my potential score. I marked the questions where I wasn’t confident in my answer. As I progressed through, I periodically calculated how many of the questions I had flagged vs. how many questions I had answered. I knew I needed a 70% to pass, and this helped me gauge how I was performing against that benchmark.

Overall, take your time. Read each question and the options carefully, review all the information on screen shots, and go back to previous questions if needed. You have two hours for the exam, so use it wisely, and good luck!

Continuing your journey

Once you’ve passed the exam, you are a certified Associate Reactive Developer! It’s a great achievement that marks the start of your low-code journey with OutSystems, but it’s just the beginning. A good next step is to focus on specializations in Front-end, Mobile, or Web, or pursue the Associate Tech Lead certification. Whatever path you choose, OutSystems has training resources and a strong community of developers to help support you.