JP7801982B2 - Business rule setting device, business rule setting method, and business rule setting program - Google Patents

Description

The present invention relates to a business rule setting device, a business rule setting method, and a business rule setting program.

For example, Patent Document 1 discloses an application development device designed to enable fast and maintainable application development. This application development device includes a GUI display control means for displaying a GUI on a display unit for setting the contents of a function for state control, a function setting means for setting the conditional and processing parts of the function for state control in response to user operations on the GUI, and an object storage means for creating an object in accordance with the settings of the function setting means and storing the object in the storage unit.

Japanese Patent Application Laid-Open No. 2021-2088

However, there has been no previous documentation on how developers can easily configure settings to control the status of screen items, such as locking or displaying them.

The present invention was made in consideration of the above, and aims to provide a business rule setting device, a business rule setting method, and a business rule setting program that enable developers to easily configure settings for state control of screen items.

To solve the above-mentioned problems and achieve the objectives, a business rule setting device is provided with a control unit and a storage unit. The storage unit stores a table containing control information including control names and properties, condition information used to determine dynamic control and including condition names and conditional expressions, and business rule information that is a rule specifying what updates to make dynamically to the set control when the set condition is true and includes state control types, conditions, and controls. The device is also provided with a screen control means for displaying a business rule development screen in a matrix format with the control from the control information on one axis and the condition from the condition information on the other axis for a selected state control type, and a setting means for selecting a control and condition pair by selecting a matrix cell on the business rule development screen, and registering business rule information including the selected state control type, condition, and control in the table.

Furthermore, according to one aspect of the present invention, the type of state control may include locked, hidden, or required.

Furthermore, according to one aspect of the present invention, the screen control means may be provided with a filter function that limits the display on the business rule development screen to the controls and conditions set in the filter information.

Furthermore, according to one aspect of the present invention, the screen control means may be configured to display screen information set in the layout screen for a control on one axis when that control is selected on the business rule development screen, and to display a condition setting screen for that condition when a condition on the other axis is selected.

Furthermore, according to one aspect of the present invention, in an application that becomes executable when the table is made public, each business rule may be judged after all logic flows have been executed.

In order to solve the above-mentioned problems and achieve the objectives, the present invention provides a business rule setting method executed by an information processing device having a control unit and a storage unit, wherein the storage unit stores a table containing control information including control names and properties, condition information used to determine dynamic control and including condition names and conditional expressions, and business rule information that is a rule that specifies what updates to make to the set control dynamically when the set condition is true and includes state control types, conditions, and controls; the method includes a screen control step of displaying a business rule development screen in a matrix format, with the control information's control on one axis and the condition information's condition on the other axis, for a selected state control type executed by the control unit; and a setting step of selecting a control and condition pair by selecting a matrix cell on the business rule development screen, and registering business rule information including the selected state control type, condition, and control in the table.

In order to solve the above-mentioned problems and achieve the objectives, the present invention provides a business rule setting program to be executed by an information processing device having a control unit and a storage unit, wherein the storage unit stores a table containing control information including control names and properties, condition information used to determine dynamic control and including condition names and conditional expressions, and business rule information that is a rule that specifies what updates to make to the set control dynamically when the set condition is true and includes state control types, conditions, and controls, and the control unit executes a screen control step in the control unit to display a business rule development screen in a matrix format with the control from the control information on one axis and the condition from the condition information on the other axis for a selected state control type, and a setting step in the business rule development screen to select a control and condition pair by selecting a matrix cell, and to register business rule information including the selected state control type, condition, and control in the table.

This invention has the advantage of allowing developers to easily configure settings for state control of screen items.

FIG. 1 is a block diagram showing an example of the configuration of a business rule setting device according to this embodiment. FIG. 2 is a diagram showing the prerequisites. FIG. 3 is a diagram showing the prerequisites. FIG. 4 is a diagram showing the prerequisites. FIG. 5 is a diagram showing the prerequisites. FIG. 6 is a diagram showing the prerequisites. FIG. 7 is a diagram showing the prerequisites. FIG. 8 is a diagram showing the prerequisites. FIG. 9 is a diagram showing the prerequisites. FIG. 10 is a diagram showing the prerequisites. FIG. 11 is a diagram showing the prerequisites. FIG. 12 is a diagram showing the prerequisites. FIG. 13 is a diagram showing the prerequisites. FIG. 14 is a diagram showing the prerequisites. FIG. 15 is a diagram showing the prerequisites. FIG. 16 is a diagram showing the prerequisites. FIG. 17 is a diagram showing the prerequisites. FIG. 18 shows a screen image during execution. FIG. 19 is a diagram illustrating an example of a definition management table. FIG. 20 is a diagram showing the logic flow assigned to the registration button. FIG. 21 illustrates an example of an API management table. FIG. 22 is a diagram showing an example of a layout development screen. FIG. 23 is a diagram showing an example of a condition development screen. FIG. 24 is a diagram showing an example of condition information in the definition management table. FIG. 25 shows an example of a condition development screen for specifying complex conditions and an example of the condition information to be set. FIG. 26 shows an example of control information and condition information in the definition management table of the development application DB. FIG. 27 is a diagram for explaining controls that are subject to dynamic updating. FIG. 28 is a diagram showing an example of a business rule development screen. FIG. 29 shows the transition to the condition setting screen. FIG. 30 shows the transition to the layout screen. FIG. 31 is a diagram illustrating an example of business rule information in the definition management table. FIG. 32 is a diagram showing an example of a business rule development screen to which a filter function has been added. FIG. 33 is a diagram illustrating an example of filter information in the definition management table. FIG. 34 is a diagram for explaining the filter function of the filter information. FIG. 35 is a diagram showing an example of a layout screen. FIG. 36 shows an example of how to set the condition (in the case of a price excluding tax). FIG. 37 is a diagram showing an image of setting business rules. FIG. 38 is a diagram showing an example of business rule information in the definition management table. FIG. 39 is a flowchart showing the process up to reflecting the business rules. FIG. 40 is a diagram for explaining the features of the flowchart of FIG. FIG. 41 is a diagram for explaining a case where dynamic updating is attempted to be realized only by mechanisms such as logic flow and action, without providing a mechanism called business rules. FIG. 42 is a diagram for explaining a case where dynamic updating is attempted to be realized only by mechanisms such as logic flow and action, without providing a mechanism called business rules.

