Skip to main content

Dynamic model

Introduction to 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 your application.
  • Check if a model enrichment is a better solution if you do not want your actions to be executed during every generation.

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.model_id    = tp.model_id
      and c.branch_id   = tp.branch_id
      and c.type_of_object   = 1 -- Column
      and c.transl_object_id = tp.transl_object_id
where tp.model_id    = @model_id
  and tp.branch_id   = @branch_id
  and tp.type_of_object  in (
                                31 -- Report parameter
                               ,32 -- Task parameter
                            )

Set up dynamic modeling​

Warning​

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.

Add a control procedure​

With dynamic modelling, the model of an application can be modified via Control procedures containing SQL code.

menu Enrichment > Dynamic model > tab Control procedure > tab Dynamic model

  1. Add the Control procedure's name and Description.

  2. Optional: change the Generation order no. Its default value is '10'. Only change it to ensure that meta procedures with interdependencies are executed in the correct order.

  3. Select a Strategy: 'Delete', 'Fully controlled', or 'Staged'.

  4. Add code to your dynamic model.

Control procedure Control procedure in the Dynamic model screen

Add code to your dynamic model​

To add the SQL code:

menu Enrichment > Dynamic model > tab Control procedure > tab Code

Control procedure code Control 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:

  • @model_id
  • @branch_id

These two parameters are also used to support meta control procedures that are imported from base models, which of course have different model and/or branch names than the work models they are linked to.

  • @control_proc_id: This parameter can be used, among other things, to fill the following fields:

    • Generated by control procedure - Use this when you are not using a Staged strategy. This way, you can fill the source for the objects that the meta control procedure creates, and make it responsible for these objects.
    • Generated - When this checkbox is selected, the object is automatically deleted and re-created when generating definitions.

    For more information, see Identify a generated object.

The 'Staged' strategy in a dynamic model​

  • You can use any model object table by referring to the corresponding temporary table name in the SQL code. The following columns are not available in the temporary tables:

    • Model and branch - The temporary tables are always in the context of a model and branch. This includes model_id and branch_id.
    • Identities - At an insert, these columns are populated automatically from the database.
    • Abs. order no columns - These values are calculated when triggered, based on the regular order no. This includes, but is not limited to abs_order_no and abs_gen_order_no.
    • No. of columns – This includes, but is not limited to no_of_col and no_of_pk_col.
    • Generation columns – This includes generated and generated_by_control_proc_id.
    • Trace columns - These columns are automatically filled in. This includes insert_user, insert_date_time, update_user, update_date_time.
    • Other derived columns – This includes template_last_changed_on, code_generated, foreign_key and is_detail.

  • Only model objects referred to by the code in temporary tables will be deleted. If a meta control procedure with a Staged strategy is changed so it no longer uses a specific temporary table, the associated model objects will not be detected and will remain in the system. You can resolve this by keeping the temporary table name commented out in the code for at least one control procedure execution or definition generation.

  • Control procedures using the Staged strategy will fail execution if deleting model objects violate the model's referential integrity constraints. This differs from model objects created by a control procedure that uses the Delete strategy. These model objects will be retained if deleting would violate the model's referential integrity constraints.

  • Execute the task Show full staged control procedure code show to inspect the full execution code, including provisioning, deleting, updating, and inserting. It also indicates how this would be implemented if a Fully controlled strategy had been used to achieve the same result.

Was this article helpful?