External Core Services Pattern Variations in Practice
When fitting OutSystems in your Enterprise Architecture you’re confronted with the challenge on how to integrate your enterprise data with your OutSystems Application. As described in the Architecture Patterns in OutSystems online training, an Entity from an external system is called an External Core Entity and we can use the External core service pattern to consume the entity. This article explains the External Core Service (ECS) variations with examples.
The external entity may be exposed to OutSystems with the following patterns:
- Extension pattern: Use an extension to wrap an external library or wrap entities from an external database
- Connector pattern: Create a wrapper module for consumers and an extension to encapsulate the external API.
- Service façade pattern: Create a wrapper module for consumers and an integration services module to consume the service.
Introduction to the example
To illustrate the patterns I’ve used a variation of OSMDb that we all know from the how to become a web developer training. Movie data now has it’s source in an external system by ACME that exposes film records through a Films API. We use an integration service (AcmeFilmIS) to consume the Films API.
In OSMDb the concept of a Motion Picture is known as Movie therefore we introduce MovieStruct as part of the OSMDb Canonical Schema (OSMDbSchema). This enables the reuse of the structure for any (future) integrations. To enable service loose coupling the Films API data structure is mapped to MovieStruct.
External core service pattern
The external system provides an integration API that must support all use cases. E.g. CRUD services.
The service façade pattern is used here to provide a wrapper module for consumers. The Films rest methods are mapped to MovieStruct server actions:
Module MovieCS consumes the public actions from FilmIS and exposes server actions that centralize business logic for creation/update.
The advantage of this pattern is the ease of implementation. The drawbacks are that it does not leverage the entity use. E.g. no aggregates, queries, scaffolding etc.
ECS with local replica
The first variation is “create a local replica of the external entity”. This is not an exact copy of the external entity but normalized to the business concept.
In this scenario the MovieCS contains entity Movie that is mapped to MovieStruct. The server actions now act on the Movie entity instead of the MovieStruct.
The MovieSave action now updates both the external data and the Movie
Also the MovieCS now contains a timer and logic to synchronise any changes in the external system to the replica.
ECS with isolated synchronisation logic
Another variation is to isolate the synchronisation logic from the previous pattern.
The advantages of this pattern are:
- Code independence
- Consumers of the CS are not affected by Sync
- Sync can orchestrate several (dependent) CS’s
ECS with direct integration and Publish/Subscribe
When there is a requirement that the data must always be in sync we can use direct integration instead of synchronisation.
In this pattern an API of the replica is build into the external system so that changes can be reflected immediately. When a record is updated in ACME Film the MovieAPI is invoked to update the Movie record.
If an Enterprise Service Bus (ESB) is available this pattern can also be implemented with a publish subscribe mechanism.
The advantage of this pattern is that changes in both the OutSystems Replica as well as in the external entity are always in sync.
Special handling must be provided for the case when a record is deleted in the external system and there exists references to the replica. For more complex data synchronisation issues you can have a look a this https://www.mulesoft.com/resources/esb/top-five-data-integration-patterns article.
Summary and conclusion
Each of the ECS variations described here has it’s advantages and disadvantages. Take careful consideration when selecting the ECS variation that best suits your needs.