Embodiments of a business rule setting device, a business rule setting method, and a business rule setting program according to the present invention are described in detail below with reference to the accompanying drawings. Note that the present invention is not limited to these embodiments.

[1. Overview]
(1) Issues: Previously, item status control was performed through programming, requiring advanced configuration work by developers. As control became more complex, developers also needed to have appropriate technical skills, and the costs of configuration and testing to prevent malfunctions increased. Furthermore, changing a system once configured required considerable time and cost, making it difficult to flexibly change the system in line with changes in the business environment. As a result, there was a risk that user satisfaction would decline due to an inability to respond quickly to customer needs.

In this embodiment, we provide a system that allows developers to easily configure settings for state control of screen items.

Specifically, this system is a mechanism for implementing settings for controlling the status of screen items, such as locking and display, on a low-code development platform. This mechanism allows for easy control of screen items, which tend to become complicated, without the need for programming.

Controlling the status of items in business applications is extremely important for stable business operations, and this mechanism, which simplifies this configuration, reduces the amount of work required for configuration and testing, contributing to the early launch of the system. Furthermore, simplified configuration can minimize system malfunctions, which is also expected to increase user satisfaction.

(2) Background This section explains the dynamic control of items required for business applications. In general business applications, it is common to dynamically control (lock, hide, etc.) screen items according to operations by business operators. As an example, consider a requirement where item A accepts two values, 0 and 1, and information from item B is required only when the value 1 is entered. To satisfy this requirement, it is necessary to dynamically control the screen items (for example, if the value of item A is 0, item B is locked, and if the value is 1, item B is unlocked).

In this way, business rules (enter information from item B when the value of item A is 1) that are set as specific actions on a business application screen are called "business rules." If business rules are not set, operators may not enter information required for business purposes, or may enter unnecessary information, which could disrupt business operations.

In conventional development, dynamic control of items was typically achieved by developers manually programming. When performing control with complex settings, the programming became more difficult and the man-hours required to complete the system also increased. Another problem was that if there were sudden changes to items, it became difficult to reconfigure them.

(3) Solution: In business applications created with low-code development tools, various processes are implemented using action processing. However, if dynamic control of items is implemented using processing within an action, the number of configuration and control issues that must be considered increases, increasing development costs.

In this embodiment, by clearly separating action settings from business rule settings, it is possible to reduce the configuration load during development while preventing unintended problems. Furthermore, by incorporating ingenuity into the business rule configuration screen, it is possible for developers to easily configure business rules.

As a result, the amount of work required for system configuration has been reduced, making it possible to provide high-quality applications to users in a short period of time. Furthermore, while business rules may change depending on the business situation, by using this system to optimize business rule settings as they occur, it is possible to provide users with a system optimized for the situation in a short period of time.

2. Configuration
An example of the configuration of a business rule setting device 100 according to this embodiment will be described with reference to Fig. 1. Fig. 1 is a block diagram showing an example of the configuration of the business rule setting device 100. The business rule setting device 100 is a device used by developers for developing applications. The business rule setting device 100 is equipped with the functions described in [3. Prerequisites] and [4. Setting Method for Dynamically Updating Screen Items (Setting Conditions and Business Rules)] below, and is configured to be able to execute the processes described therein.

The business rule setting device 100 may be an information processing device such as a workstation, a stationary information processing device such as a desktop personal computer, or a commercially available notebook personal computer.

The business rule setting device 100 comprises a control unit 102, a communication interface unit 104, a memory unit 106, and an input/output interface unit 108. Each unit of the business rule setting device 100 is connected to each other so that they can communicate with each other via any communication path.

The communication interface unit 104 communicatively connects the business rule setting device 100 to the network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has the function of exchanging data with other devices via the communication line. Here, the network 300 has the function of communicatively connecting the business rule setting device 100 to other devices such as a developer terminal (not shown) and a server 200, and is, for example, the Internet or a LAN (Local Area Network). Note that data such as tables described below may be stored in the server 200, for example.

An input device 112 and an output device 114 are connected to the input/output interface unit 108. The output device 114 may be a monitor (including a home television), a speaker, or a printer. The input device 112 may be a keyboard, a mouse, a microphone, or a monitor that functions as a pointing device in conjunction with a mouse. Note that, below, the output device 114 may be referred to as the monitor 114, and the input device 112 may be referred to as the keyboard 112 or the mouse 112.

The storage unit 106 stores various databases, tables, files, and the like. The storage unit 106 stores computer programs that work in conjunction with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) to perform various processes. The storage unit 106 can be, for example, a memory device such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, or an optical disk.

The storage unit 106 includes a development application DB 106a that stores a definition management table and the like. The definition management table may include, for example, definition identification data (definition ID and definition name), control information, action information, logic flow information, linking information, condition information, business rule information, and filter information (see Figures 19, 24, 31, 33, etc.).

Control information may include the control name, properties, etc.

Condition information is used to determine dynamic control and may include condition names, condition expressions, etc.

Business rule information is a rule that specifies what updates should be dynamically made to the set control when the set condition is true, and may include the type of state control (e.g., whether the control is locked, hidden, required, etc.), the condition, the control to which the updates should be made, etc.

