Application provision system, application provision method, and application provision program

Abstract

To enable the management of duplicate control settings by making them common.SOLUTION: A control unit is provided with a setting unit for setting common control definitions in a common control definition management table according to the developer's operations on a common control setting screen. This setting unit adds common controls from the common control definition management table to control information in the definition management table according to the developer's operations on a business application creation screen. As a result, duplicated settings on each screen can be made common and associated with controls in advance for use. Therefore, a programmer can implement necessary functions simply by using common controls, without having to configure settings related to controls from scratch, and only the minimum required settings need to be made.SELECTED DRAWING: Figure 35

Description

[Technical Field]

[0001] The present invention relates to an application providing system, an application providing method, and an application providing program. [Background technology]

[0002] Today, low-code development is known, which allows application programs to be developed quickly, without writing source code as much as possible, by combining screen or logic components through visual operations called a GUI (Graphical User Interface).

[0003] Patent Document 1 (JP 2023-057944 A) discloses an information processing device that simplifies input work when creating forms, application documents, etc. This information processing device is a low-code development web server device in which an action setting unit sets a save area definition that indicates a save area to be saved within an area on a display screen. A control setting unit sets a control definition that indicates controls that are at least display items or operation buttons to be placed within the save area set by the save area setting unit. Furthermore, a dynamic restoration target setting unit sets, among the controls, controls whose values ​​are dynamically updated and displayed the next time the screen is displayed or thereafter as dynamic restoration target control definitions.

[0004] The storage control unit associates the save area definition, the control definition, and the dynamic restoration target control definition as child elements of the save area definition, and stores the save area definition, the control definition, and the dynamic restoration target control definition in a hierarchical structure in the storage unit. This simplifies the input work when creating forms, application documents, etc. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Publication No. 2023-057944 Summary of the Invention [Problem to be solved by the invention]

[0006] In low-code development, developers create systems by dragging and dropping controls (UI: User Interface) and assigning necessary settings, such as API (Application Programming Interface) execution, to events related to those controls (for buttons, click events are common).

[0007] In large-scale business applications, the same function (such as a search function) is often used on multiple screens. Therefore, when setting the same function in an application, even if the application program screens on which the control is used are different, it is likely that there will be many overlapping settings.

[0008] When developing an application using low-code, duplicating the same settings in multiple places increases the cost of configuration and can lead to problems due to incorrect corrections. For this reason, it is preferable to share and manage duplicated settings.

[0009] The present invention has been made in consideration of the above-mentioned problems, and aims to provide an application providing system, an application providing method, and an application providing program that enable overlapping control settings to be shared and managed. [Means for solving the problem]

[0010] In order to solve the above-mentioned problems and achieve the object, the application provision system of the present invention is an application provision system that has a control unit and is configured to be able to communicate data with developer and user clients, wherein the control unit is configured to be able to access a database that stores: a definition management table that associates and registers control information that specifies a definition ID, a definition name, an ID for each control, an identification name, and a control type; logic flow information that specifies an ID for each element of a logic flow, a previous action ID, and a next action ID; and action information that specifies an ID, name, type, API, argument, and return value for each action element; and a common control definition management table that specifies common control definitions common to multiple business applications and associates and registers definition IDs, definition names, common control types, and setting contents; the control unit has a setting unit that sets common control definitions in the common control definition management table in accordance with operations by the developer on a common control setting screen, and the setting unit adds common controls in the common control definition management table to the control information in the definition management table in accordance with operations by the developer on the business application creation screen.

[0011] In addition, in order to solve the above-mentioned problems and achieve the object, the application provision method of the present invention is an application provision method for an application provision system that has a control unit and is configured to be able to communicate data with developer and user clients, wherein the control unit is configured to be able to access a database that stores: a definition management table that associates and registers control information that specifies a definition ID, a definition name, an ID for each control, an identification name, and a control type; logic flow information that specifies an ID for each element of a logic flow, a previous action ID, and a next action ID; and action information that specifies an ID, name, type, API, argument, and return value for each action element; and a common control definition management table that associates and registers definition IDs, definition names, common control types, and setting contents, which specifies common control definitions common to multiple business applications; and the control unit executes a setting step that sets the common control definition in the common control definition management table in accordance with the developer's operation on the common control setting screen, and in the setting step, adds the common controls in the common control definition management table to the control information in the definition management table in accordance with the developer's operation on the business application creation screen.

[0012] In addition, in order to solve the above-mentioned problems and achieve the object, the application provision program of the present invention is an application provision program of an application provision system that has a control unit and is configured to be able to communicate data with developers and users' clients, the control unit is configured to be able to access a database that stores: a definition management table that associates and registers control information that specifies a definition ID, a definition name, an ID for each control, an identification name, and a control type; logic flow information that specifies an ID for each element of a logic flow, a previous action ID, and a next action ID; and action information that specifies an ID, name, type, API, argument, and return value for each action element; and a common control definition management table that associates and registers definition IDs, definition names, common control types, and setting contents, which specifies common control definitions common to multiple business applications; and causes the control unit to execute a setting step that sets a common control definition in the common control definition management table in accordance with operations by the developer on the common control setting screen, and in the setting step, adds common controls in the common control definition management table to the control information in the definition management table in accordance with operations by the developer on the business application creation screen. [Effects of the Invention]

[0013] The present invention makes it possible to share and manage overlapping setting portions of controls. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 illustrates an example of a configuration of an application providing system (Web server) according to an embodiment. [Figure 2] Figure 2 shows an overview of low-code development tools. [Figure 3] FIG. 3 is a diagram showing an example of a definition management table of the business application DB in which registered UI definitions are stored. [Figure 4]FIG. 4 is a diagram showing an example of a development application DB in which control information is registered by a developer. [Figure 5] FIG. 5 is a diagram showing that a text box for inputting a reference date has been selected from the date text and placed. [Figure 6] FIG. 6 shows an error message that appears when the business operator attempts to proceed with the process without inputting the base date. [Figure 7] FIG. 7 is a diagram showing how logic flow information and action information are registered in the development application DB by a developer operating the logic flow and action development screen. [Figure 8] FIG. 8 is a diagram illustrating an example of a logic flow. [Figure 9] Figure 9 shows the state in which the business logic that is called from the UI side generated by the low-code development tool is converted into an API and registered in the API master. [Figure 10] FIG. 10 is a diagram for explaining an example in which a developer selects a necessary API from an API master that stores APIs registered in advance and sets arguments and return values. [Figure 11] FIG. 11 is a diagram showing how information (ID, name, action type, and each setting, etc.) set for each action is set in the action information of the definition management table. [Figure 12] FIG. 12 is a diagram showing how information set for each logic flow (ID, name, flow group connecting actions, etc.) is set in the logic flow information of the definition management table. [Figure 13] FIG. 13 is a diagram showing how, in the development stage, a developer allocates logic flows to each control on a layout development screen, thereby registering linking information in a definition management table of a development application DB. [Figure 14] FIG. 14 is a diagram showing how registered flows are listed in a pull-down format in the event item of the control properties. [Figure 15]FIG. 15 is a diagram showing how the ID of a control (display button), an event type, and the ID of a logic flow (logic flow 1) are registered in association with each other in the logic flow information of the definition management table. [Figure 16] FIG. 16 is a diagram showing how, in the usage stage, when a business operator presses the display button, the low-code execution platform executes the logic flow assigned to the display button. [Figure 17] FIG. 17 shows an example of the slip list screen and the business establishment search dialog. [Figure 18] FIG. 18 is a diagram showing a process list relating to the code search function. [Figure 19] FIG. 19 is a diagram for explaining a specific example of processing when a predetermined portion of the establishment text box is clicked. [Figure 20] FIG. 20 is a diagram for explaining a specific example of processing when the list in the establishment text box is selected. [Figure 21] FIG. 21 is a diagram for explaining a specific example of processing when the establishment button is clicked. [Figure 22] FIG. 22 is a diagram for explaining a specific example of processing when a value in the establishment text box is directly entered. [Figure 23] FIG. 23 is a diagram showing an example of a menu screen of a low-code development tool. [Figure 24] FIG. 24 is a diagram showing an example of the common control setting screen. [Figure 25] FIG. 25 shows an example of a common control setting screen (when setting text boxes) and an image of a list display state. [Figure 26] FIG. 26 is a diagram showing how a display item is selected from a drop-down list. [Figure 27] FIG. 27 is a diagram showing an example of an API return value set in a text box after a selection is made from the drop-down list. [Figure 28] FIG. 28 is a diagram for explaining the processing content performed on the dialog screen. [Figure 29] FIG. 29 is a diagram for explaining the screen closing action. [Figure 30] FIG. 30 is a diagram for explaining the screen activation action. [Figure 31] FIG. 31 shows records registered in the definition management table. [Figure 32] FIG. 32 shows an example of a common control setting screen (when setting buttons) and an image of a list display state. [Figure 33] FIG. 33 is a diagram showing an example of the common control definition list screen after registration. [Figure 34] FIG. 34 is a diagram showing an example of a registered common control definition management table. [Figure 35] FIG. 35 is a diagram showing the controls of the base date text box, the establishment search common control (single), the display button, and the spread. [Figure 36] FIG. 36 shows the setting items and designated contents of the common control. [Figure 37] FIG. 37 is a diagram showing an example of the common control setting screen. [Figure 38] FIG. 38 is a diagram illustrating an example of property settings for a common control. [Figure 39] FIG. 39 is a diagram showing an example in which the establishment search common control definition is arranged on a spreadsheet. [Figure 40] FIG. 40 is a diagram showing an example of setting properties of a common control. [Figure 41] FIG. 41 is a diagram showing an example of registration of a common control (single). [Figure 42] FIG. 42 is a diagram showing an example of registration of common controls (details). [Figure 43] FIG. 43 is a diagram showing the layout or setting information of each cell in the spread control. [Figure 44] FIG. 44 is a diagram showing an outline of the hierarchical structure of the spread control. [Figure 45] FIG. 45 is a diagram for explaining the details of the hierarchical structure of the spread control. [Figure 46] FIG. 46 is another diagram for explaining the details of the hierarchical structure of the spread control. [Figure 47] FIG. 47 is a diagram for explaining a multi-stage spread that is realized by increasing the number of rows of the grid in the spread and setting row and column indices of the control cells. [Figure 48] FIG. 48 is a diagram showing an example in which cell merging is set by increasing each span information of the cell matrix. [Figure 49] FIG. 49 is a diagram for explaining an example in which, in the case of a multi-stage spread, data rows are divided and different common control settings are made for each row. [Figure 50] FIG. 50 is another diagram for explaining an example in which data rows of a multi-column spread are divided and different common control settings are made for each. [Figure 51] FIG. 51 is a diagram showing an example in which a pair of common controls is correctly arranged in consecutive cells that make up the common control cell. [Figure 52] FIG. 52 is another diagram showing an example in which a pair of common controls is correctly arranged in consecutive cells that make up a common control cell. [Figure 53] FIG. 53 shows an example in which an error occurs because a pair of different types of common controls are placed in consecutive cells that make up a common control cell. [Figure 54] FIG. 54 is another diagram showing an example in which an error occurs because a pair of different types of common controls are placed in consecutive cells that make up a common control cell. [Figure 55] FIG. 55 is a flowchart for explaining the application conversion process (single) of the common control definition in the use stage. [Figure 56] FIG. 56 is a diagram for explaining the operation of adding a normal control corresponding to a common control to the control information. [Figure 57] FIG. 57 is a diagram for explaining the operation of converting a property reference portion of a code search common control into a normal control. [Figure 58] FIG. 58 is a diagram for explaining the operation of combining the acquisition API argument information and the common control definition and converting them into pull-down information for the text box. [Figure 59] FIG. 59 shows a state in which pull-down information required for a text box is associated with the text box on the definition management table. [Figure 60] FIG. 60 shows a logic flow generated based on verification API argument information, and a definition management table to which new logic flow information and action information elements of the UI definition have been added. [Figure 61] FIG. 61 is a diagram showing the state in which the logic flow and action information generated from the establishment verification API argument information and establishment verification API return value information are stored in association with the text boxes of the common control definition management table. [Figure 62] FIG. 62 is a diagram showing an example in which linking information for a control ID "establishment text", an event type "verification", and a logic flow ID "logic flow M" is added. [Figure 63] FIG. 63 shows an automatically generated logic flow that separates processing into selection and cancellation on the dialog, and a definition management table to which logic flow information and action information corresponding to the generated logic flow have been added. [Figure 64] FIG. 64 shows a definition management table and a common control definition management table that are referenced when generating a logic flow that divides processing into selection and cancellation on a dialog. [Figure 65] FIG. 65 is a diagram showing how the created logic flow is added to the definition management table via the linking information. [Figure 66]FIG. 66 is a diagram showing the control information, logic flow information, and linking information in a state where the common control has been deleted. [Figure 67] FIG. 67 shows the action information in a state where the common control has been deleted. [Figure 68] FIG. 68 is a flowchart for explaining the application conversion process (details) of the common control definition in the use stage. [Figure 69] FIG. 69 is a diagram for explaining how to specify a pair of common controls in a common control cell. [Figure 70] FIG. 70 shows cells added to the control information in common control cells (text, button, label). [Figure 71] FIG. 71 shows how the value of the establishment search common control cell (details) is converted into the value of the establishment text cell. [Figure 72] FIG. 72 shows how pull-down information required for a text box is generated and associated with the text box on the definition management table. [Figure 73] FIG. 73 is a diagram showing how the establishment verification API arguments and establishment verification API return values ​​of the common controls in the definition management table are converted into logic flow information and action information and added to the common control definition management table. [Figure 74] FIG. 74 is a diagram for explaining linking information for linking the created logic flow to an event in a text box. [Figure 75] FIG. 75 is a diagram showing how the logic flow information and action information of the generated logic flow are added to the definition management table. [Figure 76] FIG. 76 is a diagram showing how the created logic flow is added to the definition management table via the linking information and associated with a predetermined event. [Figure 77]FIG. 77 is a diagram for explaining the operation of deleting a common control cell (details) from the control information of the definition management table. [Figure 78] FIG. 78 is another diagram for explaining the operation of deleting a common control cell (details) from the control information of the definition management table. DETAILED DESCRIPTION OF THE INVENTION

