TradeDesign transactional bootstrap

The bootstrap of a transaction is technicaly defined by the TradeDesign execution rules.

At the very first action all defined “EnterTransaction” rules of all loaded modules of the launched transaction are executed in ascending order number.

Those rules are typically the core rules to setup the execution context mainly located in SYSMOD and SYSMNU.

The next step is to initialize all modules bottom up. Thus within every module instance all “Init” rules are executed in ascending order number. Whenever a module (or the transaction) get's initialized all directly included modules are already initialized.

The init rules are typically used to setup and prepare local memory of the module and to load needed configuration.

Having completed the overall init all defined “InitTransaction” rules of all loaded modules of the launched transaction are executed in ascending order number.

Those rules are typically core rules to complete the setup of the execution context mainly located in SYSMOD and SYSMNU.

Technically the overall flow touching all “default” rules will now be executed once.

Having completed the above steps the TradeDesign server now waits for events triggering further execution.

Those events might be posted by procedure call, posted event trigger, UI triggered Events (e.g. Click, TabOut, Enter) or other trigger.

At this point in time the interactive work with user input and reaction of the transaction starts.

Every change of a field results in automatic exection of all dependent default rules updating their connected objects (e.g. fields, panel).

Execution of events by clicking on buttons/icons or using the navigation might execute the defined “event” functions.

As part of the DOKA support modules (e.g. MDxBUT, MTABUT, RPTBUT, INFBUT) providing generic support function for the different transaction classes during the Init's the main entry the transaction is working on is locked with a long term lock to prevent concurrent update on the same dataset.

To exit a transaction typically there are three different options

1. Save the data (and process the entered data)
2. Pause the transaction (and create a pending entry holding all current data)
3. Cancel the entry (and forget all entered data)

With this function the currently entered data is checked and if no error is active the processing function will be launched.

Technically all that is implemented as a list of “event” rules which are assigned to the “save” button (e.g. MTABUT\SAV, MDEBUT\UPD, MDABUT\SAV) of the used generic support module.

The used order numbers are structured in

1. Check consistency and preparation
2. Starting the database transaction
3. Accuire holds on all entries intended to be updated
4. Switching from preparation to update the database
5. Commit all database inserts / updates
6. Release all long term locks aquired upon start of transaction
7. Do any needed postprocessing
8. Exit the processing of the current transaction by either chaining to a different transaction (e.g. LnkReturnToCaller) or by reinitializing the current transaction to handle a different entry