Filter information is used to limit the display of controls and conditions on the business rule development screen, and may include the filter name, control elements, and condition elements.

The control unit 102 is a CPU or the like that provides overall control of the business rule setting device 100. The control unit 102 has internal memory for storing control programs such as an OS, programs that define various processing procedures, and required data, and executes various information processing operations based on these stored programs.

The control unit 102 conceptually comprises a screen control unit 102a and a setting unit 102b.

The screen control unit 102a provides various setting screens (development screens) for setting various information in the definition management table in response to requests from developers on developer terminals.

For example, the screen control unit 102a displays a business rule development screen in matrix format for the selected state control type, with the control from the control information on one axis and the condition from the condition information on the other axis (see Figures 26 to 31, etc.).

The screen control unit 102a may also be equipped with a filter function that limits the display on the business rule development screen to the controls and conditions set in the filter information (see Figures 32 to 34, etc.).

When a control on one axis is selected on the business rule development screen, the screen control unit 102a may provide the screen information set on the layout screen for the selected control, and when a condition on the other axis is selected, the screen control unit 102a may display the condition setting screen for that condition (see Figures 29 to 31, etc.).

The setting unit 102b sets various information in the definition management table in response to operations performed by the developer on the developer terminal on various setting screens.

For example, the setting unit 102b selects a control and condition pair by selecting a matrix cell on the business rule development screen, and registers business rule information including the selected state control type, condition, and control in the definition management table (see Figures 26 to 34, etc.).

State control types may include locking, hiding, or requiring the control.

In applications that become executable by publishing the definition management table, each business rule may be judged after all logic flows have been executed (see Figures 39 and 40).

[3. Prerequisites]
In this section, prerequisites for explaining the processing in this embodiment will be described.

[3-1. Overview of low-code development tools]
(1) What is Low-Code Development? Low-code development is a development method for building systems. In this specification, the term "system" refers to a general ERP system or the like used by companies for their business operations, hereafter referred to as a "business application."

In traditional development, developers write source code themselves rather than programming, and build the entire business application, from the UI to the business logic required for processing. In contrast, low-code development generally involves the use of low-code development tools. Low-code development tools primarily have the function of generating the UI portion of a business application based on configuration.

In other words, developers can build the UI portion of business applications by setting up low-code development tools without having to do any programming themselves. As a result, there are benefits to reducing the amount of work developers themselves do and enabling more efficient system development.

(2) What is a Low-Code Development Tool? Figure 2 shows an overview of a low-code development tool. The following explanation assumes two types of users: developers and business operators at client companies. The explanation is divided into two stages: the development stage, in which developers use low-code development tools to create UI settings and business logic for business applications, and the usage stage, in which business operators actually use the applications.

The development stage is when developers use the low-code development platform to register business application configuration information in a database. The usage stage is when the low-code execution platform analyzes the configuration information registered in the development stage and converts it into an actual business application, allowing business operators to execute the business. In this specification, the low-code development platform and low-code execution platform are collectively referred to as the "low-code development tool."

Here, we will explain how to manage the data generated at each stage. From a control perspective, it is necessary to clearly separate the database in which developers manage application settings during development from the database in which business operators manage application settings referenced during business use. This is to prevent developers from directly operating the business database. In the following explanation, the database used by developers to manage application settings will be referred to as the "development application DB," and the database used by business operators to manage application settings will be referred to as the "business application DB." A database that manages data required for business purposes (master data, accounting data, etc.) separate from the business application DB will be referred to as the "business DB." Applications retrieve and update information in the business DB via a business API.

(2-1) Development Phase As shown in the upper half of Figure 2, the development phase is when developers use low-code development tools (on the low-code development platform side) to develop business applications. Low-code development mainly involves setting up the layout of the application screen and the development of a series of event processes (actions, logic flow) that are performed when the layout is operated. Finally, by linking the layout and logic flow, the UI portion of the business application can be generated. The main settings in the development phase are as follows (A) to (C).

(A) Layout development: Setting the screen layout of business applications.

(B) Logic flow development and action development This involves configuring the processing part of a business application. With low-code development tools, the processing in a business application can be configured in units called actions (the linking of the UI part and business logic mentioned above is also done through these actions). Furthermore, by connecting actions with flows, the order in which a series of actions are processed can be set. This setting of the processing order of actions is called a "logic flow."

This section explains the special action settings for calling business logic. In low-code development, developers only create the business logic portion through individual programming tasks, while the UI portion is generated by operating the low-code development tool. Therefore, in order to call business logic from the UI side, developers must convert the created business logic into an API and register it in the API master. Business logic can be executed by calling the API registered in the API master from an API call action.

(C) Combining layout and logic flow. Assign the logic flow (B) to the layout set in (A).

(2-2) Usage Phase As shown in the lower half of Figure 2, the usage phase is the phase in which the low-code development tool (on the low-code execution platform) analyzes the registered business application settings and converts them into a business application, allowing the business operator to operate the business application.

Explains the screen image during the usage phase. Figure 3 shows a screen image during the usage phase. As an example, we will explain the mechanism for setting up a list screen for supplier master maintenance. The screen name is Supplier Master Maintenance (List Screen). This is a job for business operators to check registered supplier information. When the display button is pressed after entering the extraction conditions (base date, supplier CD (From, To)), a confirmation message dialog is displayed. If Yes is selected in the dialog, suppliers that existed as of the base date and whose supplier CD meets the extraction conditions are read from the supplier master and displayed on the screen. In other words, an API is called to retrieve suppliers from the business application database, and the retrieved information is set on the screen. If No is selected in the dialog, no processing is performed.

