Dynamic model

Dynamic modeling

tip

Before using dynamic modeling, check if the solution you need is already available in the Thinkstore in the Software Factory, which contains ready-made examples that you can easily download and install into you application.

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 Modeling. 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 modeling is not intended to be used on program objects and user requirements.

You can use dynamic modeling 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 modeling are that queries can adjust your application model based on specific conditions, and that these queries will also be applied to your future model.

note

Dynamic modeling provides very high productivity, quality and uniformity, especially for large applications (eg from ISV's (independent software vendors)).

Examples

The possibilities for dynamic modeling are numerous.

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
• etc.

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 modeling 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 modeling 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 modeling

warning

Be very careful not to introduce dependencies between generated and non-generated objects into your dynamic model. If generation strategy Delete is used, your system might try to delete the generated object while it is in use by a non-generated object.

For example, using a generated table in a process action like Open document will lead to the message "Object in use" during generation. The Delete generated objects procedure will try to remove the table used by the non-generated process action.

Problems like these can be solved using the Fully managed generation strategy.

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:

• @project_id
• @project_vrs_id

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.