Discover the power of OutSystems Site Properties to streamline your application configurations. Learn how to create, manage, and secure these global constants effectively while avoiding common pitfalls. This article covers everything from leveraging secret properties for sensitive data to best practices for deployment and maintenance. Unlock the full potential of site properties for robust and efficient application management.
Site properties are a feature of OutSystems that allows you to store and manage configuration values for your applications. In this article, you will learn the benefits of using site properties, how to create and use them correctly, and what common mistakes to avoid.
About Site Properties
First things first, site properties are server-side global constant variables. They are very useful to implement slow-changing configuration values for a module. We usually use them to implement configuration values for an application - such as an API key. One important detail to have in mind is that each environment can have its unique effective value. If your application is multi-tenant, each tenant, in each environment can have different values.
In some cases, we need global variables. Variables that will remain constant and will not be changed at runtime. Some examples:
the correct maximum number of records for some queries,
API keys,
System User Id,
timer's kill switch and
even quick feature toggles.
One advantage that comes with the use of a site property is that during deployments, LifeTime guides you to set them up. It identifies new site properties and asks you to fill them in for the destination environment while deploying. Isn't that awesome? That means you don't even need to open Service Center on the target environment to update site properties after a deployment.
An alternative to using site properties is to have:
global variables (hardcoded) or
have a table that stores the settings values in the database.
Not best practice! That results in much more documentation and hotfixes in target environments when there is the need to change them. Site properties are much better, they give visibility for that setting. Since v11.25.0 of the Platform Server, there is the option to store this information in a secure way. No need to share service credentials with the developers. It is a new feature!
Okay, so how can we create a Site Property?
To create a site property, you first need to decide its data type. It could be any of the basic types except binary and in the case of choosing text as a type, there is a 2,000 characters limit. Despite Identifiers being handled as a long integer, the IDE allows you to set the type as an Identifier. Ah, and don't forget the description otherwise AI Mentor Studio won't let that fly 😉.
As OutSystems suggests in its best practices, writing a good description is very important! You can also use examples and do not forget to mention where the site property is used.
Adding Site Properties from Service Studio
As I mentioned, there is a new feature that OutSystems recently introduced on the platform. A property called "Is secret". When you set the "Is secret" to "Yes", you create a special kind of site property, because it does not have a default value (a value set at development time) and its content is also encrypted in the database.
Configuring a Site Property in Service Studio
For them, you can only set its value in Service Center. If you do not set its value in Service Center, it will assume the default value of the data type selected for your Site Property. This is a perfect feature to be used with any secrets, for example, API keys, client IDs, and client secrets.
There is a catch though! As this is a new feature, please check the minimum requirements to have them available. LifeTime >= 11.20.1; Platform Server >= 11.25.0 and Service Studio >= 11.54.35.
Common pitfalls!
The first thing to avoid doing is to update site properties programmatically, therefore you should not create a site property for values that change often. Avoid having too many site properties in your module. Carefully evaluate if you need each of them. If you do have a use case like the ones mentioned before, it is better to consider saving this information on a database table and having a back office to manage their different values. Why? Site properties are cached for faster access. When we update a site property, we also reset the modules' cache (and its consumers) and all values are reloaded from the database. This causes database overhead and impacts all the parts of your application that use any site property.
In case you need to change the secret property to no, for your app to keep working as expected, you need to set a valid default value and/or go to Service Center and define a new effective value. But don't worry, a popup will show up to remind you as soon as you change that flag.
Warning in Service Studio
In summary, OutSystems site properties are powerful tools for managing configuration values in your applications. They provide global constants that remain constant across environments and tenants. By leveraging secret site properties, you can securely handle sensitive information like API keys.
Remember to evaluate the necessity of each site property and avoid frequent updates programmatically. Keep exploring the benefits of site properties, and happy coding!
Comments