(2-3) Settings during development To realize the above-mentioned application, the developer configures the application using a low-code development platform. This application configuration is called a "UI definition." This UI definition is registered in the definition management table of the development application DB. Figure 4 is a diagram showing an example of the definition table. The definition management table manages control information, action information, logic flow information, and information linking layout and logic within the application. The meanings of the terms in the definition management table are as follows:

Definition ID: A Guid string that is automatically assigned when creating a UI definition.
・Definition name: Named by the developer when creating the UI definition.
・Control information: See "(1) Layout development" below.
・Action information: See "(2) Logic flow and action development" below.
・Logic flow information: See "(2) Logic flow and action development" below.
- Linking information: See "(3) Combining layout and logic" below.

(1) Layout Development FIG. 5 is a diagram illustrating layout development. During the development stage, a developer operates the layout development screen to register control information in the development application DB. In other words, data is stored in the control information column of the definition management table described above. For example, in the example screen shown in FIG. 5, a text box for inputting a reference date is selected and placed from the date text. Clicking on the placed control allows the user to set properties according to the type of control clicked. For example, the date text has a required property that indicates whether its input is required for the application. In the example screen shown in FIG. 5, the required property is ON, so the reference date text is a control that must be entered for the application.

At the usage stage, the definition management table information is published from the development application DB to the business application DB, allowing it to be executed as an application. In the above example, the base date is required, so if the business operator attempts to proceed without entering a base date, an error will be displayed.

(2) Logic Flow and Action Development (2-1) Action Settings During the development phase, developers operate the logic flow and action development screens to register logic flow information and action information in the development application DB (data is stored in the action information and control information columns of the definition management table described above). The initial state of logic flow settings in low-code development tools is a state in which the flow is connected between the start action that starts the process and the end action that ends the process. The settings are made by incorporating the necessary actions between these two actions, as shown in Figure 6.

You can make detailed settings for each action by clicking on it and editing it. The settings that can be made vary for each action. For example, for a message display action, you can set the type of message and the message content. In the example message action settings shown in Figure 7, a Yes/No type message box is set to display the message "Customers will be displayed. Is this OK?"

When a Yes/No type message box is selected in the action settings, the logic flow processing can be branched depending on whether Yes or No is selected. In the example shown in Figure 8, if Yes is selected in response to the message (Customer information will be displayed, is this OK?), processing is performed to obtain the customer information using an API call action, but if No is selected, processing ends.

(2-2) Special Action Settings for Linking Business Logic In the example shown in FIG. 9 , after selecting Yes in the message, an API call action is executed. As mentioned above, low-code development tools can only generate the UI portion of a business application, and developers must develop business logic, such as retrieving and updating business data, through programming. In other words, the business logic itself is external logic independent of the low-code development tool. An API call action is a special action that can link and execute UI information created with the low-code development tool and business logic created by the developer. As a preparation, the developer converts the business logic they want to call from the UI created with the low-code development tool into an API (see FIG. 10 ) and registers it in the API master (see FIG. 11 ).

This section explains how to turn business logic into an API. As shown in Figure 10, an API is created in advance in a module that is loaded when the business application is executed. In other words, it manages the actual processing of the business logic to be executed, as well as key information that will be required when the API is called later. In the example of Figure 10, an API is registered that, when a base date (date) is specified as an argument, returns a list of customer information (customer CD, customer name, etc.) registered as of that date.

We will now explain how to register in the API master. The created API information is registered in the API management table as shown in Figure 11.

Then, on the editing screen for the API call action, as shown in Figure 12, the developer selects the required API from the API master that stores APIs previously registered by the developer, and sets the arguments and return values for that API.

Now, let's take a look at action information. As shown in Figure 13, the action information in the definition management table contains information set for each action (ID, name, action type, and each setting, etc.). In the example of a message display action, the message type is registered as 3 (Yes, No) and the message content is "Displaying business partners, is this OK?". In the example of an API call action, the value of the argument (base date) passed to the API is set to the value of the base date text on the screen, and the values of the returned values (business partner CD and business partner name, etc.) are set in the business partner CD text cell and business partner name text cell on the screen.

Now, let's explain the logic flow information. As shown in Figure 14, the logic flow information in the definition management table contains information set for each logic flow (ID, name, flow group connecting actions, etc.). The previous action ID is the ID of the action that will be processed first, and the next action ID is the ID of the action that will be executed after the previous action is executed. The callback key is a key used to determine the result of a selection made by the user when executing an action. In the example of Figure 14, if the user selects Yes in the message box, the callback key identifies the Yes flow, and the action set in the next action ID is executed.

(3) Combining Layout and Logic During the development stage, the developer assigns a logic flow to each control on the layout development screen, thereby registering the linking information in the development application DB (see Figure 15). That is, data is stored in the linking information column of the definition management table described above. The controls and flows created in "(1) Layout Development" and "(2) Logic Flow and Action Development" are assigned. As shown in Figure 15, the control properties include an event item (click event in the case of a button control), where the flows previously registered are listed in a pull-down format.

Now, let's explain the linking information. As shown in Figure 16, the logic flow information in the definition management table registers three pieces of linked information: the control (display button) ID, the event type, and the ID of the logic flow (Logic Flow 1). For controls that can be assigned to multiple events, the linking cannot be determined by the control ID alone, so the event type must be included in the linking information (e.g., text box validation processing and exit processing).

By completing the above settings and publishing the definition management table information to the business application database, it becomes possible to execute it as an application (see "Screen image at execution" below). The published definition management table information is analyzed on the low-code execution platform and executed as an application. In particular, when a logic flow is executed, the flowchart processing shown in Figure 17 is carried out within the low-code execution platform. Figure 17 is a flowchart from application operation by the client to the completion of the end action for the relevant action.