[0015] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A task support device according to an embodiment of the present invention will be described in detail below with reference to the accompanying drawings. However, the present invention is not limited to the following embodiment.

[0016] [Hardware configuration] First, FIG. 1 is a diagram showing an example of the configuration of an application providing system 100 (Web server) according to an embodiment. As shown in FIG. 1, the application providing system 100 according to an embodiment can be configured, for example, on a low-code platform (low-code development platform / low-code execution platform). It may also be configured on a no-code platform.

[0017] The application providing system 100 includes a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. The units included in the application providing system 100 are connected to each other so as to be able to communicate with each other via any communication path.

[0018] The communication interface unit 104 communicably connects the application providing system 100 to a 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 a function of communicating data with other devices via a communication line. Here, the network 300 has a function of communicably connecting the application providing system 100 with Web clients (clients used by developers and clients used by business operators (users)) 400, etc., and business systems (not shown), and is, for example, the Internet or a LAN (Local Area Network). Note that the data stored in the storage unit 106 (described later) may be stored in a data server (not shown) or the like.

[0019] 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 cooperation with a mouse. In the following, 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.

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

[0021] The storage unit 106 includes a development application DB 106a that stores various setting information at the development stage, a business application DB 106b that makes public the application information of the development application DB 106a, and the like.

[0022] The development application DB 106a stores a definition management table, a pull-down definition management table, a common control definition management table, an API management table, and the like.

[0023] The definition management table is a table that associates and registers the following: definition ID, definition name, control information that specifies the ID, identification name, and control type for each control, logic flow information that specifies the ID, previous action ID, and next action ID for each logic flow element, action information that specifies the ID, name, type, API, argument, and return value for each action element, and linking information that specifies the control ID, event type, and logic flow ID for each linked element. Common controls from the common control definition management table are added to the definition management table.

[0024] The pulldown definition management table is a table in which IDs, pulldown names, API IDs for linking with the API management table, return values, display items, etc. are registered in association with each other.

[0025] The common control definition management table is used to define common control definitions that are common to multiple business applications, and is a table in which definition IDs, definition names, common control types, and setting contents are registered in association with each other.

[0026] The API management table is a table in which IDs, method names, API names, arguments (ID, name, type), return values ​​(ID, name, type), etc. are registered in association with each other.

[0027] The control unit 102 is a CPU or the like that performs overall control of the application providing system 100. The control unit 102 has an internal memory for storing control programs such as an OS, programs that define various processing procedures, required data, etc., and executes various information processes based on these stored programs.

[0028] The control unit 102 conceptually includes a setting unit 102a and an execution unit 102b.

[0029] The setting unit 102a functions as a low-code development platform, creates setting information (definitions) related to the provision of business applications, and registers the information in the development application DB 106a.

[0030] For example, the setting unit 102a provides a common control setting screen in response to a request from a web client 400 (developer), and creates a common control definition management table in response to the developer's operations on the common control setting screen, and registers the table in the development application DB 106a.

[0031] In addition, the setting unit 102a provides a business application creation screen in response to a request from a Web client 400 (developer), and adds (sets) common controls in the common control definition management table to the control information in the definition management table in response to the developer's operations on the business application creation screen.

[0032] The execution unit 102b functions as a low-code execution platform and provides business applications in response to requests from the web client 400 (user = business operator).

[0033] When the execution unit 102b receives a launch instruction from the Web client 400 (user), it launches the business application. Specifically, it reads the application information of the business application from the definition management table, and if the control information in the definition management table includes a search-type common control, it adds a control including at least two of the common control's value specification area and dialog display button to the control information, combines the common control's pull-down display command argument information with the common control definition and converts it into pull-down information for the value specification area, and if the common control definition is set to use the dialog display button, it converts the dialog display command argument information into logic flow information and action information, links the created logic flow information to the dialog display button event, deletes the common control from the control information, and performs the business application launch process in accordance with the UI definition of the converted business application.

[0034] In addition, if the search type is a code search type, the execution unit 102b further converts the property reference points of the code search type common control into normal controls, converts the verification API argument information and verification API return value information of the common control into logic flow information and action information, and links the created logic flow information to the text box event.

[0035] [Application provision system functions] Next, the application providing system 100 according to the embodiment is an application providing system configured to be able to communicate data with developers and users' clients. The control unit 102 executes a business support program stored in the storage unit 106, thereby functioning as a setting unit 102a and an execution unit 102b, as shown in FIG.

[0036] The control unit 102 can also access a database that stores the following types of information: The database stores a definition ID, a definition name, control information that specifies the ID, identification name, and control type for each control, and logic flow information that specifies the ID, previous action ID, and next action ID for each element of the logic flow.

[0037] The database also stores a definition management table that associates and registers action information that specifies the ID, name, type, API, arguments, and return value for each action element, and a common control definition management table that specifies common control definitions that are common to multiple business applications and associates and registers definition IDs, definition names, common control types, and setting contents.

[0038] The control unit 102 also includes a setting unit 102a that sets common control definitions in the common control definition management table in response to operations by the developer on the common control setting screen. This setting unit 102a adds common controls in the common control definition management table to the control information in the definition management table in response to operations by the developer on the business application creation screen.

[0039] In addition, the setting unit 102a adds a single-type common control, which is a single control and is decomposed into specified components when the application is converted, as a common control in the common control definition management table to be added to the control information in the definition management table in response to the developer's operations on the business application creation screen (see Figure 37).

