Deze week kondigde OutSystems een volledig vernieuwde editie van haar Low Code platform aan onder de naam Project Neo. Het nieuwe platform biedt nog meer mogelijkheden om in korte tijd hoogwaardige oplossingen te bouwen. Hoogwaardig vanuit zowel functioneel (business) perspectief als vanuit technisch perspectief. OutSystems maakt dit alles mogelijk door optimaal gebruik van een onderliggende Cloud infrastructuur, en slimme manieren om software ontwikkeling te ondersteunen.

Wij kunnen ons voorstellen dat u vragen heeft n.a.v. de sessies van Nextstep, of dat u graag wilt weten welke gevolgen de introductie van dit nieuwe platform heeft voor uw bestaande OutSystems omgeving. Daarom hieronder enkele punten die wij graag kort toelichten.

Een centraal punt voor alle diensten

Het huidige OutSystems platform 11 heeft verschillende tools voor het ontwikkelen, onderhouden en releasen van uw OutSystems applicatie (o.a. een zgn. IDE, Integrated Development Environment). Met project Neo, krijgt u één centrale omgeving waarin alle informatie rondom het ontwikkelen en beheren van uw applicatie samen komt. De developer hoeft niet meer te zoeken naar de juiste informatie, maar overziet alles in een overzichtelijk dashboard. Dat is handig voor de ervaren ontwikkelaar, maar vooral ook voor ontwikkelaars die het OutSystems platform nog niet kennen. OutSystems besteedt aandacht aan de technische kwaliteit van applicaties, vooral om “technical debt” te verminderen en zelfs te voorkomen. Technical debt ontstaat vaak doordat applicaties voortdurend moeten worden aangepast aan nieuwe business wensen – iets wat juist vanuit het “agile” gedachtengoed aangemoedigd wordt door OutSystems. De meeste bedrijven hebben continu te maken met verandering, en daardoor met verandering van hun systemen waardoor ze een hoog risico lopen op technical debt.

Volledig Cloud based

Met project Neo zet OutSystems een belangrijke stap richting een volledig Cloud based Low Code platform. De gehele onderliggende architectuur van deze nieuwe editie zal op basis van container technologie als Platform as a Service (PaaS) worden aangeboden. U krijgt met het nieuwe platform direct alle voordelen van een Cloudoplossing in huis waaronder: automatisch schalen van resources op basis van gebruik, het scheiden van development en run-time applicaties over verschillende geografische locaties, lichtgewicht applicatie overhead, hoge beschikbaarheid en robuustheid.

OutSystems 11

Project Neo en OutSystems 11 zijn twee gescheiden edities van het platform. Nieuwe functionaliteit zal op beide edities beschikbaar komen en OutSystems 11 zal ook ondersteund blijven worden. U hoeft zich dus geen zorgen te maken als u gebruik wilt blijven maken van een on-premise OutSystems 11 omgeving.

Public Early Access Program (EAP)

Bent u geïnteresseerd in de mogelijkheden van project Neo? In december 2021 start OutSystems met het Early Access Program rondom project Neo. Wilt u de voordelen benutten die dit nieuwe platform te bieden heeft, neem dan contact met ons op, wij helpen u graag met uw EAP aanmelding.

At this years Next Step OutSystems CEO Paulo Rosado announced an improved version of LifeTime. This improved version is necessary because OutSystems customers are developing at the speed of light and after some time they will have very large portfolios of applications. This results in the staging of applications from one environment to another taking too long. But even with this improved staging optimization, how can you manage all your applications in LifeTime?
Lets first take a few steps back, what is LifeTime?

LifeTime is a unified console with visibility of all the environments on the same OutSystems infrastructure. It manages the deployment of applications, IT Users, and security across all environments

OutSystems LifeTime
Of course, with this definition you know everything you will need to know… or maybe not? The complete documentation for LifeTime can be found at: OuySystems DOCUMENTATION and should be something that your IT infrastructure or Cloud manager should read!

It’s all about working consistently and accurately!

Let’s focus on the application part of LifeTime and how we can manage this. The problem that many companies that I visit face is that multiple developers use LifeTime and there are no common agreements. The tagging (versions) of applications is random and an application that is already in production has version 0.152 for some reason. Forge components aren’t tagged and are changed without comments to the original code. The result: LifeTime is a mess and the probability of errors is very high. But how can we fix this? Working in LifeTime is all about working consistently and accurately. Rules or common agreements should be agreed upon between all the development teams before the first application goes to the next environment.

Creating these common agreements about how to use LifeTime is very personal and will probably vary from company to company. But let me just point out a few tips from my experience.

