Things I learned at the Outsystems Advanced bootcamp

The Outsystems Advanced bootcamp is a deep dive in the entire Outsystems ecosystem. In the past week I attended it at Transfer Solutions. It has been a great learning experience, ranging from small tips to best practices and more conceptual topics. I’m happy to share a few with you.

This was originally posted at my own blog. Feel free to check it :).

Avoid monolithic architectures

A great deal of the bootcamp deals with the architecture of Outsystems environments. Makes sense, since a good architecture will help keep your development pace on par. As your environment grows, you might be able to group common subjects into domains. For example, we can group our sales related applications into a Commercial domain. In Lifetime you can group applications, and assign them to different teams. If you’re developing in a common core or foundation module, splitting your environment into parts will avoid impacting your whole factory. On the flipside, this type of architecture may lead to duplicate data and logic. When working with dependencies across domains, you can use service actions. This is similar to an server action, but uses an REST interface. This means you won’t have to refresh your dependencies when making a non-breaking change. I like that, but it can be a fallacy too. You won’t be alerted for outdated dependencies, so you will have to figure this out yourselves.

An aggregate may be better than a reusable action

As with your factory architecture, it’s best to consider between reusability and performance on a screen level. When working with aggregates, Outsystems only retrieves the columns you’re using from the database. But when you’re assigning the full list as output of a server action, it will retrieve everything from the database.

So avoid using a server action to retrieve your data on a screen, since you rarely use everything. I’m using scaffolding often, so the extra work is neglectable.

Integrate using Integration Studio

Service Studio offers a lot of functionality when consuming and exposing REST / SOAP API’s. But if not adequate, you can write your own integration plugin in .NET. Use cases might include custom cyphering and authentication. This is something that’s entirely new to me, but probably something I won’t need to do since the Forge is offering plugins to handle most use cases.

Avoid timeouts in timers

Timers are a great way to handle batch processing. This is one of the biggest subjects at the Outsystems Traditional Professional exam, the exam that is following up on the bootcamp. So naturally we did get a few best practices for timers. I’m sharing one of the best patterns with you, the self-restarting timer. This timer pattern sets a timeout and checks it within the loop. This timeout will often be 10 minutes, which is safely below the standard 20 minute timeout of timers. After exceeding the time limit, the time will restart itself using the WakeTimer node. You will need to implement functionality to keep track of the processed batches, but this way you’ll never run in a timeout.

The coming two weeks I’ll be busy reading documentation for the Professional Traditional Web Developer exam. This exam is said to be quite difficult, so hopefully I will have some time left to enjoy the beautiful spring weather in the Netherlands now!