[0040] In addition, the setting unit 102a adds a detailed common control, which is an independent control cell for each of multiple cells, as a common control in the common control definition management table to be added to the control information of the definition management table in response to the developer's operations on the business application creation screen (see Figure 39).

[0041] The control unit 102 also includes an execution unit 102b that launches a business application upon receiving a launch instruction from a user. Upon receiving a launch instruction from a user, the execution unit 102b reads application information for the business application from the definition management table, and if the control information in the definition management table includes the single-type common control, adds controls of a text box, a button, and a label to the control information.

[0042] The execution unit 102b also converts the property reference portion of the common control into a normal control, combines API argument information with the common control definition to generate pull-down information for the control, associates it with the control information in the definition management table, generates a desired logic flow based on the API argument information, and associates the logic flow information and action information of the logic flow with the control information in the definition management table.The execution unit 102b then deletes the common control from the control information and performs startup processing for the business application in accordance with the UI definition of the converted business application (see FIG. 55).

[0043] Furthermore, when the execution unit 102b receives an instruction from a user to launch a business application, it reads the application information of the business application from the definition management table, and if the control information in the definition management table includes the detail-type common control, it obtains the common control button cell and label cell from the control information, which have text cell information as the target cell.

[0044] In addition, the execution unit 102b adds a normal control cell corresponding to each common control cell to the control information, converts the property reference part of the common control cell to a normal control, combines the API argument information with the common control definition to generate pull-down information for the text cell, and associates it with the control information on the definition management table.

[0045] In addition, the execution unit 102b generates the desired logic flow based on the API argument information, associates the logic flow information and action information of the logic flow with the control information on the definition management table, deletes common controls from the control information, and performs startup processing of the business application in accordance with the UI definition of the converted business application (see Figure 68).

[0046] Furthermore, when generating a logic flow, if the control is a button control, the execution unit 102b generates a logic flow that divides the processing into processing when a selection is made by operating a button on the dialog and processing when the selection is canceled (see FIG. 63).

[0047] Such an application provision system is, for example, constructed on a low-code or no-code basis.

[0048] [Example of processing] A specific example of the processing of the application providing system 100 (Web server) of this embodiment will be described with reference to Fig. 2 to Fig. 47. Fig. 2 to Fig. 47 are diagrams for explaining a specific example of the processing of the application providing system 100 of this embodiment.

[0049] [About low-code development tools] 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, where developers use low-code development tools to create UI settings and business logic for business applications, and the usage stage, where business operators actually use the applications.

[0050] Figure 2 shows an overview of the low-code development tool. The development stage is when a developer uses 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."

[0051] 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 for managing application settings used by developers will be referred to as the "development application DB," and the database for managing application settings used by business operators will be referred to as the "business application DB."

[0052] (1) Development stage As shown in the upper half of Figure 2, the development stage is where developers use low-code development tools (the low-code development platform) 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 during the development stage are as follows (A) to (C).

[0053] (A) Layout development Configure the screen layout of the business application.

[0054] (B) Logic flow development and action development This sets the processing part of the business application. With low-code development tools, the processing in the business application can be set 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."

[0055] 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 the API call action.

[0056] (C) Combining layout and logic flow Set the logic flow (B) to be assigned to the layout set in (A).

[0057] (2) Use stage As shown in the lower half of Figure 2, the usage stage is when the low-code development tool (on the low-code execution platform) analyzes the registered business application settings, converts them into a business application, and then the business operator operates the business application. Operational tests performed before delivery are also conducted on the created business application.

[0058] (3) Setting up low-code development tools This section explains how developers configure low-code development tools. By configuring low-code development tools, developers can generate parts other than business logic without having to program them themselves. Application configuration using low-code development tools will be referred to as "UI definition" in the following explanation.

[0059] The registered UI definitions are saved in the definition management table (see Figure 3) of the business application database. The definition management table manages the control information, logic information, and information linking the layout and logic within the definition. 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 "(A) Layout Development" below. Action Information: See "(B) Logic Flow and Action Development" below. ·Logic flow information···See "(B) Logic flow and action development" below. Linking information: See "(C) Combining layout and logic" below.

[0060] (A) Layout development During the development stage, developers register control information in the development application DB by operating the layout development screen (see Figure 4). For example, in the example screen shown in Figure 5, a text box for entering the base date has been selected from the date text and placed. Clicking on the placed control allows you to set the properties according to the type of control clicked. For example, date text has a required property that indicates whether its input is required by the application. In the example screen shown in Figure 5, the required property is ON, so the base date text is a control that must be entered by the application.

[0061] In the usage stage, an application is generated based on the settings. In the example shown in Figure 5 described in the previous paragraph, the base date is required, so if the business operator attempts to proceed without entering the base date, an error will be displayed as shown in Figure 6.

[0062] (B) Logic flow and action development During the development stage, developers operate the logic flow and action development screen to register logic flow information and action information in the development application DB (see Figure 7). Figure 8 shows an example of the logic flow development screen. It shows an example of an API call action placed in a flow. The initial state of logic flow settings in low-code development tools is a state in which the flow is connected between a start action that starts processing and an end action that ends processing. Settings are made by incorporating the necessary actions between these two actions as shown in Figure 8.

[0063] In the example logic flow in Figure 8, 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 a low-code development tool and business logic created by a developer. As preparation, developers convert the business logic they want to call from the UI created with the low-code development tool into an API (see the top of Figure 9) and register it in the API master (see the bottom of Figure 9).

[0064] This section explains how to turn business logic into an API. As shown in the upper part of Figure 9, source code that describes processing as an API is created in the module used in the low-code execution platform. In other words, the actual processing of the business logic to be executed and key information that will be required later when calling the API are managed.

[0065] The low-code development platform reads the information required to execute the API (method name, arguments, return value information, etc.) from the low-code execution platform module and registers it in the API management table as shown in the lower part of Figure 9.

[0066] In the example at the top of Figure 9, the low-code execution platform registers an API such as a customer data acquisition process 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.

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

[0068] The action information will now be explained. As shown in Figure 11, 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 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 ​​(customer CD and customer name, etc.) are set in the customer CD text cell and customer name text cell on the screen, and this information is registered.

[0069] The logic flow information will now be explained. As shown in Fig. 12, the logic flow information in the definition management table contains information set for each logic flow (such as ID, name, and flow group connecting actions). 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.

[0070] (C) 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 definition management table of the development application DB (see Figure 13). The controls and flows created in "(A) Layout development" and "(B) Logic flow and action development" are assigned. As shown in Figure 14, 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.

[0071] The following explains the linking information. As shown in Fig. 15, the logic flow information in the definition management table registers three pieces of information linked together: 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 specified using only the control ID, so the event type must be included in the linking information (e.g., text box validation processing and exit processing).

[0072] In the usage stage, when a business operator presses the display button, the low-code execution platform executes the logic flow assigned to the display button (see Figure 16). In the example of Figure 16, when the display button is pressed, the API is executed with the base date (2022 / 04 / 01) as an argument. The API call process is started, the configured API (customer data retrieval process) is executed, and the customer information (customer code and customer name) as of the base date is returned as the return value, referencing the customer master.

[0073] [About the code search function] This section explains the code search function, which is frequently used in ERP systems, etc. This function itself is commonly used in ERP systems, etc., and is a functional requirement that is a prerequisite for the invention.

[0074] The code search function refers to the function that displays the name in an adjacent label after a code is selected for a text box. This type of mechanism is generally provided by a UI such as a "combo box" or "drop-down list." A "drop-down list" is a control that allows the user to display a list of selectable values ​​by clicking on the text portion. Application users cannot directly enter values ​​into the text portion. A "combo box" is a control that has the functionality of both a drop-down list and a text box. Unlike a drop-down list, application users can directly enter values ​​into the text portion. The following explanation uses a combo box type text box as an example.

[0075] There are three ways to set a value in the text field: (1) Selecting from a list in a text box (2) Direct input without using a list (3) Selecting a value from a dialog box launched by clicking a button

[0076] The following explanation uses the slip list as an example. Figure 17 shows an example of the slip list screen and the business establishment search dialog. The slip list screen is a screen that displays a list of slips registered in the database by narrowing down the conditions. It obtains a list of slips registered for the period from the start date of occurrence to the end date of occurrence for the business establishment specified as a condition. The base date is used to check the existence of the business establishment, and an error will be displayed if a business establishment that does not exist as of the base date is specified as a condition. Pressing the business establishment button "···" on the slip list screen will launch the business establishment search dialog.

[0077] To specify the establishment as a condition, the application user must specify the establishment from among the establishments registered in the establishment master. The code search function is often used in such cases.

[0078] The code search function is often made up of three controls: a text box, a button, and a label. The text box has the function of displaying a list of selectable data by clicking the ▽ part. The button has the function of calling up a separate screen specialized for the search function. This is because lists are sometimes unsuitable when dealing with large amounts of data. The button is often used to display a separate advanced search dialog when simply selecting a value from the list in the text box is not sufficient for the search function. The label has the function of displaying the name of the master corresponding to the code entered in the text box.

[0079] The application developer must assign an event to each control in the code search function beforehand during development. When the application user performs an operation, the event is triggered and the process assigned to the event is executed.

[0080] Figure 18 shows an example of a list of processes related to the code search function. The operations performed by the application user and their main processing contents are as follows: Clicking "1-1: Click the ▽ part of the establishment text box" will execute the establishment acquisition process. If you select "1-2: Select the list in the business establishment text box," the business establishment verification process will be executed. Clicking "2-1: Business Establishment Button" will launch the business establishment search dialog. When you select "2-2: Select a business from the business search dialog", the business verification process will be executed. If you select "3-1: Enter the value in the business establishment text box directly," the business establishment verification process will be executed.

[0081] Validation processing is a process that commonly occurs when a text value is changed by some means. However, when the value is changed by selecting from a list or dialog (1-2, 2-2 in Figure 18), it is unlikely that data that fails validation will be displayed as an option, so in most cases the validation result will not result in an error. Since the only pattern in which an error occurs in validation processing is when validating an error during direct input (3-1), the following explanation will simplify the validation processing for 1-2 and 2-2. The processing in Figure 18 will be explained in detail below.

