In the Software Factory, it's not only possible to build the application model graphically with the available user interface, but also dynamically by means of queries. This is called Dynamic Modelling. The queries are run while the application is being built. This way the entire model can be expanded with specific functionality or concepts without the need to create them for each part of the application model separately.
Note that dynamic modelling is not intended to be used on program objects and user requirements.
You can use dynamic modelling best to add functionality that applies to several places in the model, to extend the data model or to adjust the user interface. A simple example is adding a timestamp column to each table. You can do this graphically for each table or via one query that does it automatically for all tables and for future tables. Thus, by using SQL statements you can add conditional changes or extensions to the model.
So, the great advantages of dynamic modelling are that queries can adjust your application model based on specific conditions, and that these queries will also be applied to your future model.
Dynamic modelling provides very high productivity, quality and uniformity, especially for large applications (eg from ISV's (independent software vendors)).
The possibilities for dynamic modelling are numerous. Some of the examples below and more can be found in the Thinkwise Community (tip: search for 'dynamic model'. Especially the Innovation room contains elaborated examples. Feel free to ask questions or to add your own examples to the Community!).
The queries can be used for example:
- to set up forms
- to enrich menu's
- to set up roles automatically
- to create automated messages
- to add an update counter column to tables
- to create archiving tables and functionality
Some more specific examples:
Make logging data visible in the GUI - When you have system versioned tables in your database, SQL Server logs all changes made to the data in those tables. Use dynamic modelling to make this logging data visible in the user interface.
Trace field changes: automatically add trace fields to all tables so a user can see who added the record or who made the last change. This solution adds these fields to a separate tab page on a form.
Make your application more secure by inheriting prefilters - Sometimes data security will improve if a prefilter is available for all tables. For example, when a user should only have access to customers from a specific region (restricted data access).
Find illegal XML characters in your database - Many applications have functionality for importing or exporting data in XML format. This can lead to an error about an illegal XML character. Often it's hard to find that character. This solution creates a stored procedure search_illegal_xml_characters which searches your entire database for illegal XML characters.
Replace all file links in an end product using IAM for migration or DTAP deployment - Replace all existing file links in an end product without manually writing an update script for every table. This can be used for migrating file systems or DTAP-deployment.
Example: task and report parameter translations
Problem: in the Software Factory task and report parameters have their own translations. As a developer you have to fill them in, after creating a task or report. Though this is a flexible solution, most of the time the translations are the same as the column translations with the same name.
Solution: the dynamic modelling code copies the translation from columns to task and report parameters with the same name. This means that those parameters are translated automatically while generating your application.
update tp set tp.transl = c.transl ,tp.transl_form = c.transl_form ,tp.transl_grid = c.transl_grid ,tp.transl_plural = c.transl_plural from transl_object_transl tp join transl_object_transl c on c.project_id = tp.project_id and c.project_vrs_id = tp.project_vrs_id and c.type_of_object = 1 -- Column and c.transl_object_id = tp.transl_object_id where tp.project_id = @project_id and tp.project_vrs_id = @project_vrs_id and tp.type_of_object in ( 31 -- Report parameter ,32 -- Task parameter )
Using dynamic modelling
Using the Dynamic model screen, the model of an application can be modified via so-called Control procedures containing SQL code.
menu Enrichment > Dynamic model > tab Control procedure > tab Dynamic model
Here the Control procedure's name and Description can be added, as well as the Generation order no. and Priority.
Control procedure in the Dynamic model screen
Adding code to your dynamic model
Here you can add the SQL code.
menu Enrichment > Dynamic model > tab Control procedure > tab Code
Controle procedure code
Please contact your Thinkwise representative if you want more information on writing queries for dynamic model concepts.
Parameters for a meta control procedure
Some parameters are automatically available when writing a meta control procedure. They prevent you from having to use hardcoded names. These are:
These two parameters are also used to support meta control procedures that are imported from base projects, which of course have different project (version) names then the work projects they are linked to.
- @control_proc_id: This parameter can be used, among other things, to fill the field Generated by control procedure. This field is present for almost all objects in the model. This way, you can fill the source for the objects that the meta control procedure creates, and make it responsible for these objects. The Generated by control procedure field should not be confused with the generated checkbox. When using the Generated checkbox, the object will automatically be deleted and recreated when generating definitions. When using the Generated by control procedure field, you*ll have better control on how and when the object should be recreated.