Kevin Malone from The Office, probably
The Problem
So… you are being tasked with building a Mendix application where you need to be able to generate a large amount of data across many objects. Your domain model is a spiderweb of entities and associations, your microflows are starting to look like a multigenerational family tree, and updating any new parameters down the road feels like a daunting task. You could probably benefit from a system that can handle the configuration and generation of everything all at once!
Meet my good friend, the Reference Key!
One Entity? Enlighten Me!
One thing to understand first about the Reference Key is that it is not the same for everyone. It’s extremely loyal, follows the rules, and can be told to do anything with perfect understanding of the desired outcomes. You will need to use the Reference Key in unique ways depending on your situation, however the process and outcomes are largely the same.
With a reference key entity in your application, you have the freedom to set up everything possible beforehand, and any changes in the future require no additional development. If the application demands a new object to be triggered from a complex selection of entities, simply add an association from that object to the desired reference key
Are you still listening? Trust me, keep reading! It will all make more sense in about 3 minutes.
The Solution
Let’s start with an example: You are a construction manager starting a project to build a new skyscraper in NYC. You need to configure and generate a project that contains all of the required applications to construct this building. Each of these applications can be triggered by selecting some combination of services. You have been provided a comprehensive list of all combinations of services and applications, but there are a TON of if/then constraints for something being included or not.
If the agency of the service is this, and the job type is that, then the application is this and that… if the agency is this and the job type is the other that…
You get the point… Don’t start building a behemoth microflow that uses decision splits and rules to handle directing all of this logic traffic. Set up something on the backend that can perfectly execute everything with simple instructions.
The domain model above shows a basic reference key setup. We have Reference Key objects in the database that point to each of the agency, jobtype, and worktype entities. At runtime we configure a Reference Key for every combination of those 3 items. These are our core reference items, there can only ever be a single reference key for any combination of the 3 determining entities. Each unique combination will be added to the database during runtime for access during user workflows.
ReferenceKey1 — Agency:NYC, JobType:New Building, WorkType:Foundation
ReferenceKey2 — Agency:NYC, JobType:New Building, WorkType:Structural
ReferenceKey3 — Agency:NYC, JobType:Alteration, WorkType:Plumbing
ReferenceKey4— Agency:Transit, JobType:Garage, WorkType:Lighting
Now when we select 10 services for this project, these services can already be linked to their respective reference keys at runtime (via an import or manual entry), giving us a single point of reference for any other object in the database such as applications or requirements.
At this point you have a base structure for configuring a single point of entry for all reference entities in the entire application that use the reference key associated items (Agency, JobType, WorkType). This saves you the trouble of having to have an association to these 3 entities from every entity in the app. You also have a very simple database retrieve to get the related objects.
The list of reference keys from the services on this project allows you to iterate through and retrieve any linked objects to create an inclusion of these for this specific project, applications in this example. Repeat this with any reference entity in the database to build out an entire project from the single reference key entity. The only lift from a development standpoint from here is setting up the retrieve or create logic on save of the project for each entity that has a relationship to the entities the reference key uses.
How About a tldr?
If you find yourself building a TON of associations to the same reference tables, consider using a reference key entity to marry everything into one place. This will allow you to point to a single object instead of many, and massively simplify microflow logic.
Long Term Benefits
Once you have this system in place, all of your workflows are scaleable and future proof. If you add a new application to your system, just point it to the relevant reference keys and everything will generate when it needs to. If you add a new entity to your database, such as permits, you would need to create the master table of permits and set up all of their corresponding reference keys, then add in the iterative logic to retrieve or create the permit inclusions in the workflow explained above. Once you have that, permits are ready to expand your project creation workflow with minimal effort from a dev standpoint.
Ask Me Anything!
Sometimes it’s easier to share ideas and content face to face, especially with some context around any given problem. If you ever find yourself at the end of this medium article and want more info, reach out! I would love to connect and talk about your app.
luke.bashford@kinetechcloud.com
This post was originally published on Medium.com. View that post, here.