[0082] "1-1: Click the ▽ part of the business establishment text box." Figure 19 is a diagram to explain a specific example of the processing that occurs when the ▽ part of the establishment text box is clicked. 1-1-1. Clicking the drop-down list will retrieve a list of establishment masters that are available as of the reference date. 1-1-2. Retrieve establishments that exist as of the reference date. 1-1-3. Retrieve available establishment information (code, name) from the establishment master and display it on the drop-down list.

[0083] "1-2: Select the list in the business establishment text box" 20 is a diagram for explaining a specific example of processing when the list in the business establishment text box is selected. A validation process is performed on the value (Z001) selected on the list, and the name is displayed in the label.

[0084] "2-1: Click the business button" Figure 21 is a diagram to explain a specific example of the processing that occurs when the establishment button is clicked. 2-1-1. Clicking the establishment button "···" has a function specialized for establishment searches, and when the establishment button "···" is clicked, the establishment search dialog is launched. 2-1-2. When the display button for the establishment search dialog is clicked, 2-1-3. Establishments that existed as of the reference date and whose name contains the string "Tokyo" are retrieved. 2-1-4. The information for the establishment code selected from the establishment search dialog is set to the establishment text. At this point, the value is considered to have been changed, and a verification process is performed to determine whether the establishment code is valid for the selected value.

[0085] "2-2: Processing after selecting a business from the business search dialog" When a business establishment is selected from the business establishment search dialog, a validation process is performed on the value (Z004) selected on the business establishment search dialog, and the name is displayed in the label.

[0086] "3-1: Enter the value in the business establishment text box directly" Figure 22 is a diagram illustrating a specific example of processing when a value is directly entered in the business establishment text box. 3-1-1. The application user directly enters a value in the text box, and the entered value is verified to determine whether the business establishment code is valid. The following processing is described as a general master validation process. 3-1-2. Based on the argument base date and business establishment code, if data exists that matches the argument business establishment code and meets the conditions of start date < base date and base date < end date, the name is returned as the return value. If the argument business establishment code matches and the base date < start date (in the case of a business establishment to be established in the future) or the end date < base date, the error message "The business establishment is outside its validity period" is returned as the return value. If no business establishment matches the argument business establishment code, the error message "Business establishment does not exist" is returned as the return value. 3-1-3. If the validation result is NG, the error content is set to the text error message property. The error message property is a type of property that can be set in a text box. Unlike a normal value property, when a value is set to this error message property, an error message is displayed in the text box to notify the user of the error.

[0087] As such, there are a wide variety of common operations required when an application user selects a business establishment master record. When there are many screens that search for the same master, developing and configuring each one individually raises issues regarding cost and maintainability of quality control. The cost increases further as the number of masters increases. For this reason, this invention has developed a mechanism that allows application developers to configure the above-mentioned code search function with fewer steps.

[0088] [Code search function realized by common controls] The code search function realized by the common control will be described with reference to FIGS. 24 to 47B.

[0089] (I. Development Stage) In this invention, the functional elements required for master search used on multiple screens are generalized (see "3-2. About the Code Search Function"), and by extracting the commonly required setting elements when configuring the master search function on each screen, it is possible to save and use them as independent definitions on the low-code development platform. This definition will be referred to as the "common control definition" in the following explanation. This common control definition mechanism realizes a mechanism that reduces the configuration burden on application developers.

[0090] (A) Registering common control definitions First, developers configure common controls and create common control definitions. These definitions are saved in the common control definition management table in the development application database. The common control definition management table manages the common control types and common control settings within the definition.

[0091] Figure 23 shows an example of the menu screen of a low-code development tool. Tabs are displayed on the left side of the menu screen. If an application is selected, a settings screen for individual screen development will be displayed; if a common control is selected, a common control settings screen will be displayed. Here, we will set up common controls, so click the Common Controls tab from the menu screen.

[0092] Figure 24 shows an example of the common control setting screen. By selecting the type of common control that can be set using the tabs at the top of the screen, a list of registered common controls is displayed. Pressing the New button will transition to new creation mode on the common control setting screen for the selected type.

[0093] (Common control settings screen) (A-1) Setting the text box part of the common control for code search type The common control settings screen is where you set up code search type common controls. For search functions that need to be set in text boxes, it is assumed that a pull-down definition has been registered in advance. The pull-down function is an input candidate selection function that assists operators with input. To provide a pull-down function in an application, you need to set elements such as the API that retrieves records, the items to display in the list, and the value to be returned in the text box when a list selection is made.

[0094] The API to retrieve the record is selected from the records registered in the API management table. The API management table has the following fields: ID, method name, API name, arguments (ID, name, type), and return value (ID, name, type).

[0095] The pull-down management table has ID, pull-down name, APIId, return value (ID, name, type), and display item (ID, name, type of each item). The display item and return value to the text box are selected from the API return values.

[0096] 1. APIId is an ID used to obtain the information to be displayed in the pull-down menu from the API management table, and one is selected from the API management table. 2. The API return value is the element that is set in the text box after selecting from the drop-down list, and one of the API return values ​​is selected. 3. Display items are the elements to be displayed on the drop-down list, and one or more items can be selected from the API return values. The items you want to display on the drop-down list (business code, business name) are displayed side by side.

[0097] The code search function uses text boxes, buttons, and labels, so you need to set the common parts in each setting. There is no common setting for labels, so there is no need to set them in common.

[0098] 25 shows an example of a common control setting screen (when setting text boxes) and an image of the list display state. The common control setting screen has a field for setting a name, tabs for text boxes, buttons, and labels, and an area for setting the selected tab.

[0099] Application developers can freely set the "Name" field. Depending on the type of common control selected, it is possible to set each component control, and the code search function can be set for three types of controls: text boxes, buttons, and labels.

[0100] In the text boxes, set the following information: 1. Select the pulldown definition to use when obtaining the display data for the dropdown list. Obtain the pulldown list information from the pulldown definition management table. The list will display the pulldown definition information obtained from the pulldown management table.

[0101] 2. Select the API to use when verifying the business code. The list will retrieve and display a list of API information from the API management table. Based on the selected verification API information, a list of return values ​​will be retrieved from the API management table.

[0102] 3. Among the verification API return values ​​obtained, set the return value to be returned as the label value (for when verification is completed successfully). The list retrieves and displays a list of business verification API return values ​​from the API management table.

[0103] 4. Set the value to be returned as a text error message among the return values ​​of the validation API (for when validation ends with an error). The list retrieves and displays a list of the business validation API return values ​​from the API management table.

[0104] Here, to provide pull-down functionality in the application, the following three settings need to be made.

[0105] 1. API settings → API information to obtain the information to be displayed in the drop-down menu (select one from the API management table). 2. Setting the display items → As shown in Figure 26, the elements to be displayed in the drop-down list (select one or more from the API return values). 3. Set the return value: As shown in Figure 26, this is the element that will be set in the text box after selecting from the drop-down list (select one from the API return values).

[0106] (A-2) Setting the button part of the common control for code search types When configuring the button portion of the common control definition, it is assumed that the following definition has been registered in advance. This definition functions as a dialog called from the application to obtain business information (allowing for more advanced search processing than pull-down).

[0107] (Processing performed on the dialog screen) That is, in FIG. 1. When the display button is pressed, the business establishment acquisition API is executed (using the base date and business establishment name as API arguments) 2. Obtain a list of business locations that meet the conditions from the database according to the arguments 3. Bind the business information returned as an API return value to a table and display it. 4. When one of the records in the table is selected and the Select button is pressed, the business code and business name information of the selected record is returned to the calling application. 5. When the Cancel button is pressed, the application returns to the calling application without performing any processing.

[0108] (About screen start / close actions) For screens that are intended to be called from an application, it is necessary to return operations to the calling application after the dialog processing is complete, so it is necessary to perform a process to close the dialog (see Figure 29). There is a screen close action that performs a process to close this dialog. A screen close action is placed at the end of the logic flow, and the dialog is closed when this process is executed.

[0109] On the other hand, the application that calls the dialog must perform the necessary processing to call the dialog. There is a screen launch action that performs this processing to call the dialog (see Figure 30). With the screen launch action, you can select the dialog screen to call and set arguments to the dialog screen.

[0110] In addition, in the logic flow, you can write branching processing after the dialog is closed by executing the screen exit action of the called dialog screen. In other words, after selecting the dialog screen to call, you can read the list of screen exit actions set on the dialog screen side, and write branching processing after each screen exit action is executed.

[0111] Figure 31 shows the records registered in the definition management table, and also displays an excerpt of the information from the business establishment search dialog screen registered in the definition management table. The definition management table contains logic flows assigned to the select button and the cancel button, and within each logic flow a special action called a screen exit action is executed. When the screen exit action is executed, the logic flow processing ends and the dialog screen is closed. This is a mechanism by which processing continues on the parent screen side.

[0112] 32 shows an example of a common control setting screen (when setting buttons) and an image of the list display state. For buttons, the following information is set.

[0113] 1. Select the button type. If you select "Use," you can launch a screen with a different UI definition created in the low-code development tool. If you select "Do not use," buttons will not be used (only text and labels will be used).

[0114] 2. Select the screen to display when the button is clicked. The list retrieves and displays definitions in a list from the definition management table. The list of UI definitions is retrieved by referencing the records registered in the definition management table. In the dialog screen that is launched by clicking a button, it is assumed that the screen will close and return to the screen that launched it when either (1) a selection process or (2) a cancellation process is selected. In order to implement selection and cancellation processes, it is necessary to set a special action called a screen exit action (an action that must be set when closing the screen). When setting the button part of the common control definition, a list of screen exit actions is referenced from the actions set in the dialog (business search dialog), and action information that will be called when a value is selected or when the action is canceled is stored within the definition. When the action information stored on the dialog screen is called, the processing branches on the screen that launched it (see the process of converting business search dialog argument information in (II. Conversion of common control information in the usage phase)).

