OutSystems Developer Cloud – verschillen met OutSystems 11

Eind 2022 heeft OutSystems Project Neo omgedoopt in OutSystems Developer Cloud (verder te noemen ODC). Dit is een platform in de cloud dat Kubernetes, Linux containers en microservers ondersteunt, en is gebaseerd op het fundament van Amazon Web Services (AWS) native cloud services.

In dit artikel ga ik in op een aantal verschillen tussen ODC en OutSystems 11 (verder te noemen OS11). Deze informatie is ook te vinden op de OutSystems site onder trainingen en dan From O11 to OutSystems Developer Cloud. Ongetwijfeld zijn er meer verschillen, maar dit zijn degene waar ik mijn aandacht tot nu toe op heb gericht.

Opmerking: Voor ODC kun je nog geen permanente persoonlijke omgeving aanmaken. Wel kun je het een beperkte tijd uitproberen.

Nieuwe termen

Allereerst wat nieuwe termen die bij ODC zijn geïntroduceerd.

OS11	ODC
Infrastructure	Organization	In OutSystems 11 wordt dit ook wel factory genoemd.
Environment	Stage	Gebruikelijke omgevingen/stages zijn, Ontwikkel, Test en Productie.
Module	Niet aanwezig	Modules bestaat niet in ODC, alleen Web Apps en Libraries.
IT user	Organization user	Gebruiker met toegang tot het ODC Portal en ODC Studio (IDE).
Site property	Setting	Settings zijn vergelijkbaar met Site Properties in OS11 en kunnen gemarkeerd worden als Secret.
Version	Revision	Bij publicatie van een app of library creëert ODC een nieuwe revision. Vorige revisions zijn te openen in ODC Studio en te deployen.

Apps en Libraries

In ODC is het mogelijk om Web Apps en Libraries te maken. Web Apps zijn vergelijkbaar met Reactive Web Modules in OS11. Libraries zijn ongeveer gelijk aan de Service Modules in OS11. Het concept Module bestaat niet meer in ODC, alleen Apps en Libraries.

ODC promote het concept van Library als een “First-class Citizen”. Het geeft je de mogelijkheid om herbruikbare elementen te maken en in te sluiten.

Data

Database Server – In ODC wordt Aurora PostgreSQL gebruikt.

Aggregates – Blijft in principe hetzelfde, alleen de onderliggende database is anders. OutSystems raadt aan om Aggregates in plaats van SQL queries te gebruiken.

SQL Queries – Als je zelf queries schrijft, doet dit dan voor Aurora PostgreSQL (zie migratie “Playbook” van AWS). Hieronder een paar voorbeelden van veel gebruikte queries.

	OS11 (SQL Server)	ODC (Aurora PostgreSQL)
SELECT	SELECT * FROM {Employee}	SELECT {Employee}.* FROM {Employee}
INSERT	INSERT INTO {Employee} ({Employee}.[Name]) VALUES (“John Smith”)	INSERT INTO {Employee} ([Name]) VALUES (“John Smith”)
UPDATE	UPDATE {Employee} SET {Employee}.[Name] = “John Smith” WHERE {Employee}.[Id] = 2	UPDATE {Employee} SET [Name] = “John Smith” WHERE {Employee}.[Id] = 2
LIKE	… WHERE {Employee}.[Name] LIKE “%John%”	… WHERE caseaccent_normalize( {Employee}.[Name] collate “default” ) LIKE caseaccent_normalize( “%John%” )
TOP/LIMIT	SELECT TOP 10 {Employee}.* FROM {Employee}	SELECT {Employee}.* FROM {Employee} LIMIT 10
Concatenate text	… WHERE {Employee}.[Name] = “First” + “Last”	… WHERE {Employee}.[Name] = “First” \|\| “Last”
Random records	SELECT {Employee}.* FROM {Employee} ORDER BY NEWID()	SELECT {Employee}.* FROM {Employee} ORDER BY RANDOM()
Compare Time data types	… WHERE {Entity}.[Time] > “11:01:41”	… WHERE {Entity}.[Time]::time > “11:01:41”

Static Entities – Afhankelijk van waar de Static Entity is gemaakt, is deze qua gedrag anders. Is de Static Entity gemaakt in een Web App, dan is deze gekoppeld aan een database tabel, soortgelijk in OS11. Als je een Static Entity maakt in een Library dan bestaat de gelinkte database tabel niet. In plaats daarvan fungeert deze als een enumerator. In beide gevallen kun je de Static Entity gebruiken in Aggregates en SQL queries.

