Use Cases · Published April 6, 2022

Advanced Model Mapping

Devil Is In The Details. Spaghetti-Model, is usually the term that comes to mind after we have Reverse-Engineered a Legacy Model for purposes of Model-Mapping, yet nearly all the Intertwined Associations and Heurestics of a Model can eventually be Mapped for an Application - keyword being Eventually.

We though, have simplified Model-Mapping techniques for Porting Data & Other Applications, quite drastically on our Low-Code platform. We have developed features to specify Expressions In-Line, Business-Logic in Context, Conditional Associations, so on & so forth, making Model Mapping as Easy, Efficient and Iterative as possible.

There is no Devil once the Maps have been discovered - We have developed features to specify Expressions In-Line, Business-Logic in Context, Conditional Associations, so on & so forth, making Model Mapping as Easy, Efficient and Iterative as possible.

Devil Is In The Details.

An overwhelming number of Applications can be thought of as Model-Maps and Model-Mapping is the activity of creating those Model-Maps. The Screen of an App or a Web-Page is displaying data mapped to an under-lying Data-Model with some Business Logic Slathered on it; Inversely, Analytics Data collected from Front-End Engagement is mapped to an Analytical Model, so forth.


The Model-Mapping technique can be applied to many other use-cases :

• Applying Modern Front-Ends to Legacy Models,
• Breaking down Monoliths to Micro-Services,
• Mapping Legacy Data-Models to Open APIs for Data-Monetisation.
• Data Logistics between Applications.
  
  There are quite a few Applications to the Model-Mapping technique, only limited by our imagination. We used Model-Mapping for porting data even between completely different Applications. Vivid Imagination is a good thing. Please do give this Use-Case a read too.

Data Logistics : Data Logistics in Symplat

No Code Model Mapping

To Start, a Model may be in a Normalised or a De-Normalised form or both. De-Normalisation is usually done to avoid expensive joins, or the Evolution of a Model may not have been known up-front, or it emulates the real world very accurately; many reasons to it & there are advantages for De-Normalised Models.

The constant in both cases is Entity Relationships or Associations. We are talking in the context of Relational Models here not Graph Databases. We will post in the future about Graph Databases too.

In the Example Below :

A Party in the legacy CRM model (Source Database) could be a Supplier of Goods and/or Services Or, a Customer of Goods and/or Services; determined by an entry in the General Ledger if a Payment Voucher for the Party(Supplier) or a Sales Order for a Party(Customer) is present. A Party is also associated with a Country.

Whereas Customer at the target model is only that, with no overloaded connotations and is associated with a Territory.

Data from “Party” (Source) needs to be mapped to “Customer” (Target).

Mapping Completely Disparate Models.

In the Screen Recording from Visual Studio Code (Editor used by more than 57% of Software Engineers) below, We are creating a Model-Map to port data between “Party” from the legacy CRM Model to “Customer”.
There are complicated things happening in the platform when the Model-Map from Customer to Party is being created:

Firstly, a Model-Map is created using pure declaration for “Territory” which is an association for a Customer from the target CRM Module. It is mapped to “Country” in the Legacy Model with the familiar “Switch-Case” construct. Even without a keen eye, one must have observed :

NOT ONE LINE OF CODE !!!

Secondly, We are cleaning the data too, by annotating the “territoryName” attribute with “@TRIM” there is ISO Standards for Countries and Codes available yet applications may or may not end up using these standards and even if standards are used some house-keeping is always to be expected.

Thirdly, Customer of the target model not only has an association to Territory within the model but also needs to be mapped to Party from the legacy model.

To summarise, we are slicing & dicing data at an attribute level and mapping them to attributes of a target entity, as well as accounting for all the associations without writing a single line of code. THIS IS WHAT WE MEAN BY LOW-CODE DECLARATIVE MAGIC.

The activity of porting the Customer Data to the new CRM was done at “Warp-Speed” by us for our client, what took time was accruing the domain knowledge from the legacy CRM.

If this is something which interests you : Contact Us

Fetch Data For Import

Once the CRM entity Customer was mapped, sanitised and vetted by the client using the prior steps, now it is a matter of presentation. Presentation can range from markup using HTML, or a Tabular format using Markdown, or a JSON, or YAML or in this specific case a CSV to be imported into the target model database.

The actual Customer Names of our Client from the legacy CRM have been stubbed due to Contractual Obligations.

Conditional Joins

Apart from the Attribute Mapping and Association Features of Model-Mapping we mentioned above, there is robust support for Conditional Joining too. Joining Associations has facets to it, in SQL we know them as Left, Inner, Cross & so forth.

A Party in the Legacy CRM could be a Sundry Creditor(Supplier) or a Sundry Debitor(Customer) and has entries accordingly in the General Ledger. The Customer Map is actually a conditional join.

The Example below Illustrates this feature of our platform of applying Model-Maps on an Entity with conditional joins.

Symplat (Low Code): Symplat