[0115] 3. From the actions that are executed when the screen is closed, select the process that will be executed when a value in the dialog is selected. The list displays a list of screen closing actions retrieved from the action information in the definition management table.

[0116] 4. From the actions that are executed when the screen is closed, select the process that will be executed when the dialog is canceled. The list displays a list of screen closing actions retrieved from the action information in the definition management table. From the list of controls set on the selected screen (business search dialog), select the process to be executed when a value is selected or when the dialog is canceled.

[0117] 5. Select the value to be updated from the dialog. The list displays a list of controls for which values ​​can be set, retrieved from the control information in the business establishment search dialog definition.

[0118] After configuring the text boxes and buttons, press the Register button to register the common control definition in the common control definition management table. Information such as the definition name and creation date and time can also be checked on the common control definition list screen. Figure 33 shows an example of the common control definition list screen after registration. Figure 34 shows an example of a registered common control definition management table.

[0119] The common control definition management table includes a definition ID, a definition name, a common control type, and data. Definition ID: Key information that is automatically assigned when creating a UI definition Definition name: Named by the developer when creating the UI definition Common control type: Determined by the type of common control selected (1 for code search type common control, 2 for optional search type, etc.) Data...Common control settings

[0120] In this example, the definition ID is "GlobalControlKey1", definition name is "Business Code Search Common Control", common control type is "1 (Code Search)", data is "Textbox: Pull-down definition (ID "PullDownKey1 (Business pull-down definition)", validation process (ID "APIKey2 (Business validation API)", return value (value) "KenshouAPIReturnValue1 (Business name)", return value (error) "KenshouAPIReturnValue2 (Error message)", button: type (1 (Use)), target screen (ID "AppDefinitionKey1 (Business search dialog)", when selected "SelectActionKey (Selection process)", when canceled "CancelActionKey (Cancel process)", return value "ZigyoushoCDCell (Business code cell)".

[0121] (B) Use of common control definitions within an application Next, the registered common control definitions are displayed in the control list on the low-code development platform, and developers can use them as controls on the application layout setting screen, just like regular controls.

[0122] The roles of the common control and the application controls placed on the layout are clearly different, so the names are listed separately as follows:

[0123] 1. When referring to the common control definition itself → Common control (definition) 2. When referring to a control on an application → Common control (single) or Common control cell (details)

[0124] Note that "○○" can be text, a button, or a label (if the control is placed on a spread).

[0125] The difference between a common control (single) and a common control cell (detailed) is that the single type is generated as a single control when you drag the common control (it is broken down into text, buttons, and labels when the application is converted), whereas the detailed type is generated as an independent control cell separated into cells when you drag it.

[0126] For example, the example in Figure 35 shows the base date text box, business establishment search common control (single), display button, and spread controls. Also, the example in Figure 35 shows an example in which a business establishment search common control text cell (details), business establishment search common control button cell (details), and business establishment search common control label cell (details) are placed on the spread.

[0127] (1) Settings when using common controls as a single UI Next, configure the business search common control (definition) to use it as a single-type control within the application. When placing the business search common control definition on the screen, it can be set as a control of type = common control (single). For the common control (single), the properties shown in Figure 36 can be specified. Figure 36 lists the common control setting items and the specified contents. (1) Pull-down definition argument: FROM... Specifies the value to be passed to the API argument used in the pull-down definition (business pull-down definition). (2) Pull-down definition argument: TO... Specify the argument of the business establishment acquisition API to pass the value (reference the argument information of the business establishment acquisition API from the API management table) (3) Business Verification API Argument: FROM... Specify the value to be passed to the business verification API argument (4) Business establishment verification API argument: TO... Specify the argument of the business establishment verification API to pass the value (reference the argument information of the business establishment verification API from the API management table) (5) Business Verification API Return Value (Optional): FROM... Specify the return value of the business verification API (refer to the return value information of the business verification API from the API management table), TO... Specify the control on the screen that receives the value

[0128] The following specifies the value to be passed to the dialog screen that is called when the button is clicked, only in the case of a common control definition that uses a button (values ​​can also be passed to the dialog itself, just like with the API). (6) Search dialog arguments: FROM... Specifies the value to be passed to the business search dialog (7) Search dialog argument: TO... Specifies the destination of the business search dialog value

[0129] For each property, select the value to be passed to the argument (caller) and the argument to which the value is passed (callee).When the developer selects a common control placed on the screen, the information of the API and dialog (business establishment acquisition API, business establishment verification API, business establishment search dialog) referenced by the common control is read, and the property title (underlined part on the screen) is replaced (such as the business establishment acquisition API argument).

[0130] (5) above is an optional item that can be set. To implement the code search function, it is sufficient to return the label value and error message from the validation API, and the control that receives each value is self-evident (the text and label of the common control), so there is no need to set it on this screen.

[0131] In this case, the business establishment validation API returns elements other than the label value and error message (○○ category 1) as return values, so by specifying any control on the screen that will receive the values, the required values ​​can be set on the screen in one validation process. This increases the scalability of the code search function.

[0132] Fig. 37 is a diagram showing an example of a common control setting screen. When you drag and drop the business establishment code search common control from the common control area to the dashed line on the right side using the mouse, the screen shown in Fig. 38 for setting properties (common controls) is displayed, and you can set the properties (common controls) described above (1) to (7).

[0133] (2) Settings when using common controls as a detail-type UI Next, set up the business search common control (definition) to be used as a control cell in a spread. As shown in Figure 39, when placing the business search common control definition on a spread, it can be set as a control of type = common control cell (details). At this time, the number of columns of cells to be placed will change depending on the number of common control controls. If buttons are used, the common control text cell will be placed in column 1, the common control button cell in column 2, and the common control label cell in column 3. If buttons are not used, the common control text cell will be placed in column 1 and the common control label cell in column 2.

[0134] Unlike the single case, the three controls - text cell, button cell, and label cell - are set separately starting from the column where they were dropped. In other words, if you drop it on column N, it will be set separately in three columns: column N, column N+1, and column N+2. At this time, the properties of the common controls that need to be set are collected in the text section and set, as shown in Figure 40. Note that there are no properties to be set for button cells and label cells.

[0135] The registered common control information is added as one piece of control information in the definition management table, just like normal controls, as shown in Figures 41 and 42. The common control definition ID becomes the key of the common control definition management table. Common control properties (acquisition API arguments, validation API arguments, validation API return value, and business establishment search dialog arguments) are added.

[0136] In the example shown in FIG. 41, control 2 has the name "Office Search Common Control (Single)", the type "Common Control (Single)", and the common control definition "Office Search Common Control (Definition)".