[4. How to set up dynamic updates for screen items (setting conditions and business rules)]
A method for setting dynamic updates of screen items (setting conditions and business rules), which is a characteristic feature of this embodiment, will be described with reference to FIGS.

The method for configuring dynamic updates of screen items described in this specification has its own unique features for both the development and execution stages.

During the execution phase, the processing of actions and logic flows is clearly separated from the processing of business rules, preventing conflicts between the various processes and resulting in incorrect behavior.

During the development phase, the complexity of configuration on the low-code development platform was prevented by clearly separating the settings for actions and logic flows from the settings for conditions and business rules. Furthermore, the screen layout allowed developers to intuitively configure business rules, minimizing problems during configuration.

The features of each are explained below.

(1) Screen image at execution time Figure 18 is a diagram showing the screen image at execution time. As an example, we will explain the mechanism for setting up the Customer Master Maintenance screen. The screen name is Customer Master Maintenance (Edit Screen). Here, we will mainly explain the edit screen of the Customer Master Maintenance screen. We will explain the job that allows the business operator to register customer information. It is assumed that there are only five items: Customer CD, Customer Name, Revision Date, Corporate Classification, and Corporate Number. Transition from Customer Master Maintenance (List Screen) to Customer Master Maintenance (Edit Screen).

There are two types of business partners: corporations and individuals. Corporations (corporate category = 0) require the entry of a corporate number, while individuals (corporate category = 1) do not. When setting up such an application, we want to ensure that all necessary information is registered by dynamically switching the lock status of the corporate number depending on the value of the corporate category.

As shown in Figure 18, when the business operator changes the value of the corporate category to 1 (individual), the corporate number (text) is locked. On the other hand, when the business operator changes the value of the corporate category to 0 (corporation), the corporate number (text) is unlocked.

(2) Information on the underlying definition management table (control information, action information, logic flow information, linking information)
19 is a diagram showing an example of a definition management table. The definition management table is assumed to have the information shown in FIG. 19 registered as customer master (edit screen) information. For simplicity, only the action information, logic flow information, and linking information related to registration are shown.

Figure 20 shows the logic flow assigned to the registration button. In Figure 20, API call action 1 is assigned to the registration button. Figure 21 shows an example of an API management table. API call action 1 is expected to execute the customer data registration process (API). Five pieces of information - customer CD, customer name, revision date, corporate classification, and corporate number - are received as arguments, and the customer information is updated based on the arguments (no return value is assumed).

(3) Information on newly required definition management tables (condition information, business rule information)
The condition development screen and business rule development screen can be accessed from the layout development screen. Figure 22 is a diagram showing an example of the layout development screen. Clicking the condition button on the layout development screen in Figure 22 will transition to the condition development screen. Also, clicking the business rule button will transition to the business rule development screen. As mentioned above, dynamic control of the corporate number is required for customer master maintenance. Below, we will explain the settings that developers make using the low-code development platform to achieve dynamic control of the corporate number.

The corporate classification value is used to determine the control of the corporate number. Therefore, you must first register the corporate classification value as the condition expression (hereinafter referred to as the "condition") required to determine dynamic control.

(3-1) Condition Settings Figure 23 shows an example of the condition development screen. Condition settings are configured as a single formula by setting elements on the screen as values on the left and right sides and combining them with equality (or inequality) signs for comparison. Examples of values that can be set in a formula include constant information such as numbers and character strings, as well as the value of a control on the screen (the type of value to be set can be specified for each formula). The left and right sides of the formula are compared, and if the comparison result is true, the screen information is updated based on the business rules described below.

In Figure 23, if Type = Control is specified, a control on the screen can be selected from a list, and properties (such as value and whether or not there is an error) can be set in the expression. If Type = Constant is specified, any value (string, number, boolean) can be specified. In the above setting example, if the value of the corporate classification is set to 1, it will be true. Figure 24 is a diagram showing an example of condition information to be registered in the definition management table. In Figure 24, the condition information set in Figure 23 is set.

In addition, multiple expressions and conditions can be included within a single condition, and by linking each condition with AND or OR, it is possible to specify more complex conditions. Figure 25 shows an example of a condition development screen for specifying complex conditions, and an example of the condition information that can be set. The example screen in Figure 25 provides buttons for adding expressions and conditions. In the example in Figure 25, the condition "This condition is true if Text Box 1 = 1 AND Text Box 2 = 2 AND (Text Box 3 = 3 OR Text Box 4 = 4) are met." is set.

(3-2) About business rule settings A business rule is a rule that determines what kind of dynamic update is performed on the set control when the set condition is true. Three types of dynamic update can be selected: "Locked,""Hidden," and "Required." When the condition is true, the set control will be locked, hidden, or required.

The business rule development screen displays a matrix table with a list of controls on the vertical axis and a list of conditions on the horizontal axis, and allows check boxes to be placed in cells. The developer specifies the type of business rule (the action to be taken when a condition is met) and checks the box in the matrix table to complete the setup.

In this way, a low-code development platform makes it easy to configure dynamic screen updates, which can often be complex, without programming, minimizing the configuration burden and the occurrence of unintended bugs. The main features are as follows:

Feature 1: Dynamic screen updates that can be determined by values can be completed simply by setting conditions and business rules (trying to achieve control by setting logic flow would be cumbersome, and if values are rewritten after a determination is made, this could cause problems depending on the order in which actions are processed).

Feature 2: By separating conditions and business rules, settings that tend to become complicated can be simplified (conditions and states are managed in the database as separate items within the definition).

Feature 3: Business rules can be set in matrix format (complex business rules can be set on a single screen).

