Platform overview

First, we should realize that there are two possible contexts for working in OutSystems:

• Personal Environment: OutSystems offers a small software factory free of charge (in the cloud) so that we can do our exercises, tests, and small applications without a productive context.
• Enterprise: Licensed software factories for companies. It can exist in the cloud (AWS), private cloud, or on the company's own physical servers (on-premises). Enterprise versions can exist in different types of licensing and are paid.

We will be able to see this issue in more detail in Chapter 3, Starting Work with OutSystems.

All these tools exist both in personal environments and in enterprise factories. In personal environments, there is a set of restrictions and limitations of services and features, from the number of environments available and the space available in the database to the number of IT users allowed.

Whenever we think of an enterprise environment, we are aware that there must be non-productive and productive environments, the most common model being that of three environments:

• Development
• Quality Assurance
• Production

All existing tools can connect to the environments that make up the OutSystems infrastructure, allowing you to perform any type of necessary task, without, in most cases, the use of external tools.

Platform server

The Platform server is composed of a set of servers (which can be installed both in the cloud and on-premises) that perform all the necessary operations so that the developed applications are available to users. These operations are as follows:

• Compile
• Deploy
• Manage
• Run
• Monitor

To develop our applications, we can connect to the platform server using Service Studio and Integration Studio. After development, we can publish our applications, and the platform server handles the operations necessary to make the applications available to users.

When we publish an application, the platform saves the version of it in its database, thus creating a repository of versions and backups. During publication, the platform will compile, optimize the code, and make it available on the servers for use.

Application servers use traditional databases and conventional external systems to run applications, thereby ensuring uniformity and standardization.

The following screenshot shows the OutSystems environment ecosystem:

Figure 1.1 – OutSystems ecosystem

As we can see, the ecosystem has all the characteristics of a state-of-the-art model while maintaining simplicity for those who develop applications or manage the platform. To take advantage of this ecosystem, we need to have agile tools at our fingertips, both to develop applications and to manage them and the ecosystem itself. And that's what we've already followed!

Service Studio

Service Studio is the visual OutSystems IDE. Its use is related to the low-code paradigm, reducing the use of textual code as much as possible, reducing the error factor, and thus offering the opportunity for the developer to focus more on the business itself. Using this same tool, we can develop both our web and mobile applications.

This tool addresses four layers of application development:

• Data
• Logic
• Frontend
• Processes

In addition, it provides a section called TrueChange, where the entire analysis of the code is reported, providing detailed information on existing errors and warnings.

The following screenshot shows the look and feel of Service Studio:

Figure 1.2 – OutSystems Service Studio canvas look and feel

OutSystems main application development tool manages to be super intuitive and provides us with numerous accelerators that we can take advantage of. However, this is not all!

Integration Studio

Do you need to create your own custom C #/.NET code? Do you need to connect with external databases? Do you need to create a connection with your legacy systems? Then this is your tool!

Integration Studio offers a set of accelerators to support our native C # code, as well as integrations with databases external to the platform, making these routines simple and easily scalable.

After creating our code and our integrations, Integration Studio, together with the platform server, creates its representations in the OutSystems universe, thereby being available for use in the same visual paradigm with which we develop our OutSystems applications.

The following screenshot shows the look and feel of Integration Studio:

Figure 1.3 – OutSystems Integration Studio look and feel

With the tools presented, we found out which path to take to develop and make reactive web and mobile applications available at the speed of light. Now, how can we manage and operate the application server? With the next tools!

Service Center

Service Center is a web console that allows you to manage an OutSystems environment, including parameterization, the inspection of logs, and viewing existing applications and the current status of existing services, thereby facilitating the export of generated event reports. The following screenshot shows the look and feel of Service Center:

Figure 1.4 – OutSystems Service Center look and feel

Service Center guarantees us a very practical control of each of our environments. However, OutSystems wanted to go further and complemented this tool with the one we'll demonstrate next, taking the power and ease with which we can master our platform even further.

LifeTime

We are going to visualize a kingdom, composed of several layers, and at the top there is someone on a throne. Is it displayed? Whoever is on the throne is called LifeTime!

LifeTime, also a web console, allows you to control, monitor, and configure the complete life cycle of our applications between the multiple environments in the framework. With this, this tool allows you to go further than we can through Service Center.

With this console, we are able to deploy the different applications existing in the OutSystems infrastructure, benefiting from multiple integrity checks to guarantee the stability and robustness of the environments. In addition, the deployments made by LifeTime guarantee "zero downtime," translating this into a better experience for the end user since, in this way, applications are never unavailable.

In addition, LifeTime allows you to track versions of our applications, and we can customize their tags at the time of deployment (if we do not, LifeTime does it for us).

Another fantastic feature that exists in LifeTime is the ability to manage the permission levels of each IT user and development team, thus ensuring the ownership of each of the existing workstreams.

The following screenshot shows the look and feel of LifeTime:

