Hi,
I’ve just started prototyping Corteza on a local instance, connecting the application to an existing POSTGRESQL database.
I’m still getting the hang of many things, and I’ll indubitably have further questions, but what I’ve seen so far is really great, and super accessible, speaking as a non developer with a bit of technical appreciation and some SQL knowledge.
One thing that’s could be pretty key for what we’re doing is to be able to centralise and reference data that comes from other data sources, (i.e. not input using a low code CRM solution).
How can I make it so I can read that data and in order to exploit it and create dashboards or interaction based on that data?
The low code solution seems to rely on data tables created BY the low code solution, and with data sources input or imported USING the low code solution. I can’t look up my existing tables to integrate functions.
Any help or pointers would be welcome!
Thanks! 
I’ll update myself on this one for the benefit of others who may have a similar question.
Corteza creates a number of its own data tables in its Corteza instance in POSTGRE. These store the users, roles, modules, and the contents of the modules.
But the tables that we’re creating within the low code app are rather cleverly designed as tables WITHIN tables, using a master recordid or delimiter values to link data that we created in separate modules and actually store them in a single master table. It’s pretty funky, but suddenly clear what the challenge would be.
The data standard for a native postgre table is not the same as the data standard in our modules. When i posted last week I didn’t yet have access to the postgre tables and couldn’t see this structure set up.
So my guess, if I still wanted to do something like this, is that to integrate existing data sources into Corteza I’d first need to create the module “containers” to store the data I want to use, and then I’d need to run an agent to convert data from native postgre tables into the Corteza “compose container”, with appropriate delimiters, and at a refresh frequency that is appropriate.
The low code solution includes an iFrame function and a separate MI database may be a better way to read and present data. I kind of wanted to benefit from some of the cool charting functionality with existing read only sources, but an alternative option could be to design them using another tool and integrate them into a low code app as an iframe result.
Not sure if that made sense, but perhaps it helps other people looking at corteza too!
2 Likes