Feature 4: In addition to the matrix format settings, the information required for the settings can be easily checked, minimizing the setup costs even when developing large-scale applications.
1. Clicking on a condition (horizontal axis) will take you to the corresponding condition setting screen.
2. Clicking on the control (vertical axis) will highlight the displayed layout screen.
3. Clicking on a control on the layout screen selects (focuses on) a row in the matrix.

Feature 5: In large-scale systems, the number of configuration items tends to increase, so by using filters to limit the types of controls and conditions displayed in the matrix table, developers can prevent configuration errors.

Large-scale application screens can have a huge number of conditions and controls, which can make the configuration process a burden. However, by taking advantage of this feature and making it easier to check conditions and layouts, this burden can be reduced.

(A) Example of settings (Business rule: Lock)
On the business rule development screen, controls that are subject to dynamic update are extracted from the control information and condition information in the development application DB, and are displayed as a list on the vertical and horizontal axes, respectively.

Figure 26 shows an example of control information and condition information in the definition management table of the development application DB. Figure 27 is a diagram explaining controls that are subject to dynamic updates. In Figure 27, the low-code development platform stores attributes in an attribute table in the figure to determine whether each control element is subject to update for each business rule type. The attribute table specifies whether a control element (text, label, button, radio button, etc.) is subject to update for each business rule type (locked, hidden, required) (Yes: subject to update, No: not subject to update). The attribute table is registered in the memory and is referenced when displaying the business rule development screen to extract configurable controls from the control information for each business rule type. In this example attribute table, if the business rule type is locked, the label is not displayed in the list of target controls. If the business rule type is hidden, the label is displayed in the list of target controls.

Figure 28 shows an example of the business rule development screen. (A) shows an example when the business rule type is "locked," and (B) shows an example when the business rule type is "hidden."

As shown in Figure 28, the business rule development screen displays a matrix table with a list of controls on the vertical axis and a list of conditions on the horizontal axis. For simplicity's sake, the example screen only displays text and labels. As shown in (A), if the business rule type is locked, the label will not be displayed in the list of target controls due to the above attribute. As shown in (B), if the business rule type is hidden, the label will be displayed in the list of target controls due to the above attribute. By specifying the business rule type (the process to be performed when a condition is met) and checking boxes in the matrix table, the developer can set business rule information for the selected control and condition combination in the definition management table. In the example shown in (A), the cell for the combination of control "Corporate Number" and condition "Condition 1" is checked.

As shown in Figure 29, clicking on the condition on the horizontal axis will take you to the condition development screen.

As shown in Figure 30, when you click a control on the vertical axis, the screen information set on the layout development screen is displayed, and the row of the selected control is highlighted.

Figure 31 shows an example of business rule information set in the definition management table. Business rule information includes the business rule name, type, condition, and destination. The type is updated with the type of the selected business rule. The condition and destination are updated as a single business rule, with the combination of checked condition and control role items.

In the example shown in the figure, the business rule name is "Business Rule 1", the type is "Lock", the condition is "Condition 1", and the destination is "Corporate Number (Text)".

(B) About the filter function on the matrix screen As the scale of a system increases, the number of controls on the screen and the number of required conditions also increase. As a result, the matrix table also becomes larger, increasing the possibility of developers making configuration errors, such as forgetting to add settings or adding the wrong settings. Therefore, this system provides a filter function in the matrix table to minimize configuration errors by developers.

Figure 32 shows an example of a business rule development screen with a filter function added. In Figure 32, the business rule development screen has a field for selecting the filter being set and an Add Filter button. Clicking the Add Filter button transitions to the Add Filter screen. On the Add Filter screen, the developer sets the filter name, checks and selects the controls and conditions to be filtered, and clicks the Register button, which sets the filter information in the definition management table. In the example shown in Figure 32, the filter name "Customer Filter" is set, and the controls "Customer" and "Customer Name" and the condition "Condition 1" are selected. The list of controls and conditions on this screen is also obtained from the control information and condition information in the development application DB.

Figure 33 shows an example of filter information set in the definition management table. Filter information consists of a filter name, control element, and condition element. In the example shown in Figure 33, the filter name "Customer Filter", control elements "1. Customer" and "2. Customer Name", and condition element "1. Condition 1" are set.

Figure 34 is a diagram explaining the filter function of filter information. Registered filter information is registered in the definition management table (definition information), and when you select a filter on the business rule development screen, the conditions and controls that you have checked are displayed in a narrowed down view.

The top of Figure 34 shows an example of the business rule development screen, the bottom left shows an example of target control information and condition information when the filter is not set, and the bottom right shows an example of target control information and condition information when the filter is set to business partner. When a developer selects the filter they want to use when setting up on the business rule development screen, the controls and conditions that meet the conditions of the selected filter are extracted from the definition management table and displayed on the business rule development screen, narrowing down the controls and conditions.

In the example shown in Figure 34, the customer filter is selected, and the controls "Customer," "Customer Name," and "Condition 1" that meet the conditions of the customer filter are displayed.

(C) Advantages of the Matrix Screen In the example of customer master maintenance, one control (corporate number) was controlled for one condition (corporate classification), but as a more complex pattern, consider the case where multiple conditions are used to dynamically lock multiple controls. Figure 35 shows an example screen, Figure 36 shows an example of how to set a condition (amount excluding tax), and Figure 37 shows an example of how to set business rules.

In the example screen in Figure 35, four items are entered: tax category, amount excluding tax, consumption tax amount, and amount including tax. At this time, depending on the value of the tax category, the three controls for the amount excluding tax, consumption tax amount, and amount including tax are locked under different conditions.

If the tax category is 0 (tax exempt), the consumption tax amount text box and tax-inclusive amount text box are locked (tax exempt: the operator enters only the amount excluding tax).
If tax category = 1 (excluding tax), the tax-inclusive amount text box is locked (excluding tax: the operator enters the amount excluding tax and the amount of consumption tax).
If tax category = 2 (tax included), the tax-excluded amount text box is locked (tax included: the operator enters the tax-inclusive amount and the consumption tax amount).

