In the film “The Hitch Hikers Guide to the Galaxy” the earth gets destroyed and rebuilt afresh. It is along a similar line of thinking that the “DeleteCreate” design pattern was engineered.
The “DeleteCreate” design pattern is used within complex enterprise environments where sourcing data from many other applications happens frequently. These integration environments present the question of data ownership. For example: while a system you’re building might have a version of a dataset the most up to date version of that data sit in another system, the data’s owner system.
As a result a scenario of having to refresh that dataset within your own system often arises. The modeler needs to decide, on an entity level, how to refresh the entities with the new data. The logic of refreshing the data itself is not the only responsibility a modeler faces – the Mendix Business Engineer needs to add this logic using a practical naming convention as well as build the model in a common, optimized and consistently presentable way. That way other modelers working on the application can recognise the design pattern from the naming convention as well as immediately and efficiently understand exactly how the underlying logic will execute.
The DeleteCreate design pattern has been created to neatly solve that problem.
The Entity Model
In order to illustrate the pattern we’re going to use a customer risking example. In this example we’re collecting some risking data from the customer in the form of bureau data via web service. The important thing to know here is that the bureau data entity is the one we’ll be wanting to refresh – it has to be linked to an owner entity somehow. In this case that entity is the “Customer” entity and, specific to this example, we’ll track that entity down using the customer’s ID number.
The Design Pattern
The design pattern has 4 major steps.
1. Retrieving the owner entity. As mentioned above we do that using the customers ID number.
2. Retrieving the old bureau data linked to that owner entity with a simple retrieve. This data is now old and, according to the business in this example, no longer relevant.
3. Deleting that old bureau data.
4. Creating the new entity and linking it to the owner Customers entity.
As a fifth and final step this design pattern does give you the space to then return the new bureau data should the calling Microflow need it.
Calling the Design Pattern
The design pattern will then obviously be called from within a Microflow as illustrated below.
Design patterns achieve 2 great goals. Firstly they efficiently solve common problems and secondly they leave a recognisable trail for any modeler following the original solution.