The OutSystems Platform includes a unique deployment engine capable of generating and deploying both .NET and Java-based applications. These applications have three types of components that are included in a well-documented application project solution, along with generated source code, business logic and a database.
This dual-stack architecture allows a choice of the stack that best suits particular business requirements and enables easy migration between technologies, without having to rewrite or even change existing applications.
If a subscription to OutSystems Platform is terminated, the code can be detached from the OutSystems Platform by following a well defined process, which ensures that your implementation remains technology-independent.
The code is generated in a pattern that abstracts the underlying technology from the development. In the end, you will always get a fully open, up-to-date, standard, optimized and documented implementation of business applications in .NET or Java.
Applications created with the OutSystems Platform include three types of components: generated, runtime and custom.
These components are created automatically whenever an application is submitted for compilation and publishing. The generated components include:
Pages (aspx or jsf)
Reusable controls (ascx or jsp)
Cascading Style Sheets (css)
Images (gif, jpg, png), and other resources
Web Services (asmx or wsdl and servlets)
Code behind classes (dll or jar)
Proxies to other referenced applications (dll or jar)
These are a set of components included in every application that support the base functionality, including base rendering capabilities and access to several services in OutSystems Platform:
Generic Platform Library: Classes and methods used in all generated applications, such as the OutSystems Platform built-in functions available in Service Studio, database connection management utilities, Excel workbook management, site properties management, Ajax server side utilities, or timer related utilities.
Web Library: Classes and methods that extend Microsoft Web UI controls or JEE JSF controls with new functionalities for standard HTML browsers (for example, support for confirmation message in web buttons).
Developed in Integration Studio, these custom components extend OutSystems Platform and allow integration with external systems. They contain an implementing DLL, JAR, or both created directly by Integration Studio, and published to the Platform Server. These components are used in the context of an application that references them, and the code is executed in the front-end server where the application is deployed. The following diagram provides an overview of how an application is split among its underlying components:
When the source code of an applications is downloaded from Service Center, OutSystems Platform will include all of these components, in a consistent and well documented project solution. This solution (.sln or build.xml) is ready to be opened, compiled and built using a standard .NET or Java integrated development environment, such as Visual Studio or Eclipse.
In a typical scenario where multiple applications with dependencies from integration adapters or other applications are running, OutSystems Platform also provides a full and consistent package with all the generated source code, libraries and dependencies needed to compile each application in your ecosystem.
The following example shows how the Directory application (available from the OutSystems Apps catalog) looks in Visual Studio and Eclipse after downloading its source code:
Generated source code
All the code generated by the OutSystems Platform, either .NET or Java, enforces a series of rules and optimizations that ensures applications behave correctly and avoids scalability or reliability issues. Such rules and optimizations are applied to all layers of the application to ensure the best performance, from database accesses to web page size.
All the generated code is fully detachable from OutSystems Platform and follows a set of rules that assure it is fully readable and maintainable in even when someone stops using OutSystems Platform. The main goals are:
Direct mapping between Service Studio elements and generated code: This mapping, not only in terms of names, but also in terms of code structure, means the application architecture defined will be reflected on the actual generated code.
Fully documented code as defined in Service Studio: The descriptions and notes defined with the OutSystems Platform tools are included so that when people are looking at the code, the context is similar to that in Service Studio. The code also includes all the expressions that were built in Service Studio as comment, to allow easier interpretation of what each line of code is implementing.
Graph analysis to avoid “go-tos”: The OutSystems Compiler uses advanced graph analysis to avoid “go-tos” in the generated code. This way, no matter how complex applications are, the code is more intuitive to read and easier to maintain.
The application interfaces designed in Service Studio have a direct mapping in the markup code associated with the page elements and instantiated on the .aspx or .jsp files, and also in the code behind libraries that include logic directly related to the page, such as the logic that runs before rendering the screen or validating inputs.
The following image depicts the code generated by the OutSystems Platform for an edit employee details page.
To comply with application performance and scalability requirements, OutSystems Platform also provides a set of code optimizations that are kept in the source code, even after it is detached. Examples are:
Pages are compressed. To assure that minimal bandwidth is used by applications and that requests made by users are served faster, all pages are automatically compressed to reduce their size.
Pages can be partially rendered: By taking advantage of the built-in support for Ajax, the application pages can be partially rendered, thus sending less information to the server and returning only a part of the page. The result is less bandwidth consumption, better responsiveness and an improved user experience.
Ajax requests are always queued: The generated code assures Ajax requests are always queued so that a given user cannot flood the web application server by sending multiple requests simultaneously to the server.
Duplicated Ajax requests are dropped: The generated code also assures AJAX requests are only sent once to the Web Application Server, thereby preventing an increase in server load. For example, if several requests from an AutoComplete pattern are queued in the browser, only the last one will be sent to the server.
Graph analysis to send only the necessary fields to the view state: By using advanced graph algorithms that verify which scope variables are written, read, or not accessed at all, the OutSystems Compiler generates code that ensures that only essential fields are sent to the View State, thus highly optimizing the size of the page.
OutSystems Platform enables the modeling of complex business logic without writing code, instead using only simple visual constructs like conditions, cycles, nested calls, assignments, queries, and a wide range of other prepackaged or extended visual building blocks. These building blocks and services save a lot of work while ensuring that the application is an enterprise-class system. This is because features like transaction handling, auditing, exception handling, Excel file handling, integrated authentication, and user/profile Management are services that are available as visual out-of-the-box elements in OutSystems Platform.
Moreover, the OutSystems Platform leverages a full reference-checking and self-healing engine (TrueChange) that assures error-free and consistent changes across all application components. For example, whenever someone modifies a business rule, this engine automatically updates all related business services, data, and user interface elements that use that piece of logic.
The following image shows the code generated by the OutSystems Platform for a business rule that updates an employee birthday:
If an organization stops using OutSystems Platform, its developers won’t be able to use all these visual constructs to create or change your business logic, nor take advantage of the full reference checking and self-healing engine capabilities. However, they will be able to change the standard .NET or Java generated code by hand, using traditional IDEs, and can continue benefiting from these and other code optimizations introduced by the Platform.
Invocations to custom code are contained for duration
Custom components can have all sorts of C# or Java code, either to provide custom algorithms or simply integrate with external systems. If coded with Visual Studio or Eclipse and wrapped using Integration Studio, such code might have performance problems. If invocations to this custom code take more than a reasonable time to execute, OutSystems Platform automatically discards them by timeout, thus assuring that the performance of other applications is not hindered due to extra CPU or memory consumption.
Batch processes are throttled
OutSystems Platform allows people to model business logic that executes asynchronously. Since multiple asynchronous batch processes are possible, those are automatically throttled to ensure that even heavy loads of badly programmed scheduled activities do not take all the processing power required to serve application users.
Following the visual model of Service Studio, you can create, model and integrate persistent data repositories based on third-party databases without resorting to traditional complex SQL statements. OutSystems Platform handles database creation, tuning and consistency with your application during any refactoring operation.
As far as database performance is concerned, the applications include a set of optimizations that are retained when if an organization stops using the OutSystems Platform and extracts the source code. These are:
Connections are pooled: This enhances the performance of executing database commands and reduces the amount of time a user must wait for a connection to the database to be established. Connection pooling also avoids the excessive use of operating system, network and database resources that would derive from having one connection per user accessing the application.
Connections are only kept open if needed: When they are no longer of use, they are automatically released. This allows greater scalability with reduced database resources consumption.
Transactions are always committed or rolled back and then released: Regardless of what the developer coded, in the end they are always released - either by committing or rolling back - assuring your application leaves no orphaned transactions or locked tables and does not consume unnecessary resources.
Queries are only copied to memory if needed: This assures that applications consume the minimum possible amount of memory, despite the fact that they can handle massive data.
Query fields are only fetched if required: Advanced graph algorithms verify the usage of fields within business logic and user interface so queries exclusively fetch the required fields from the database. This ensures minimal load on the database and minimal data transfer latency, regardless of what the developer coded.
Queries are contained for duration: If, even with all these optimizations, some queries take too long to execute, OutSystems Platform automatically discards them by timeout, to ensure the database is not affected by heavy queries, which enables applications to perform at an optimum level.
Tables have automated indexing for primary and foreign keys: This optimizes the most common database queries. If more advanced queries require extra indexes in the tables, those can be visually created in Service Studio.
What code pattern do apps generated by OutSystems use? Is it the MVC pattern?
OutSystems Platform uses a code pattern that is different from MVC. It abstracts the underlying technology from the development process, so that:
Teams can develop, deploy and manage their apps faster.
Developers are isolated from constant technology shifts.
What does OutSystems use?
Currently the source code of the applications generated in OutSystems Platform use:
WebForms with an MVVM architecture for the applications generated in .NET
Faces for applications generated in Java
Also, OutSystems Platform is architected in a modular way to ensure that we have the flexibility to move to a different generated architecture. So if a vendor discontinues the support for one of the technologies we use, that change won't affect our customers or their customers.
Why do developers use MVC? Why doesn't OutSystems?
When choosing an application architecture, developers often choose an MVC approach, because it:
Structures the code in a more maintainable way
Can offer better performance than other approaches
OutSystems tackles maintainability and performance differently:
OutSystems Platform enables the development of visual models that are easier to maintain and change. Teams can develop faster and be confident that their changes have high quality.
The OutSystems Platform code generator performs static analysis of the application models. This way, we can optimize an application when generating its source code. For example, the view state is optimized to only include what's actually being used.
Independent of the language and architecture in which applications are generated, we are constantly working so that they run with the highest performance possible.