Identifiers in Static Entities – In OS11 heb je de mogelijkheid om Auto Number te gebruiken. Dit is niet beschikbaar in ODC. Nu moet je een Identifier-waarde specificeren wanneer je een Static Entity maakt. ODC Studio wijst automatisch een ID toe die je desgewenst kunt aanpassen. Deze manier voorkomt mogelijke problemen met data management, waar het hetzelfde record een andere identifier heeft in verschillende omgevingen van OS11.

Gebruikers en Rollen

Isolation – Rollen zijn gedefinieerd in een app en kunnen niet naar Public gewijzigd worden.
Om te controleren of een gebruiker een specifieke rol heeft, of om een rol toe te wijzen of in te trekken, kun je een wrapper maken voor de gewenste functionaliteiten d.m.v. Service Actions. Een aanbevolen manier, om de impact van runtime performance te reduceren, is om een rol met dezelfde naam te maken in meerdere apps, om vervolgens in ODC deze rollen toe te wijzen aan de gebruikers.

Grant Roles – In ODC kun je een nieuwe rol, nadat een rol is aangemaakt in ODC Studio en een app is gepublished, toewijzen aan de gebruikers in ODC Portal. Hiervoor dien je “organization administrator” te zijn. In OS11 werd dit uitgevoerd in de Users app.

Zie ook:
– Reuse elements across apps
– Secure your app with end-user roles

Portal / consoles

Unified Portal – Als administrator gebruik je ODC Portal om alles te beheren. In OS11 heb je LifeTime om het infrastructuur te beheren, Service Center om een omgeving te beheren en zelfs een Users app voor het standaard gebruikers beheer. Met ODC Portal is alles dus gecentraliseerd. Vanuit hier kun je de diverse omgevingen beheren, alsmede deployments, applicaties, configuraties en de gebruikers met hun permissies. Tevens kun je de applicatie-logs analyseren.

Forge – De Forge is in ODC Portal geïntegreerd. Vanuit hier kan je applicaties vanuit de Forge rechtstreeks installeren in de ontwikkelomgeving.

Gebruikersbeheer

Organization User – ODC heeft 1 type gebruiker, de Organization User; er is geen verschil tussen eind gebruikers en IT gebruikers. Een Organization User heeft bepaalde permissies om toegang te krijgen (of niet) tot het organization account in de ODC Portal alsmede permissies om apps te gebruiken door middel van de toegewezen rollen.

Deployments

Onafhankelijk – Elke app word onafhankelijk gedeployed in ODC. Voordat deployment plaatsvindt, zal de impactanalyse de afhankelijkheden controleren met andere apps, zodat er geen afhankelijkheden missen op de doelomgeving.

Snelheid – Een app deployen in ODC duurt enkele seconden. Wanneer de container met de app gedeployed wordt naar een andere omgeving, wordt de app niet opnieuw gecompileerd wat het proces versnelt.

Gelijktijdigheid – Het is mogelijk om deployments van meerdere apps gelijktijdig te starten. Dit geeft gebruikers de mogelijkheid om hun apps naar de gewenste omgeving te brengen zonder dat er gewacht wordt op andere deployments of dat andere gebruikers hier last van hebben.

Libraries – Het is niet mogelijk om Libraries te deployen. Een library wordt bij een app container gevoegd en deze container wordt dan naar de doel omgeving gedeployed.

Configuration

Settings – In ODC zijn de Site Properties vervangen door Settings. Het is niet mogelijk om de Settings programmeerbaar te wijzigen d.m.v. bijv. een Assign. De waarde van een Setting kan via het ODC Portal gewijzigd worden, in de app configuratie waar deze gedefinieerd is en rechtstreeks via ODC Studio tijdens het ontwikkelen.
Belangrijk om te weten is dat een Setting die gedefinieerd is in een Library, in elke app die deze library gebruikt onafhankelijk gewijzigd kan worden.
Wanneer je Settings met Site Properties vergelijkt dan heeft Settings een additionele eigenschap die Is Secret genoemd wordt. Dit kan je gebruiken om gevoelige informatie te beschermen, zoals bijv. wachtwoorden of API Sleutels.

Monitoring

Logs – Alle Logs zijn gecentraliseerd in ODC, in de Logs sectie binnen de Monitoring tab. Logs kunnen gefilterd worden d.m.v. ernst (errors, warnings of information). Dit biedt de mogelijkheid om alle logs van iedere omgeving op 1 plek te controleren. Filtering op app is mogelijk.

Activities – Activity types (bijv. client actions) worden nu gelogd onder de Activity Tab. Je kunt filteren op activity type en van iedere component de performance controleren en begrijpen.