Support > Repository > Business logic > Cross-model calculation (transaction)

The calculation across the model is "transaction". This section explains how to create transaction scripts.

Here is an example of changing the value of the (related) inventory model zaiko at the same time when registering the sending model syukko.

Figure 1 Image of inventory management system

"Product" and "Product inventory" have a 1: 1 relationship.For this reason, the primary key of "product inventory" is to refer to "goods".

Here, we focus on "transaction slip" which is a transaction system.It is necessary to fluctuate commodity stock at the same time in the new registration process of this model.Also, for goods issue requests beyond the product stock, you should return an error.

Initial data shown in Fig. 2 was set in the product inventory master model.Each stock number is 100 each.

Figure 2 Initial Values ​​of the Product Inventory Master Model

Create a goods issue slip.I will issue one designated item.(Figure 3)

Figure 3 Creating a new issue document

A goods issue document has been created.Transaction processing has been completed normally at this timing.

Figure 4 Transaction processing also works when creating a goods issue slip

Check the item stock master.You can see that inventory has been reduced.

Fig. 5 Stock has been reduced

Handling on error

We tried to return an error message when trying to issue a number exceeding the stock quantity.(FIG. 6)
In this case, the value of the database does not change.

Figure 6 Transaction Failure

Define the four models shown in Figure 1.

Figure 7 Four models defined

Warehouse master

Warehouse ID and warehouse name, warehouse administrator defined.

Figure 8 Warehouse Master

Product master

Product ID, product name, unit price are kept.Also, it is linked to one warehouse.

Figure 9 Product Master

Item inventory master

"Principal item" which is the primary key has 1: 1 relation with product master.

Main key Please set item "Item" not to use order.

Figure 10 Item inventory master

Goods issue slip

We will record how many items you have taken out.

Figure 11 Goods issue slip

hereReduce the inventory quantity of the item inventory master according to the number of goods issuedfor,Model reference itemWe will set up transactions for 'goods'.(FIG. 12)
Here, when newly registering, we designate it to be linked with the "stock" model.

Figure 12 Transaction settings
The reason for specifying the model name is because in this case (model of reference) is "item inventory" instead of "product"."Product" and "Product inventory" are in a 1: 1 relationship, and the primary key of "product inventory" is the same as the primary key of "product".
If the referenced model is equal to the target model of transaction processing as it is, the model name can be left blank.If this field is blank, the reference model name is used.

When you set a new transaction (when checking new registration, update, deletion, copy registration) please perform the build process.
After setting once, build processing is unnecessary.Changes to transaction scripts take effect immediately.

Fig. 13 Build process

The actual transaction processing code (transaction script) is described in the "Script at transaction control" column in Figure 12.

var suryou = zaiko.suryou;
var syukko_num = syukko.syukkoNum;
if (suryou - syukko_num < 0) {
  return "在庫 "+suryou+" に対して "+syukko_num+" を出庫しようとしました。";
zaiko.suryou = suryou - syukko_num;
return null;
  • In the script, return value is returned with the return instruction.If the return value is null, it is treated as normal.In case of error, return error message (character string).
  • Specify either "New registration" "Update" "Delete".You can write a transaction script at each timing.
  • There is no distinction between registration processing and copy registration processing.SCREENTYPE constantCan be used to determine.It holds the value of the SCREENTYPE function that returns the screen type.
    The same script file is called at the time of new registration and copy registration, but an example of performing control not to process at copy registration is shown below.
    if (SCREENTYPE == "copy") {
        /* コピー登録時は処理を行わない */
        return null;
    /* 登録時にのみ実行される */

An example

You can specify transactions for items in the repeating container.
Figure 14 shows an example of specifying multiple items at the same time on the details of a goods issue document.

Figure 14 Prepare details (as repeating containers) in the issue slip

You can see that more than one data has been rewritten at the same time.(FIG. 15)

Figure 15 Transaction is successful

Definition method

We changed the definition of the issue document of Figure 11 and prepared the details.(Figure 16)

Figure 16 Definition of goods issue slip prepared item

Change transaction script

The filename and file storage position will not change.
Within the script you can use the repeating container "details".At this time, this script is executed for each data of multiple repeating containers.(In FIG. 16, since there were three item data, this script is executed three times in total for each data unit.)

/* トランザクションで使うオブジェクト sykko, zaiko は利用可能になっている。
   繰り返しコンテナも利用できる。details という名前のオブジェクトが用意されている。*/
var suryou = zaiko.suryou;

/* detailsは明細データ毎に呼び出された値がセットされる */
var syukko_num = details.syukkoNum;
if (suryou - syukko_num < 0) {
    return "在庫 "+suryou+" に対して "+syukko_num+" を出庫しようとしました。";
zaiko.suryou = suryou - syukko_num;
return null;

With Wagby's foreign key relationship, one parent data can manage multiple child data. In the following example, we will explain using parent model name parent and child model name child.

The child model child has a foreign key field pkey pointing to the parent model.At this time, you can write a transaction script for this pkey item.

Figure 17 Transaction script sample with parent-child model relationship

In the example shown above, at the timing of new registration of the child model, the value of the child model is posted to the item of the parent model.

parent.pname = child.cname;

With Wagby's standard, model update control uses pessimistic locking.You can switch this to optimistic locking.Locking during transaction execution is controlled according to the specified method.

In pessimistic lock, if the target data is being updated (the update screen is open), if you try to register/update, an error message "Failed" appears on the screen.

With Optimistic Lock, if the target data is updated separately, an error similarly occurs.

In either case, the transaction fails.This is correct behavior.

You can use Service/Dao class (automatically generated by Wagby) from server side JavaScript.You can also use SQL.

This page is explained on a separate page.For details, please read "Using Service/Dao class, SQL".

Wagby's transaction boundary is the Service class.An example of update processing is shown in Fig.

Figure 18 Transaction boundary

Dao, Helper and script called after CRUD method of Service class are processed within the same transaction.The Controller class is not a transaction boundary.

  • Transactions can be specified only for model reference fields or foreign key fields.It is ignored even if it is specified for numeric, character string, or date type items.(It does not work.)