Preparing your OutSystems 11 apps to ODC

If you’ve been using OutSystems recently, you’ve probably heard about ODC. But do you know what to do to prepare for it?

ODC, or OutSystems Developer Cloud, is the next generation of the low-code platform we all love, and as it gains more and more awareness, current O11 (OutSystems 11) customers are planning to migrate their applications to get the most out of it.

However… as ODC is an entirely new product with different architecture and concepts, it means that 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 and thus, we will need to make some efforts to make this happen.

Nevertheless, there is no reason to be alarmed or worried.

Whether you’re planning to move to ODC soon or a year from now, there are a few things we can start or stop doing to make your transition smoother than ever and help us build for the future.

As a friendly reminder, before we delve deeper into this topic, if you don’t already know the main differences between O11 and ODC, I highly suggest you start by reading this and this articles and check out the ODC Training Courses.

This will help you understand the key differences we need to take into consideration in the future, such as:
- Not having modules, only apps;
- Difference between a Library and a normal App;
- Among others…

With all that said, let’s take a look at what we should avoid or start doing to prepare our O11 applications for ODC:

1 — Don’t stop using the Architecture Canvas!

If for some reason, when reading about the main differences between O11 and ODC you had the idea that no more modules meant everything in one app, you might think:

Well… If I’m not going to have modules in ODC, why don’t I stop following best practices regarding splitting my code into the 3-layer canvas in my new O11 apps? This way, as soon as I migrate to ODC, everything will be in a single app and it will be as simple as ctrl+c / ctrl+v.

Makes sense… right?!

No! It really doesn’t! If you are following this line of thinking, stop right there!

You shouldn’t compromise your O11 applications just because you think it will be easier to migrate.

Even worse, you could be making it even more difficult!

The recommendation is to continue following the Architecture Canvas best practices, still dividing your modules into 3 different layers.

This way you will ensure that your applications do not have misconceptions or mixed concepts that may be even more difficult to split in the future.

Additionally, I’m sure OutSystems will provide tools that will help you merge your O11 modules into a single application, so don’t stop following the O11 architecture best practices and keep tracking the architecture findings in AI Mentor.

2 — Consider start using Domain Driven Architecture.

If you are not familiar with Domain Driven Architecture, I recommend you start familiarizing yourself right now!

The concept brought to O11 by 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 practically as Micro-Services, and 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 can 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 I expect is to have a mobile app and a desktop app sharing a common core app.

If this is your scenario, what you could do is have 3 different domains on O11.

• Mobile domain
• Desktop domain
• 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 to have your common UI elements.

3 — Consider reworking your Traditional Web Apps, and keep your technical debt under control!

If you have TWAs (Traditional Web Applications) in your factory, you will have to choose between two options.

The first is to consider turning them into Reactive Applications as soon as possible.
The second is waiting for rewriting them on ODC.

The fact is that ODC will not support TWA, so that means any tools OutSystems makes available to help you migrate from O11 to ODC won’t work for you!

If you want to migrate to ODC but still can’t because ODC doesn’t have all the features you need yet, what you can do is turn your applications into reactive while using O11, which will save you time when the time to migrate comes.

If you don’t want to convert your TWA to reactive while using O11, you can wait for the ODC to meet all your requirements and then rebuild it directly in ODC.

Furthermore, 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.

4 — Consider other integrations protocols other than SOAP

If you still consume or expose SOAP APIs, consider using REST or different protocols.

ODC will still allow you to consume SOAP APIs. It won’t be as easy as O11, as you’ll need to use C# extensions with high code, but you’ll still have an option if absolutely necessary.

Exposing a SOAP API, on the other hand, 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.

5 — 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.

On 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.

In other words, 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, here is a mapping of O11 queries to ODC.

I don’t want to create false expectations, but this is something that could be included as part of an O11 to ODC migration tool in the future, who knows?

6 — Keep an eye on your custom code extensions and Forge components.

Another big difference from O11 to 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 more technical terminology, in O11 each Front End will have 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 is related 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 also a work in progress.

7 — Refactor your core widgets modules if possible

In ODC the way you reuse elements will be a little different from what we are used to.

We currently have only two types of applications that can be created in ODC. App or Library:

The important information about Apps is:

• It can have all kinds of different elements, including Entities.
• Entities can only be exposed as read-only and 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:

A Library is a little different, what you need to know about this type of application is:

• It can contain only some types of elements.
• One of the element types that it can’t contain are Entities.
• A Library can also only consume elements from other Libraries or consume external REST APIs.

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 this link.

Also, take a look at this diagram, which shows how an App and Library interact with each other:

If you understood correctly, you may have already noticed that a Library cannot interact with normal entities.

It can’t have a server action that updates a record, for example.

Libraries should only have reusable UI elements and actions that do not interact directly with the database.

Therefore, 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.

This means that you will, either:

• Need to 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.

This isn’t the ideal solution, but for now it’s all we can do in these scenarios.
We hope that in the future we will have another way to deal with this.

8 — Prepare to change your BPT (Business Process Technology) processes. And your CMF (Case Management Framework) and Workflow Builder use cases.

At this point, it’s still unclear how exactly BPT will work on ODC.

We’ll definitely have something, but it’s more likely to be reworked and work differently than we’re used to in O11, so be prepared to spend some effort changing your code.

The same is true for CMF (Which is built on top of BPT) 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.

9 — Start considering manual referential integrity checks on entities from different modules.

This may seem complex, but let’s try to understand what it means.

In ODC, an App can only expose entities as read-only.

This 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 a microservices architecture, this means that each application will have its own scope.

Due to this, FKs of entities that exist in different apps will not have indexes created and therefore will not be validated.

This means you can create a record in a table and set a value to an FK that doesn’t actually exist in the table you are consuming from the other application.

Or that you can remove a record that is being referenced in another table from a different application and it won’t throw a constraint error.

If you need to ensure data integrity, remember that in the future you may need to manually implement checks to avoid inconsistent data in your database.

And that’s all!

I know it is a significant effort and might take time to prepare your apps to ODC. But if you try to follow all these suggestions from now on, your migration will certainly go more smoothly in the future, and you will be able to start using ODC very soon.

Thank you for reading!

RR