Figure 1.5 – OutSystems LifeTime look and feel

As we can see, OutSystems allows us, in addition to having great power and control over all aspects of the platform, to do so responsibly, with guarantees to maintain the correct functioning and abstracting from the high complexity that a system of this category has. Everything is much simpler, more practical, and more effective.

Next, we will analyze the functionalities and capabilities that the OutSystems platform makes available to us in order to facilitate and accelerate our work, thereby ensuring that we have a greater focus on the business and its needs.

With this information in mind, a pertinent question arises: How do we publish our applications to our servers?

Publishing an application

We know that if we want to have our applications fully available and make the most of our infrastructures, we will want to publish them on all our frontend servers to process all requests coming from browsers or mobile devices in an identical manner. In the example of three frontend servers, did we need to publish the application three times (once on each server)?

The answer is no! OutSystems tools such as Service Studio, Integration Studio, and Service Center provide the 1-Click Publish functionality, which basically triggers the action of publishing in the corresponding environment. In addition, this feature manages to do it in style: with so-called zero downtime! Applications are never unavailable during the publishing process, minimizing the impact on their users. This feature is achieved by publishing the necessary files in a virtual directory, and when the operation is complete, the old directory is replaced in its entirety by the new one. This whole process is called hot deployment.

To obtain this behavior, there is a server called Deployment Controller Server that has installed the Deployment Controller Service service (it does not need to be a dedicated server; this service can be installed on one of the frontend servers, assuming the same two roles) that communicates with all other frontends through their deployment services.

In summary, we press the 1-Click Publish button, which saves a new version of our module, generates and compiles optimized code and SQL scripts, and updates the database model until it finally deploys the application.

The following screenshot shows the application publishing flow from Service Studio:

Figure 1.6 – OutSystems application publishing flow from Service Studio

The publishing flow of an application is done in a fully controlled way to ensure that everything is ready and without generating any issues regarding the use of our applications. Even so, it may be necessary to check events to ensure that everything runs smoothly. Monitoring? Logging? Of course these functions are available!

Monitoring and logging