[0137] In addition, this control 2 is the business establishment acquisition API arguments (1: caller (From) "value of base date text", callee (To) base date), business establishment verification API arguments (1: caller (From) "value of base date text", callee (To) "base date", 2: caller (From) "value of business establishment search common control (single)", callee (To) "business code"), business establishment verification API return value (1: caller (From) "○○ category", callee (To) "any item on the screen", business establishment search dialog arguments (1: caller (From) "value of base date text", callee (To) "value of base date text").

[0138] Also, in the example shown in Figure 42, control 3 has the name "Business Establishment Search Common Control (Details)", type "Common Control Text Cell (Details)", common control definition "Business Establishment Search Common Control (Definition)", row index "0", and column index "0".

[0139] In addition, Control 3 is the business establishment acquisition API arguments (1: caller (From) "value of base date text", callee (To) base date), business establishment verification API arguments (1: caller (From) "value of base date text", callee (To) "base date", 2: caller (From) "value of business establishment search common control text cell (details)", callee (To) "business establishment code"), business establishment verification API return value (1: caller (From) "○○ category", callee (To) "any item on the screen", business establishment search dialog arguments (1: caller (From) "value of base date text", callee (To) "value of base date text (value of business establishment search dialog)".

[0140] As shown in Figure 41, a common control (single) is registered as a single control called Control 2, whereas as shown in Figure 42, common controls as control cells are registered as separate controls called Controls 3 to 5. The necessary settings are concentrated in Control 3, which is the text cell part, and Controls 4 and 5, which are the button cell and label cell parts, hold target cell information, which is information linking them to the text cell part (used when converting the application).

[0141] Next, in the development phase, after (A) registering the common control definition, the application developer for each screen uses the common control definition to (B) set the common control definition within the application. By reusing information commonly required for the code search function and minimizing the information required for each screen, the productivity and maintainability of the application can be improved.

[0142] Furthermore, by making it possible to apply common controls to both single-type controls and detail-type control cells, the scope of use and maintainability of common controls can be improved.

[0143] When using the developed application, the definition information set in the business application database is published (see "About Low-Code Development Tools"). When the application is executed on the low-code execution platform, the configuration information in (A) and (B) is analyzed and converted into definitions that can be used by the application.

[0144] (Spread cell data structure) Here we will explain the data structure of a spread cell. A control that can display multiple records in a table is called a spread control. This spread control manages the layout or setting information for each cell by dividing it into three elements: columns, data, and footers, as shown in Figure 43.

[0145] FIG. 44 is a diagram showing an overview of the hierarchical structure of a spread control. Also, FIGS. 45 and 46 are diagrams showing an overview of the hierarchical structure of a spread control. As shown in FIGS. 44 and 45, hierarchical management is possible by having the grid of each element as a child element of the spread, and the control cell information as a child element of the grid. The spread itself contains information such as whether or not to use a footer (see "Footer Use" in FIG. 45), and if a footer is used, the footer information is added to the child elements of the spread. Note that FIGS. 45 and 46 are diagrams in which only data cell information is displayed as a control element.

[0146] (complex configuration) Next, as shown in Figures 47(a) and 47(b), by increasing the number of rows in the grid in the spread and setting row and column indices for the control cells, a multi-stage spread can be realized.

[0147] As shown in Figures 48(a) and 48(b), cell merging can be set by increasing the span information of each cell row and column. Note that the row and column index in this case is not the data record that the business operator actually checks, but the positional relationship of the cell information within the spread. When actually binding business data to a spread cell using an API or the like, the cell to which the business data is bound is specified based on this positional relationship.

[0148] In the case of a multi-stage spread, it is also possible to separate the data rows and set different common controls for each, as shown in FIGS.

[0149] Next, depending on the structure of the spread, there are cases where common controls can be set and cases where an error should be detected. This determination is made according to the following flow.

[0150] 1. Get the row index and column index of the business establishment search common control text cell (details), 2. Whether the cell type in the acquired row index and column index + 1 part is a common control button cell (details) or not. 3. Whether the target cell of the business establishment search common control button cell is the business establishment search common control text cell, 4. Whether the cell type in the acquired row index and column index + 2 part is a common control label cell (details), and 5. It is determined whether the target cell of the business establishment search common control label cell is a business establishment search common control text cell or not.

[0151] 51 and 52, a pair of common controls is correctly placed in the consecutive cells that make up the common control cell, so it is determined that a common control can be set.

[0152] In contrast, the examples in Figures 53 and 54 show cases where the shared control pair is broken. In this case, when determining whether the above-mentioned "1. Get the row index and column index of the shared control text cell (details)" and "2. Is the cell type at the acquired row index and column index + 1 part a shared control button cell (details)?" are true, a different type of cell, a numeric text cell, is placed, so it is determined to be an "error" and an error message is displayed on the low-code development platform.

[0153] (Application conversion of common control definitions at the usage stage (single)) When an application that uses common controls is launched, information about the common controls set in the definition management table is read, the common control information is converted into normal controls (text boxes, buttons, labels), and information such as logic flow related to those controls is automatically generated internally, making it usable as an application.

[0154] (Flowchart for running an application that uses common controls) 55 is a flowchart for executing an application using a common control. This flowchart is executed by the control unit 102 functioning as the execution unit 102b based on the application providing program stored in the storage unit 196.

[0155] In this example, the execution unit 102b is described as being implemented in software by an application providing program, but all or part of the execution unit 102b may be implemented in hardware. In either case, the same effects as those described below can be obtained.

[0156] In this flowchart, the information of the application to be launched is read, and if common control information is included, the definition is dynamically converted. New controls (text, buttons, labels) included in the common control definition are added, and the functions required to realize the code search function are generated and assigned to each control. This results in the final conversion into usable application information.

[0157] The business application DB 106b stores a definition management table, a common control definition management table, and a pull-down definition management table.

[0158] 55, when an application user starts an application program (step S1), the execution unit 102b reads application information from the definition management table (step S2). It is determined whether the control information of the read application information includes data of type common control (single) (step S3). If the control information does not include data of type common control (single) ("No" in step S3), the process proceeds to step S13.

[0159] If the control information includes data of type common control (single) ("Yes" in step S3), three controls, a text box, a button, and a label, are added to the control information in step S4.

[0160] In step S5, the property reference portion of data whose type is common control (single) is converted to a normal control. In step S6, the acquired API argument information and the common control definition are combined and converted into pull-down information for a text box.

[0161] In step S7, the verification API argument information and verification API return value information are converted into logic flow information and action information. In step S8, the logic flow created in step S7 is associated with the event in the text box.

[0162] Next, in step S9, the execution unit 102b determines whether the common control definition is a setting that uses a button. If it is determined that the common control definition is not a setting that uses a button ("No" in step S9), the process proceeds to step S13.

[0163] On the other hand, if it is determined that the common control definition is set to use a button ("Yes" in step S9), the execution unit 102b converts the establishment search dialog argument information into logic flow information and action information in step S10.

[0164] Next, in step S11, the execution unit 102b associates the logic flow created in step S10 with the button event. In step S12, the common control is deleted from the control information, and the process proceeds to step S13. As a result, in step S13, the low-code execution platform performs startup processing of the application program in accordance with the UI definition of the converted application program.

[0165] Next, the processing in steps S4 to S12 of the flowchart will be described with reference to FIGS.

[0166] (Step S4: Add the normal control corresponding to the common control to the control information) In Figure 56, if the common control is a code search type that uses a button, text box, button, and label controls are added to the definition management table. If the common control is a code search type that does not use a button, text box and label controls are added.

[0167] In the control information of the definition management table, the common control is set as control 2. Controls M, M+1, and M+2 for text, button, and label corresponding to this control 2 are added in the format of normal controls (ID, identification name, control type).

[0168] (Step S5: Convert property references of code search common controls to normal controls) In the low-code development tool, this was set as the value of a common control (business search common control (single)), but since it is an element that corresponds to the value of the text box when used as an application, it is converted when the normal control is added in step S4. Figure 57 shows an example where the "value of business search common control (single)" has been converted to the "value of business text."

[0169] (Step S6: Combine the acquired API argument information and the common control definition and convert it into pull-down information for the text box) In this case, first, pull-down definition information is obtained from the common control definition management table as shown in Fig. 58(a). Next, pull-down definition management table information (APIId, return value, display item) is obtained from the pull-down definition in the common control definition management table as shown in Fig. 58(b), and arguments are obtained from the API management table as shown in Fig. 58(c).

[0170] Next, as shown in Figure 58(d), common control information set in the definition management table is obtained for the argument obtained from the API management table. As a result, pull-down information required for the text box is generated and associated with the text box in the definition management table. That is, as shown in Figure 59, pull-down setting information and pull-down relation information (control ID, pull-down ID) are added to the definition management table. The pull-down relation information in the definition management table in Figure 59 is information that associates pull-downs with controls, and associates the control ID with the pull-down ID.

[0171] (Step S7: Convert the business establishment verification API argument information and business establishment verification API return value information into logic flow information and action information and associate them with the text boxes) The business establishment verification API arguments and business establishment verification API return values ​​of the common control in the definition management table shown in Figure 61(a) are converted into logic flow information and action information, and added to the common control definition management table as shown in Figure 61(b).

[0172] Also, based on the information of the establishment verification API arguments, a logic flow as shown in Fig. 60(a) is generated internally, and added to the definition management table as a new logic flow element and action element of the UI definition as shown in Fig. 60(b). At this time, information on the settings (API, arguments, return value) of the API call action to be generated is obtained from the definition management tables shown in Fig. 61(a) and Fig. 60(b) and the common control definition management table shown in Fig. 61(b).

[0173] (Step S8: Associate the logic flow created in step S7 with the text box event) Figure 62 shows an example of a definition management table (an excerpt of the linking information to be generated), and adds linking information to link the created logic flow to the text box event. Figure 62 shows an example where linking information for the control ID "Office Text", event type "Verification", and logic flow ID "Logic Flow M" has been added.

[0174] For common control definitions that use buttons, the following conversions are performed:

[0175] (Step S10: Convert argument information from the business establishment search dialog into logic flow and action information) A logic flow is automatically created that separates processing when a selection is made and when a cancellation is made on the dialog.The logic flow shown in Figure 63(a) is generated internally based on the business office search dialog arguments in the definition management table shown in Figure 64(a) (an excerpt from the dialog argument settings section for the common control) and the button information for the business office search common control in the common control definition management table shown in Figure 64(b).Then, logic flow information and action information are generated based on the generated logic flow and added to the definition management table as shown in Figure 63(b).

[0176] As shown in Fig. 64(b), the button information in the common control definition is "Selection Process" when selected, so when selection processing is performed on the business establishment search dialog side, the flow proceeds to the selection processing flow shown in Fig. 63(a). Also, as shown in Fig. 64(b), when cancellation is performed, the flow proceeds to the cancellation processing flow, so when cancellation processing is performed on the business establishment search dialog side, the flow proceeds to the cancellation processing flow.

[0177] A supplementary note about logic flow branching: Flow element 2 and flow element 3 shown in Figure 63(a) are special flows that, when a screen launch action is set in the previous action ID, branch off into subsequent processing depending on the screen close action processing of the child screen launched by the screen launch action.

[0178] In the common control definition, a screen exit action when a dialog value is selected and a screen exit action when the dialog is cancelled are registered, and the subsequent processing is branched depending on each processing.

[0179] For details about the screen exit action set on the dialog side, please refer to the description in "(A-2) Setting the button part of the code search type common control." In this example, since the actions to be taken when a value is selected and when it is canceled are registered in the buttons of the common control definition, when the selection process on the business office search dialog side is executed, the process branches to flow element 2 and the screen update action on the parent screen side is called. In contrast, when the cancellation process is executed, the process branches to flow element 3 and the exit action on the parent screen side is called.

[0180] (Step S11: Link the logic flow created in step S10 to the button event) Next, the created logic flow is added to the definition management table (an excerpt of the generated linking information) via the linking information shown in Figure 65, and is associated with a specific event. This example shows linking information with a control ID of "office button," an event type of "click," and a logic flow ID of "Logic Flow M+1."

[0181] (Step S12: Delete the common control from the control information) Next, the common control is deleted from the control information in the definition management table, as shown in Fig. 66(a). With the control information for Control 2 (common control part) deleted, various information for the text, button, and label parts remains in the control information in Fig. 66(a), the logic flow information in Fig. 66(b), the linking information in Fig. 66(c), and the action information in Fig. 67.

[0182] As a result, the definition of the slip list, which previously used common controls, can be converted to logic flow and action settings using normal text boxes, buttons, and labels, and can be used as a normal definition. By performing this conversion work internally, developers do not need to assign logic flow or actions to each control, such as a text box, using a low-code development tool, significantly reducing the burden on developers.

[0183] Furthermore, by interpreting the registered information at runtime and performing the conversion rather than performing the conversion when the common control is placed, even if the common control definition is changed, the changes are reflected in real time at runtime, thereby improving maintainability.

[0184] The above explanation was about using the code search type of common control, but even if you use a different type of common control (different combination of controls or processing content), you can achieve the processing required for your application by performing a similar conversion process.

[0185] (Application conversion of common control definitions at the usage stage (details)) When an application that uses common controls is launched, information about the common controls set in the definition management table is read, the common control information is converted into normal control cells (text box cells, button cells, label cells), and information such as logic flow related to those controls is automatically generated internally, making it usable as an application.

[0186] (Flowchart for running an application that uses common controls) 68 is a flowchart for executing an application using a common control. This flowchart is executed by the control unit 102 functioning as the execution unit 102b based on the application providing program stored in the storage unit 196.

[0187] In this example, the execution unit 102b is described as being implemented in software by an application providing program, but all or part of the execution unit 102b may be implemented in hardware. In either case, the same effects as those described below can be obtained.

[0188] When an application that uses common controls is launched, information about the common controls set in the definition management table is read, the common control information is converted into normal control cells (text box cells, button cells, label cells), and logic flows related to these control cells are automatically generated internally, making it usable as an application.

[0189] The business application DB 106b stores a definition management table, a common control definition management table, and a pull-down definition management table.

[0190] 68, when an application user starts an application program (step S11), the execution unit 102b reads application information from the definition management table (step S12). It is determined whether the control information of the read application information includes data of type "common control text cell (details)" (step S13). If the control information does not include data of type "common control text cell (details)" ("No" in step S13), the process proceeds to step S24.

[0191] If the control information contains data of type common control text cell (details) ("Yes" in step S13), in step S14, common control button cells and label cells that have text cell information in the target cell are obtained from the control information.

[0192] In step S15, a normal control cell corresponding to each common control cell is added to the control information, and in step S16, the property reference portion of the code search common control cell is converted to a normal control.

[0193] In step S17, the acquired API argument information and the common control definition are combined and converted into pull-down information for the text cell. In step S18, the business verification API argument information and business verification API return value information are converted into logic flow and action information and associated with the text cell. In step S19, the created logic flow is associated with the text cell event.

[0194] Next, in step S20, the execution unit 102b determines whether the common control definition is a setting that uses a button. If it is determined that the common control definition is not a setting that uses a button ("No" in step S20), the process proceeds to step S24, where the low-code execution platform performs application startup processing according to the UI definition of the converted application.

[0195] On the other hand, if it is determined that the common control definition is a setting that uses a button ("Yes" in step S20), the execution unit 102b converts the establishment search dialog argument information into logic flow information and action information in step S21.

[0196] Next, in step S22, the execution unit 102b associates the logic flow created in step S21 with the button cell event. In step S23, the common control cell (details) is deleted from the control information, and the process proceeds to step S24. As a result, in step S24, the low-code execution platform performs startup processing of the application program in accordance with the UI definition of the converted application program.

[0197] Next, the processing in steps S14 to S23 of the flowchart will be described with reference to FIGS.

[0198] (Step S14: Obtain common control button cells and label cells that have text cell information in the target cell from the control information.) As shown in Figure 69, common control cells have their control information registered separately, so the target cell information is used to identify the common control pair. By providing this target cell information, even if multiple common controls are used within the same definition, the original common control pair can be identified.

[0199] (Step S15: Add a normal control cell corresponding to each common control cell to the control information) For example, as shown in Fig. 70, for a common control cell (text), a character string text cell is added to the control information of the definition management table, for a common control cell (button), a character string button cell is added to the control information, and for a common control cell (label), a character string label cell is added to the control information.

[0200] In reality, the cell information of a spread also includes setting information for column cells, footer cells, etc., but Figure 70 simplifies and illustrates only the data cells. Data cell information contains information about what type of data each column of the spread can bind (for example, string type or numeric type). Control N to Control N+2 are used as templates for the data portion of the spread when binding actual business information.

[0201] (Step S16: Convert the property reference part of the code search common control cell into a normal control) In the low-code development tool, this was set as the value of a common control (business establishment search common control (details)), but since it is an element equivalent to the value of the text box when used as an application, it is converted when the normal control cell is added in step S15. Figure 71 shows an example where the value of the "business establishment search common control cell (details)" has been converted to the "value of the business establishment text cell."

[0202] (Step S17: Combine the acquired API argument information and the common control definition and convert it into pull-down information for the text cell) In this case, first, pull-down definition information is obtained from the common control definition management table, as in the explanation using Fig. 58(a). Next, pull-down definition management table information (APIId, return value, display item) is obtained from the pull-down definition in the common control definition management table, as in the explanation using Fig. 58(b), and arguments are obtained from the API management table, as in the explanation using Fig. 58(c).

[0203] Next, as in the explanation using Figure 58(d), common control information set in the definition management table is obtained for the argument obtained from the API management table. As a result, the pull-down information required for the text box is generated and associated with the text box in the definition management table. That is, as shown in Figure 72, pull-down setting information and pull-down relationship information (control ID, pull-down ID) are added to the definition management table. The pull-down relationship information in the definition management table in Figure 72 is information that associates a pull-down with a control, and associates the control ID (business office text cell) with the pull-down definition (business office pull-down definition).

[0204] (Step S18: Convert the business verification API argument information and business verification API return value information into logic flow information and action information and associate them with text cells) As explained using Figure 61(a), the business establishment verification API arguments and business establishment verification API return values ​​of the common controls in the definition management table are converted into logic flow information and action information, and added to the common control definition management table as shown in Figure 73.

[0205] In addition, the logic flow explained using Fig. 60(a) is generated internally based on the information of the establishment verification API arguments, and is added to the definition management table as a new logic flow element and action element of the UI definition, as explained using Fig. 60(b). At this time, information on the settings (API, arguments, return value) of the API call action to be generated is obtained from the definition management table explained using Figs. 61(a) and 60(b) and the common control definition management table explained using Fig. 61(b).

[0206] (Step S19: Associate the logic flow created in step S18 with the text box event) Figure 74 shows an example of a definition management table (an excerpt of the linking information to be generated), and adds linking information to link the created logic flow to the text box event. Figure 62 shows an example where linking information for the control ID "Office Text Cell", event type "Verification", and logic flow ID "Logic Flow M" has been added.

[0207] If the common control definition is one that uses a button (step S20: Yes), the following conversion is performed.

[0208] (Step S21: Convert argument information in the business establishment search dialog into logic flow and action information) A logic flow is automatically created that separates processing when a selection is made and when a cancellation is made on the dialog.The logic flow described using Figure 63(a) is internally generated based on the business office search dialog arguments in the definition management table (excerpt from the setting section of the dialog arguments for the common control) described using Figure 64(a) and the button information for the business office search common control in the common control definition management table described using Figure 64(b).Then, logic flow information and action information are generated based on the generated logic flow and added to the definition management table as shown in Figure 75.

[0209] As explained using Fig. 64(b), the button information in the common control definition is set to "selection process" when selected, so when selection process is performed on the business establishment search dialog side, the flow proceeds to the selection process flow shown in Fig. 63(a). Also, as explained using Fig. 64(b), when cancellation process is performed, the flow proceeds to the cancellation process flow, so when cancellation process is performed on the business establishment search dialog side, the flow proceeds to the cancellation process.

[0210] The same applies to the branching of logic flows as described above. That is, flow element 2 and flow element 3 shown in Figure 63(a) are special flows, and when a screen launch action is set in the previous action ID, they are subsequent processes that branch according to the screen close action processing on the child screen side that is launched by the screen launch action.

[0211] In the common control definition, a screen exit action when a dialog value is selected and a screen exit action when the dialog is cancelled are registered, and the subsequent processing is branched depending on each processing.

[0212] For details about the screen exit action set on the dialog side, please refer to the description in "(A-2) Setting the button part of the code search type common control." In this example, since the actions to be taken when a value is selected and when it is canceled are registered in the buttons of the common control definition, when the selection process on the business office search dialog side is executed, the process branches to flow element 2 and the screen update action on the parent screen side is called. In contrast, when the cancellation process is executed, the process branches to flow element 3 and the exit action on the parent screen side is called.

[0213] (Step S22: Link the logic flow created in step S21 to the button event) Next, the created logic flow is added to the definition management table (an excerpt of the generated linking information) via the linking information shown in Figure 76, and is associated with a specific event. This example shows linking information with a control ID of "office button cell," an event type of "click," and a logic flow ID of "Logic Flow N+1."

[0214] (Step S23: Delete the common control cell (details) from the control information) Next, as shown in Fig. 77(a), the common control cells (details) are deleted from the control information of the definition management table. As the control information for Control 3 to Control 5 (common control cell portion) has been deleted, various information remains in the text, button, and label portions of the control information in Fig. 77(a), the logic flow information in Fig. 77(b), the linking information in Fig. 77(c), and the action information in Fig. 78.

[0215] As a result, the definition of the slip list, which previously used common controls, can be converted to logic flow and action settings using normal text boxes, buttons, and labels, and can be used as a normal definition. By performing this conversion work internally, developers do not need to assign logic flow or actions to each control, such as a text box, using a low-code development tool, significantly reducing the burden on developers.

[0216] Furthermore, by interpreting the registered information at runtime and performing the conversion rather than performing the conversion when the common control is placed, even if the common control definition is changed, the changes are reflected in real time at runtime, thereby improving maintainability.

[0217] The above explanation was about using the code search type of common control, but even if you use a different type of common control (different combination of controls or processing content), you can achieve the processing required for your application by performing a similar conversion process.

[0218] [Effects of the embodiment] In low-code development, developers create systems by placing controls (UI) using drag-and-drop and assigning necessary settings, such as API execution, to events related to those controls (click events are common in the case of buttons).

[0219] In large-scale business applications, the same function (such as a search function) is often used on multiple screens. When setting the same function in an application, it is likely that there will be many overlapping settings even if the screens are different.

[0220] However, when developing applications using low-code, duplicating the same settings in multiple places increases configuration costs and can lead to problems due to incorrect corrections. For this reason, it is desirable to have a system that allows duplicated settings to be managed in a common manner.

[0221] The application providing system of the embodiment standardizes the settings that are duplicated on each screen and associates them with controls in advance so that they can be used. In this way, the controls to which setting information is assigned are the common controls described above.

[0222] By simply using the common controls, developers no longer need to configure settings related to the controls from scratch, and can implement the required functions by configuring only the minimum necessary settings.

[0223] Furthermore, if the UI information of a common control is strictly defined, situations will arise where the common control cannot be used because the UI is different even if the setting information is the same, limiting its use.For example, application controls include controls that hold a single value (e.g., text box) and control cells that hold values ​​for cells in a table (e.g., text box cell).

[0224] Because text boxes and text box cells share many common settings, it is desirable to be able to use the setting information contained in a single common control for both controls. The application provision system of this embodiment makes the setting information of a common control available to both the control and the control cell. This expands the range of situations in which common controls can be used.

[0225] Furthermore, the application providing system of the embodiment includes a definition management table in which control information that defines a definition ID, a definition name, an ID for each control, an identification name, and a control type, logic flow information that defines an ID for each element of a logic flow, a previous action ID, and a next action ID, and action information that defines an ID, name, type, API, argument, and return value for each action element, are associated and registered, and a common control definition management table in which definition IDs, definition names, common control types, and setting contents are associated and registered, and when an instruction to start a business application is received from a user, the application providing system reads application information of the business application from the definition management table, and if a search type common control is included in the control information of the definition management table, adds a value specification area for the common control, a dial The system includes an execution unit 102b that adds a control including at least two dialog display buttons, combines the pull-down display command argument information of the common control with the common control definition and converts it into pull-down information for a value specification area, and in the case of a common control definition for a setting that uses a dialog display button, converts the dialog display command argument information into logic flow information and action information, links the created logic flow information to an event of the dialog display button, deletes the common control from the control information, and performs startup processing for the business application in accordance with the UI definition of the converted business application.Therefore, by providing a mechanism for patterning frequently used application functions and saving reusable settings for each pattern as an independent common control definition, it is possible to provide users with business applications that reduce the amount of work required for configuration and prevent problems caused by incorrect configuration.

[0226] In the above embodiment, a common control definition of a code search type has been described, but the present invention is not limited to this, and similar processing can be performed when using common control definitions of other search types, such as a value search type, an arbitrary search type, etc. Furthermore, the present invention can be applied to business applications other than slip lists, and can also be applied to search types other than the code search type.

[0227] [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.

[0228] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to the achievement of SDGs Goals 12, 13, and 15.

[0229] Furthermore, this embodiment can contribute to strengthening control and governance, which can contribute to the achievement of Goal 16 of the SDGs.

[0230] [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.

[0231] 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.

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

[0233] Furthermore, with regard to the application providing system 100, the components shown in the figures are functional concepts, and do not necessarily have to be physically configured as shown in the figures.

[0234] For example, all or any part of the processing functions of the application providing system 100, particularly the processing functions performed by the control unit 102, 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 an information processing device to execute the processes described in this embodiment, and is mechanically read by the application providing system 100 as needed. That is, a computer program for providing instructions to the CPU in cooperation with the OS and performing various processes is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive). The computer program is executed by being loaded into RAM, and cooperates with the CPU to form the control unit.

[0235] This computer program may also be stored in an application program server connected to the application providing system 100 via any network, and all or part of it may be downloaded as needed.

[0236] Furthermore, the program for executing the processes described in this embodiment may be stored in a non-transitory computer-readable recording medium or configured as a program product. Here, the term "recording medium" includes any "portable physical medium" such as a memory card, a Universal Serial Bus (USB) memory, a Secure Digital (SD) card, a flexible disk, a magneto-optical disk, a ROM, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable and Programmable Read Only Memory (EEPROM (registered trademark)), a Compact Disk Read Only Memory (CD-ROM), a Magneto-Optical disk (MO), a Digital Versatile Disk (DVD), and a Blu-ray (registered trademark) disc.

[0237] Furthermore, a "program" is a data processing method written in any language or description method, and does not matter whether it is in the form of source code or binary code. Note that a "program" is not necessarily limited to a single structure, but also includes a structure that is distributed as multiple modules or libraries, or a structure that achieves its function by cooperating with a separate program, such as an OS. Note that the specific configuration and reading procedure for reading a recording medium in each device shown in this embodiment, as well as the installation procedure after reading, can use well-known configurations and procedures.

[0238] The various databases stored in the memory unit 106 are storage means 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 providing websites.

[0239] The application providing system 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device to which any peripheral device is connected. The application providing system 100 may also be realized by installing software (including programs, data, etc.) that causes the device to perform the processing described in this embodiment.

[0240] Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the drawings, and all or part of them can be configured by functionally or physically distributing and integrating them in any unit according to various additions or functional loads. In other words, the above-described embodiments can be implemented in any combination, or embodiments can be implemented selectively. [Industrial Applicability]

[0241] The present invention is suitable for application to development work of various programs. [Explanation of symbols]

[0242] 100 Application Provision System 102 Control section 102a Setting section 102b Executive Department 104 Communication interface unit 106 Storage section 106a Development application database 106b Business application database 108 Input / Output Interface Section 112 Input Device 114 Output Device 300 Network 400 Web Client

Claims

1. An application providing system including a control unit and configured to be able to communicate data with developers and users, The control unit A definition ID, a definition name, and control information specifying an ID, an identification name, and a control type for each control; Logic flow information that specifies the ID, previous action ID, and subsequent action ID for each element of the logic flow; Action information specifying the ID, name, type, API, arguments, and return value for each action element; a definition management table in which the above are associated and registered; A common control definition management table that specifies common control definitions that are common to multiple business applications and that associates and registers definition IDs, definition names, common control types, and setting contents; It is configured to be able to access a database that stores The control unit a setting unit that sets the common control definition in the common control definition management table in response to an operation by a developer on a common control setting screen; the setting unit adds the common control in the common control definition management table to the control information in the definition management table in response to an operation by a developer on a business application creation screen; An application providing system comprising:

2. the setting unit adds, in response to an operation by the developer on the business application creation screen, a single-type common control which is one control and which is decomposed into predetermined components when the application is converted, as the common control in the common control definition management table to be added to the control information in the definition management table; 2. The application providing system according to claim 1, wherein:

3. the setting unit adds, in response to an operation by the developer on the business application creation screen, a detail-type common control which is an independent control cell for each of a plurality of cells as the common control of the common control definition management table to be added to the control information of the definition management table; 3. The application providing system according to claim 2, wherein:

4. The control unit an execution unit that starts a business application when a start instruction is received from a user; When the execution unit receives an instruction to start a business application from a user, it reads application information of the business application from the definition management table; If the control information in the definition management table includes the single-type common control, add controls of a text box, a button, and a label to the control information; Convert the property reference of the common control to a normal control, Combining API argument information and a common control definition to generate pull-down information for the control, and associating the pull-down information with the control information in the definition management table; A desired logic flow is generated based on the API argument information, and the logic flow information and action information of the logic flow are associated with the control information on the definition management table; Deleting the common control from the control information and performing a startup process for the business application in accordance with the UI definition of the converted business application; 4. The application providing system according to claim 3, wherein:

5. When the execution unit receives an instruction to start a business application from a user, it reads application information of the business application from the definition management table; If the control information in the definition management table includes the detail type common control, a common control button cell and a label cell having text cell information in the target cell are obtained from the control information, adding a normal control cell corresponding to each common control cell to the control information; Convert the property reference of the common control cell into a normal control, generating pull-down information for the text cell by combining API argument information and a common control definition, and associating the pull-down information with the control information in the definition management table; A desired logic flow is generated based on the API argument information, and the logic flow information and action information of the logic flow are associated with the control information on the definition management table; Deleting the common control from the control information and performing a startup process for the business application in accordance with the UI definition of the converted business application; 5. The application providing system according to claim 4, wherein:

6. When the control is a button control, the execution unit generates a logic flow that divides processing into processing when a selection is made by operating a button on a dialog and processing when the selection is canceled, 6. The application providing system according to claim 4 or claim 5, wherein:

7. The application provision system is constructed on a low-code or no-code basis.

7. The application providing system according to claim 6, wherein:

8. An application providing method for an application providing system that includes a control unit and is configured to be able to communicate data with developers and users' clients, The control unit A definition ID, a definition name, and control information specifying an ID, an identification name, and a control type for each control; Logic flow information that specifies the ID, previous action ID, and subsequent action ID for each element of the logic flow; Action information specifying the ID, name, type, API, arguments, and return value for each action element; a definition management table in which the above are associated and registered; A common control definition management table that specifies common control definitions that are common to multiple business applications and that associates and registers definition IDs, definition names, common control types, and setting contents; It is configured to be able to access a database that stores The control unit executing a setting step of setting the common control definition in the common control definition management table in response to an operation by a developer on a common control setting screen; In the setting step, the common control in the common control definition management table is added to the control information in the definition management table in response to an operation by a developer on a business application creation screen; An application providing method characterized by the above.

9. An application providing program for an application providing system including a control unit and configured to be able to communicate data with developers and users' clients, The control unit A definition ID, a definition name, and control information specifying an ID, an identification name, and a control type for each control; Logic flow information that specifies the ID, previous action ID, and subsequent action ID for each element of the logic flow; Action information specifying the ID, name, type, API, arguments, and return value for each action element; a definition management table in which the above are associated and registered; A common control definition management table that specifies common control definitions that are common to multiple business applications and that associates and registers definition IDs, definition names, common control types, and setting contents; It is configured to be able to access a database that stores The control unit executing a setting step for setting the common control definition in the common control definition management table in response to an operation by a developer on a common control setting screen; In the setting step, the common control in the common control definition management table is added to the control information in the definition management table in response to an operation by a developer on a business application creation screen; An application providing program characterized by:

Images