If you’ve been using OutSystems recently, you’ve probably heard about ODC. But do you know what to do to prepare for it?
OutSystems Developer Cloud (ODC) is the next generation of the low-code platform we all love. As it gains more awareness, current OutSystems 11 (O11) customers are planning to migrate their applications to ODC to realise the many benefits it has to offer.
However, since ODC is an entirely new product with different architecture and concepts, migrating your applications from O11 to ODC may not be as easy as the ‘1-Click Publish’ we are used to in the current version.
Nevertheless, there is no reason to be alarmed or worried. There are simple steps you can take to prepare your O11 applications for ODC and ensure your transition runs smoothly.
If you don’t already know the main differences between O11 and ODC, a good place to start is to read the following articles:
We also recommend that you check out the following ODC Training Courses.
These articles and courses will help you understand the key differences between O11 and ODC, which include:
- Having apps only, instead of modules
- Having only two types of applications – App or Library.
Let’s take a look at the additional things you can do to help prepare your O11 applications for ODC:
1. Continue using the Architecture Canvas
When reading about the main differences between O11 and ODC you might assume that no more modules with everything in one app means you no longer have to split your code into the 3-layer canvas in your new O11 apps. You might think this will make migrating to ODC simpler. But this presumption is misleading.
In fact, discarding the conventional 3-layer canvas structure could potentially complicate the migration to ODC. For a smoother transition, please continue following the Architecture Canvas best practices, which requires you to divide your modules into 3 different layers and continue to keep track of the architecture findings in AI Mentor.
OutSystems will provide tools that will help you merge your O11 modules into a single application.
2. Start using Domain Driven Architecture
If you are unfamiliar with Domain Driven Architecture, we recommend you start familiarising yourself with it as soon as possible. This type of architecture is very much in line with the ODC architecture.
In ODC, different applications communicate with each other using ‘Service Actions’. ‘Service Actions’, unlike ‘Server Actions’, are executed in a different transaction having their own context and scope – they are basically REST API calls that you can easily use on the platform. This means that in ODC you will need to handle your reusable services similar to microservices. If you can start doing this already in O11 by applying a Domain Driven Architecture, it means that your journey to ODC will be halfway there.
If you successfully define your different domains in O11 based on different sponsors and lifecycles, this means they will likely map to your new applications when using ODC. A very common scenario would see a mobile app and a desktop app sharing a common core app. In this case, you could have 3 different domains on O11: a mobile domain, a desktop domain and a core service domain. In O11, you can still have multiple modules and applications in each domain. But when migrating to ODC, you will probably have 3 Apps, one for each domain, and more than one Library for your common UI elements.
3. Consider reworking your Traditional Web Apps
ODC will not support Traditional Web Applications (TWAs), so if you have these applications, any tools OutSystems provides to help you migrate from O11 to ODC won’t work for you. You will need to transition away from these applications if you wish to use ODC.
If you have TWAs you have two options:
- Consider turning them into Reactive Applications as soon as possible. This will save time when you are ready to migrate to ODC. OR/
- Wait and rewrite them once you’ve migrated to ODC.
4. Try to keep your technical debt under control
Work to reduce your technical debt as much as possible by using AI Mentor to track your findings. This will ensure that your application follows best practices and you can migrate without any major problems.
5. Consider other integrations protocols besides SOAP
If you still consume or expose SOAP APIs, consider using REST or different protocols. ODC will still allow you to consume SOAP APIs, however, it won’t be as easy as O11. If you go down this path, you will need to use C# extensions with high code. It’s not ideal, but it’s a backup option if absolutely necessary.
Exposing SOAP APIs is not a top priority for ODC going forward, so if you hope to migrate sooner rather than later, focus on changing your SOAP APIs as quickly as possible.
6. Keep an eye on your advanced SQL queries
In O11, you can choose to use SQL Server, Azure SQL Database, Oracle, or DB2 as the database for your applications. However, in ODC, your applications will be required to use AWS Aurora PostgreSQL. While SQL Server and the older options are relational databases, AWS Aurora PostgreSQL is an object-relational database. This means that in ODC you can build SQL queries with complex data types and object inheritance and will inevitably use different syntax. If you use a lot of advanced SQL queries, you may run into some problems, especially if you are using Oracle or DB2.
To help you understand the differences you will face, OutSystems has mapped out O11 queries to ODC.
7. Keep an eye on your custom code extensions and Forge components
Another big difference between O11 and ODC, is the way custom code extensions (.xif) will work.
In ODC, all your custom code extensions (like C#) will run using AWS Lambda. This means that your code will run in a serverless service, which will be accessed through a REST API, and not in your application container. In other words, your custom code will follow the principle of FaaS (Function as a Service).
This is different from O11 where your code was hosted and executed directly on the server where your code was also running.
In O11, each front end has a version of your customized C# code running on its application server (IIS). This makes it possible to change the front end configuration programmatically, for example, and even create a static object that can be reused for different requests.
In ODC, your code will be executed as a serverless function and, therefore, after the request the entire context will be discarded. This also means that you cannot programmatically change anything in your application’s container as it is running in a different scope. If you have any extensions that access server resources or need extreme performance with low latencies, you will need to rethink how things are done.
Another important point to keep in mind relates to the different forge components you use. As ODC is a new platform, don’t expect to find all of the Forge components already there. Migrating all O11 components to ODC is a work in progress also.
8. Refactor your core widgets modules if possible
In ODC, the way you reuse elements will be a little different to what you are used to.
There are only two types of applications that can be created in ODC – App and Library.
Important information about Apps:
- An App can have all kinds of different elements, including Entities.
- Entities can be exposed as read-only. If you need to update a record in an entity you will need to do so by exposing a Service Action with the logic to update your record.
- Although Apps can have web blocks, they cannot be exposed as public.
Here are the different types of elements an App can have:
Important information about Libraries:
- A Library can contain only certain types of elements.
- One element type a Library cannot contain is Entities.
- A Library cannot interact with normal Entities. For example, it cannot have a Server Action that updates a record.
- A Library can only consume elements from other Libraries or consume external REST APIs.
- A Library should only have reusable UI elements and actions that do not interact directly with the database.
Here are the different types of elements a Library can have:
For a more detailed look at what types of elements can be public or exposed in each type of App, check out OutSystems Guide to Reusing Elements Across Apps.
Also, take a look at this diagram, which shows how an App and Library interact with each other:
If your Core Widgets modules – which are supposed to be reusable – have actions that use database entities, you will not be able to turn them into Libraries in ODC, and you will not be able to reuse the web blocks in different applications.
In this case, you have two options:
- Refactor your blocks to remove database dependencies and trigger events for the consuming App to handle database operations OR/
- Move the blocks into your App and, if they need to be reused, duplicate the code.
We hope that in the future there will be a better way to deal with this scenario.
9. Prepare to change your BPT processes, CMF and Workflow Builder use cases
At this point, it’s unclear exactly how Business Process Technology (BPT) processes will work in ODC, however, it’s likely to be different to how they are handled in O11. So be prepared to spend some effort changing your code.
The same is true for Case Management Frameworks (CMF) and Workflow Builder. They will probably be rebuilt and have major changes. If you use a lot of BPTs, keep an eye on announcements so you can react as quickly as possible.
10. Consider manual referential integrity checks on Entities from different modules
In ODC, an App can expose entities as read-only. An Entity can be consumed by another App and even be used to create a Foreign Key in another table. However, because ODC is designed to use microservices architecture, each App will have its own scope. Accordingly, Foreign Keys of Entities that exist in different Apps will not have indexes created and, therefore, will not be validated. This means it’s possible to create a record in a table and set a value to a Foreign Key that doesn’t actually exist in the table you are consuming from the other App. Also, you could remove a record that is being referenced in another table from a different App and it won’t throw a constraint error.
In future, if you need to ensure data integrity, remember that you may need to manually implement checks to avoid inconsistent data in your database.
Conclusion
It’s a lot to take in, but if you follow these suggestions, your migration from O11 to ODC will go more smoothly and you will be able to start leveraging the benefis of ODC sooner.
About the author
Raphael Ranieri, Tech Lead | OutSystems MVP
Raphael graduated in Computer Science from ‘Universidade Presbiteriana Mackenzie’ in 2014. Originally from Brazil, he moved to Australia in 2022 to work specifically with the OutSystems platform. With 12 years of experience in IT, 8 with OutSystems alone and 6 as a Tech Lead, he is always looking for challenges. He has a keen interest in Architecture, Reusability and Processes with the platform.
This article was originally published on Medium.