The OutSystems platform provides an automatic monitoring service for our applications. This means that any event is recorded in databases so that we can search for them in the future. To this end, an asynchronous approach was applied to the writing of the logs. If they were recorded in real time, we would have a performance problem because we have lots of logs to be written simultaneously in the database, thereby causing delays and possible locks on the tables. We can imagine an application with hundreds or thousands of users at the same time… anything could go wrong (Murphy's law always comes up).

And how does asynchronous logging work? To this end, each frontend server has a logging service. The logs are transmitted to the Microsoft Message Queuing (MSMQ)by the service center of the respective server, and they are subsequently captured by the log service from time to time which, in turn, inserts the data in bulk (bulk insert) in the respective database tables. These same tables, to ensure the best possible performance in writing, do not use indexes (indexes are very useful and optimize performance in research, but slow down writing).

Well, throughout this explanation, we have already seen that there are several functionalities for writing data to the existing tables on the database server. For the better segregation of concepts, OutSystems makes it possible (only on on-premises installations, that is, on its own servers and not in the cloud) to create multiple database catalogs in order to facilitate the maintenance and segregation of databases. All of this can be done in a very simple way through the Service Center tool. It is not a topic that it makes sense to go into in too much detail since the focus of OutSystems is to orient the market to the future: the cloud (as a curiosity, OutSystems, when it received its name, did not have the term cloud in it because the cloud was not prevalent at that time).

The following screenshot shows the monitoring view (errors) in Service Center:

Figure 1.7 – Monitoring View in the OutSystems Service Center

Service Center allows us to make the most of the platform's logs – practical filters, information details, exportability, and everything else – grouped by concept. This is proof that, in addition to OutSystems equipping us with tools, it does it the right way.

Distribution

Another functionality provided by the OutSystems platform is support for Content Distribution Network (CDN). What does this consist of?

Firstly, the CDN is located between the clients' browsers and the frontend servers (on farm installations, from the load balancer).

The CDN is used to distribute content efficiently among end users. Basically, the idea is that, instead of our environment doing the distribution of content for all requests made, there are servers in the various zones where applications are available that do this for them. With this, the distribution of cached resources such as CSS is much more efficient and faster, thereby freeing the environment for other tasks. Note that even with CDN, the frontend servers in our environments continue to process information requested by end users, such as the HTML of the web page for each request. That same HTML has references and links to CSS files, JavaScript, images, and static content, these being loaded from the servers made available by the CDN.

But how do these servers know whether the content should be updated? That is, if we publish a new version of our application with changes to the content stored on the servers made available by the CDN, they must be able to know that such an event has occurred. For this, the platform facilitates this operation with the simple suffix in the resources, and the servers can compare the same with the version existing in themselves. If the suffix is different, the servers obtain the necessary new content and update their versions. The browser's cache works in exactly the same way: if the suffix is different, even in cases of an aggressive cache, the browser obtains the new content from the frontend servers (if there is no CDN) or from the servers provided by the CDN.

Note

Throughout this book, the term CDN will be used to identify the functionality of the content distribution network.

The following screenshot shows an example of a CDN:

Figure 1.8 – General example of a CDN

While it is difficult to accurately predict what the future of CDNs will be, one thing is certain: this industry will grow exponentially, which means that the technologies used to run them will evolve further.

Cache

The OutSystems platform provides built-in caching capabilities. With this, we seek to obtain substantial improvements in performance (long cache, normally associated with static content, similar to what we saw regarding the CDN) and the prevention of the so-called "peak traffic heavy load" (short cache).

Regarding the long cache, this is something automatic on the part of the platform. For example, if we inspect a web page of an application developed in OutSystems, we can verify in the properties of static content (as in the case of images) that the value of a month is set to a maximum age for cache control in response headers.

In the case of the short cache, it has this name precisely because its period of stay is defined in minutes, seconds, or milliseconds and serves to save computing time on servers. This functionality is used whenever it is guaranteed that the orders are identical and that their result does not vary, otherwise, that same cache would not be used, leading to computational reprocessing.

This short cache can be set to the following:

• Aggregates and SQL nodes (used to fetch data in OutSystems code):

Figure 1.9 – Cache in minutes in Aggregate

• User actions and SOAP methods consumed:

Figure 1.10 – Cache in minutes in Server Action

The value of the cache time is defined in the properties section of each of these components, in the Cache in Minutes attribute. When defining the value of the cache, whenever the server is asked for a certain artifact from those mentioned above, instead of recalculating the request, the previously calculated value is returned and made available in the cache. Note the importance of the order having to be exactly the same as foreseen in the multiple scenarios. For example, if we cache an aggregate that has an input defined and is used in the filters, if the value of the different requests is different, the cache will not comply with the forecast, since the previously calculated value does not fit the order in question and it has to be recalculated.

Objectively, to use the short cache, we must carry out a careful analysis of the candidate elements to verify whether their use makes sense. Another scenario to consider, for example, a SOAP service that returns a list, is the fact that we must assess whether the fact that we use the cache and do not have the data in real time can affect the business.

SEO – Search Engine Optimization

The OutSystems platform is already prepared and provides features for the so-called SEO – Search Engine Optimization. But what is this?

Important Note

For Reactive web applications, these features are in Technical Preview, so they need to be activated in LifeTime. SEO is a set of techniques used to make web pages more easily indexable by search engines (such as Google). It often involves making the URL of the page more user-friendly or even changing the native URL. With these techniques, the URLs of our applications go up in the indexing ranking, gaining visibility. Basically, the idea is to make the URLs as similar as possible to the search strings entered by users.

Note

Throughout this book, the term SEO will be used to identify the functionality of Search Engine Optimization.

In the service center of each of the constituent environments of the OutSystems platform, four features are available to solve this problem:

• Module Alias Rules: This feature allows you to give another name to the module that appears in the URL. For example, if the module is called AssetsManager and we want it to be simpler, we define a rule where the alias of that module is Assets. From that moment, in the URL, the part of the module no longer shows the initial value showing the value of the alias. With this, it is no longer necessary to rename our modules.

Figure 1.11 – Service Center view for Module Alias

• Redirect Rules: This feature allows us to define a URL that, when the call arrives at IIS, informs the browser to make a new request for a URL provided by it. For example, if we call the URL us.acme.com and we have a redirect rule defined so that it is redirected to www.acme.com/us when the call arrives at IIS, it will communicate to the browser to make a new order for this new URL. This is a widely used technique, including by Google.

Figure 1.12 – Service Center view for Redirect Rules

• Site Rules: This feature allows you to configure the root application for a given URL. For example, we have an application called Site and we set the URL www.acme.com so that, when called, this opens the Site application. This way, we can optimize the control of our domains in parallel with our applications without needing to access the URL built with the domain and the application to open a specific application. In addition, we were also able to define the locale parameter (very useful when working with multiple languages or when we have different versions of our applications based on the language).

Figure 1.13 – Service Center view for Create Site Rule

• Page rules: This feature allows us to configure the trailing part of the URL to be more user-friendly. With this, instead of having something like /CityBuses/SearchPage? From={From}&To={To}, we can have something more user-friendly: /CityBuses/From-{From}-To-{To} (the values between {} are the input parameters for the search). Recently, OutSystems made these settings available in a more understandable way, directly in the page properties in the IDE (Service Studio). With this, as we create and develop our application pages, we can immediately configure our page rules in a simplified and intuitive way. This is the technique that most allows good ranking positions to be achieved in search engines since the trailing part of the URLs is the one that is usually the least human-readable:

Figure 1.14 – Service Center view for Create Page Rule

With this in mind, we realize that SEO allows us to obtain better results in search engine searches, much more attractive and user-friendly URLs, and a much more understandable use of our applications, always managed in a centralized and simple way.