Forge components in LifeTime
When installing forge components immediately tag the components in LifeTime with the same version as the installed forge component. After installing forge components the connection between your local version and the version in the forge is broken. So if the developers of the component come up with a new version in the forge you can now easily check if you should upgrade or not.

Tagging in LifeTime
You can tag your applications in the following format: M.m.r (Major.Minor.Revision).
The major position is something that will be different in each project. Usually you use version 1.0.0 when going to production for the first time. When should you go to version 2.0.0? It’s up to you, but normally this is done when you have really new functionality in your application.

OutSystems is usually used in combination with an Agile method like Scrum. Using the iteration or sprint number in the tag is a good way to connect you application version to the sprint. The minor (m) could be your current sprint (like sprint number 14) so before production when you start sprint number 14 your application tag would be 0.14.0

The revision position can be used as an ascending number within your sprint. Probably you want to deploy to test multiple times, or you want to tag your application every time you have finished one particular user story. Example your application is already in production and you are currently in sprint number 11 your tag could be: 1.11.6

Keep it clean
There are a bazillion different other ways to keep your LifeTime clean like:

• Start every test application with TEST_xxx so they are grouped together or create one big test application. You probably you don’t want to stage those application to the next environment.
• Remove old Test applications
• Create application logos. These are especially important for mobile apps, because this will be the logo for you native app, but for web applications these logos can be used for you as a developer to differentiate between the hundreds of applications you have installed in your development environment.
• Don’t use abbreviations in your application name.

And you can probably think of many more.

Remember you and your team are the ones that can make a total mess of LifeTime or create nice stress-free environments where we all would be happy. Do you have some other useful tips or tricks that you use to manage your LifeTime, let me know!

 

[1] This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated.

Last couple of months I had the pleasure to introduce several of our customers to the OutSystems Platform [1]. OutSystems provides a low-code rapid application development and delivery platform that enables seamless integration of custom code. It combines speed with custom coding for the best of both worlds.

Often there is a big question mark about the license structure of OutSystems. In this blog I would like to tell you a little bit more about the OutSystems license structure and what you as a developer should keep in mind. This will result in a efficient license and a cleaner application architecture.

In an OutSystems License there are 2 major factors that determine your license fee[2]:

• The number of “Active Named Users”. In other words the total amount of users in the OutSystems User application.
• And the number of Application Objects.

The easiest way to monitor this is to look at the license page in Service Center, you can find this at: <OutSystems Environment>/ServiceCenter/Environment_Configuration. (jsf/aspx) under the link “Licensing”.

The number of users is fairly straight forward, but what is an Application Object (AO)?

If you look at the description from OutSystems it states: “all Entities, Screens and Integrations count for 1 AO”. With this you could roughly count how many AO’s your application will cost. But for all you techies I will give you a little bit more specifics about what count and what doesn’t count as an Application Object.

So OutSystems divides its IDE tool and platform into 4 categories:

Data

In this category you can find everything related to the data structure and resources of your application. Every (static) entity that you make will count as 1 AO. An (static) entity correlates with an database table inside the OutSystems database. So in other words you could say that every table your application requires, will count as 1.

Everything else (Entity Diagrams, Structures, Session/Site variables and recourses) in this category is “free” and will not count towards your Application Object maximum. If you reuse entities from other eSpaces or extension they will count as Application Objects in their original module.

Logic

Creating (user) actions, roles, or exceptions will not count as AO’s. A good level of granularity in your actions can make your module better maintainable and supports the reuse in other modules. So don’t try to make one big action that supports all cases.

Consuming or exposing web services will count as AO’s because these services are integrations. Keep in mind that OutSystems counts the service methods and not the services. For example: if you expose 1 Service with 3 Service methods it will count as: 3 AO’s. The same rule is applied when consuming services each method you consume will count as 1 AO.

Interface

This category is straightforward: 1 AO for each screen and each email template you create. Reusable parts of a screen (webblocks) will not count on their own. A small thing worth mentioning: Multilingual Locales are also free from the AO count. So you could make your application Multi-language in as many locales if you want.

Processes

In this fourth and last category you have the opportunity to make (batch) timers and processes. Both will not count towards your application object maximum.

A good architecture and clean way of working will result in an optimal use of Application Objects. This holds for example for the use of tables (do you really need them) and the use of applications from the Forge.

If you reach the maximum application objects you cannot longer publish any modules that contain new application objects.

In conclusion, as a developer be aware of how many Application Objects the module you are developing and optimize your application if necessary. This will not only give you room to develop more great applications but also helps you to make your module as lean as possible. A lean module will support the reusability and maintainability of you application!

[1] OutSystems overview & education by Transfer Education.

[2] Over time OutSystems license terms and conditions may be subject to change.  Please contact OutSystems or Transfer Solutions for the latest information with regard to OutSystems licenses.