If an organization decides to stop using OutSystems Platform, the generated code of the applications can be detached and deployed to standard .NET or Java web application server stacks. There are a few things to do before the code is detached. There are also dependencies to be considered.
Viewing the source code without detaching
Before detaching the source code
Since there is a close mapping between the visual model and the generated code, we recommend that someone who understands the business logic of the original application built in the OutSystems Platform map the logic in code to the visual logic in the application and transfer this knowledge to those who will be maintaining the application in the future. There should also be developers on hand who understand underlying stack technologies and standard .NET or Java web application architecture and code written in the corresponding language.
If an organization decides to detach its source code, it must also take the following into account:
Access to all the application development, management and operation capabilities of OutSystems Platform will be lost.
Embedded feedback, performance monitoring and logging capabilities will require other tools.
All of the OutSystems Platform tools and services, along with their features, will become unavailable. This includes the visual development environment, the integration environment, the environment management console, and the infrastructure management console. However, all core functionality of the applications developed with in the IDEs will be retained.
All dependencies of the generated source code, necessary to execute the application outside of OutSystems Platform, must now be tracked. These dependencies include OutSystems services, OutSystems runtime libraries and databases.
There is no reverse engineering process to get the applications back into the OutSystems Platform from Eclipse or Visual Studio.
Our commitment to helping our customers who want to detach their source code will be the same as if they were any other kind of customers. Anyone who needs any help detaching source code from OutSystems Platform, can call their account manager or OutSystems Support.
Detach and OutSystems Public Cloud
To detach the source code of your applications, you need to build first a hybrid deployment, where you install one OutSystems environment either on-premises or an another public cloud.
All the instructions below assume you already have completed this installation.
Check the detailed steps to complete a transition from the OutSystems Public Cloud to on-premises.
How to detach the source code
To detach the source code of your applications and stop using OutSystems Platform:
Compile and build your applications with Visual Studio or Eclipse. The project files extracted from Service Center contain all the resources and dependencies for compiling and building the applications with a standard .NET or Java integrated development environment like Visual Studio or Eclipse. You can then deploy the application into an application server.
Migrate your databases/schemas to a new database server (optional)
Your application’s data is reusable, either by using the same database server or by detaching/backing up the existing databases/schemas from the current database server and attaching/restoring them to a new one.
How to handle source code dependencies
After an application is detached, the source code will still have external dependencies. These dependencies include OutSystems services, OutSystems runtime libraries and databases. They must be handled differently after detachment.
OutSystems Services and the Scheduler Service
A set of code optimizations and services won’t be available once OutSystems Platform is no longer used. This includes the Log Service, the Deployment Services, Service Center, and LifeTime. These dependencies will be removed, along with the probes that monitor health and performance (which are automatically added by OutSystems Platform) and automated deployment and configuration management.
Organizations who are using time-based batch processing logic will be able to keep this functionality even after detaching the source code. The source code of the Scheduler Service will be provided for this purpose. This dependency can be removed manually if a decision is made to handle this with a different external tool.
OutSystems runtime libraries
The source code of OutSystems Platform libraries required by applications is open and available. This means that this code can be changed. Even if the applications initially require that code, they can be changed to remove this dependency.
Data models, as defined in the applications, are created and updated in the database without any extra effort and without resorting to special database configurations and complex management expertise. During compilation and publishing, the OutSystems Platform generates standard differential SQL DDL (Data Definition Language) scripts that are executed over the runtime database. The generated source code assumes the model is properly created (both schema and configuration data) and depends on each specific database vendor driver, SQL syntax, and other specificities.
A decision to use a different database server after leaving OutSytems will require that databases, schemas or both, be manually moved and the application server configured accordingly. Notice that the SQL scripts to create and populate the database and/or schemas are not provided by OutSystems. Also, the application’s source code will have to be changed to make it compliant with the new database engine.