Since the locking conditions are different for the tax-excluded amount, tax-included amount, and consumption tax amount, prepare conditions for each.
The amount excluding tax is locked with tax category = 2. The amount including tax is locked with tax category = 0 or 1. The amount of consumption tax is locked with tax category = 0.

As in the example above, if you want to dynamically update multiple screen items using different conditions, a matrix-style setup like this system allows you to link controls, conditions, and update types (lock in the example above) on a single screen, making the settings highly maintainable and readable, and very convenient for developers.

Figure 38 shows an example of business rule information registered in the definition management table in the above example.

(4) Flowchart for Reflecting Business Rules By making the above settings and publishing the definition management table information to the business application DB, it becomes possible to execute it as an application (see "Screen image at execution"). The published definition management table information is analyzed on the low-code execution platform and executed as an application. In particular, when reflecting business rules, the flowchart processing shown in Figure 39 is performed within the low-code execution platform. Figure 39 is a diagram showing a flowchart for reflecting business rules.

In Figure 39, when an event is triggered by an operator's screen operation (step S1), it is determined whether a logic flow has been assigned (step S2). If a logic flow has been assigned ("Yes" in step S2), the logic flow processing is executed (step S3) and the process proceeds to step S3. If a logic flow has not been assigned ("No" in step S2), the process proceeds to step S4.

In step S4, after the logic flow has been executed, the business rules to be judged are extracted. Next, a judgment is made for each business rule (step S5). Steps S5 to S17 are repeated in a loop until each business rule is completed (loop processing). The conditions assigned to the business rule to be looped are extracted (step S6), and branching is performed based on the type of business rule (step S7).

If the type is "lock," it is determined whether the condition is met (step S8). If the condition is met ("Yes" in step S8), the target control is locked (step S11) and the process proceeds to step S17. If the condition is not met ("No" in step S8), the target control is unlocked (step S12) and the process proceeds to step S17.

If the type is "Hidden," it is determined whether the condition is met (step S9). If the condition is met ("Yes" in step S9), the target control is made invisible (step S13) and the process proceeds to step S17. If the condition is not met ("No" in step S9), the target control is made visible (step S14) and the process proceeds to step S17.

If the type is "Required," it is determined whether the condition is met (Step S10). If the condition is met ("Yes" in Step S10), the target control is made required (Step S15) and the process proceeds to Step S17. If the condition is not met ("No" in Step S10), the target control's required status is cancelled (Step S16) and the process proceeds to Step S17.

In step S17, it is determined whether any undetermined business rules exist. If any undetermined business rules exist ("Yes" in step S17), the process returns to step S5 and loops through steps S4 to S16 until no undetermined business rules exist. If no undetermined business rules exist ("No" in step S17), the process ends.

Figure 40 is a diagram explaining the features of the flowchart in Figure 39. There are two cases in which values on the screen are changed: changes on the client side and changes on the server side. (1) A change on the client side occurs when a business operator changes a value directly. (2) A change on the server side occurs when a screen update action (one of the actions that can update values on the screen) is executed.

As shown in Figure 40 (A), in step S1, (1) if the business operator changes the value directly, the value is finalized before the event is fired. In step S3, (2) if the value is changed by a screen update action, the value is finalized within the logic flow processing.

Figure 40 (B) shows an example logic flow that calls a screen update action. For example, an action that updates a value on the screen updates the corporate classification to "1."

Figure 40 (C) shows an example of the Customer Master Maintenance (edit screen). When a logic flow is executed, the screen update action updates the values on the screen, which also affects the logic flow's judgment.

When an action that updates a value on the screen is included, such as in the example logic flow that calls a screen update action, it is not known at what point in the logic flow the screen update will occur, so the value on the screen cannot be finalized until the end action is completed.

For this reason, business rules are always judged after the logic flow is completed, and the separation of these two types of processing is a major feature.

(5) Complexity of management when dynamic updates are implemented using action processing. Referring to Figures 41 and 42, we will explain the case of implementing dynamic updates using only logic flow and action mechanisms, without providing a business rule mechanism. This is likely to be the case in typical low-code development. In Figure 41, when state control actions such as locking and display/hide are prepared and executed within a logic flow, the state control actions are distributed across multiple logic flows. As a result, it becomes difficult for developers to develop and maintain a comprehensive view. It is difficult to identify and properly manage the state control-related parts of multiple logic flows.

Also, in Figure 42, when screen values are rewritten on the server side, as in the screen update action mentioned above, the results of state control may change depending on the rewritten values. Therefore, if the server does not understand when values change and perform state control at the appropriate time, there is a risk of incorrect settings being made.

As such, if you try to complete processing using only logic flow and actions, the number of things that developers have to consider increases, making the system difficult to configure.

As described above, this embodiment includes a screen control unit 102a that displays a matrix-format business rule development screen with the control from the control information on one axis and the condition from the condition information on the other axis for the selected state control type, and a setting unit 102b that selects a control and condition pair by selecting a matrix cell on the business rule development screen and registers business rule information including the selected state control type, condition, and control in the definition management table, allowing developers to easily configure state control for screen items.

[5. Contribution to the United Nations-led Sustainable Development Goals (SDGs)]
This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby contributing to the achievement of SDGs Goals 8 and 9.

Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to SDGs goals 12, 13, and 15.

Furthermore, this embodiment can contribute to strengthening control and governance, thereby contributing to Goal 16 of the SDGs.

6. Other Embodiments
The present invention may be implemented in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

