“Dit artikel legt stap-voor-stap uit hoe je verwijzingen kunt maken conform de regels voor de architectuur.”
Bij het inpassen van OutSystems in je Enterprise-architectuur word je geconfronteerd met de uitdaging hoe je de Enterprise data moet integreren in je OutSystems applicatie. Zoals wordt uitgelegd in de online training Architecture Patterns in OutSystems wordt een entiteit van een extern systeem een externe core-entiteit genoemd en kunnen we het External Core Service pattern gebruiken om de entiteit te benutten. Dit artikel bespreekt variaties van de External Core Service (ECS) en geeft voorbeelden.
De externe entiteit kan met de volgende patterns worden blootgesteld aan OutSystems:
Ter illustratie van de patterns heb ik een variant van de OSMDb gebruikt die we allemaal kennen van de training 'How to become a web developer'. De bron van de gegevens van Movies is nu een extern systeem van ACME dat toegang geeft tot filmgegevens via een Films API. We gebruiken een integratieservice (AcmeFilmIS) om de Films API te benutten.
In de OSMDb staat het concept bioscoopfilm bekend als Movie, en daarom introduceren we MovieStruct als onderdeel van het Canonical Schema (OSMDbSchema) van de OSMDb. Hierdoor is hergebruik van de structuur mogelijk voor alle (toekomstige) integraties. Om service loose coupling mogelijk te maken, wordt de datastructuur Films API toegewezen aan MovieStruct.
External Core Service pattern
Het externe systeem voorziet in een integratie-API die alle use cases moet ondersteunen, bijvoorbeeld CRUD services.
Het Service façade pattern wordt hier gebruikt om een wrappermodule beschikbaar te stellen voor consumenten. De REST methoden van de Films API worden toegewezen aan Server Actions van MovieStruct:
De module MovieCS consumeert de publieke acties van de FilmIS en stelt Server Actions bloot die de bedrijfslogica voor creëren/updaten centraliseren.
Het voordeel van dit pattern is het gemak waarmee het kan worden geïmplementeerd. Het nadeel is dat het niet het gebruik van de entiteit ten volle benut. Er zijn bijvoorbeeld geen aggregaten, queries, scaffolding, etc.
De eerste variatie is 'creëer een lokale replica van de externe entiteit'. Dit is niet een exacte kopie van de externe entiteit, maar een kopie die is genormaliseerd naar het bedrijfsconcept.
In dit scenario bevat de MovieCS de entiteit Movie, die is toegewezen aan MovieStruct. De Server Actions zijn nu actief op de entiteit Movie in plaats van op MovieStruct.
De actie MovieSave werkt nu zowel de externe gegevens als de Movie bij.
MovieCS bevat nu bovendien ook een timer en logica voor het synchroniseren van de replica met alle wijzigingen in het externe systeem.
ECS met geïsoleerde synchronisatielogica
Een andere variatie is het isoleren van de synchronisatielogica van het vorige pattern.
De voordelen van dit pattern zijn:
ECS met directe integratie en publiceren/abonneren
Als het een vereiste is dat de gegevens altijd synchroon moeten zijn, kunnen we directe integratie gebruiken in plaats van synchronisatie.
In dit pattern wordt een API van de replica in het externe systeem ingebouwd, waardoor wijzigingen onmiddellijk kunnen worden weergegeven. Wanneer in ACME Film een record wordt bijgewerkt, wordt de Movie API getriggerd om het Movie record bij te werken.
Wanneer een Enterprise Service Bus (ESB) beschikbaar is, kan dit pattern ook worden geïmplementeerd met een mechanisme voor publiceren/abonneren.
Het voordeel van dit pattern is dat wijzigingen in zowel de OutSystems replica als de externe entiteit altijd synchroon lopen.
Een speciale verwerking is nodig als in het externe systeem een record wordt verwijderd en er verwijzingen naar de replica bestaan. Voor complexere problemen met synchronisatie van gegevens kun je dit artikel lezen:
https://www.mulesoft.com/resources/esb/top-five-data-integration-patterns.
Alle ECS variaties die hier zijn omschreven hebben hun voor- en nadelen. Denk er goed over na en kies de ECS variatie die het beste past bij je behoeften.
Verwijzingen:
[Met dank aan: Jaacov de Leeuw en Jorge Martins.]
Blockchain technologie krijgt – na de financiële wereld – de komende jaren veel invloed op onze manier van leven en werken. Steeds meer nieuwe blockchain toepassingen worden al zichtbaar. Vooral de organisatorische implementatie is nog een uitdaging.
Door de hoge druk op onderhoud van bestaande systemen komen veel IT-afdelingen nauwelijks toe aan strategisch belangrijker taken, zoals innovatie en creatieve projecten voor het moderniseren van bedrijfsprocessen.Dat blijkt uit recent Amerikaans onderzoek, dat ook voor Nederlandse IT-afdelingen heel herkenbaar is. Dagelijks terugkerende taken lijken steeds zwaarder te wegen en gaan ten koste van het strategisch innoveren van IT-processen voor de langere termijn. Maar uiteindelijk heeft dát meer rendement voor de business. Hoe komt een IT-afdeling uit deze spagaat?
Volg ons
