Does OutSystems allow the reuse of code?
Table of contents
Yes. Applications built with OutSystems can share and reuse code that is made available for discovery and usage. Reusability is available at all application layers: UI, business logic and database. And, code reuse is better with OutSystems for a number of reasons.
Discovery and usage
Inside the visual model that defines an application's module, objects have a "Public" property. This property makes them available for discovery and usage in multiple applications. Here's an example of an action made public:
Public objects can be found in the development environment:
UI
At the UI level developers can expose a variety of artifacts to be reused in any other OutSystems application.
Web blocks
These reusable UI pieces have a variety of purposes:
- Functioning as a self-contained widget with its data inputs, user interface, events and notifications. An example is a customer data summary that updates customer information, used across several pages in one or multiple applications.
- Packaging JavaScript plus CSS functionality. An example is the Google Maps component that uses the Google Maps API to expose the ability to use maps in OutSystems applications.
- Being used as theme layout pages with style, placeholders and functionality. For example, OutSystems built-in themes exercise this concept by exposing different layouts for different types of screens such as web, email and popup.
Themes
A theme exposes CSS. When reusing a theme, the consuming application inherits the theme style sheet, which can then be overridden locally. The OutSystems built-in themes exercise this concept.
Themes can also be built from the ground up, allowing CSS style sheets developed by your design team or digital agencies to be easily integrated.
Pages
Web screens can be exposed for reusability as a way to navigate or redirect control. An example is a common login page used by several modules in the same portal.
Business logic
Any block of business logic written with OutSystems can be reused in any other business logic function, business process orchestration, web screen, mobile screen or asynchronous job, whether the logic is being reused in the same module and application or across multiple applications.
Roles available in one application:
The roles with access to the dashboard:
The concept of roles, frequently used in logic to control user interface elements and business rules, can also be shared across multiple applications. For example, a user can be assigned a manager role, which might allow different functions in different applications, whereas from a user management stand point, it is one and the same role.
Exposing web services is also a way to share functions not only with multiple OutSystems applications, but also with external applications, which can consume these services in a de-coupled fashion.
Database
All database tables (entities) designed and deployed by OutSystems can be marked as public and therefore reused by any other applications. Data can be shared as read-only, where the consuming application cannot write into the specific tables, or it can be shared with read/write access, giving the consuming application full control over the data.
For example, it is typical to have a single customer table used across multiple applications to ensure master data consistency.
A module that isolates the customer data:
Using customer data from another module:
Because OutSystems uses standard database technologies (Microsoft SQL Server, Oracle) to deploy its data schemas, on-premises installations can easily have external systems reading and writing into those databases, too. This is a scenario of sharing and reusing platform generated artifacts by external applications.
In memory data structure definition, there is also an artifact that can be shared across multiple applications to ensure consistency of auxiliary complex data types.
Why is code reuse better with OutSystems?
The OutSystems code reuse difference is that OutSystems offers governance, reports to help users understand the network of dependencies between apps, and analysis of the impact of changes.
Governance
Reusing code is great, but doing it in a controlled fashion is even better.
OutSystems can manage roles that perform certain tasks in certain environments and with certain applications. With this construct it is possible to enable which users or teams have access to the shared components exposed by each application.
Example of the developer permissions:
Example of the senior developer permissions:
Understanding the network of dependencies
In OutSystems consoles, there are reports that allow users to browse and understand the network of dependencies between apps. Different levels of granularity are available, such as dependencies between applications and between each module.
Dependency map between different applications and modules:
OutSystems is also open so developers can extend it to create additional components that provide more insight about the way applications relate to each other, such as this architecture analysis tool available on our Forge website.
Impact analysis
OutSystems provides immediate visibility of the impact of changes made to a specific module at the time of its publication. Here's an example of a dependency analysis graph:
Developers have real-time visibility of which modules or applications will be affected and might need to be fixed or simply recompiled.
Preventing a deployment due to broken references:
Publishing applications across environments not only identifies and packages all the required dependencies in terms of reused code but also analyzes the impact of promoting that code to a different environment, where different versions may already have been deployed.