external DB users  - how do you organize your extensions/modules?

Over the past year we have built a handful of apps that all use APIs to interface with the core enterprise database.  Some of the apps store data for internal business logic, but for the most part CRUD operations are performed against the database via APIs.  As you might imagine, this has been a huge bottleneck for the OutSystems team, and we have finally gotten the go-ahead to interface directly with the database - very exciting!  But now I'm faced with the task of architecting those interfaces, and I'm curious how other folks have handled that.  

We have a handful of entities that are common to most apps but generally our apps are specialized and will use tables and views that aren't used elsewhere.  If you're integrating with a very large database, do you keep all the entities in a single extension?  Do you group them in multiple extensions, with a single service module as an interface for your application IS/CS modules?  Or do you give each application its own BL -> CS -> IS -> DB extension pattern?

Curious to hear what kind of successes and failures the community has experienced, maybe you can save us some painful lessons down the road!

mvp_badge
MVP

Hello Douglas,

Most of my team's current projects require using data in external databases, so we resort to Extensions. My advice would be to not centralize everything into a single extension. The goal when grouping concepts within modules is two-fold: to make it easier to find specific components of your applications, and to minimize the impact when changes occur.

If you have multiple applications consuming data from a single module, they'll have to be published if you apply any changes to the module, even if those changes don't directly impact them all - otherwise your environment will be riddled with outdated references. This is why you should identify key concepts of the Tables you'll be representing in the Extension. Instead of using them to represent a database, you should use them to represent the underlying business concept of a set of Tables of the database and then split them into Extensions. This way, a change to a set of Entities will only impact the set of applications that rely on those Entities, and not all the consumers of that module. As your environment grows, it's very important to stay aware of the overall state of your references - monolithical modules can become very burdensome on your development and your application pushes to other environments.

Regarding the surrounding modules, I find that it depends on a few things, namely what sort of interactions you'll be implementing for that data. If all you need is a read-only model, you could just directly consume the Extensions where the data needs to be presented. If you need to write data, then a Core module would be sufficient to hold your CRUD actions. If you're going to have specific business logic, a BL module makes sense, but you should take note whether the business logic is related to the concept being represented within the Extension, or if it belongs to the actual application that relies on that data.

One thing to keep in mind of is that as far as I know, there's no way to set Extension Entities as read-only, like regular module Entities - so if you're planning on writing data to those Entities, it's important to keep an eye out on any references that are not of the Core module - while these may be benign references to read the data, they might also be used to write data with the default CRUD actions.

Thanks so much for your response, that's exactly what I was looking for!

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.