In addition, the processing procedures, control procedures, specific names, registered data for each process, information including parameters such as search conditions, screen examples, and database configurations shown in this specification and drawings may be changed as desired unless otherwise specified.

Furthermore, with regard to the business rule setting device 100, the components shown in the figure are functional concepts and do not necessarily have to be physically configured as shown.

For example, all or any part of the processing functions of the business rule setting device 100, particularly the processing functions performed by the control unit, may be implemented by a CPU and a program interpreted and executed by the CPU, or may be implemented as hardware using wired logic. The program is recorded on a non-transitory, computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processes described in this embodiment, and is mechanically read by the business rule setting device 100 as needed. In other words, a computer program that works in conjunction with the OS to issue commands to the CPU and perform various processes is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive). This computer program is executed by being loaded into RAM, and works in conjunction with the CPU to form the control unit.

In addition, this computer program may be stored on an application program server connected to the business rule setting device 100 via any network, and all or part of it may be downloaded as needed.

In addition, the program for executing the processing described in this embodiment may be stored on a non-temporary computer-readable recording medium, or may be configured as a program product. Here, this "recording medium" includes memory cards, USB (Universal Serial Bus) memories, SD (Secure Digital) cards, flexible disks, magneto-optical disks, ROMs, EPROMs (Erasable Programmable Read Only Memory), EEPROMs (registered trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROMs (Compact Disk Read Only Memory), MOs (Magneto-Optical disks), DVDs (Digital Versatile Disks), and more. This includes any "portable physical media" such as a Blu-ray Disc (registered trademark) and a Blu-ray (registered trademark) Disc.

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. It should be noted that a "program" is not necessarily limited to a single structure, but also includes a distributed structure consisting of multiple modules or libraries, or a structure that achieves its function by working in conjunction with a separate program, such as an OS. The specific structure and reading procedure for reading a recording medium in each device shown in the embodiments, as well as the installation procedure after reading, can use well-known structures and procedures.

The various databases stored in the memory unit are storage devices such as memory devices such as RAM and ROM, fixed disk devices such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and website provision.

The business rule setting device 100 may also be configured as an information processing device such as a known personal computer or workstation, or as an information processing device connected to any peripheral device. The business rule setting device 100 may also be implemented by installing software (including programs, data, etc.) that causes the device to perform the processing described in this embodiment.

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or functional loads. In other words, the above-mentioned embodiments may be implemented in any combination, or embodiments may be implemented selectively.

This invention can be used in all business sectors and industries.

100 Business rule setting device 102 Control unit
102a Screen control unit
102b Setting unit 104 Communication interface unit 106 Storage unit
106a Development application DB
108 Input/output interface unit 112 Input device 114 Output device 200 Server 300 Network

Claims (6)

A business rule setting device for allowing a developer to set business rules , the device comprising a control unit and a storage unit,
The storage unit includes:
Control information including control name and properties,
Condition information including a condition name and a condition expression, which is used to determine dynamic control;
A rule that specifies how to dynamically update the set control when the set condition is true. Business rule information including the type of state control, condition, and control.
It contains a table containing
a screen control means for displaying a business rule development screen in a matrix format with the control of the control information on one axis and the condition of the condition information on the other axis for the selected type of state control;
a setting means for selecting a set of a control and a condition by selecting a cell in a matrix on the business rule development screen, and registering business rule information including the type, condition, and control of the selected state control in the table;
Equipped with
The business rule setting device is characterized in that the screen control means has a filter function that limits the display of conditions and controls on the business rule development screen in accordance with operations by a developer on the business rule development screen . The business rule setting device of claim 1, wherein the type of state control includes locked, hidden, or required. The business rule setting device of claim 1, wherein the screen control means displays the screen information set in the layout screen for a control on one axis when that control is selected on the business rule development screen, and displays the condition setting screen for that condition when a condition on the other axis is selected. The business rule setting device according to any one of claims 1 to 3 , characterized in that in an application that becomes executable when the table is made public, a judgment is made on each business rule after all logic flows have been executed. A business rule setting method executed by a business rule setting device for allowing a developer to set business rules, the business rule setting device comprising a control unit and a storage unit,
The storage unit includes:
Control information including control name and properties,
Condition information including a condition name and a condition expression, which is used to determine dynamic control;
Business rule information including the type of state control, condition, and control, which is a rule that specifies what updates should be made dynamically to the set control when the set condition is true;
It contains a table containing
Executed in the control unit:
a screen control step of displaying a business rule development screen in a matrix format with the control of the control information as one axis and the condition of the condition information as the other axis for the selected type of state control;
a setting step of selecting a set of a control and a condition by selecting a cell of a matrix on the business rule development screen, and registering business rule information including the selected state control type, condition, and control in the table;
Including,
A business rule setting method characterized in that the screen control step is provided with a filter function that limits the display of conditions and controls on the business rule development screen in accordance with operations by a developer on the business rule development screen . A business rule setting program for a developer to set business rules, the business rule setting program comprising a control unit and a storage unit, and to be executed by a business rule setting device ,
The storage unit includes:
Control information including control name and properties,
Condition information including a condition name and a condition expression, which is used to determine dynamic control;
A rule that specifies how to dynamically update the set control when the set condition is true. Business rule information including the type of state control, condition, and control.
It contains a table containing
The control unit
a screen control step of displaying a business rule development screen in a matrix format with the control of the control information as one axis and the condition of the condition information as the other axis for the selected type of state control;
a setting step of selecting a set of a control and a condition by selecting a cell of a matrix on the business rule development screen, and registering business rule information including the selected state control type, condition, and control in the table;
It is a business rule setting program for executing
The screen control process is characterized by having a filter function that limits the display of conditions and controls on the business rule development screen in accordance with operations by a developer on the business rule development screen.