JP7807664B2 - Information processing system, control method for information processing system, and program - Google Patents

Description

This article relates to information processing systems, control methods for information processing systems, and programs, and in particular to technologies suitable for use in building application software.

Conventionally, there have been no-code/low-code development tools that build application software (hereinafter referred to as "applications") according to a definition, which are used as no-code/low-code development tools that require little or no coding in a programming language.

Patent Document 1 proposes that screen components such as buttons and text boxes can be placed by dragging and dropping on a layout editor screen for editing the screen of an application to be constructed, and that the placed screen components are stored in an input/output definition table. Patent Document 2 proposes a system that deploys virtual components of an application in a cloud service execution environment and provides the application to users via a network.

Japanese Patent Application Laid-Open No. 2019-49858 Japanese Patent Application Laid-Open No. 2022-92310

When an application is built for a cloud service execution environment such as that described in Patent Document 2, the application is executed by linking the execution environment on the cloud service side (server side) with the terminal device of the application user who accesses the execution environment. Therefore, when the application is executed, it is necessary to generate information to be used in both the execution environment and the terminal device. However, if the developer were to develop the application while clearly managing these, this would result in complicated development. Patent Documents 1 and 2 do not take these issues into consideration.

In view of the above problems , the present invention aims to provide a mechanism for reducing the complexity of application development.

An information processing system including a terminal device,
The information processing system includes:
a display control means for controlling the display of an input area for inputting an action when a component to be arranged on a screen displayed by the application to be constructed is operated as a development screen for constructing the application;
a recording control means for controlling recording of definition information of the application including information on the action input in the input area;
a first control means for controlling generation of first information defining an action to be executed in the execution environment of the application based on the definition information;
a second control means for controlling a terminal device that accesses the execution environment when executing the application to generate second information used by the terminal device based on the definition information;
and
The second control means
generating the second information defining whether a component to be placed on a screen displayed by an application is an input item into which a value to be transmitted to the runtime environment is input or an output item into which a value transmitted from the runtime environment is to be displayed, based on information about the action among the definition information transmitted from the runtime environment;
The terminal device
a third control means for controlling, based on the second information, when the constructed application is executed, to transmit a value input via a screen of the application to the execution environment if the component is the input item, and/or to display a value received from the execution environment on the screen of the application if the component is the output item.
An information processing system comprising:

According to the present invention , it is possible to reduce the complexity of application development.

FIG. 1 is a system configuration diagram of an information processing system. FIG. 2 is a hardware block diagram of a developer terminal 100, an application user terminal 200, and an application user terminal 201. 10 is a flowchart of a login process. 10 is a flowchart of a UI editor process. 10 shows display examples in login processing and UI editor processing. 10 is a display example of tab components and an AppBar in a UI editor process. 10 is a flowchart of a context menu process. 10 is a flowchart of an action board process. 10 is a display example for explaining an action board process. 10 is a display example in action board processing. 10 is an example of source code generated by the development environment 300. 10 is a flowchart of a screen switching process. 10 is a flowchart of processing executed in the developer terminal 100, the development environment 300, and the execution environment 400, respectively, for displaying user information for an application. (a) A specific example of developer information 301. (b) A specific example of user information 411 in a multi-tenant execution environment. (c) A specific example of user information in a single tenant execution environment. 10 is an example of user information display. 10 is a flowchart of a workflow process. 10 is a display example relating to workflow processing. 10 is a display example of a database, UI parts, and actions generated by workflow processing. 10 is a flowchart of a canvas context menu process. 10 is a display example relating to the CRUD generation process. 10 is a display example of databases, actions, and functions generated by the CRUD generation process. 10 is a flowchart of a developer account registration process. 10 shows details of a DB set in an execution environment. 10 is a flowchart of a deployment process. This is a display example when deploying a mobile app. 10 is a display example of a UI editor screen relating to a template screen. 10 is a display example on the canvas of the template screen. This is an example of how a property box is displayed. 10 is a display example of an action board in which an action has been input. 10 is a flowchart of a data grid context menu process. This is an example of a display in a property box of a data grid. This is an example of a display on the action board of a data grid. 10 is a flowchart illustrating the execution of an action. FIG. 10 is a transition diagram of UI definition information including action information. 10 is a flowchart illustrating the execution of an action in a modified example. FIG. 10 is a transition diagram of UI definition information including action information in a modified example.

The following embodiments are described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the claimed invention, and not all combinations of features described in the embodiments are necessarily essential to the invention. Two or more of the features described in the embodiments may be combined in any desired manner. Furthermore, identical or similar components are designated by the same reference numerals, and redundant descriptions will be omitted.

The various features shown in the following embodiments can be combined with each other. Note that, below, "application" and "app" both refer to application software.

<System Configuration>
Fig. 1 shows a system configuration diagram of an information processing system according to an embodiment of the present invention, which includes a system for developing software and a system for using the developed software.

The developer terminal 100 is an information processing device (information processing terminal) operated by a developer user, which can be configured as a personal computer (hereinafter referred to as PC) or smartphone. In other words, it is the user terminal of the developer user. The developer terminal 100 accepts design operations for the application to be developed from the developer, and transmits various definition information for the application, which is the designed content, to the development environment 300.

The development environment 300 is an environment that uses at least one hardware resource built on a network (on the cloud, on the Internet). The development environment 300 is a multi-tenant environment, and multiple developer users can log in to it. The development environment 300 includes developer information 301, an execution engine 302, and storage 320. The development environment 300 is built by combining multiple web services (cloud services).

Developer information 301 is information that records the developer's account that can log in to development environment 300, such as an email address (user ID) that serves as the developer's account ID, and a password. Developer information 301 is recorded on at least one recording medium included in development environment 300. Details of developer information 301 will be described later using Figure 14(a).

Execution engine 302 is at least one hardware resource for executing processing to be executed in development environment 300, and includes processor 303 and memory 304. Processor 303 consists of at least one processor, and may be a single processor on the cloud, or a processor group combining multiple processors. Memory 304 is at least one recording medium on which programs to be executed by processor 303 are recorded. Of the various flowcharts described below, those described as being executed by development environment 300 are executed by execution engine 302. In other words, the programs recorded in memory 304 are implemented by processor 303 by expanding them into an area of development environment 300 that serves as work memory and executing them.

The distribution engine 305 transmits a client program 322 (such as HTML source code or JavaScript source code) to be executed on the developer terminal 100 to the developer terminal 100 that has accessed the development environment 300. The client program 322 is pre-recorded in storage 320 included in the development environment 300.

Storage 320 is a storage area of at least one recording medium, and stores at least a client program 322 that is common to each developer. It also has a developer area, which is a storage area for each developer account. For example, if developers A, B, and C are able to log in, it includes a developer A area 323 for developer A, a developer B area 324 for developer B, and a developer C area 325 for developer C. Each developer area stores definition information for the apps developed by each developer. For example, developer A area 323 stores app definition 323a (including app UI definition information and app execution environment programs, which will be described later in Figure 34).

The developer accesses the development environment 300 by accessing the URL for accessing the development environment 300 from the browser software on the developer terminal 100, and logs in to the development environment. Once logged in to the development environment, the developer receives from the development environment the client program 322 and the app definition (UI definition information) that is the content of previous development work that was saved. The developer then performs an operation to design a new application or an operation to update the design of an existing (in-progress) application, and sends the resulting app definition information (app definition, UI definition information) to the development environment 300. The development environment 300 stores the received app definition in its developer area. In this way, in this embodiment, any terminal that can access the development environment 300 on the cloud can be used as the developer terminal 100 to design an application. Therefore, as long as a terminal that can connect to the Internet is available, developers can develop applications regardless of location.

Execution environment 400 is an environment using at least one hardware resource built on a network (on the cloud or the Internet). Execution environment 400 includes a multi-tenant execution environment 410 and multiple single-tenant execution environments (e.g., single-tenant execution environments 450, 460, 470). Execution environment 400 is built by combining multiple web services (cloud services). Execution environment 400 is an environment for deploying application definition information (app definition) developed using developer terminal 100 and development environment 300. Application user terminals 200 and 201 used by users who use the application access execution environment 400 by accessing a URL for executing the application. The execution environment 400 then executes various actions in response to operations performed on application user terminals 200 and 201, thereby executing the developed application and providing the application's functions to the app user. Applications built in execution environment 400 on a network are so-called web applications.

The multi-tenant execution environment 410 is a multi-tenant execution environment shared by multiple developers, and applications developed by multiple developers are deployed to it. In other words, it is an environment shared by multiple developers, and is an environment in which multiple apps by multiple developers can be built. The multi-tenant execution environment 410 includes user information 411, an execution engine 412, a distribution engine 415, storage 420, and a DB set 433.

User information 411 is information that records the account of an app user who can log in to the application, such as an email address (username) that serves as the user account ID for the deployed application (built application), and a password. User information 411 is recorded on at least one recording medium included in the multi-tenant execution environment 410.

The execution engine 412 is at least one hardware resource for executing processing to be executed in the multi-tenant execution environment 410, and includes a processor 413 and memory 414. The processor 413 consists of at least one processor, and may be a single processor on the cloud, or a processor group combining multiple processors. The memory 414 is at least one recording medium on which programs to be executed by the processor 413 are recorded. Of the various flowcharts described below, those described as being executed by the multi-tenant execution environment 410 are executed by the execution engine 412. In other words, this is realized when the processor 413 deploys and executes the programs recorded in the memory 414 in an area of the multi-tenant execution environment 410 that serves as work memory. The programs executed here include programs that execute application actions.

The distribution engine 415 transmits a client program 422 (such as HTML source code or JavaScript source code) to be executed on the application user terminal 200, 201 to the application user terminal 200, 201 that has accessed the multi-tenant execution environment 410. The client program 422 is pre-recorded in the storage 420 included in the execution environment 410.

Storage 420 is a storage area of at least one recording medium, and stores at least a client program 422 that is common to multiple applications. In addition, access destination information 421 for accessing the execution environment (multi-tenant execution environment 410) is recorded in a specified area of storage 420 (specified folder, specified bucket, specified level). It also has developer areas, which are storage areas for each developer account. For example, it includes developer A area 423, which is an area for developer A, developer B area 424, which is an area for developer B, and developer C area 425, which is an area for developer C. Each developer area stores definition information for apps developed by each developer and deployed from development environment 300. For example, developer A area 423 stores app definition 423a.

DB set 430 is a group of information related to databases used by applications deployed in execution environment 410. DB set 430 is stored in the storage area of at least one recording medium. Details of DB set 430 will be described later using Figure 23.

Single-tenant execution environments 1 (450), 2 (460), and 3 (470) are each execution environments dedicated to one developer (one developer account), and applications developed by the owner developer using development environment 300 are deployed therein. In this embodiment, as an example, the owner of single-tenant execution environment 1 (450) is Developer A, the owner of single-tenant execution environment 2 (460) is also Developer A, and the owner of single-tenant execution environment 3 (470) is Developer B. In this manner, one developer can own multiple single-tenant execution environments. Single-tenant execution environments 1 (450), 2 (460), and 3 (470) each include user information 451, 461, and 471, execution engines 452, 462, and 472, distribution engines 455, 465, and 475, storage 456, 466, and 476, and DB sets 457, 467, and 477. Apart from the fact that these are dedicated to a single developer, they have the same functions as the user information 411, execution engine 412, distribution engine 415, storage 420, and DB set 433 of the multi-tenant execution environment 410 described above, so detailed explanations will be omitted. It is possible to build many more single-tenant execution environments than the three shown in the figure.

Using the system in Figure 1, for example, an operator could provide the multi-tenant execution environment 410 to developers free of charge and the single-tenant execution environments for a fee. The operator of this system would need to pay maintenance costs to the resource and service provider (cloud service provider) for both the multi-tenant execution environment 410 and each single-tenant execution environment. By having the operator cover the maintenance costs of the multi-tenant execution environment 410 and provide it free of charge to multiple developers, developers would not need to incur costs for trial use of the system, making it easier for many developers to use and promoting the spread of the system. The operator would recover costs by charging developers for the single-tenant execution environments.

There is a limit to the number of processing requests that can be processed per unit time in a single execution environment. If many applications are built in a multi-tenant execution environment and many app users access them simultaneously, the requests may not be able to be processed, which could result in the applications running slowly. There are also some limitations on the number of applications developed by many developers that can be deployed and executed in a multi-tenant execution environment, and these limitations may prevent applications from achieving their full performance. Developers can avoid (or mitigate) these problems caused by the limitations of a multi-tenant execution environment by paying to own a dedicated single-tenant execution environment. In other words, by building applications in a single-tenant execution environment, it is possible to build applications that demonstrate sufficient performance.

Taking into account the characteristics of both the multi-tenant single environment and the single-tenant execution environment, developers can use the system as follows. For example, when using the system for the first time, a developer can build an application developed using the system in the multi-tenant execution environment 410 and test it. After determining that the system is beneficial to the developer's software development, the developer can purchase a single-tenant execution environment. Furthermore, when developing a specific application X, a developer can build an alpha version of application X in the multi-tenant execution environment 410 for a limited number of test users to try out before releasing it to general users. Application X is then tested, modifications are made, and further development is carried out. Then, once development is complete to a level where it can be released to general users, a production version of application X is built in the single-tenant execution environment and released to general users. Using the system in this way, developers can reduce development costs during the development period and operate applications without any problems, even when used by a large number of general users.

Figure 2 shows a hardware block diagram of an information processing device as an example of a device (electronic device) that can be used as developer terminal 100, application user terminal 200, and application user terminal 201. In Figure 2, CPU 101, memory 102, non-volatile memory 103, image processing unit 104, display 105, operation unit 106, recording medium I/F 107, external I/F 109, and communication I/F 110 are connected to internal bus 150. Each unit connected to internal bus 150 is capable of exchanging data with each other via internal bus 150.

Memory 102 is, for example, RAM (volatile memory using semiconductor elements, etc.). CPU 101 controls each part of the information processing device using memory 102 as work memory in accordance with programs stored in, for example, non-volatile memory 103. Non-volatile memory 103 stores image data, audio data, other data, and various programs for CPU 101 to operate. Non-volatile memory 103 is, for example, composed of a hard disk (HD) or ROM.

Under the control of the CPU 101, the image processing unit 104 performs various image processing on image data stored in the non-volatile memory 103 or recording medium 108, video signals acquired via the external I/F 109, image data acquired via the communication I/F 110, captured images, etc. The image processing performed by the image processing unit 104 includes A/D conversion processing, D/A conversion processing, image data encoding processing, compression processing, decoding processing, enlargement/reduction processing (resizing), noise reduction processing, color conversion processing, etc. The image processing unit 104 may be configured with a circuit block dedicated to performing specific image processing. Furthermore, depending on the type of image processing, the CPU 101 may perform image processing according to a program without using the image processing unit 104.

Under the control of CPU 101, display 105 displays images and GUI screens that constitute a GUI (Graphical User Interface). CPU 101 generates display control signals according to a program and controls each part of the information processing device to generate video signals for display on display 105 and output them to display 105. Display 105 displays images based on the output video signals. Note that the information processing device itself may only have an interface for outputting video signals for display on display 105, and display 105 may be configured as an external monitor (such as a television). Hereinafter, unless otherwise specified, the display destination for processes executed by developer terminal 100, application user terminal 200, and application user terminal 201 will be assumed to be the display 105 of each operator.

The operation unit 106 is an input device for accepting user operations, and includes a character information input device such as a keyboard, a pointing device such as a mouse or touch panel, a button, a dial, a joystick, a touch sensor, a touchpad, etc. The touch panel is an input device that is configured as a planar surface overlaid on the display 105 and outputs coordinate information according to the position of contact.

The recording medium I/F 107 allows a recording medium 108 such as a memory card, CD, or DVD to be attached, and reads and writes data from and to the attached recording medium 108 under the control of the CPU 101. The external I/F 109 is an interface that connects to an external device via a wired cable or wirelessly, and is used to input and output video and audio signals. The communication I/F 110 is an interface that communicates with external devices and the Internet 111, sending and receiving various data such as files and commands. The developer terminal 100 can communicate with (send and receive information from) the development environment 300 on the Internet 111 using the communication I/F 110. The application user terminals 200 and 201 can communicate with (send and receive information from) the execution environment 400 on the Internet 111 using the communication I/F 110.

<Login process>
3A and 3B show flowcharts of the login process. This process covers the process from logging in to the development environment 300 from the developer terminal 100 to displaying the UI editor. When the developer terminal 100 launches the internet browser software and receives an instruction to access the development system (application development platform) of this embodiment by specifying the URL, the process shown in FIG. 3A begins. The process shown in FIG. 3A is realized by the CPU 101 of the developer terminal 100 loading into memory 102 a program stored in nonvolatile memory 103 for executing the internet browser software and a client program 322 received from the development environment 300. Hereinafter, the process simply described as the process executed by the developer terminal 100 refers to the process in which the CPU 101 of the developer terminal 100 loads into memory 102 a program stored in nonvolatile memory 103 for executing the internet browser software and a client program 322 received from the development environment 300 and executes them.

When the developer terminal 100 launches the internet browser software and accesses the development system (application development platform) of this embodiment by specifying its URL, the distribution engine 305 of the development environment 300 detects the access and sends the client program 322 to the developer terminal 100 that is the source of the access.

In S301, the developer terminal 100 determines whether it has received the client program 322 sent from the development environment 300. If it has not been received, it waits for reception in S301, and if it has been received, it proceeds to S302.

In S302, the developer terminal 100 records the client program 322 received from the development environment 300 in memory 102.

In S303, the developer terminal 100 displays a login screen on the display 105 in accordance with the client program 322. The login screen displays a message indicating that this is the login screen for the development system of this embodiment, as well as fields for entering a developer ID and password, a new registration button (icon), and a login button (icon).

In S304, the developer terminal 100 accepts input operations into the input fields for the developer ID and password on the login screen. The user's input operations are performed using the operation unit 106. The developer ID is user identification information used to identify (specify) the developer user. In this embodiment, the developer ID (user name) is assumed to be an email address. Furthermore, the password used as the secret code is assumed to be an arbitrary character string, but it may also be other secret code, such as biometric authentication information (fingerprint authentication is information used for face authentication) or pattern authentication information (information on the trajectory pattern entered on the screen).

In S305, the developer terminal 100 determines whether an operation has been performed (e.g., a click) to instruct the new registration button on the login screen. Note that hereafter, an operation to instruct a display item (a display object such as a button or icon, or a display item) by clicking with the mouse included in the operation unit 106 or touching the touch panel will be referred to simply as "pressing." If the new registration button has been pressed, proceed to S306; if not, proceed to S307.

In S306, the developer terminal 100 performs developer account registration processing. Details of the developer account registration processing will be described later using Figure 22 (a).

In S307, the developer terminal 100 determines whether the login button on the login screen has been pressed. If the login button has been pressed, the process proceeds to S308; if not, the process returns to S304.

In S308, the developer terminal 100 sends the information entered in the developer ID and password input fields on the login screen (the entered developer ID and password) to the development environment 300 as login information. After sending, authentication processing is performed in the development environment 300, so the developer terminal 100 waits for the results.

In S309, the developer terminal 100 determines whether it has received information from the development environment 300 indicating a login error. If it has received information indicating a login error, it returns to S304 and accepts the input of login information again; if not, it proceeds to S310.

In S310, the developer terminal 100 determines whether it has received an execution environment list from the development environment 300. If login authentication is successful, the development environment 300 sends the execution environment list to the developer terminal 100, so receiving the execution environment list means that login authentication was successful (login was successful). If the execution environment list has been received, proceed to S311; if not, return to S309.

In S311, the developer terminal 100 records the execution environment list received in S310 in memory 102 as the development screen for the app after login, and displays execution environment options on the display 105 based on the received execution environment list. The execution environment list indicates the execution environments that the logged-in developer can access. Note that screens displayed on the developer terminal 100 after S311 that differ from the screen of the built app are collectively referred to as development screens.

Figure 5(a) shows an example of the execution environment options displayed in S311. In the display example of Figure 5(a), two options are displayed as execution environments accessible to the logged-in developer: option 551 corresponding to the multi-tenant execution environment 410, and option 552 corresponding to the single-tenant execution environment. The developer user can select one of these options by pressing it, and confirm the selection by pressing the SAVE button 553. The selection made here is the destination to which the application updated in subsequent work during this login will be deployed. The execution environment is not accessed at this point. The execution environment selected here can be changed using the operations described below.

In S312, the developer terminal 100 determines whether an execution environment has been selected. If one of the execution environment options has been pressed and the SAVE button 553 has been pressed, the process proceeds to S313; if not, the process waits for the execution environment to be selected in S312.

In S313, the developer terminal 100 records information identifying the execution environment selected in S312 (such as the execution environment ID) in memory 102 as the "selected execution environment" and transmits it to the development environment 300. In response to receiving the information identifying the selected execution environment (selected environment), the development environment 300 transmits, as app information, information identifying all applications owned by the logged-in developer (applications previously generated and recorded in storage 320) (such as the app ID and app name).

In S314, the developer terminal 100 determines whether or not app information has been received from the development environment 300. If app information has been received, the process proceeds to S315; if not, the developer terminal 100 waits for the reception of app information in S314.

In S315, the developer terminal 100 records the received app information in memory 102 and, based on the app information, displays on the display 105 a list of applications (app list) owned (or under development) by the logged-in user.

In S316, the developer terminal 100 determines whether any application has been selected from the list of applications displayed in the app list. If any application has been selected, the process proceeds to S317; if not, the process proceeds to S320.

In S317, the developer terminal 100 records the application selected from the app list as the "selected app" in memory 102, and also transmits information identifying the selected app (such as the app ID and app name) to the development environment 300. Upon receiving the information identifying the selected app, the development environment 300 obtains definition information (app definition) for the selected app from the area of storage 320 for the logged-in developer, and transmits it to the developer terminal 100.

In S318, the developer terminal 100 determines whether it has received definition information (UI definition information) for the selected app from the development environment 300. If it has received definition information for the selected app, it records the received definition information for the selected app in memory 102 and proceeds to S319. If not, it waits for the reception of definition information in S318. In this embodiment, this definition information is a Json file in Json format that describes various definitions related to the application. Thereafter, when the selected app is displayed on the display 105, it is displayed based on the definition information recorded in memory 102. When an operation to update the selected app (e.g., changing the layout of UI components) is performed using the UI editor process described below, the definition information in memory 102 is updated to define the updated content. Then, when a save command is received, the latest definition information recorded in memory 102 is sent to the development environment 300 and saved in the logged-in developer's area of storage 320. This reduces the frequency of communication with the development environment 300 and prevents a decrease in response time due to communication, allowing for smooth update operations.

In S319, the developer terminal 100 displays a UI editor screen on the display 105 and displays the screen based on the received definition information. For example, a canvas (editing area of the UI screen) with a shape corresponding to whether the selected app is for desktop or mobile use (i.e., a shape corresponding to the type of device on which the app will be used) is displayed. For desktop use, a rectangular canvas with a 16:9 aspect ratio is used, and for mobile use, a canvas with a vertical aspect ratio similar to that of a smartphone is used. A list of UI screens owned by (belonging to) the selected app is displayed in the submenu area (described below). (Strictly speaking, this process is performed in S401 of Figure 4, described below.) The canvas also displays components (UI parts to be placed on the UI screen) that will be placed on the UI screen selected by default (the initial UI or the UI screen edited at the time of the last save). Note that the UI screen to be edited may not be selected by default, and nothing may be displayed on the canvas at this point. The login process ends in S319, and the process proceeds to S401 of Figure 4.

On the other hand, in S320, the developer terminal 100 determines whether an icon (a + mark, not shown) for creating a new application displayed on the screen displaying the list of apps has been pressed, instructing the creation of a new application. If it determines that a command to create a new application has been issued, the process proceeds to S321; otherwise, the process returns to S316.

In S321, the developer terminal 100 displays a selection screen asking whether the newly created application should be for desktop use (for PCs) or for mobile use, and accepts an operation to select one of the options. A desktop application is an application that is intended to be accessed and operated from an application user terminal 200 such as a desktop PC or laptop PC. A mobile application is an application that is intended to be accessed and operated from an application user terminal 201 such as a smartphone.

In S322, the developer terminal 100 displays a screen for accepting input of basic app information (at least the app name and app ID) for the newly created application, and accepts input operations to set the app information. Upon accepting the input of the app information, the information on whether the application is for desktop (PC) or mobile use accepted in S321 and the app information accepted in S322 are sent to the development environment 300. In this way, definition information for the new application is created in storage 320 of the development environment 300 as definition information for the newly created application, and the information on whether the application is for desktop (PC) or mobile use, the app name, and the app ID are recorded. In this way, the information on whether the application is for desktop (PC) or mobile use, the app name, and the app ID are also recorded in the definition information for applications that have already been created in the past.

In S323, the developer terminal 100 displays a UI editor screen as an editing screen for the newly created application. In this case, the canvas is displayed in a shape that corresponds to whether it is for desktop or mobile use, selected in S321. The canvas is also displayed as blank information with no components placed on it. The login process ends in S323, and the program then proceeds to S401 in Figure 4.

Figure 3(b) shows the login process on the development environment 300 side, which cooperates with the login process on the developer terminal 100 side in Figure 3(a). The process in Figure 3(b) is realized by the processor 303 of the development environment 300 expanding and executing a program recorded in memory 304 into an area of the development environment 300 that serves as work memory. Hereinafter, any description of a process simply executed by the development environment 300 will be taken to mean a process executed by the execution engine 302 of the development environment 300, or more specifically, by the processor 303.

In S331, the development environment 300 determines whether the login information sent from the developer terminal 100 in S308 has been received. If the login information has been received, the process proceeds to S332; if not, the process waits for the login information to be received.

In S332, the development environment 300 compares the received login information with the developer information 301 and performs login authentication (user authentication). More specifically, it determines whether the developer information 301 (user information) contains information that matches the developer ID and password combination contained in the received login information. If so, authentication is successful.

In S333, the development environment 300 determines whether the result of the authentication process in S332 is that the login is successful (authentication was successful, the user was authenticated, authentication is successful). If the login is successful, the process proceeds to S335; if the login is not successful, the process proceeds to S334, and information indicating a login error is sent to the developer terminal 100.

In S335, the development environment 300 sends to the developer terminal 100 a list of execution environments for developers (logged-in developers) whose login has been approved, which are included in the developer information 301. As shown in FIG. 14(a), the developer information 301 records accessible execution environment IDs for each developer, in addition to an email address (username, developer ID) and password. Each execution environment ID is an account ID for a cloud service (web service) and is assumed to be a 12-digit ID in this embodiment. For developers who can access multiple execution environments, the 12-digit execution environment IDs are recorded, separated by commas. In S335, the accessible execution environment IDs (one or more execution environment IDs separated by commas) for the logged-in developer are sent to the developer terminal 100. That is, in S335, the execution environments accessible by the logged-in developer are identified by referencing the developer information 301. In this way, the accessible execution environments for each developer (the execution environments available to each developer) are recorded in the developer information 301 stored in the development environment 300. This login-enabled execution environment can only be obtained by the developer who has been granted permission to log in. Furthermore, only the developer who has been granted permission to log in can obtain the execution environment that they themselves have access to. This eliminates the need for developers to manage information for accessing their own accessible execution environment separately from the information used to log in to the development environment 300. It also prevents other users from accessing the execution environment illegally.

In S336, the development environment 300 determines whether it has received information identifying the selected execution environment (environment identification information) sent from the developer terminal 100 in S313. If it has received information identifying the selected execution environment, it proceeds to S337; if not, it waits for reception of information identifying the selected execution environment.

In S337, the development environment 300 records the selected execution environment in a settings management file stored in the logged-in developer area of storage 320 based on the information identifying the selected execution environment received in S336.

In S338, the development environment 300 obtains app information indicating all applications owned by (created by) the logged-in developer from the logged-in developer's area in storage 320, and sends this information to the developer terminal 100. The app information sent here is only the app definition information necessary to display the app list mentioned above in S315, and does not include detailed definition information about each app (such as component placement and information indicating actions, which will be described later).

In S339, the development environment 300 determines whether or not it has received information about the new app (including information about whether it is for desktop (PC) or mobile use, the app name, and the app ID) sent from the developer terminal 100 in S322. If it has received information about the new app, it proceeds to S340; if not, it proceeds to S341.

In S340, the development environment 300 creates and records definition information for a new application in the logged-in developer's area of storage 320 based on the information about the new app received in S339. The definition information recorded here includes information about whether the app is for desktop (PC) or mobile use, the app name, and the app ID. To distinguish the app from other users' apps in the multi-tenant execution environment 410, the development environment 300 records the app ID by appending an eight-digit developer code that uniquely corresponds to the developer ID of the developer who owns the app immediately before the ID entered by the developer in S322. The login process then ends. Thereafter, when performing internal processing or displaying the app ID in a programming language on the action board, the ID appended with the developer code of the logged-in developer is used. Furthermore, when displaying the app ID in a UI editor, etc., only the ID portion entered by the developer in S322 is displayed, excluding the developer code.

In S341, the development environment 300 determines whether or not it has received information identifying the selected app sent from the developer terminal 100 in S317. If it has received information identifying the selected app, it proceeds to S342; if not, it returns to S339.

In S342, the development environment 300 retrieves definition information (app definition) for the selected app from the logged-in developer's area in storage 320 based on the information identifying the selected app received in S341, and transmits this information to the developer device 100. The definition information transmitted here includes detailed definition information about the selected app (such as component placement and information indicating actions, which will be described later). The login process then ends.

<UI Editor Processing>
The UI editor process will be described with reference to Figures 4 and 5B. The UI editor process is a process for defining various aspects of the application to be constructed (UI component definitions, action definitions) in response to operations by a developer (user) on the UI editor screen (application development screen).

Figure 5(b) shows an example of a layout editing screen displayed by the UI editor process on the display 105. The screen in Figure 5(b) includes a header menu area 500, a main menu area 510, a submenu area 520, and a canvas 530 (the editing reception area of the UI screen).

The header menu area 500 displays a selected execution environment box 501, a selected app box 502, a selected UI screen box 503, a save button 504, a preview button 505, and a deploy button 506.

The selected execution environment box 501 displays the selected execution environment ID as information indicating the selected execution environment. By pressing the arrow icon on the right end of the selected execution environment box 501, a list of execution environments accessible to the logged-in developer obtained in S310 is displayed as a pull-down menu, and the selected execution environment can be changed by selecting any execution environment from the list. Even if the selected execution environment is changed, the selected app does not change, and the content displayed in the main menu area 510, submenu area 520, and canvas 530 does not change. In this way, by changing the selected execution environment to which the same application is deployed, it is possible to deploy the same application to any number of execution environments.

The selected app box 502 displays the name of the selected app as information representing the selected app. By pressing the arrow icon on the right end of the selected app box 502, a list of apps owned by the logged-in developer obtained in S314 is displayed as a pull-down menu, and the selected app can be changed by selecting any app from the list. When the selected app is changed, the content to be displayed in the submenu area 520 and canvas 530 changes.

The selected UI screen box 503 displays the name of the UI screen being edited as information representing the UI screen being edited on the canvas 530. By pressing the arrow icon in the selected UI screen box 504, a list of UI screens belonging to the selected app is displayed as a pull-down menu based on the definition information of the selected app obtained in S318, and by selecting any UI screen from the list, it is possible to change the UI screen being edited and displayed on the canvas 530.

The main menu area 510 displays the following selection icons for the main menu items: an app list button 511, a UI screen button 512, a workflow button 513, a settings button 514, an environment list button 515, a database button 516, a file manager button 517, a user management button 518, and a snapshot button 519. The processing performed in response to pressing these selections will be described later in the screen switching processing of Figure 12.

The submenu area 520 displays a submenu corresponding to the item selected in the main menu. In the example of Figure 5(b), a UI component list (UI part list) is displayed as a lower-level menu of the UI screen button 512.

The canvas 530 is the layout editing area for the selected UI screen of the selected app (the UI screen whose UI screen name is displayed in the selected UI screen box 503). The canvas 530 in Figure 5(b) is an example of a canvas display for a desktop application, displayed in a desktop format. The user can select any UI component (UI part) from the list of UI components displayed in the submenu area 520 and place it in the canvas area 530 by dragging and dropping it. The size and position of a UI component can be adjusted by selecting it in the canvas area 530. Furthermore, by selecting a UI component in the canvas area 530, right-clicking, and selecting properties from the right-click menu (context menu), more detailed settings such as color scheme can be made. Furthermore, by selecting an action from the context menu, an action board is displayed, allowing the user to set the action to be executed when the UI component is operated. By right-clicking while the cursor is in a blank area of the canvas 530, the canvas's context menu can be displayed. By selecting an action from the menu, you can set the action to be executed when the UI screen of that canvas is loaded in the built application (to be executed when the UI screen is displayed).

Figure 5(b) shows an example in which a pie chart 531, a button 532, text fields 533 and 534, an output field 535, and a tab component 536 are arranged as UI components on a canvas 530 with a UI screen name "ui1" for an app with an app name "UI1." Operation path 531a is a selection frame indicating the selected UI component and an operation path (operation handle) that accepts zoom instructions, indicating that pie chart 531 is selected.

Figure 4 shows a flowchart of the UI editor process. This process is executed by the developer terminal 100 and follows S319 or S323 in Figure 3.

In S401, the developer terminal 100 displays a list of UI screens for the selected app as options in the submenu area 520 based on the definition information of the selected app. Each screen displayed in this UI screen list is designed to be displayed when the selected app is deployed and built in an execution environment, and accessed and executed from the app user terminal 200, 201. This UI screen list can also accept operations to add new UI screens and delete UI screens.

In S402, the developer terminal 100 determines whether an operation to select any of the UI screens from the list of UI screens displayed in S401 has been performed. If any of the UI screens has been selected, the process proceeds to S404; if not, the process proceeds to S403.

In S403, it is determined whether an operation to select one of the options displayed in the main menu area 510 has been performed. If an option displayed in the main menu area 510 has been selected, the UI editor processing ends, and the process proceeds to the screen switching processing described below at 112. If not, the process returns to S402.

In S404, the developer terminal 100 displays the UI screen selected in S402 on the canvas 530 based on the definition information of the selected app recorded in memory 102. If the UI screen has previously had UI components placed on it, the UI components placed on it according to the definition information are displayed on the canvas 530. In other words, if the UI screen was previously created but only partially, development can continue from that point. If the UI screen selected in S402 is a newly created UI screen, the canvas 530 is displayed blank with no UI components placed on it. If the UI screen selected in S402 is a UI screen (template screen) that has been prepared in advance as a template, a template component with a predetermined action defined is displayed in a predetermined position on the canvas 530, even if the user has not previously placed UI components on that UI screen.

At S405, the developer terminal 100 displays a list of UI components in the submenu area 520. That is, the display switches from the UI screen list of the selected app to a UI component list. UI components that can be placed on the canvas 530 include types: INPUT, Button, Display (information display component), Navigation, Layout, and Chart, each of which has multiple UI components categorized under that type. In the UI component list, a list of UI component types is first displayed, as shown in FIG. 5(c). When an operation to select one of the displayed types is performed, the UI components classified under the selected type are expanded and displayed. The aforementioned FIG. 5(b) shows an example in which the option 522 for the type corresponding to INPUT is selected, and a list of UI components classified under INPUT is displayed. UI components classified under INPUT include, for example, a text field 523 and a text area 524. The submenu area 520 is scrollable, and options that cannot be displayed (options for the UI component of the expanded type and options for other types) can be scrolled to display them. When an option 522 for an expanded type is operated, as shown in Figure 5(b), the list of UI components for the expanded type is collapsed, and a list of UI component types is displayed.

In S406, the developer terminal 100 determines whether a UI component displayed in the submenu area 520 has been selected. More specifically, it determines whether an operation to drag a UI component displayed in the submenu area 520 has been performed. If a UI component displayed in the submenu area 520 has been selected, the process proceeds to S407; if not, the process proceeds to S411.

In S407, the developer terminal 100 determines whether an operation to specify a position on the canvas 530 has been performed. More specifically, it determines whether an operation to drop a dragged UI component onto the canvas 530 has been performed. If an operation to specify a position on the canvas 530 has been performed, the process proceeds to S408; if not, the process waits for specification of a position on the canvas 530 in S407. Note that, although an example of drag and drop is described in this embodiment, the operation method is not limited to this as long as it is an operation to select a UI component from the submenu area 520 and place it at a specified position on the canvas 530.

In S408, the developer terminal 100 determines whether the position on the canvas specified in S407 is included in the area of a tab component (a type of UI component) that has already been placed. If it is not included in the area of the tab component, the process proceeds to S409; if it is included in the area of the tab component, the process proceeds to S410. An example of a tab component is the tab component 536 shown in Figure 5(b). A tab component has multiple tabs (in the example of Figure 5(b), there are three tabs displayed as ITEM1, ITEM2, and ITEM3), and when one of the tabs is selected, the display content displayed by the tab component is switched to the element screen corresponding to the selected tab.

Tab components will be explained using Figures 6(a) and (b). Figure 6(a) is an example of a display on the display 105 when a tab component 601 is placed on a canvas 530 displaying a UI screen different from that shown in Figure 5(b). The area indicated by the operation bus 601a of the tab component 601 is the area occupied by the tab component 601. By operating the operation bus 601a, the overall display position and overall display size of the tab component 601, including the element screen, can be changed. The tab component 601 has three tabs: tab 610, tab 620, and tab 630. Each tab displays a label as the tab name, which can be set by the developer in the tab component's property settings. In the example shown, they are displayed as Tab0, Tab1, and Tab2, respectively. The number and order of tabs can be changed in the tab component's property settings. Tab properties are set by opening a tab property box from the tab's context menu in S706 of the context menu processing described later in FIG. 7 , and then performing setting operations on the tab property box (setting screen) that is displayed accordingly. The element screen area 602 indicated by the dashed-dotted line (illustrated for illustrative purposes only and not actually displayed) is an area in which the display content changes depending on the selected tab. The display content corresponding to each tab displayed in the element screen area 602 is referred to as the element screen corresponding to each tab. Different UI components can be arranged on the element screen corresponding to each tab. The example in FIG. 6A shows an example in which tab 610 is selected and the element screen corresponding to tab 610 is displayed. In the illustrated example, UI components 611 and 612 are arranged on the element screen corresponding to tab 610. The example in FIG. 6B shows an example of a display in which tab 620 is clicked from the state in FIG. 6A , changing the selected tab from tab 610 to tab 620. In FIG. 6B , the element screen area 602 displays the element screen corresponding to the selected tab 620. In the illustrated example, a UI component 621 is placed on the component screen corresponding to tab 620. In the examples of FIGS. 6(a) and 6(b), the definition information at least records the UI component ID (UI component identification information) of tab component 601 and the position of tab component 601 in the UI screen in association with the ID (UI screen identification information) of the UI screen being edited on canvas 530. Also, the IDs of UI components 611 and 612 and their respective positions in the component screen of tab 610 are recorded in association with the ID of tab 610 of tab component 601. Also, the ID of UI component 621 and the position of UI component 621 in the component screen of tab 620 are recorded in association with the ID of tab 620 of tab component 601. Return to the description of FIG. 4.

In S409, the developer terminal 100 places the UI component selected in S406 from the submenu area 520 at the specified position on the canvas 530 at a default size, and records the information defining this in the definition information stored in memory 102. That is, in the definition information, the type of UI component placed in S410, UI component ID, placement coordinates, placement size, etc. are recorded in association with the ID of the UI screen where the component is to be placed (the UI screen being edited).

In S410, the developer terminal 100 places the UI component selected in S406 from the submenu area 520 at a default size on the element screen (the currently displayed element screen) corresponding to the selected tab among the tab components at the specified position on the canvas 530, and records the information defining this in the definition information stored in memory 102. That is, the definition information associates the ID of the destination UI screen (the UI screen being edited) with the type of UI component placed in S410, the tab component ID as the UI component ID, the ID of the selected tab for that tab component, the placement coordinates in the element screen corresponding to the selected tab, the placement size, and other information. In this way, in this embodiment, it is possible to place and layout different UI components on each element screen corresponding to each tab of the tab component. Furthermore, at this time, there is no need for complex operations to define the tab of the element screen on which the UI component will be placed; simply select and display the destination element screen when placing the desired UI component by dragging and dropping it.

In S411, the developer terminal 100 determines whether a UI component already placed on the canvas 530 has been selected by clicking or the like. If a placed UI component has been clicked (selected), the process proceeds to S412; if not, the process proceeds to S415.

In S412, the developer terminal 100 displays an operation path for the UI component clicked in S411. Examples of displayed operation paths are the operation path 531a and operation path 601a described above.

In S413, the developer terminal 100 determines whether the position specified by clicking in S411 is within the area of the tab portion of the tab component. If it is not within the tab portion, the process proceeds to S431; if it is within the tab portion, the process proceeds to S414. The tab portion is a designation area that instructs switching to the corresponding element screen.

In S414, the developer terminal 100 switches the display of the tab component's element screen area to the element screen corresponding to the tab at the position specified by the click in S411. For example, if one of the three tabs displayed as ITEM1, ITEM2, or ITEM3 on the tab component 536 is clicked in S411, the developer terminal 100 displays an operation path for the tab component 536 in S412, and switches the display content of the element screen area 436a to that of the element screen corresponding to the clicked tab. Also, for example, if the display is as shown in FIG. 6(a), the display switches to that shown in FIG. 6(b) when tab 620 is specified. That is, the UI components 611 and 612 located on the element screen displayed before the click are hidden, and instead, the UI component 621 located on the element screen corresponding to the clicked tab 620 is displayed. This control is performed to simplify the operation of defining the element screen of the desired tab when a developer wants to place another UI component on the element screen of a desired tab of the tab component. If a developer wants to place another UI component on the component screen of a desired tab of a tab component, they can simply click the desired tab to display the desired component screen before dragging and dropping the desired UI component.

In this embodiment, for the sake of simplicity, the processing of S409, S410, S413, and S414 has been described using a tab component as an example, but this is not limited to this. The processing of S409, S410, S413, and S414 can be applied to a specific type of UI component other than a tab component, as long as the display content of the UI component changes in response to an operation on the UI component after the application is built.

On the other hand, in the case of UI components that are not of a specific type, such as tab components, the display content within the UI component is not changed in response to the selection of the UI component on canvas 530. The only processing performed in response to the selection of the UI component is processing related to the display of the operation path, and no other actions are performed. For example, when button 532 is selected on canvas 530 in Figure 5(b), only the operation path is displayed, and the action of button 532 (the processing that is executed when button 532 is pressed in the constructed app) is not executed. Furthermore, when text field 533 is selected on canvas 530, only the operation path is displayed, and processing such as displaying a character input cursor within text field 533 is not performed.

Using Figures 6(c), 6(d), and 6(e), we will explain an example of an AppBar as an example of a type of UI component to which the processes of S409, S410, S413, and S414 can be applied, similar to tab components. Figure 6(c) shows an example in which UI components AppBar 650, TextField 661, and Button 662 are placed on canvas 530. AppBar 650 is a single UI component, and contains element icons 651 and 652. In a constructed application, element icon 651 is a display item that accepts instructions for displaying a drawer menu. In a constructed application, element icon 652 is a display item that accepts instructions for displaying a pop-up menu. When the positions of element icons 651 and 652 of placed AppBar 650 on canvas 530 are clicked, they are controlled in the same way as the tab portion of a tab component. More specifically, it is controlled as follows:

When the position of the element icon 651 in the placed AppBar 650 is clicked (Yes in S411), the operation path for the AppBar 650 is displayed (S412), and if a Yes determination is made in S413, a drawer menu is displayed as an element screen (S414). This transitions the display state from FIG. 6(c) to FIG. 6(d). In FIG. 6(d), the operation path 650a for the AppBar 650 is displayed, and the drawer menu 651a, which is the element screen corresponding to the element icon 651, is also displayed. The drawer menu 651a is an area that is displayed by sliding from the left edge of the screen to the right, and displays one or more menu items. With the drawer menu 651a displayed, other UI components can be placed in the drawer menu 651a by dragging other UI components from the submenu area 520 and dropping them onto the drawer menu 651a, similar to the processing described in S408 and S410 using the tab component as an example.

When the position of the element icon 652 in the placed App Bar 650 is clicked (Yes in S411), the operation path for the App Bar 650 is displayed (S412), and if a Yes determination is made in S413, a pop-up menu is displayed as an element screen (S414). This transitions the display state from FIG. 6(c) to FIG. 6(e). In FIG. 6(e), the operation path 650a for the App Bar 650 is displayed, and a pop-up menu 652a, which is an element screen corresponding to the element icon 652, is also displayed. The pop-up menu 652a is an area displayed near the element icon 652 and displays one or more menu items (options). With the pop-up menu 652a displayed, other UI components can be placed on the pop-up menu 652a by dragging another UI component from the submenu area 520 and dropping it onto the pop-up menu 652a, similar to the processing described in S408 and S410 using the tab component as an example. Return to the description of FIG. 4.

In S415, the developer terminal 100 determines whether an operation to drag a placed UI component on the canvas 530 has been performed. If an operation to drag a placed UI component has been performed, the process proceeds to S416; if not, the process proceeds to S417. In S416, the developer terminal 100 changes the position of the dragged UI component (selected component) in response to the drag operation. Specifically, it places the component at the dropped position. When the position is changed, the definition information recorded in memory 102 is also updated to indicate the new position.

In S417, the developer terminal 100 determines whether an operation has been performed on the operation path of a UI component already placed on the canvas 530. If an operation has been performed on the operation path, the process proceeds to S418; if not, the process proceeds to S419. In S418, the developer terminal 100 changes the size of the UI component (selected component) to which the operation path has been assigned in accordance with the operation on the operation path. When the size is changed, the definition information recorded in memory 102 is also updated to reflect the changed size.

In S419, the developer terminal 100 determines whether a command to display a context menu (in this embodiment, a right-click of the mouse) has been performed in any area of the canvas 530. If a right-click has been performed, the process proceeds to S420; otherwise, the process proceeds to S421. In S420, a context menu (right-click menu) is displayed according to the position of the mouse cursor at the time of the right-click, and context menu processing is performed to perform processing according to the operation on the context menu. For example, if a right-click is performed while the mouse cursor is over button 532 in FIG. 5(b), a context menu 540 related to button 532 (specified UI component) as shown in FIG. 5(d) is displayed. The context menu 540 displays properties 541, actions 542, and delete 543 as menu options. When properties 541 is selected, a properties box (detailed settings dialog) related to button 532 is displayed, allowing detailed settings to be made, such as the button name (label) to be displayed on button 532, the color of button 532, and the size specified numerically. When action 542 is selected, an action board related to button 532 is displayed, and an action can be entered into the action board in JavaScript, a programming language. The action entered here is the process to be executed when button 532 (specified UI component) is pressed in the constructed application. When delete 543 is selected, button 532 is deleted (removed) from canvas 530. Details of context menu processing will be described later using Figure 7.

In S421, the developer terminal 100 determines whether the Save button 504 has been pressed. If the Save button 504 has been pressed, the process proceeds to S422; if not, the process proceeds to S423. In S422, the developer terminal 100 transmits the definition information of the application being edited, which is stored in memory 102, to the development environment 300. Upon receiving the definition information, the development environment 300 performs the save process described below in Figure 33(a) or Figure 35(a).

In S423, the developer terminal 100 determines whether the preview button 505 has been pressed. If it determines that the preview button 505 has been pressed, the process proceeds to S424; otherwise, the process proceeds to S425. In S424, the developer terminal 100 performs preview processing. In the preview processing, the canvas 503 is hidden, and a preview of the UI screen being edited on the canvas 503 is displayed based on the definition information stored in memory 102 or the definition information stored in the development environment 300, so that the UI screen will look the same as when viewed in the built application. The preview does not display the operation paths for operating UI components. In addition, some operations that are not performed on the UI editor screen (not performed by operations on the canvas 530) are performed in the preview. For example, when a UI component for screen transitions or a link is operated, a screen transition or transition to the link destination is performed. In addition, operations such as moving the selection frame for an item by operating the tab key on the keyboard are also performed. Please note that actions entered by the developer in the action boat and database references will not be performed. As a result, the preview process can be displayed faster than if you actually deploy and check the results.

In S425, the developer terminal 100 determines whether the Deploy button 506 was pressed. If the Deploy button 506 was pressed, the process proceeds to S426; if not, the process proceeds to S427. In S426, the developer terminal 100 executes the deployment process. The deployment process will be described later using FIG. 24(a). Note that when the Deploy button 506 is pressed to execute the deployment process, the developer does not need to select the destination execution environment; deployment occurs to the pre-selected execution environment displayed in the Selected Execution Environment box 501. Developers often work to update all the content to be deployed to a specific execution environment at once. For this reason, the system prompts the developer to select the destination execution environment before selecting the application to be updated (S311 in FIG. 3), eliminating the need to select the execution environment each time an application is deployed. This prevents operational errors such as accidentally deploying to an unintended execution environment and improves work efficiency. Furthermore, although authentication processing is performed when logging in to the development environment 300, there is no need to perform separate account authentication processing for the execution environment to be deployed to. This prevents an increase in the amount of work required and allows for efficient work. In other words, the developer terminal 100 does not obtain authentication information related to the execution environment to which the developer is deploying from the developer user.

In S427, the developer terminal 100 determines whether an operation to change the selected execution environment has been performed. Specifically, it determines whether an operation to change the selected execution environment has been performed on the selected execution environment box 501. If an operation to change the selected execution environment has been performed, the process proceeds to S428; if not, the process proceeds to S429. In S428, the developer terminal 100 records information identifying the selected execution environment (such as an execution environment ID) in memory 102 as the "selected execution environment" and sends it to the development environment 300. The developer terminal 100 also updates the display content of the selected execution environment box 501 to represent the changed selected execution environment. Upon receiving the information identifying the selected execution environment, the development environment 300 records the selected execution environment in a settings management file stored in the logged-in developer area of storage 320 based on that information.

In S429, the developer terminal 100 determines whether an operation to change the application to be edited has been performed. Specifically, it determines whether an operation to change the selected app has been performed in the selected app box 502. If an operation to change the selected app has been performed, the process proceeds to S317 in FIG. 3, and the processing from S317 onwards is executed based on the changed selected app. In other words, the display contents of the submenu area 520 and canvas 530 are updated. If an operation to change the selected app has not been performed, the process proceeds to S430.

In S430, the developer terminal 100 determines whether an operation to change the UI screen to be edited has been performed. Specifically, it determines whether an operation to change the selected UI screen has been performed on the selected UI screen box 503. If an operation to change the selected UI screen has been performed, the process proceeds to S404, and processing is performed based on the changed selected UI screen. In other words, the display content of the canvas 530 is updated (switched) to the changed content of the selected UI screen. If no operation to change the selected UI screen has been performed, the process proceeds to S431.

In S431, the developer terminal 100 determines whether an operation to select one of the options displayed in the main menu area 510 has been performed. If an option displayed in the main menu area 510 has been selected, the UI editor processing ends and the process proceeds to the screen switching processing described later in FIG. 12. If not, the process returns to S406.

<Context menu processing>
7 shows a flowchart of the context menu process, which is a detailed flowchart of S420 in FIG.

In S701, the developer terminal 100 determines whether the context menu to be displayed relates to a UI component of the button type. More specifically, it determines whether the type of UI component designated with the mouse when the right-click was accepted in S419 (designated UI component) is a button. If it is a button, the process proceeds to S710; if not, the process proceeds to S702.

In S702, the developer terminal 100 determines whether the context menu to be displayed is related to the canvas. More specifically, it determines whether the position designated with the mouse when the right-click was accepted in S419 was a blank area of the canvas 530 where no UI components were placed. If it is a blank area (if the context menu to be displayed is related to the canvas), the process proceeds to S703; otherwise, the process proceeds to S704.

In S703, the developer terminal 100 performs canvas context menu processing. Canvas context menu processing will be described later using Figure 19.

In S704, the developer terminal 100 determines whether the context menu to be displayed relates to a UI component of the data grid (table) type. More specifically, it determines whether the type of the UI component (specified UI component) designated with the mouse when the right-click was accepted in S419 is a data grid. If it is a data grid, the process proceeds to S705; if not, the process proceeds to S706.

In S705, the developer terminal 100 performs context menu processing for the data grid. Context menu processing for the data grid will be described later using Figure 30.

In S706, as other processing, the developer terminal 100 displays a context menu related to the specified target corresponding to the specified position and performs processing according to the operation. Details are omitted.

In S710, the developer terminal 100 determines whether the UI screen to be edited (selected UI screen) is a template screen. If it is a template screen, the process proceeds to S721; if not, the process proceeds to S711.

In S711, the developer terminal 100 superimposes and displays the button context menu shown in FIG. 5(d) near the specified position (mouse cursor position) as a context menu for the specified UI component.

In S712, the developer terminal 100 determines whether or not Properties (Properties 541 in FIG. 5(d)) has been selected from the options included in the context menu. If Properties has been selected, the process proceeds to S713; if not, the process proceeds to S714.

In S713, the developer terminal 100 displays a property box for the button superimposed on the canvas 530 as a property box (detailed settings dialog) for the specified UI component. It then accepts various setting operations for the property box. Here, detailed settings can be made, such as the button name (label) to be displayed on the button (the specified UI component), the button color, and the size (specified numerically). After making the settings and performing an operation to reflect them, the specified UI component is displayed on the canvas 530 in a display format that reflects the settings.

In S714, the developer terminal 100 determines whether an action (property 542 in FIG. 5(d)) has been selected from the options included in the context menu. If an action has been selected, the process proceeds to S715; if not, the process proceeds to S716.

In S715, the developer terminal 100 performs action board processing for the button, which is the specified UI component. Action board processing will be described later using Figure 8.

In S716, the developer terminal 100 determines whether or not "Delete" (Delete 543 in FIG. 5(d)) has been selected from the options included in the context menu. If "Delete" has been selected, the process proceeds to S717; if not, the process proceeds to S718.

In S717, the developer terminal 100 erases the specified UI component and erases information about the specified UI component (definitions such as position and size, properties and actions, etc.) from the definition information recorded in memory 102. As a result, the specified UI component is erased (deleted) and hidden from the canvas 530.

In S718, the developer terminal 100 determines whether another option has been selected from the options included in the context menu. If another option has been selected, the process proceeds to S719, where processing is performed according to the selected option. If not, the process proceeds to S720.

In S720, the developer terminal 100 determines whether an operation to close the context menu has been performed (for example, an operation to click outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden and the processing in Figure 7 ends. If no operation to close the context menu has been performed, the process returns to S712.

Meanwhile, in S721, the developer terminal 100 superimposes a button context menu for the template screen shown in FIG. 26(d) near the specified position (mouse cursor position) as a context menu for the specified UI component. Unlike the context menu for a normal UI screen (context menu 540 shown in FIG. 5(d)), the template screen context menu (template component 2634 in FIG. 26(d)) does not display options such as Action or Delete, but only Properties. In other words, for UI components placed on a template screen among UI screens, the developer is prevented from setting the action to be taken when the UI component is operated. The reason for this will be explained later.

In S722, the developer terminal 100 determines whether or not Properties has been selected from the options included in the context menu. If Properties has been selected, the process proceeds to S723; if not, the process proceeds to S724. The processing of S723 is the same as S713.

In S724, the developer terminal 100 determines whether an operation to close the context menu has been performed (for example, an operation to click outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden and the processing in Figure 7 ends. If no operation to close the context menu has been performed, the process returns to S722.

<Action Board Processing>
The processing related to the action board will now be described. When a UI component placed on the canvas is designated and an action is selected from the context menu, an action board for setting an action related to the designated UI component is displayed. For example, consider the case where a UI screen such as that shown in FIG. 9A is being edited. FIG. 9A is a diagram showing a portion of the UI editor screen on the display 105. In FIG. 9A, a list of UI components is displayed in the submenu area 520, and the UI screen to be edited is displayed on the canvas 900. A UI component 901, which is a button, and other UI components are arranged on the canvas 900. When the UI component 901 is designated and an action option is selected from the context menu, an action board such as that shown in FIG. 9B is displayed.

Figure 9(b) is an example of an action board display for UI component 901. Action board 910 is displayed in place of canvas 900 in the area where canvas 900 was displayed. Unless the specified UI component is a template component pre-placed on the template screen, and unless the developer has previously set an action for the specified UI component, action board 910 will be displayed blank, as shown in Figure 9(b). Note that the "1" displayed on action board 910 is a guide indicating the number of lines, and does not represent the action itself. Developers can set any action on this action board 910 by operating the keyboard included in operation unit 106 and entering any string in JavaScript, a programming language. The trigger for executing the content set on the action board is predetermined and occurs when the specified UI component is operated. Therefore, developers do not need to set the trigger for executing the action (there is no need to write it in JavaScript). For example, if the specified UI component is a button, pressing that button in the constructed app will be the trigger, and when the trigger occurs, the action set in the action board for that button will be executed.

In addition to the action board 910, a function list 920 is displayed in the submenu area instead of the UI component list or UI screen list shown in Figure 9(a) that was displayed on the UI editor screen. The function list 920 displays an option 922 for instructing the display of the action board 910 and function options for instructing the display of each function. Note that a function that is not a pre-prepared function but is created (added) by the developer (user) by pressing the Add Function button 921 (described below) is referred to as an "original function" (created function, added function, self-made function). If there are no automatically created functions or pre-prepared functions and the developer has not previously created an original function for the specified UI component, the function list 920 will not display function options, and only the option 922 and the Add Function button 921 will be displayed, as shown in Figure 9(b).

When the Add Function button 921 is pressed, a dialog box (referred to as the Add dialog 930) for adding an original function is displayed. Figure 9(c) shows an example of the Add dialog 930. The Add dialog 930 displays a type selection field 931 that accepts the selection of the function type, a function name input field 932 that accepts the input of the function name, and a SAVE button 933. When input is made to the Add dialog and the SAVE button 933 is pressed, a function settings screen corresponding to the type selected in the type selection field 931 is displayed, and the function name entered in the function name input field 932 is added to the function list 920.

Figure 9 (d) is an example of a REST function setting screen that is displayed when REST is selected in the type selection field 931. In place of the action board 910, a REST function setting screen 940 is displayed to accept various settings required to create a function (REST function) using REST (REpresentational State Transfer). The function list 920 also displays a function 923 with the function name "rest01" entered in the function name input field 932 as a function option. The icon displayed before "rest01" indicates that the type of function 923 is a REST function. If all required setting items are not set on the function setting screen (if information that should be set is missing), an incomplete mark 929 indicating that the function is incomplete is displayed, clearly indicating that the corresponding function 923 is in an incomplete state.

The REST function setting screen 940 in Figure 9(d) displays setting fields 941 to 944. Setting field 941 is a setting screen for the function name. By default, it displays the function name entered in the function name input field 932, but this can be changed based on input from the developer. Setting field 942 is a setting field for setting the variable name for the arguments. In this embodiment, param is set by default and cannot be changed. It is displayed grayed out to indicate that it cannot be changed. Setting field 943 is a setting field for setting the type of REST function. By operating the triangle icon on the right side of this area, a pull-down menu appears with options: GET, POST, PUT, and DELETE, and one of these options can be selected and set. The type set here indicates the type of request made by this function. Setting field 944 is a setting field for the URL to which the request made by this function is sent. In this way, when creating a REST function on the REST function setting screen 940, developers do not need to write source code strings in a programming language.

Figures 10(a) to (d) show further examples of the creation function setting screen and action board display. In Figure 10, the same elements as in Figure 9 are given the same reference numerals as in Figure 10, and their explanations will be omitted.

Figure 10(a) shows an example of the SQL function setting screen that appears when SQL is selected in the type selection field 931. Instead of the action board 910, an SQL function setting screen 950 is displayed to accept various settings required to create a function (SQL function) using SQL (Structured Query Language). The function list 920 also displays the function 924 with the function name "sql01" entered in the function name input field 932, along with an incomplete mark 929, as a function option. The icon displayed before "sql01" indicates that the type of function 924 is an SQL function. The setting field 951 is a function name setting screen. Initially, the function name entered in the function name input field 932 is displayed, but this can be changed based on input operations by the developer. The setting field 952 is a setting field for setting variable names for setting arguments. In this embodiment, param is set by default and cannot be changed. It is displayed as grayed out to indicate that it cannot be changed. The setting field 953 is an input field for entering a string of characters (SQL sentence, SQL statement) that issues instructions to a database in SQL, a type of computer language (a database language, not a programming language). The developer can enter any SQL STATEMENT into the setting field 953 using a keyboard included in the operation unit 106, for example. In this way, when creating an SQL function on the SQL function setting screen 950, the developer does not need to write the source code string in a programming language.

Figure 10(b) shows an example display of the stage when a developer has created functions 923-925, entered (written) some code (character strings) in JavaScript into the action board 910, and then entered "sq." In this embodiment, when a developer user enters a character string, if the entered character string matches the prefix of the function name (identification information) of a previously created created function, the code assist field 911 displays the matching function name as an input candidate option. In the illustrated example, the entered "sq" matches the prefix of the function name "sql01" of function 924, a previously created created function, so "sql01" is displayed as an option. When the user performs an operation to select "sql01" displayed in the code assist field 911, "sql01" is entered into the action board 910, as shown in Figure 10(c), without performing an operation to enter "sql01." This code assist function allows developers (users) to enter the function name (identification information) of a created function without typing all the characters of the function name on the keyboard, thereby reducing the number of steps required. Furthermore, if the function name matches the prefix of a previously created created function, the full name is displayed in the code assist field 911. If there is no match (i.e., if no function begins with that character string), the code assist field 911 is not displayed. This allows developers to confirm that the function name they are entering is correct for a previously created created function, preventing input errors in the function name. If there are multiple previously created functions that match the prefix, multiple options are displayed in the code assist field 911. Furthermore, the function names of created functions displayed in the code assist field 911 are functions created for the specified UI component (UI component 901 in the illustrated example) targeted by the action board 910; created functions created for other UI components are not displayed. This prevents the mistake of accidentally entering the name of a created function created for another UI component on the action board 910, even if that function does not exist as a created function for the specified UI component.

As shown in Figure 10(c), the function list 920, along with the action board 910, displays the function type (icon before the string) and function name for each of the developer-created functions 923-925. Therefore, while entering (writing) the action code (JavaScript string) into the action board 910, the developer user can check the types and names of the created functions they have created. This reduces the effort required to check and manage valid created functions that can be written into the action board 910 (e.g., the effort required to make a note of them or open another screen to check). It also helps prevent input errors in function names. The functions displayed in the function list 920 are functions created for the specified UI component (UI component 901 in the illustrated example) targeted by the action board 910; created functions created for other UI components are not displayed. This prevents the mistake of accidentally entering a function name of a creation function created for another UI component that does not exist as a creation function for the specified UI component on the action board 910. Furthermore, creation functions are only valid when defining the action of the specified UI component and do not affect the action definitions of other UI components. Therefore, if the function name of a creation function created for a specified UI component is the same as the function name of a creation function created for another UI component, even if that function name is entered on the action board 910, only the function settings set for the specified UI component will be reflected, and the function settings set for the other UI components will not be reflected. Therefore, no error will occur even if the same function name as the function name of a creation function already created for another UI component is used. Therefore, the user can decide on the function name of the creation function and enter it on the action board 910 without worrying about duplicate function names with creation functions already created for other UI components. In other words, many original functions will be created throughout the entire development of an application, but these are automatically managed and organized in association with specified UI components and displayed in the code assist field 911 and function list 920, making it extremely easy for developers to manage a large number of original functions. This reduces the effort and time required to check function names. It also reduces input errors in function names. This also reduces the amount of debugging work (debug fixes) required when inputting a function name. This reduces the workload and man-hours required for software development (application development), enabling more efficient software (application development).

Figure 10(d) is an example of the display after action code has been entered in a programming language into the action board 910. In the illustrated example, the portion indicated by the dotted line 960 on the third line uses the original function "rest01" (function 923 in the function list 920). The code string shown on the action board 910 in Figure 10(d) does not define the details of the original function rest01. Furthermore, when the developer configured rest01 on the REST function setting screen 940, the details of rest01 were not defined in the programming language. If definition information including the action definition in this state is uploaded and saved to the development environment 300, the development environment 300, in the saving process of Figure 33(a) or Figure 35(a) described below, creates source code in the programming language including the function definition in the programming language from the uploaded definition information as a program for the execution environment, based on the function settings and the string written on the action board 910. In this way, when the development environment 300 acquires a string containing identification information (function name) of a created function written in a programming language, it performs control to enable the execution of the function (action) indicated by the string containing the function of the created function (action written on the action board) based on the information set on the function setting screen.

Figure 11 shows an example of source code in a programming language generated by the development environment 300 based on the string entered on the action board 910 in Figure 10(d) and the settings for rest01 configured on the REST function setting screen 940. Note that in the illustrated example, the numbers 1 to 75 written on the left side are used to indicate the line numbers and are not part of the source code. The example in Figure 11 shows 75 lines of source code including a detailed definition of rest01 in a programming language. However, developers do not need to enter all 75 lines themselves. By configuring the REST function setting screen 940 and entering the amount of string (7 lines) shown on the action board 910 in Figure 10(d), the source code content shown in Figure 11 can be defined. In other words, efficient development can be achieved using low code.

Figure 8 shows a flowchart of the action board processing. This processing is a detailed flowchart of the action board processing described above in S715 of Figure 7, and is a process that controls the operations described using the display examples in Figures 9(b) to (d) and 10(a) to (d).

In S801, the developer terminal 100 displays an action board on the display 105. If no action has been defined for the specified UI component, a screen including a blank action board 910 as described in FIG. 9(b) is displayed. If an action has already been defined for the specified UI component, a screen including an action board 910 with the action string entered as described in FIG. 10(d) is displayed.

In S802, the developer terminal 100 determines whether an operation to describe an action (description operation) has been performed on the action board 910. An operation to describe an action is, for example, a text input operation performed by operating the keyboard included in the operation unit 106 while the action board 910 is selected, or by touching a soft keyboard displayed on a touch panel. If an operation to describe an action has been performed, the process proceeds to S803; if not, the process proceeds to S810.

In S803, the developer terminal 100 accepts the action input operation by the action description operation and displays the input characters on the action board 910.

In S804, the developer terminal 100 determines whether the character string consisting of the characters entered in S803 and the characters entered up to that point matches (i.e., partially matches) the function name of the created function. If there is a prefix match, proceed to S805; if not, proceed to S808.

In S805, the developer terminal 100 displays the function names of the created functions determined to be a match in S804 as options in the code assist field. This causes the code assist field 911 to be displayed as described in FIG. 10(b). Note that the code assist field 911 may display not only created functions, but also function names that are generally available in programming languages and that prefix-match the input string.

In S806, the developer terminal 100 determines whether any of the options displayed in the code assist field has been selected. If any of the options has been selected, the process proceeds to S807, where the function name of the selected option is displayed in the code assist field 911. For example, in response to the selection of an option in the code assist field 911 from the state shown in FIG. 10(b), "sql01" is entered and displayed, as shown on the fifth line of the action board 910. If none of the options has been selected, the process proceeds to S808.

In S808, the developer terminal 100 determines whether the operation to describe the action is being performed continuously. If the operation to describe the action is being performed continuously, the process proceeds to S803; if not, the process proceeds to S802.

In S810, the developer terminal 100 determines whether an operation has been performed to instruct adding a function. Specifically, it determines whether the Add Function button 921 has been pressed. If the Add Function button 921 has been pressed, the process proceeds to S811; if not, the process proceeds to S820.

In S811, the developer terminal 100 displays the addition dialog 930 for adding a creation function and accepts input into the addition dialog 930. The content of the input accepted in the addition dialog is as described above with reference to FIG. 9(c). Once input into the addition dialog has been made and the SAVE button 933 has been pressed, the process proceeds to S812.

In S812, the developer terminal 100 displays the function name entered in the function name input field 932 of the addition dialog in the function list 920 in the submenu area, with an incomplete mark 929 added.

In S813, the developer terminal 100 determines whether the type selected in the type selection field 931 of the addition dialog is script. If it is script, the process proceeds to S814; if not, the process proceeds to S815. In S814, the developer terminal 100 displays a script function settings screen (not shown) and accepts setting operations from the developer user.

In S815, the developer terminal 100 determines whether the type selected in the type selection field 931 of the addition dialog is SQL. If it is SQL, the process proceeds to S816; if not (i.e., if the type selected in the type selection field 931 of the addition dialog is REST), the process proceeds to S817. In S816, the developer terminal 100 displays an SQL function setting screen and accepts setting operations from the developer user. The setting contents accepted on the SQL function setting screen are as described above using Figure 10(a).

In S817, the developer terminal 100 displays the REST function setting screen and accepts setting operations from the developer user. The setting contents accepted on the REST function setting screen are as described above with reference to Figure 9 (d).

In S818, the developer terminal 100 determines whether input into the setting items predetermined as required items has been completed (whether the settings have been completed) on the function setting screen for each type. If input into the required items has been completed, the process proceeds to S819; if not, the process proceeds to S802.

In S819, the developer terminal 100 hides the incomplete mark that was displayed in association with the function name displayed in the function list 920 for the creative function being set. This allows the user (developer) to recognize that the creative function being set is in a valid setting that can be used on the action board 910.

In S820, the developer terminal 100 determines whether any of the creation functions displayed in the function list 920 has been selected (pressed). If a creation function has been selected in the function list 920, the process proceeds to S813, and in S814, S816, or S817, a settings screen corresponding to the type of creation function selected is displayed, reflecting the settings that have already been configured. The user (developer) can change the settings on the settings screen or add settings (i.e., edit the creation function).

In S821, the developer terminal 100 determines whether a save instruction operation (e.g., pressing the Save button 915) has been performed. If a save instruction operation has been performed, the process proceeds to S822; if not, the process proceeds to S823.

In S822, the developer terminal 100 records the details of the action board processing performed up to this point in the definition information stored in memory 102 and transmits it to the development environment 300.

In S823, the developer terminal 100 determines whether option 922, which is displayed in the function list 920 and instructs the display of the action board 910, has been pressed. If option 922 has been pressed, the process proceeds to S801, and the action board of the specified UI component is displayed. As a result, if the function settings screen was displayed, it switches to displaying the action board. If option 922 has not been pressed, the process proceeds to S824.

In S824, the developer terminal 100 determines whether an operation to close the action board (an operation to end action board processing) has been performed. If an operation to close the action board has not been performed, the process proceeds to S802 and the process is repeated. If an operation to close the action board has been performed, the action board is hidden, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor processing.

<Screen switching process>
A flowchart of the screen switching process is shown in Fig. 12. This process corresponds to the selection of an option displayed in the main menu area 510 described above in the display example of Fig. 5(b).

In S1201, the developer terminal 100 determines whether the App List button 511 has been pressed. If the App List button 511 has been pressed, the process proceeds to S315 in Figure 3; if not, the process proceeds to S1202.

In S1202, the developer terminal 100 determines whether the UI screen button 512 has been pressed. If the UI screen button 512 has been pressed, the process proceeds to S1203; if not, the process proceeds to S1204. In S1203, the UI editor process of Figure 4 is performed.

In S1204, the developer terminal 100 determines whether the workflow button 513 has been pressed. If it determines that the workflow button 513 has been pressed, the process proceeds to S1205; if not, the process proceeds to S1206.

In S1205, the developer terminal 100 performs workflow creation processing. The workflow creation processing will be described later using Figure 16.

In S1206, the developer terminal 100 determines whether the Settings button 514 has been pressed. If the Settings button 514 has been pressed, the process proceeds to S1207; if not, the process proceeds to S1209.

In S1207, the developer terminal 100 displays an app settings screen. The app settings screen is a screen that accepts setting operations related to the selected app. In S1208, the developer terminal 100 accepts setting operations on the app settings screen and updates the definition information recorded in memory 102 based on the settings. Settings that can be accepted in S1208 include, for example, a display language setting and a setting for whether to build an app that can be used as a PWA (Progressive Web App). There is also a setting for which UI screen, out of multiple UI screens belonging to the app, is to be designated as the initial UI. The initial UI is the screen that is displayed first when accessing a built app deployed in the execution environment, or the screen that is displayed first after authentication is successful on the app authentication screen after accessing the built app.

In S1209, the developer terminal 100 determines whether the Environment List button 515 has been pressed. If the Environment List button 515 has been pressed, the process proceeds to S311 in Figure 3; if not, the process proceeds to S1210.

In S1210, the developer terminal 100 determines whether the database button 516 has been pressed. If the database button 516 has been pressed, the process proceeds to S1211; if not, the process proceeds to S1215. Pressing the database button 516 is a request to connect to the database.

In S1211, the developer terminal 100 determines whether the selected execution environment is a multi-tenant execution environment 410. If it is a multi-tenant execution environment 410, the process proceeds to S1213; if it is not (if it is a single-tenant execution environment), the process proceeds to S1212.

In S1212, the developer terminal 100 acquires database information acquired by the development environment 300 from the selected execution environment. More specifically, the development environment 300 determines whether the selected execution environment is a multi-tenant execution environment or a single-tenant execution environment, and if it is a single-tenant execution environment, the development environment 300 accesses the DB set (any of DB sets 457, 467, 477, etc.) of the single-tenant execution environment, which is the selected execution environment, and acquires the contents recorded in the database. The development environment 300 then transmits the database information acquired from the selected execution environment to the developer terminal 100. The developer terminal 100 will never access the single-tenant execution environment without going through the development environment 300.

In S1213, the developer terminal 100 references the DB instance name recorded in the developer information of the logged-in developer (the information registered for the logged-in developer in the developer information 301). Then, from among the DB sets 430 included in the multi-tenant execution environment 410, which is the currently selected execution environment for the development environment 300, the developer terminal 100 obtains the contents recorded in the database of the DB instance indicated by the DB instance name obtained by reference to the developer information of the logged-in developer. Then, the development environment 300 transmits the database information obtained from the currently selected execution environment to the developer terminal 100. The developer terminal 100 will not access the multi-tenant execution environment 410 without going through the development environment 300.

In S1214, the developer terminal 100 displays the database management screen and displays the database information obtained in S1212 or S1213. It then accepts DB management operations to specify various settings for the database of the selected execution environment and to instruct content updates.

In S1215, the developer terminal 100 determines whether the file manager button 517 has been pressed. If the file manager button 517 has been pressed, the process proceeds to S1216; if not, the process proceeds to S1218.

At S1216, the developer terminal 100 displays a file management screen for managing files to be saved in the selected execution environment, and at S1217, accepts operations for managing files to be saved in the selected execution environment. For example, an image file to be displayed on the screen of an application being constructed can be uploaded and saved in the developer area of the selected execution environment. When a file to be saved in the selected execution environment is selected from the local storage area (such as the recording medium 108) of the developer terminal 100 and a save instruction is given, the developer terminal 100 sends the selected file to the development environment 300. When the development environment 300 receives the selected file, it sends it to the developer area of the selected execution environment, thereby saving it in the selected execution environment. The various execution environments only accept access from the development environment 300. Therefore, for file management, the developer terminal 100 accesses the various execution environments via the development environment 300. The developer terminal 100 never accesses the multi-tenant execution environment 410 without going through the development environment 300. As explained in the login process above, developers must authenticate themselves before logging in to the development environment 300. Therefore, by restricting access to various execution environments to via the development environment 300, other users who cannot log in to the development environment 300 cannot access the execution environment illegally, thereby improving security.

In addition, the developer user only needs to perform the authentication operations required to log in to the development environment 300, and does not need to perform the authentication operations required to log in to each execution environment. This prevents an increase in the number of operations required.

In S1218, the developer terminal 100 determines whether the User Management button 518 has been pressed. If it determines that the User Management button 518 has been pressed, the process proceeds to S1219; if not, the process proceeds to S1220.

At S1219, the developer terminal 100 performs user information display processing. The user information display processing displays user information (such as user information 411, 451, 461, 471 for each execution environment shown in FIG. 1) that is information about app users (information managed separately from the developer) who can log in to the application built in the selected execution environment, and accepts management operations from the developer. The user information display processing will be described later using FIG. 14.

In S1220, the developer terminal 100 determines whether the snapshot button 519 has been pressed. If the snapshot button 519 has been pressed, the process proceeds to S1221 to perform snap processing; if not, the process proceeds to S1222.

In S1222, the developer terminal 100 determines whether an end operation has been performed. If an end operation has not been performed, the process proceeds to S1201 and the process is repeated; if an end operation has been performed, the screen switching process ends.

<User information display process>
FIG. 14( a) shows a specific example of developer information 301 held in the development environment 300. In the developer information 301, the following information is recorded in association with each developer as account information for each developer, as shown in each row in the figure: an email address (username) that serves as the developer's account ID (developer ID), a password, a last name, a given name, an accessible execution environment ID, Verify, and an accessible DB instance name in the multi-tenant execution environment. In this embodiment, the accessible execution environment ID is assumed to be the account ID of the cloud service. If one developer can access multiple execution environments, the accessible execution environment ID is recorded as a string in which multiple execution environment IDs are listed consecutively, separated by commas. Verify is information indicating whether the account is valid. Note that information recorded in association with one account may be information other than that shown in FIG. 14( a).

Figure 14(b) shows a specific example of user information 411 stored in the multi-tenant execution environment 410. In the user information 411, the following information is recorded in association with each app user as account information for each app user, as shown in each row in the figure. The account information for each app user includes an email address (user name) that serves as the app user's account ID, a password, a last name, a first name, information on whether the email has been approved, and an owner ID. In a multi-tenant execution environment, multiple applications owned by multiple developers are deployed together. Therefore, to identify which developer (owner) created the app for each app user, a developer ID is also recorded as the owner ID. Note that information recorded in association with a single account may be information other than that shown in Figure 14(b). For example, the creation date and time, update date and time, etc. may also be recorded.

Figure 14(c) shows a specific example of user information (user information 451, 461, 471, etc.) stored in a single-tenant execution environment. Two types of user information are recorded in the single-tenant execution environment: user-specific information shown in Figure 14(c1) and group information shown in Figure 14(c2).

In the user-specific information shown in Figure 14 (c1), the following information is recorded in association with each app user as account information for each app user, as shown in each row. The account information for each app user includes the email address (user name) that serves as the app user's account ID, password, last name, first name, and information on whether the email has been approved. On the other hand, in a single-tenant execution environment, multiple applications owned by multiple developers do not coexist, so the owner ID is not recorded. Note that information recorded in association with a single account may be other than the information shown in Figure 14 (c1). For example, the creation date and time, update date and time, etc. may also be recorded.

The group information shown in Figure 14 (c2) records multiple group IDs in association with the usernames of one or more users who belong to each group, as shown in each row.

Figure 13(a) shows a flowchart of the user information display process on the developer terminal 100. This process is a detailed flowchart of S1218 in Figure 12 mentioned above.

At S130, the developer terminal 100 sends a user information acquisition instruction for the development environment 300 (information instructing the acquisition of user information for the selected execution environment).

In S1302, the developer terminal 100 determines whether it has received user information sent from the development environment 300 in response to the user information acquisition instruction sent in S1301. If user information has not been received, it waits for reception of user information in S1302, and if user information has been received, it proceeds to S1303. The acquired user information is information such as that shown in FIG. 14(b) if the selected execution environment is a multi-tenant execution environment, and information such as that shown in FIG. 14(c1) or FIG. 14(c2) if the selected execution environment is a single-tenant execution environment.

In S1303, the developer terminal 100 displays user information on the display 105 based on the user information received in S1302. Figure 15 shows an example of the user information displayed on the developer terminal 100 in S1303. In Figure 15, display items that are the same as those in the display example of Figure 5(b) described above are given the same symbols and will not be described again. Display item 1501 is an instruction item for instructing a display based on the user-specific information shown in Figure 14(c1). Display item 1502 is an instruction item for instructing a display based on the group information shown in Figure 14(c2). Either display item 1501 or 1502 can be selected by switching between them. Furthermore, if the selected execution environment is a multi-tenant execution environment, display items 1501 and 1502 are not displayed and it is not possible to switch to displaying group information. Group information 1505 is an example of user information displayed based on the user information received in S1302 (in the illustrated example, the per-user information shown in FIG. 14(c1)). In group information 1505, the Username and Email Verified columns correspond to the information in the email address (username) and email verification columns in the per-user information shown in FIG. 14(c1), respectively. In the Delete column, a button icon is displayed in each row to accept an instruction to delete the user account of that row. Add user button 1503 is an operation icon for adding a row to group information 1505 and registering information for a new application user. Save button 1504 is an operation icon for issuing an instruction to save group information 1505, the content of which was edited on the screen of FIG. 15, in the selected execution environment.

In S1304, the developer terminal 100 accepts editing operations for the user information displayed in S1303. For example, adding a user account by pressing the Add User button 1503, deleting a user account by pressing the button icon displayed in the Delete column, or editing the content of editable items by operating the keyboard.

In S1305, the developer terminal 100 determines whether the Save button 1504 has been pressed. If the Save button 1504 has been pressed, the process proceeds to S1306; if not, the process proceeds to S1307.

In S1306, the developer terminal 100 sends an instruction to the development environment 300 to update the user information to reflect the editing operation received in S1304.

In S1307, the developer terminal 100 determines whether an execution environment change operation has been performed. If an execution environment change operation has been performed (if an operation has been performed on the selected execution environment box 501), the process proceeds to S1308; if not, the process proceeds to S1309.

In S1308, the developer terminal 100 records the changed selected execution environment in memory 102 and transmits it to the development environment 300. When the selected execution environment changes, the user information to be displayed for editing also changes, so the process returns to S1301 and repeats the process.

In S1309, the developer terminal 100 determines whether a screen switching operation has been performed, which is an operation to select one of the options displayed in the main menu area 510. If a screen switching operation has not been performed, the process returns to S1304; if a screen switching operation has been performed, the user information display process ends and the process proceeds to the screen switching process described above.

Figure 13(b) shows a flowchart of the user information acquisition process in the development environment 300, which is a process in response to the user information display process in Figure 13(a).

In S1311, the development environment 300 determines whether or not it has received the user information acquisition instruction sent from the developer terminal 100 in S1301. If it has received the user information acquisition instruction, it proceeds to S1312; if not, it proceeds to S1316.

In S1312, the development environment 300 obtains access destination information (connection destination information) from the selected execution environment. If the selected execution environment is the multi-tenant execution environment 410 of FIG. 1, the obtained access destination information is access destination information 421. If the selected execution environment is the single-tenant execution environment of FIG. 1, the obtained access destination information is the access destination information for the selected execution environment from among access destination information 456b, 466b, 476b, etc. More specifically, the development environment 300 obtains the execution environment ID of the selected execution environment (specific environment) from the account information of the logged-in developer in the developer information 301 and stores it in memory 304. Within the selected execution environment, the development environment 300 accesses a file recorded in a specific path (a path that is determined once the execution environment ID is known) and obtains the URL of the access destination stored in that file as access destination information. The specific path consists, for example, of the name of a specific area (folder, bucket, directory) and a specific file name. The name of the specific area is, for example, a "fixed string + execution environment ID." The specified file name is, for example, a predetermined common file name common to all execution environments. In this case, the specified path is "fixed character string + execution environment ID/common file name.json." In other words, once the execution environment ID is known, a specified file (access destination information file) in a specified area that is determined is obtained, and the access destination information is obtained from that file and recorded in memory 304. The URL of the access destination information indicates an address within the execution environment and is the URL to which a request for retrieval or updating of user information stored in the execution environment is made. Unless a request is made to this URL, user information stored in the execution environment cannot be retrieved or updated. Thus, without knowing the execution environment ID, access destination information for retrieving or updating user information cannot be obtained. The execution environment ID is information that can only be obtained by a developer logging in to the development environment 300 after performing authentication processing. Furthermore, a developer who can log in to the development environment 300 can only retrieve the execution environment ID that they can access. This prevents people who cannot log in to the development environment 300, or people who can log in to the development environment 300 but have a different accessible execution environment, from illegally accessing the execution environment and leaking user information. In other words, security is improved.

In S1313, the development environment 300 sends a user information acquisition request (a request to execute a process to send user information to the development environment 300) and developer information to the access destination indicated in the access destination information acquired in S1312 (transmission control). The developer information to be sent to the access destination is obtained by acquiring encrypted account information of the currently logged-in developer from the developer information 301. The acquired account information is one row's worth of information for the currently logged-in developer in the developer information 301 table shown in Figure 14 (a). In other words, it includes information about the email address, password, last name, first name, and accessible execution environment ID. This information is encrypted and converted into a single data string, and the acquired information is used. Even if only this encrypted information is leaked, the email address, password, last name, first name, and accessible execution environment ID will not be leaked because it is encrypted.

In S1314, the development environment 300 determines whether or not it has received user information from the selected execution environment in response to the user information acquisition request sent in S1313. This user information is sent from the execution environment in S1325 or S1326, described below. If user information has been received, it proceeds to S1315; if not, it waits for the reception of user information in S1314.

In S1315, the development environment 300 sends the user information received in S1314 to the developer terminal 100. The user information sent here is received in S1302 as described above.

In S1316, the development environment 300 determines whether a user information update instruction has been received from the developer terminal 100. The user information update instruction received here is the one sent from the developer terminal 100 in S1306 described above. If a user information update instruction has been received, the process proceeds to S1317; if not, the process proceeds to S1318.

In S1317, the development environment 300 sends a user information update request (a request to execute the user information update process) and developer information to the access destination indicated in the access destination information acquired in S1312. The developer information sent to the access destination is the same as that described in S1313, and is the encrypted account information of the currently logged-in developer acquired from the developer information 301.

In S1318, the development environment 300 determines whether or not it has received an instruction to change the selected execution environment from the developer terminal 100. This change instruction is sent from the developer terminal 100 in S1308, as described above. If an instruction to change the selected execution environment has been received, it proceeds to S1319; if not, it proceeds to S1311 and repeats the process.

In S1319, the development environment 300 stores the execution environment ID of the changed selected execution environment in memory 304 as the changed selected execution environment.

Figure 13(c) shows a flowchart of user information management processing in the selected execution environment of execution environment 400, which is processing in response to the user information acquisition processing of Figure 13(b). Hereinafter, the operator of this processing will be simply referred to as execution environment 400, but in reality, it is executed by the execution engine in the selected execution environment of execution environment 400. That is, for example, if the selected execution environment is multi-tenant execution environment 410, the operator is execution engine 412, and the processor 413 included in execution engine 412 executes a program using memory 414 as work memory. Also, for example, if the selected execution environment is single-tenant execution environment 450, the operator is execution engine 452, and the processor 453 included in execution engine 452 executes a program using memory 454 as work memory.

In S1321, the execution environment 400 determines whether or not it has received a user information acquisition request sent from the development environment 300. The user information acquisition request received here is the one sent from the development environment 300 in S1313 described above. If a user information acquisition request has been received, it proceeds to S1322; if not, it proceeds to S1327.

At S1322, the execution environment 400 performs access right verification processing. This processing is performed to determine whether the sender of the user information acquisition request is a developer with legitimate access rights. This processing reduces the possibility of user information being leaked to anyone other than the developer with legitimate access rights, thereby improving security. The access right verification processing will be described later using Figure 13(d).

In S1323, the execution environment 400 determines whether the result of the access right confirmation process is an error. If there is an error, the execution environment 400 proceeds to S1321 without sending the user information held in its own environment to the source of the user information acquisition request. If there is no error, the execution environment 400 proceeds to S1324.

In S1324, the execution environment 400 determines whether it is a multi-tenant execution environment 410. If it is a multi-tenant execution environment 410, proceed to S1326; if it is a single-tenant execution environment, proceed to S1325.

At S1325, the execution environment 400 sends the user information held in its own execution environment to the development environment 300. In a single-tenant execution environment, the environment itself is owned by a single developer, and therefore the user information only relates to applications owned by that single developer. Therefore, unlike the processing in a multi-tenant execution environment at S1326 described below, the entire user information is sent, rather than just the portion of the user information owned by the logged-in developer. For example, if the selected execution environment is a single-tenant execution environment 450, user information 451 is sent to the development environment 300. The user information sent here is received by the development environment 300 at S1314 and sent to the developer terminal 100 at S1315.

At S1326, the execution environment 400 transmits to the development environment 300 the portion of the user information held in its own execution environment whose owner ID matches the received developer information. The encrypted developer information is transmitted from the development environment 300, received at S1341 (described below), decoded (decrypted) at S1343, and stored in memory 414. This is the received developer information. Of the user information 411 in the multi-tenant execution environment 410 shown in FIG. 14(b), information for rows that have the same owner ID as the developer ID (email address) included in the received developer information is obtained and transmitted to the development environment 300. Of the user information 411 in the multi-tenant execution environment 410, information for rows that do not have the same owner ID as the developer ID (email address) included in the received developer information is not transmitted to the development environment 300. In a multi-tenant execution environment, user information owned by multiple developers is recorded mixed together, so the portion of the user information owned by the logged-in developer is transmitted. The user information sent here is received by the development environment 300 in S1314 and sent to the developer terminal 100 in S1315.

In S1327, the execution environment 400 determines whether a user information update request has been received. The user information update request received here is the one sent from the development environment 300 in S1317 described above. If a user information update request has been received, the process proceeds to S1328; if not, the process proceeds to S1321.

At S1328, the execution environment 400 performs access right verification processing. This processing is performed to determine whether the sender of the user information update request is a developer with legitimate access rights. This processing reduces the possibility of user information being rewritten (updated) by a request from someone other than a developer with legitimate access rights, thereby improving security. The access right verification processing will be described later using Figure 13(d).

In S1329, the execution environment 400 determines whether the result of the access right confirmation process is an error. If there is an error, the execution environment 400 proceeds to S1321 without updating in accordance with the user information update request. If there is no error, the execution environment 400 proceeds to S1330.

At S1330, the execution environment 400 updates the user information stored in its own environment in accordance with the user information update request. At this time, if a new user is registered, in the case of a multi-tenant execution environment, the developer ID of the logged-in developer is registered as the owner ID in association with the account information of the new user.

Figure 13(d) shows a flowchart of the access right confirmation process. This process is a detailed flowchart of steps S1322 and S1328 in Figure 13(c) described above.

In S1341, the execution environment 400 determines whether encrypted developer information has been received from the development environment 300. The developer information received here is the developer information sent from the development environment 300 in S1313 or S1317 described above. If encrypted developer information has been received, the process proceeds to S1343; if not, the process proceeds to S1342.

In S1342, the execution environment 400 records (outputs) the fact that an error occurred as a result of the access right verification process. In this case, an error is determined in S1323 or S1329 described above. In this way, even if a user information acquisition request or user information update request is received, if encrypted developer information is not received, an error is treated as an error and request control is performed such that processing in response to the request is not performed (the request is not permitted). This makes it possible to suppress processing in response to unauthorized access.

In S1343, the execution environment 400 decodes (decrypts, decrypts) the developer information received in S1341 using a decryption key stored in advance. The decrypted developer information is not sent outside the execution environment, so there is little chance of it being leaked.

In S1344, the execution environment 400 determines whether the execution environment ID of its own execution environment (the execution environment in question) is included in the portion of the developer information decoded in S1342 that indicates accessible execution environments. If it is included, the processing is terminated (in this case, the access is deemed legitimate); if it is not included, the processing proceeds to S1342, where an error is recorded (output) as a result of the access rights confirmation processing. This prevents processing in response to a user information acquisition request or user information update request from a developer who does not have access rights to the execution environment in question. Therefore, processing in response to unauthorized access can be suppressed.

The execution environment 400 does not accept access from any source other than the development environment 300, and is controlled so that even if a user information acquisition request or user information update request is received from a source other than the development environment 300, no processing is performed in response to the request. This prevents processing even if a forged developer information and user information acquisition request or user information update request are sent and encrypted by a device other than the development environment 300. This improves security.

The user information display process described above can prevent unauthorized processing due to unauthorized access to the execution environment 400, reduce the risk of information leaks, and improve security. Note that while the above-described user information display process describes processing related to user information stored in the execution environment, it can also be applied to other processing related to the execution environment other than processing related to user information. For example, similar processing can be applied to processing related to databases and files stored in the execution environment 400 to improve security.

For example, this can be applied to the processing related to displaying and updating a database described in S1210 to S1214 of Figure 12. In this case, in response to a DB operation instruction from the developer terminal 100, the development environment 300 obtains an access destination information file from the selected execution environment, as in S1312. The access destination information file records a DB operation request reception URL, which is the request destination for receiving DB operation requests, and the execution environment 400 sends the DB operation request and developer information to this URL, as in S1313. The execution environment 400 performs processing to determine whether the sender of the DB operation request is legitimate, as in the processing described in Figures 13(c) and 13(d), and only if the sender is legitimate performs processing related to the DB set held in its own execution environment in response to the DB operation request.

The present invention can also be applied to the file management processing described in S1215 to S1217 of Figure 12, for example. In this case, in response to a file management instruction from the developer terminal 100, the development environment 300 obtains an access destination information file from the selected execution environment, as in S1312. The access destination information file records a file management request reception URL, which is the request destination for receiving file management requests, and the execution environment 400 sends the file management request and developer information to that URL, as in S1313. The execution environment 400 performs processing to determine whether the sender of the file management request is legitimate, as in the processing described in Figures 13(c) and 13(d), and only if the sender is legitimate performs processing related to the files stored in its own execution environment in response to the file management request.

<Workflow processing>
16 shows a flowchart of the workflow process. This process is a detailed flowchart of S1205 in FIG. 12. This process is executed by the developer terminal 100.

In S1601, the developer terminal 100 displays a workflow (WF) creation screen on the display 105. FIG. 17(a) shows an example of the WF creation screen. A node list 1710 is displayed in the submenu area 510. The node list 1710 includes node options: Start 1711, which is the starting point; End 1712, which is the end point; and Status 1713, which is the intermediate point. In the area where the canvas 530 was displayed, a WF placement area 1700 is displayed in place of the canvas 530. The WF placement area 1700 is a blank area before placement. Any of the multiple options (node options) displayed in the node list 1710 can be selected and placed in the WF placement area 1700. In this embodiment, placement is performed by drag-and-drop. That is, any of the multiple options displayed in the node list 1710 can be dragged and dropped into the WF placement area 1700 to place it.

In S1602, the developer terminal 100 determines whether an operation to place a node has been performed. Specifically, it determines whether an operation to place a node has been performed by dragging one of the options displayed in the node list 1710 and dropping it into the WF placement area 1700. If an operation to place a node has been performed, the process proceeds to S1603; if not, the process proceeds to S1604.

In S1603, the developer terminal 100 places the selected node in the WF placement area 1700 in response to the node placement operation.

In S1604, the developer terminal 100 determines whether an operation to draw an arrow has been performed. An arrow connects two placed nodes and indicates the processing content when transitioning from the node at the origin of the arrow to the node beyond. When a placed node is selected, an operation path is displayed for the selected node. An arrow can be drawn by starting a drag with the mouse cursor on that operation path (i.e., pressing the left mouse button and starting to move the mouse) and dropping it on another node (i.e., releasing the left mouse button). The node from which the drag was started becomes the origin of the arrow, and the node where it was dropped becomes the tip of the arrow. If an operation to draw an arrow has been performed, proceed to S1605; if not, proceed to S1606.

In S1605, the developer terminal 100 draws an arrow object between two nodes already placed in the WF placement area 1700 in response to the operation to draw an arrow.

Figure 17 (b) shows an example of the display after nodes and arrows have been placed in the WF placement area 1700. Nodes 1701 to 1705 are placed in the WF placement area 1700. Node 1701 is the starting node. Nodes 1702, 1703, and 1704 are intermediate (status) nodes. Node 1705 is the end node. Arrow 1706 is the arrow from node 1701 to node 1702. Arrow 1707 is the arrow from node 1702 to node 1703. Arrow 1708 is the arrow from node 1703 to node 1704. Arrow 1709 is the arrow from node 1704 to node 1705. Each node represents one procedure (step) in a workflow that includes multiple procedures (steps), and the arrows indicate the order of the procedures. In other words, in the example shown, nodes 1701 to 1705 represent the first to fifth steps, respectively.

In S1606, the developer terminal 100 determines whether an operation to set node properties has been performed. Specifically, it determines whether an operation to select a node already placed in the WF placement area 1700 and right-click has been performed. If an operation to set node properties has been performed, the process proceeds to S1607; if not, the process proceeds to S1608.

In S1607, the developer terminal 100 displays a property box for setting properties for the node and accepts operations to set the node properties. Figure 17(c) shows an example of the display of a node property box. The node property box accepts settings for the node ID (an initial value that does not overlap with other nodes is set and can be changed), label (the name to be displayed), and the ID of the UI screen on which the generated workflow will be placed. To set the UI screen ID, a list of UI screen IDs is displayed as a choice, and the user can select and set it from that choice.

In S1608, the developer terminal 100 determines whether an operation to set the properties of the arrow has been performed. Specifically, it determines whether an operation to select an arrow already drawn in the WF placement area 1700 and right-click has been performed. If an operation to set the properties of the arrow has been performed, the process proceeds to S1609; if not, the process proceeds to S1610.

In S1609, a property box for setting properties for the arrow is displayed, and settings for the operation property, which is a property of the arrow, are accepted. Figure 17(e) shows an example of the display of an arrow property box. The arrow property box accepts the arrow's ID (a default value that does not overlap with other arrows is set and can be changed), label (the name to be displayed), type, and user settings. The type can be set by selecting one of the options corresponding to approval (Update), application (Create), or return (Remand). The user can set it by selecting one of the options corresponding to SelectUser and CurrentUser. The type indicates the type of action to be taken when transitioning from the original procedure of the arrow to the subsequent procedure. Based on this type, the action of the automatically placed UI component, described below, is automatically set.

In S1610, the developer terminal 100 determines whether the Create Workflow button 1730 has been pressed. If the Create Workflow button 1730 has been pressed, the process proceeds to S1611; if not, the process proceeds to S1615.

In S1611, the developer terminal 100 displays the selection acceptance form (dialog box) shown in FIG. 17(e) as a wizard and accepts the selection of the status to be created. At least one of Start, Applying, Approved, and Not Applied can be selected as the status to be created.

In S1612, the developer terminal 100 displays the selection acceptance form (dialog box) shown in FIG. 17(f) as a wizard and accepts the selection of whether to create an additional task table. Here, it is possible to select whether to generate a task table and the ID of the UI screen to be added. When selecting the UI screen ID, a list of UI screen IDs is displayed as a choice, and the user can select from that choice.

In S1613, the developer terminal 100 displays the specification acceptance form (dialog box) shown in FIG. 17(g) as a wizard and accepts the specification (selection) of a database. The database can be specified by selecting it from the displayed options.

In S1614, the developer terminal 100 creates a workflow definition based on the nodes and arrows already placed in the WF placement area 1700, their respective properties, and the settings made by selecting from the options in S1611 to S1614, and records the definition information in memory 102. This automatically places UI parts (UI components) based on the workflow on the UI screen. Actions corresponding to the workflow are automatically set for these automatically placed UI parts. In this way, UI parts with automatically defined actions are generated based on the workflow created by the developer user's operation of selecting options, without the developer user having to write them in a programming language. Additionally, tables used in the workflow are created in the database specified in the specification acceptance form shown in FIG. 17(g). Actions are also set (defined) on the canvas of the UI screen according to the settings. The actions set on the canvas are the processing performed when the UI screen is loaded in the constructed application. In other words, they are the processing performed as the initial operation when the screen is displayed.

In S1615, the developer terminal 100 determines whether a screen switching operation has occurred. More specifically, it determines whether any of the options included in the main menu area 510 has been selected. If any of the options included in the main menu area 510 has been selected, the processing of FIG. 16 ends, and the processing proceeds to the screen switching processing described above in FIG. 12. If not, the processing proceeds to S1602.

Figure 18(a) shows an example of the display when the database tables added in S1614 of Figure 16 are displayed by pressing the database button 516 in the main menu area. That is, Figure 18(a) is one of the database-related screens displayed in S1214 of Figure 12. Of the table list displayed in the submenu area, tables 1801 and 1802 are tables that were automatically added in response to the creation of the workflow. They have been added (created) as tables included (subordinate, lower-level) in the database whose designation was accepted in S1613.

Figure 18 (b) shows an example of a canvas display of a UI screen on which UI components were automatically placed in S1614 of Figure 16. UI components 1811-1813 placed on canvas 530 are UI components that were automatically placed in response to the generation of the workflow. In other words, UI components 1811-1813 were not placed by the developer using drag-and-drop from the UI component list in the submenu area. An action has been automatically set (defined) in UI component 1813. UI component 1813 is an automatically generated component for which an action to be taken when transitioning to the next step in the workflow is defined. Furthermore, the UI screen on which UI component 1813 is placed is the source screen for transitioning to the next step in the workflow by executing the action automatically defined in UI component 1813.

Figure 18(c) shows an example of an action board displayed when a button UI component 1813 is set as the specified UI component. That is, this action board is displayed in step S801 described above in Figure 8 when the specified UI component is UI component 1813. The action board 910 displays the action string, as shown in Figure 18(c), written in a programming language as the default, even when the developer has not yet written the action in a programming language. In other words, the action board 910 displays the source code in a programming language that defines the action, as shown in Figure 18(c), as the default, even when the developer has not yet written the source code for the action in a programming language. The action displayed in the action board 910 in Figure 18(c) defines at least a database (line 3) and the UI screen to be displayed next (line 6), based on the operations received from the user during the workflow creation process in Figure 16. The user can edit these automatically defined actions using the processes in steps S802 to S808 described above. In other words, you can use the string of an automatically defined action as a base, partially reuse it, and enter programming language to modify or add text. In other words, you can accept modifications to the string of an automatically defined action. In this way, by using the programming language of an automatically generated and displayed action as a base, you can easily set up an action with fewer steps (amount of text input) than if a developer were to write the action in a programming language from scratch. Furthermore, because you can customize an automatically generated action by making modifications rather than using it as is, you can create actions that meet more specific requests.

Figure 18(d) shows an example of a display when an action board is displayed on a canvas of a UI screen where actions have been automatically set in response to the creation of a workflow. This action board is displayed when a blank area on the canvas is designated and a context menu is executed to display the action board. It is displayed in S1903 of Figure 19, which will be described later. The action board displays the action string, as shown in Figure 18(d), written in a programming language as the default, even when the developer has not yet written the action in a programming language. In other words, the action board displays the source code in the programming language that defines the action, as shown in Figure 18(d), as the default, even when the developer has not yet written the source code for the action in a programming language. The user can edit these automatically defined actions using the processing in S1904, which will be described later. In other words, similar to the actions automatically set in UI components described in Figure 18(c), actions can be easily set with minimal operation (text input), and actions that meet more specific user needs can be generated.

For example, the following customizations can be added to the UI components and actions that are automatically generated in response to the generation of the workflow described above.
- Set an action on the canvas action board to display the name of the current procedure (step) in the workflow.
- Place an input field (UI part) for the reason for application, and modify the action board of UI part 1813 so that the data entered there is sent to the next step.
Modify the action board of the part 1813 so that data is saved in a different table. For example, customize it so that the reason for application and case ID are also recorded in a different database.
On the campus action board, set the initial user to be entered in the UI component 1812 (combo box) to the person who applied last time by writing an action using programming limits. Alternatively, write an action to display people who can approve as options.

As such, according to this embodiment, the basic parts of a workflow can be created quickly and easily by following the operations on the workflow creation screen and the input content into the wizard (i.e., based on a group of operations that does not include the operation of writing source code in a programming language, but includes the operation of selecting from options). Furthermore, by presenting automatically created UI components and actions set on the canvas of the UI screen in a way that can be modified in a programming language, a greater degree of design freedom is possible.

<CRUD generation process>
19 shows a flowchart of the canvas context menu process. This process is a detailed flowchart of S703 in FIG. 7 described above. This process is executed by the developer terminal 100. The canvas context menu includes options for generating a CRUD.

In this embodiment, as an example for explaining CRUD generation, we will explain a case where a canvas of a selected UI screen, such as that shown in Figure 20(a), is displayed before CRUD generation (before CRUD buttons are placed), and a blank area of the canvas is right-clicked to display the canvas context menu. CRUD is an abbreviation of the four basic functions required of software: data creation (Create), data read (Read), data update (Update), and data deletion (Delete). The canvas in Figure 20(a) displays UI components 2001-2003 placed by a developer during UI editor processing. All of UI components 2001-2003 are Input-type UI components. UI component 2001 displays "ID" as the label, UI component 2002 displays "Name" as the initial value, and UI component 2003 displays "age" as the label. That is, the canvas in Figure 20(a) is a canvas for a UI screen designed to be used for some kind of user registration. UI part 2001 is an input field for entering the ID of the newly registered user, UI part 2002 is the name of the newly registered user, and UI part 2003 is the age of the newly registered user. The UI part IDs of UI parts 2001 to 2003 are "number_field_ID", "text_field_Name", and "number_field_age", respectively.

In S1901, the developer terminal 100 displays a canvas context menu superimposed near the mouse cursor. Figure 20(b) shows an example of the canvas context menu display. The canvas context menu displays options 2011 to 2015, which are menu items.

In S1902, the developer terminal 100 determines whether the menu item (option 2013) in the canvas context menu that instructs the display of the action board has been pressed. If the menu item (option 2013) instructs the display of the action board has been pressed, the process proceeds to S1903; if not, the process proceeds to S1906.

In S1903, the developer terminal 100 displays the canvas action board based on the definition information stored in memory 102. An example of the canvas action board display is shown in Figure 18(d) above. Figure 18(d) is an example in which an action has been automatically set. If no action has been set, the action board will be displayed blank. If a developer has previously input (set) an action into the action board and the content of that input is recorded in the definition information, a character string in a programming language indicating the set action will be displayed on the action board.

In S1904, the developer terminal 100 accepts input operations, editing operations, and function setting operations in a programming language from the developer user on the action board (edit acceptance). This process is similar to the processes in S802 to S823 in Figure 8 described above, so details will be omitted.

In S1905, the developer terminal 100 determines whether an operation to close the action board (an operation to end action board processing) has been performed. If an operation to close the action board has not been performed, the process proceeds to S1904 and the process is repeated. If an operation to close the action board has been performed, the action board is hidden, the process of Figure 19 is terminated, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor processing.

In S1906, the developer terminal 100 determines whether the menu item (option 2015) instructing the generation of a CRUD has been pressed in the context menu of the canvas. If the menu item (option 2015) instructing the generation of a CRUD has been pressed, proceed to S1907; if not, proceed to S1914.

In S1907, the developer terminal 100 displays CRUD input form 1 (a dialog box) as a wizard and accepts an operation to select a UI component in the CRUD from which data is to be acquired. Figure 20(c) shows an example of the display of CRUD input form 1. Area 2021 displays the UI component IDs of all UI components placed on the selected UI screen as options. The user (developer) selects the option from which data is to be acquired from the options displayed in area 2021 and displays it in the selected area 2022 to make the selection.

In S1908, the developer terminal 100 determines whether a selection operation is performed on input form 1 and whether the NEXT icon 2023 is pressed. If the NEXT icon 2023 is pressed, the process proceeds to S1909; if not, the process waits in S1908 for the NEXT icon 2023 to be pressed.

In S1909, the developer terminal 100 displays CRUD input form 2 (a dialog box) and accepts the selection of columns to be prepared in the database table that will be the target of the CRUD. Figure 20(d) shows an example of the display of CRUD input form 2. Area 2031 displays the UI component IDs of the UI components selected in input form 1 as options. The user (developer) selects the option they want to use as the target column for the CRUD from the options displayed in area 2031 and displays it in the selected area 2032 to make the selection.

In S1910, the developer terminal 100 determines whether a selection operation has been performed on input form 2 and whether the NEXT icon 2033 has been pressed. If the NEXT icon 2033 has been pressed, the process proceeds to S1911; if not, the process waits in S1910 for the NEXT icon 2033 to be pressed.

In S1911, the developer terminal 100 displays CRUD input form 3 (a dialog box) and accepts the selection of the database and table to be used by the CRUD. Figure 20(e) shows an example of the display of CRUD input form 3. Area 2041 is an area for accepting the selection of a database. The database can be selected from the options displayed by pressing the icon on the far right. Area 2042 is an area for accepting the input of the table name.

In S1912, the developer terminal 100 determines whether a selection/input operation has been performed in input form 3 and whether the FINISH icon 2043 has been pressed. If the FINISH icon 2043 has been pressed, the process proceeds to S1913; if not, the process waits in S1912 for the FINISH icon 2043 to be pressed.

In S1913, the developer terminal 100 generates a CRUD button based on the content entered in input forms 1 to 3 (selected content) and automatically places it on the selected UI screen. It also generates a UI screen that becomes the Next UI, which is the screen that is transitioned to and displayed in response to pressing the CRUD button. In other words, a UI screen is automatically generated for the selected app. It also automatically generates a database table for the content entered in input form 3 in the DB set of the selected execution environment.

In S1914, the developer terminal 100 determines whether any of the other menu items (options 2011, 2012, or 2014) in the canvas context menu has been pressed. If any of the other menu items has been pressed, the process proceeds to S1915; otherwise, the process proceeds to S1916.

In S1915, the developer terminal 100 performs other processing according to the pressed menu item.

In S1916, the developer terminal 100 determines whether an operation to close the canvas context menu has been performed (for example, an operation to click outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden in S1917, and the processing in FIG. 19 ends. If no operation to close the context menu has been performed, the processing returns to S1902.

Figure 20(f) shows an example of the display of a CRUD button (automatically generated component) automatically placed by the processing of S1913. Figure 20(f) is an example of the display of a canvas of the same UI screen as Figure 20(a), and the same UI components as Figure 20(a) are assigned the same reference numerals. In Figure 20(f), UI components 2051-2053 have been added to Figure 20(a). These UI components 2051-2053 are CRUD buttons. Actions are automatically set for UI components 2051-2053, which are CRUD buttons. The action of UI component 2051, which is a CRUD button, is to save (update or add) the value entered in the UI component selected in Input Form 1 to the database table set in Input Form 3 in response to pressing UI component 2051, and then transition to the screen Next UI. The action of UI part 2052, which is a CRUD button, is to delete data from the database table set in input form 3 that has the value entered in the UI part selected in input form 1 in response to pressing of UI part 2052, and then transition the screen to Next UI. The action of UI part 2053, which is a CRUD button, is to retrieve data from the database table selected in input form 3 that matches the value entered in the UI part selected in input form 1 in response to pressing of UI part 2052, and transition the screen to Next UI to display the retrieved data.

Figure 20(g) shows an example of a UI screen (UI screen ID is crud-newui-UI01) automatically generated by processing S1913. Figure 20(g) is an example of a canvas display for a UI screen different from that shown in Figure 20(a), in which a data grid 2061, a UI component, is placed. Data grid 2061 has four columns: "ID," "number_field_ID," "text_field_Name," and "number_field_age." Of these, the columns other than ID correspond to the UI components selected in input form 2. In addition, UI component 2062, a button, is automatically placed. Canvas actions are also automatically set on this UI screen (crud-newui-UI01). The automatically set canvas action is an action that controls the display of data from the row targeted by the CRUD in the data grid 2061 when one of the various CRUD buttons on the transition source screen is pressed in the database table set in input form 3. This canvas action can also be customized by the developer (user) based on the automatically set action by the processing in S1904 described above.

The automatically generated data grid 2061 can also be edited in various ways using the grid property box and action board (described below). For example, you can change the grid's decoration or change the label displayed as a column name from "text_field_Name" to "Name." It's also possible to modify the grid so that some columns aren't displayed. After deploying an application and starting operation, you may need to add or remove columns for various reasons (such as changes in regulations or operational methods). For example, you may want to hide the "number_field_age" column in the data grid 2061 in the future. In this case, you can simply delete the column you want to remove from the column properties in the UI editor. This eliminates the need to re-enter and re-generate CRUD input forms 1 to 3. In this way, being able to edit UI components and screens automatically generated based on input into the CRUD input forms (fizzards) allows you to easily and flexibly accommodate future changes to the application's operation with minimal effort.

Figure 21(a) shows an example of a database table automatically added by the processing of S1913. This display example is displayed when the database button 516 in the main menu area is pressed. That is, Figure 21(a) is one of the database-related screens displayed in S1214 of Figure 12. Of the table list (TABLES) included in the database "sample" displayed in the submenu area, table 2101 (CRUD_T01) is a table automatically added in response to the generation of the CRUD. Table 2102 displays the details of table 2101 (CRUD_T01), and it can be seen that in addition to the ID column, there is a column named after the UI component ID of the UI component selected in Input Form 2. For these columns, properties such as data type are also automatically set according to the properties of the UI component selected in Input Form 2.

Figure 21(b) shows an example of a display when an action board for UI component 2051, a CRUD button automatically placed in the processing of S1913 in Figure 19, is displayed. That is, this action board is displayed in S801 described above in Figure 8 when the specified UI component is UI component 2051. The action board 910 displays the action string as shown in Figure 21(b) written in a programming language (JavaScript) as the default, even when the developer has not yet written the action in a programming language. In other words, the action board 910 displays the source code in the programming language that defines the action as shown in Figure 21(b) as the default, even when the developer has not yet written the source code for the action in a programming language. The user can edit such automatically defined actions using the processing of S802 to S808 described above. That is, the user can use the automatically defined action string as a base, partially reuse it, and input programming language to modify or add text. That is, modifications to the automatically defined action string can be accepted. In this way, by using the programming language of the automatically generated and displayed actions as a base, developers can easily set up actions with fewer steps (amount of text input) than if they were to write actions in a programming language from scratch. Furthermore, because automatically generated actions can be modified and customized rather than used as is, it is possible to generate actions that meet more detailed requests.

In addition, in Figure 21 (b), function list 920 in the submenu area displays functions 2121 and 2122 as options for pre-prepared functions. Functions 2121 and 2122 are functions automatically generated in the processing of S1913 in Figure 19.

Figure 21(c) shows an example of the display when function 2121 is selected from function list 920 and the function settings screen is displayed. Function 2121 is an SQL function, and the SQL function settings screen is displayed. Since the SQL function settings screen has the same configuration as that described above in Figure 10(a), in Figure 21(c) the same setting/input fields as in Figure 10(a) are assigned the same symbols and their descriptions are omitted. In setting field 951, "SQL_Save" is automatically set as the function name. In addition, in setting field 953, an SQL statement has been pre-entered. In this SQL statement, the character string "INSERT INTO" indicates that the database processing type is "INSERT" and that this is a process to add a new row to a table. In addition, the character string "sample.CRUD_T01" indicates that the database to be processed is "sample" and the table is "CRUD_T01." This reflects the content entered in Input Form 3. The subsequent strings indicate the column values included in the row to be added, and reflect the content entered in Input Form 1. The content of setting fields 951 and 953 is based on what was automatically generated, and can be edited (corrected, deleted, added to, customized) by the developer using the processes in S813 to S820 in Figure 8 described above.

Figure 21(d) shows an example of the display when function 2122 is selected from function list 920 and the function settings screen is displayed. Function 2122 is an SQL function, and the SQL function settings screen is displayed. Since the SQL function settings screen has the same configuration as that described above in Figure 10(a), in Figure 21(d), the same setting/input fields as in Figure 10(a) are assigned the same symbols and their descriptions are omitted. In setting field 951, "SQL_Update" is automatically set as the function name. In addition, in setting field 953, an SQL statement has been pre-entered. In this SQL statement, the character string "UPDATE" indicates that the database processing type is "UPDATE" and that the processing is to update the values of existing rows in the table. In addition, the character string "sample.CRUD_T01" indicates that the database to be processed is "sample" and the table is "CRUD_T01." This reflects the content entered in Input Form 3. The subsequent string indicates the value of the column to be updated, and reflects the content entered in Input Form 1. The content of setting fields 951 and 953 is based on what was automatically generated, and can be edited (corrected, deleted, added to, customized) by the developer using the processes in S813 to S820 in Figure 8 described above.

The following describes in detail the content of the automatically generated actions shown in the action board 910 in Fig. 21(b). Each line of the JavaScript character string written in the action board 910 in Fig. 21(b) has the following meaning.
Line 1: Defines a set of values containing the values in lines 2 to 5 under the variable name params.
Line 2: Defines the ID number. It will be a serial number.
Lines 3 to 5: Obtain the value entered in the UI component selected in Input Form 1. Note that "$ui.UI component ID.Type of target information" is written to the right of "=" to indicate that a value is to be obtained, but this notation method itself is not a standard JavaScript notation method, but is unique to this system. More details on this will be provided later.
Line 6: Executes the function SQLUpdate using the params defined in lines 2 to 5 as arguments. In other words, it updates the database table set in Input Form 3 with the values entered in the UI components selected in Input Form 1.
Line 7: Obtain the row affected by the update.
Line 8: Determine whether any rows were obtained in line 7. In other words, determine whether any rows were updated.
Line 9: If line 8 is true, display "Successfully Updated."
Line 10: Transition to the UI screen with the UI screen ID "crud-newui-UI01" as NextUI.
Line 12: Determines whether the number of rows retrieved in line 7 is 0. If this is true, it means that there is no existing row corresponding to the params retrieved this time, so a new row will be added and registered.
Line 13: If line 12 is true, execute the function SQLSave with the params defined on lines 2 to 5 as arguments. That is, add a row to the database table set in input form 3 using the values entered in the UI components selected in input form 1 and save the row as a new row.
Line 14: Obtain the lines affected by the new save on line 13 (i.e., the added lines).
Line 15: Determines whether any rows were obtained in line 14. In other words, determines whether the new row was successfully added and registered.
Line 16: If line 15 is true, displays "Successfully Inserted."
Line 17: Transition to the UI screen with the UI screen ID "crud-newui-UI01" as NextUI.
Lines 19 and 20: If lines 8 and 12 are both false, display "Insertion Failed."

The content that is automatically generated in this way and presented on the action board in a programming language so that the developer (user) can modify it can be customized by the developer (user), for example, as follows:
・Since we want to change the message content (the message that is displayed when the action is executed), we will only rewrite the message content on lines 9, 16, and 20.
・Since we want the screen that is displayed when the SAVE button is pressed (the screen that is displayed when an action is executed) to be one that we created ourselves, we only need to rewrite the UI screen ID part of NextUI on lines 10 and 17 (crud-newui-UI01).
- Delete line 5 because you want to change the operation so that age is not registered. In other words, change the component that obtains and/or outputs information when the action is executed.
- Because you want to register it in multiple databases, create (add) a new SQL function (original function) and add it. When creating a new SQL function, copy and paste the automatically created SQL statements for "SQLSave" and "SQLUpdate" into the setting field 953, and modify only the target database and table parts.

In this way, customizing an automatically generated action can significantly reduce the amount of work required, rather than creating the desired CRUD button action from scratch with no action description in a programming language. Furthermore, because customization is free, there is also a great deal of freedom in the content of the actions that can be created. According to this embodiment, actions defined without the developer (user) having to write them in a programming language (actions defined based on the group of operations entered into input forms 1 to 3) can be more flexibly modified and used.

<Developer account registration process>
22A shows a flowchart of the developer account registration process on the developer terminal 100. This process is a detailed flowchart of S306 in FIG.

In S2201, the developer terminal 100 displays input fields on the display 105 to accept input of an email address, last name, and first name as newly registered account information, and accepts input from the user (developer) into each input field.

In S2202, the developer terminal 100 sends the account information entered in S2201 and a registration request to newly register the account information to the development environment 300.

In S2203, the developer terminal 100 displays a reception screen on the display 105 for receiving input of a one-time password, and receives input of the one-time password from the user (developer). When a request to register account information is sent to the development environment 300, the development environment 300 sends a one-time password to the email address included in the account information to confirm that the email address is valid. As the developer is the owner of that email address, the developer views the one-time password sent to that email address and enters it into the one-time password reception screen displayed on the display 105.

In S2204, the developer terminal 100 sends the one-time password entered in S2203 to the development environment 300.

In S2205, the developer terminal 100 determines whether or not a login OK notification has been received from the development environment 300. If a login OK notification has been received, the process proceeds to S2209; if not, the process proceeds to S2206.

In S2206, the developer terminal 100 displays a resend instruction screen to request the development environment 300 to resend the one-time password.

In S2207, the developer terminal 100 determines whether the developer (user) has issued a command to resend the one-time password. If a command to resend has been issued, the process proceeds to S2208. If a command to resend has not been issued, the developer terminal 100 waits until a command to resend is issued.

In S2208, the developer terminal 100 sends a request to the development environment 300 to resend the one-time password.

In S2209, the developer terminal 100 sends a password registration screen to the developer terminal 100 and accepts password registration (input of data to be used as the password).

In S2210, the developer terminal 100 sends the data to be used as the password received in S2209 to the development environment 300.

Figure 22(b) shows a flowchart of the developer account registration process in the development environment 300. This process is a process on the development environment 300 side that works in conjunction with the developer account registration process on the developer terminal 100 in Figure 22(a).

In S2221, the development environment 300 determines whether or not it has received account information and a registration request (registration instruction) that is a request to newly register that account information from the developer terminal 100. This account information and registration request were sent from the developer terminal 100 in S2202 of FIG. 22(a). If it has received account information and a registration request that is a request to newly register that account information from the developer terminal 100, it proceeds to S2222; otherwise, it waits until it is received.

In S2222, the development environment 300 adds a row to the developer information 301 and records the account information received in S2221. In addition, the value of the "Verify" column in this row is recorded as "unconfirmed." The columns in the developer information 301 are those shown in Figure 14(a). One row in the developer information 301 represents the account information for one person, and the information in each column recorded in the same row is recorded in association with each other as account information for the same developer.

In S2223, the development environment 300 instructs the external one-time password issuing system (not shown) to issue and send a one-time password to the email address included in the account information received in S2221. As a result, the one-time password is sent from the external one-time password issuing system to the developer's email address. Note that in this embodiment, the external one-time password issuing system is instructed to send the one-time password, but the development environment 300 itself may also send the one-time password.

In S2224, the development environment 300 determines whether a one-time password has been received from the developer terminal 100. The one-time password received here is the one sent from the developer terminal 100 in S2204 of FIG. 22(a). If a one-time password has been received, the process proceeds to S2225; if not, the process waits in S2224.

In S2225, the development environment 300 sends the one-time password received in S2225 to the external one-time password issuing system and sends an instruction to confirm whether it matches the issued one-time password. In other words, it instructs the system to verify the one-time password.

In S2226, the development environment 300 determines whether it has received notification from the external one-time password issuing system that the one-time password is correct (that the verification was successful). If it is correct (that the verification was successful), it proceeds to S2228; if not, it proceeds to S227.

In S2227, the development environment 300 determines whether a request to resend the one-time password has been received from the developer terminal 100. The request received here is the one sent from the developer terminal 100 in S2208 of FIG. 22(a). If a request to resend the one-time password has been received, the process proceeds to S2223; if not, the process waits in S2227.

In S2228, the development environment 300 activates the account added to the developer information 301 in S2222. Specifically, among the account information added to the developer information 301 in S2222, the value of the column "Verify" is changed to "confirmed." Account information with the value of the column "Verify" set to "confirmed" has its registered email address confirmed to be valid by matching the one-time password, and is considered to be a registered, valid account. Note that in this embodiment, authentication is performed using an email address, but if other contact information for the developer, such as a phone number or SNS account, is registered as account information, authentication may also be performed using the other contact information.

In S2229, the development environment 300 determines whether the number of valid accounts registered in the developer information 301 (the number of accounts for which the "Verify" value is "confirmed") is greater than a predetermined threshold 2 (e.g., 9,000). If the number of valid accounts is greater than threshold 2, the process proceeds to S2230; if the number of valid accounts is equal to or less than threshold 2, the process proceeds to S2232.

In S2230, the development environment 300 determines whether a DB instance has been added to the multi-tenant execution environment 410. If a DB instance has been added, proceed to S2232; if not, proceed to S2231.

In S2231, the development environment 300 adds a new DB instance to the DB set 430 of the multi-tenant execution environment 410. Adding (creating) a new DB instance takes several tens of minutes of processing time, so preparations are made in advance when the number of active accounts exceeds threshold 1 (> threshold 2), described below, before changing the connected DB instance. By doing this, when the connected DB instance is changed, it is possible to connect to the new DB instance immediately without delay.

In S2232, the development environment 300 determines whether the number of valid accounts registered in the developer information 301 (the number of accounts for which the "Verify" value is "confirmed") is greater than a predetermined threshold 1 (a value greater than threshold 2, for example, the developer terminal 10000). If the number of valid accounts is greater than threshold 1, the process proceeds to S2233; if the number of valid accounts is equal to or less than threshold 1, the process proceeds to S2236.

In S2233, the development environment 300 determines whether the DB instance name stored in memory 304 as the DB instance name of the multi-tenant execution environment to be assigned to the newly added account information has been updated to the DB instance name of the new DB instance added in S2231. If it has been updated, proceed to S2236; if not, proceed to S2234.

In S2234, the development environment 300 updates the DB instance name stored in memory 304 as the DB instance name of the multi-tenant execution environment to be assigned to the newly added account information to the DB instance name of the new DB instance added in S2231. The DB instance name is an identifier for a database environment. As a result, for example, while "DB instance name 1" was assigned to accounts added previously, "DB instance name 2" is assigned to accounts added thereafter. As the number of accounts connecting to a single DB instance (database environment) increases, the number of simultaneous database accesses increases, which can lead to performance degradation such as slower response times when accesses are concentrated. In contrast, if the number of accounts exceeds threshold 1, accounts registered thereafter are configured to connect to a new DB instance (database environment) different from the previous one. This reduces the possibility of access concentration due to an excessive number of developers using a single DB instance. This reduces the possibility of performance degradation such as slower response times when accessing the database.

In S2235, the development environment 300 updates threshold 1 to threshold 1 = threshold 1 + threshold 1. It also updates threshold 2 to threshold 2 + threshold 1. As a result, for example, if threshold 1 before the update was 10,000 developer devices and threshold 2 before the update was 9,000, threshold 1 = 20,000 and threshold 2 = 19,000. In other words, each time the number of developer device accounts increases by 10,000 (each time the number of valid accounts increases by the number of threshold 1), the processes of S2231 and S2234 are performed.

In S2236, the development environment 300 assigns the DB instance name stored in memory 304 as the destination DB instance for the account information added in S2222 (the currently added account). More specifically, the DB instance name stored in memory 304 is recorded as the destination DB instance in the column indicating the destination DB instance name (the rightmost column in Figure 14(a)) of the row of the currently added account in the developer information 301. By the processing described in S2232 to S2235, for example, if threshold 1 is developer device 10000 and the currently added account is the 9999th valid account, "DB instance name 1" is recorded. If the currently added account is the first valid account on developer device 1000, "DB instance name 2" is recorded.

In S2237, the development environment 300 sends a login OK notification to the developer terminal 100. The login OK notification sent here is received by the developer terminal 100 in S2205 described above.

In S2238, the development environment 300 receives the data to be used as the password sent from the developer terminal 100 in S2210 described above, and registers it as the password for the newly added account information. More specifically, it records it in the password column of the row for the newly added account in the developer information 301.

Figure 23(a) shows details of DB set 430 in the multi-tenant execution environment 410. DB set 430 initially has a fixed number of DB environments (DB instances), which can be one or more. In this embodiment, the fixed number is 1, meaning that initially only DB instance 1 (2310) is prepared. DB instance 1 includes a developer information DB 2311 and DBs for each developer. Developer information DB 2311 indicates which database is prepared for each developer (each account). For example, DB information 2312 for developer A is information indicating the correspondence that developer A's DB is DB1. DBs for each developer include DB1 (2314), DB2 (2315), DB3 (2316), etc., and the number increases each time a valid account is registered in developer information 301. However, the upper limit is the same as Threshold 1, and if Threshold 1 is 10,000 developer devices, DBmax (2317) is the DB on the 10,000th developer device, and subsequent DBs are created in separate DB instances. Each inventor's DB further contains one or more tables. For example, DB1 (2314) contains multiple tables, such as Table 1, Table 2, and so on. Each DB instance (database environment) is a writable database instance.

By processing S2231, the next DB instance 2 is created before the number of DBs in DB instance 1 reaches the upper limit (threshold 1). Then, if DB instance 1 has already created up to DBmax (2317) and another valid developer account is registered in developer information 301, S2232 returns Yes, and the newly registered developer is registered in developer information 301 so that he or she connects to DB instance 2 (2320). DBs for accounts (developers) added thereafter are then created in DB instance 2 (2320). Note that the number of DBs that can be stored in DB instance 2 (2320) is also limited to threshold 1 (total, up to threshold 1 x 2), and accounts registered thereafter are similarly controlled to connect to the next DB instance.

Figure 23(b) shows details of DB set 457 in a single-tenant execution environment. Because a single-tenant execution environment is dedicated to one account (one developer), DB set 457 is also dedicated to one account (one developer). Therefore, there is little chance of an increase in DBs or concentrated access to the extent that response is degraded. Therefore, DB set 457 has only one DB environment, DB instance 1 (2350). Furthermore, developer information DB 2351 records only information for one account statement (for example, DB information 2352 for developer A). There is no upper threshold for the number of DBs that can be stored. Furthermore, as explained in Figure 22(b), the control that determines the database environment of the single-tenant execution environment to be connected to in association with the registered account information is not performed when registering (adding) a new developer account.

<Deployment process>
24A shows a flowchart of the deployment process in the developer terminal 100. This process is executed by the developer terminal 100, and is a detailed flowchart of S426 in FIG.

Figure 25(a) shows an example of the UI editor screen when the selected app is a mobile app. Canvas 2501 is a canvas shaped for mobile devices, and is modeled after a smartphone. When the deploy button 506 is pressed, the process in Figure 24(a) begins.

In S2401, the developer terminal 100 sends information to the development environment 300 instructing the development environment 300 to deploy the selected app. Note that before issuing the deployment instruction, a save process may be performed to save the latest definition information stored in the memory 102 of the developer terminal 100 in the development environment 300, and then the deployment instruction may be issued.

At S2402, the developer terminal 100 displays a waiting screen. The waiting screen displays guide information indicating that the deployment is in progress.

In S2403, the developer terminal 100 determines whether or not a deployment failure notification has been received from the development environment 300. If a failure notification has been received, the process proceeds to S2404; if not, the process proceeds to S2405.

In S2404, the developer terminal 100 displays an error message indicating that the deployment has failed. If the deployment has failed, the processes of S2407 and S2409 described below are not performed.

In S2405, the developer terminal 100 determines whether a deployment success notification has been received from the development environment 300. The success notification includes information (URL) of the access destination for accessing the deployed app. If a success notification has been received, the process proceeds to S2406; if not, the process proceeds to S2403.

In S2406, the developer terminal 100 determines whether the selected app (deployed app) is for mobile use. If it is for mobile use, the process proceeds to S2408; if not (i.e., if it is for desktop use), the process proceeds to S2407. If it is not for mobile use, the QR code (registered trademark) is not displayed in S2409, which will be described later.

In S2407, the developer terminal 100 displays a screen accessed by the URL of the deployed app (the URL for accessing the execution environment) included in the success notification in a new tab of the browser software, different from the screen (e.g., a UI editor screen including a canvas) that was displayed in the browser software before receiving the deployment instruction. This allows the developer to immediately recognize that the deployment was successful. In addition, the authentication screen or initial UI of the deployed app is displayed in the new tab, and by operating the new tab, the display content and operation of the actual deployed app (built in the execution environment) can be immediately confirmed and verified. The processing of S2407 accesses the URL of the deployed app (the URL for accessing the execution environment) and executes the app. Details of the app execution processing will be explained using the flowcharts of Figure 33(c) or Figure 35(c).

In S2408, the developer terminal 100 performs a process to convert the app URL included in the success notification into a QR code. In other words, it generates a QR code (two-dimensional code) that includes information about the app's URL.

In S2409, the developer terminal 100 displays the QR code generated in S2409. The QR code is displayed when deployment is completed (successful), allowing the developer to recognize when deployment was successful. Figure 25(b) shows an example of the QR code displayed in S2409. Figure 25(b) is an example of the screen to which the transition occurs when the deploy button 506 is pressed from the state shown in Figure 25(a), a deployment instruction is issued, and deployment is successful. A QR code dialog 2510 is displayed superimposed on the mobile canvas. The QR code dialog 2510 displays the QR code 2511 generated in S2408, a close button 2512, and an open in new tab button 2513. Note that the app URL contained in QR code 2511 is a different URL from URL 2504 (the URL of the development system (application development platform) of this embodiment, which is the URL for accessing the developer terminal 100) displayed in the address bar of the browser displaying the UI editor screen. QR code 2511 is displayed when deployment is complete, and is the address for executing the deployed app, and is access destination information indicating the location (execution environment) where the deployment was performed.

By scanning the QR code 2511 displayed on the display 105 of the developer terminal 100 with a smartphone (mobile terminal), the developer (user) can access the deployed app's URL (the URL for accessing the execution environment) on the smartphone. This allows the developer (user) to easily access the deployed URL with minimal effort. In this case, the smartphone functions as the app user terminal 201. The deployed app's authentication screen or initial UI is displayed on the smartphone, allowing the user to immediately confirm and verify the display and operation of the deployed app (built in the execution environment) by operating the smartphone. Because the operation of a mobile app can be confirmed and verified on a mobile terminal rather than the developer terminal 100, it is easier to confirm whether the app is suitable for use as a mobile app than by verifying and verifying it on the developer terminal 100. In addition to or instead of the QR code 2511, a code image other than a QR code may be displayed as a code image from which the app's URL included in the success notification can be read. For example, a barcode, Chameleon Code (registered trademark), etc. may be used. Furthermore, the URL of the app included in the success notification may be displayed as a string in the QR code dialog 2510.

In S2410, the developer terminal 100 determines whether the Open in New Tab button 2513 has been pressed. If the Open in New Tab button 2513 has been pressed, the process proceeds to S2407; if not, the process proceeds to S2411.

In S2411, the developer terminal 100 determines whether or not the close button 2512 has been pressed. If the close button 2512 has been pressed, the process proceeds to S2412; if not, the process proceeds to S2410.
In S2412, the developer terminal 100 hides the QR code dialog 2510 and returns to the screen that was displayed before the deployment instruction was issued.

Figure 24(b) shows a flowchart of the deployment process. This process is executed by the development environment 300 and starts when the development environment 300 receives the deployment instruction sent from the developer terminal 100 in S2401 of Figure 24(a).

In S2421, the development environment 300 acquires the definition information of the selected app to be deployed from the app definition information stored in the developer area of the logged-in developer in the storage 320 of the development environment 300. The definition information acquired here includes the UI definition information (uiDef.json) described below and the execution environment program (JavaScript).

In S2422, the development environment 300 determines whether the selected execution environment is a multi-tenant execution environment. If it is a multi-tenant execution environment, the process proceeds to S2423; if it is not (if it is a single-tenant execution environment), the process proceeds to S2424.

In S2423, the development environment 300 stores the definition information of the selected app acquired in S2421 in the developer area (dedicated folder) of the logged-in developer in the storage 420 of the multi-tenant execution environment 410. More specifically, the development environment 300 sends the definition information of the selected app acquired in S2421 to the multi-tenant execution environment 410 and instructs the multi-tenant execution environment 410 to record it in the developer area of the logged-in developer (folder for each developer). If this recording is completed without any problems, the deployment is successful.

In S2424, the development environment 300 stores the definition information of the selected app acquired in S2421 in the storage of the single-tenant execution environment, which is the currently selected execution environment (a folder directly under the bucket of the single-tenant execution environment). More specifically, the development environment 300 sends the definition information of the selected app acquired in S2421 to the single-tenant execution environment, which is the currently selected execution environment, and instructs the multi-tenant execution environment 410 to record it in a folder directly under the bucket. If this recording is completed without any problems, the deployment is successful.

In S2425, the development environment 300 determines whether the deployment failed. If the deployment failed, the process proceeds to S2426; if not, the process proceeds to S2427. The deployment may fail if the definition information cannot be sent or recorded in the execution environment due to a communication failure or other reason.

In S2426, the development environment 300 sends a failure notification to the developer terminal 100 indicating that the deployment has failed.

In S2427, the development environment 300 determines whether the deployment has been completed (successful). If the deployment has been completed, the process proceeds to S2428; if not, the process proceeds to S2425.

In S2428, the development environment 300 sends a deployment success notification to the developer terminal 100, including information about the URL of the deployed app (information about the access destination for accessing the app deployed in the execution environment). The success notification sent here is received by the developer terminal 100 in S2405 of FIG. 24(a) described above.

<UI screen template>
The following describes UI screen templates. In addition to UI screens created by the user, there are also UI screens (template screens) that are prepared in advance as templates. A template screen is a screen in which at least one template component with a predefined action is placed in a predetermined position, even if the user has not previously placed UI components on the UI screen. The template screen can be customized using predefined information. More specifically, the template screen can be displayed on a canvas in the UI editor, and can be edited using the UI editor process described in FIG. 4.

Figure 26(a) shows an example of the display of template screen options when a list of UI screens is displayed as options in the submenu area 520. This display is performed by the processing of S401 in Figure 4 described above. Figure 26(a) shows an example of an expanded display of a list of UI screen options classified into the Authentication UI (UI screen for authentication, authentication screen) group, out of the UI screens classified into multiple types. Group name 2610 indicates that the expanded and displayed group is Authentication UI. When group name 2610 is pressed, the expanded Authentication UI options are collapsed, and the group names of the other groups are displayed in the submenu area 520. Options 2611 to 2622 are each options for one UI screen, and all are prepared in advance as template screens.

FIG. 26(b) shows an example of a display when option 2611 is selected and "Sign in ID," which is the template screen (UI screen) corresponding to option 2611, is displayed on canvas 2630. The screen of FIG. 26(b) is displayed in S404 of FIG. 4 described above in response to selection of option 2611. Template components 2631 to 2634 are displayed on canvas 2630. Template components 2631 to 2634 are not placed by the user (developer) using drag-and-drop from the UI component list in submenu area 520, but are template UI components whose display position (arrangement), color, size, and display content are defined in advance. Template components 2631 to 2634 are UI components as follows:
Template component 2631: A UI component for displaying "Sign In" in the Output Field.
Template component 2632: A UI component of Input type TextField for receiving input of an email address, which is the user name (user ID) of the application. In other words, a UI component for receiving input of user-specific information.
Template component 2633: A UI component of a button, which is set (labeled) to display "CREATE ACCOUNT?". When pressed, an action is set (predefined) to transition to a "Sign Up form" screen, which is a type of template screen (the UI screen shown in FIG. 27(c) and corresponds to option 2614).
Template component 2634: A UI component in the form of a button, which is set (labeled) to display "NEXT." When pressed, a predetermined action is set (predefined) to acquire the value (email address) input to template component 2632 and transition to a "Sign in Password" screen, which is a type of template screen (the UI screen corresponding to option 2612 in the screen shown in FIG. 27( a)).

Fig. 27(a) shows an example of the display on the canvas of the "Sign in Password" screen. Note that Fig. 27(a) to Fig. 27(k) are each partial display examples showing only the canvas portion when a template screen is displayed on the canvas. Template components 2711 to 2715 placed on the "Sign in Password" screen are UI components as follows:
Template component 2711: A UI component of the Input type TextField for receiving input of the application user password.
Template component 2712: A UI component in the form of a button that is set to display "Forget Password?" When pressed, a predetermined action is set (predefined) to transition to a "Reset Password Step 1" screen (a UI screen corresponding to option 2618 on the screen shown in FIG. 27(g)), which is a type of template screen.
Template component 2713: A check box that displays "Trust this device for 14 days."
Template component 2714: This is a button that displays "CHANGE EMAILS," and when pressed, an action of returning to the "Sign in ID" screen is predetermined (predefined).
Template component 2715: This is a button that displays "SIGN IN." When pressed, a predetermined action is performed (predefined): the value entered in template component 2632 (email address), the value entered in template component 2711 (password), and whether the check box in template component 2713 is checked, are sent to the execution environment in which the application is built.

In an actually constructed app, in response to pressing a button corresponding to template component 2715 displayed on the app user terminal 201, the app user terminal 201 sends to the execution environment an email address (which serves as the username), a password, and whether or not a check mark is selected. The execution environment verifies whether the received email address and password combination is correct, and checks whether it matches the user information 411 of the multi-tenant execution environment (shown in FIG. 14(b)) or the user-specific information of the single-tenant execution environment (shown in FIG. 14(c1)). If the verification results in authentication being successful, the user logs in to the app, and an initial UI is displayed on the app user terminal 201.

Similarly, the following are examples of template screens displayed on the canvas. Both are screens related to user authentication for the app.
27(b): UI screen corresponding to option 2613.
27(c): UI screen corresponding to option 2614.
27(d): UI screen corresponding to option 2615.
27(e): UI screen corresponding to option 2616.
27(f): UI screen corresponding to option 2617.
27(g): UI screen corresponding to option 2618.
27(h): UI screen corresponding to option 2619.
27(i): UI screen corresponding to option 2620.
27(j): UI screen corresponding to option 2621.
27(k): UI screen corresponding to option 2622.

Each of the template screens described above can be customized, and as explained in the process from S405 onward in Figure 4, developers can edit them using a UI editor. Edits include adding UI components other than template components, changing the template component's placement and display size, and changing template component properties (changing the display format, such as the displayed text and color). Actions on the template screen's canvas can also be set and changed. However, template component actions cannot be changed or deleted, and template components cannot be erased. Furthermore, actions cannot be changed or deleted for regular UI components (UI components that are not template components) added to the template screen. This prevents unintended errors that could result from modifying actions required for authentication processing using cloud services, which could cause authentication processing to malfunction. In other words, the actions required for error-free authentication are predefined in the template components and cannot be modified, ensuring reliable authentication processing using cloud services, even if a developer customizes the template screen. The reason why actions cannot be set for normal UI components added to template screens is to prevent the setting of actions that would cause authentication to not work properly. For example, if a new button is added to the "Sign in ID" template screen in Figure 26 (b) and an action is set for that button that transitions to a UI screen unrelated to authentication, the email address and password required for authentication cannot be sent to the runtime environment, and authentication will not work. If authentication is not successful, the UI screen to which the transition is made will not be displayed, and the app will not work properly. This type of problem can be prevented by not allowing actions to be set for normal UI components added to template screens.

Figure 26(c) shows an example display of a context menu 2655 for a button 2654 placed on the canvas of a UI screen that is not a template screen. As such, a button's context menu typically includes options for action and deletion. This is the same as what was explained in the display example of Figure 5(d). Therefore, as explained in steps S711 to S720 of Figure 7, editing such as editing properties, editing actions, and deleting components is possible.

Figure 26 (d) shows an example of a display showing the context menu 2635 of a button 2634 placed on the canvas of a template screen. As such, the action and delete options are not displayed in the context menu of a template component placed on the template screen. This prevents the user from setting an action or deleting the template component. In other words, the action board is not displayed either. Therefore, as explained in S721 to S724 of Figure 7, only the properties of the template component can be edited (the display format can be changed).

Figure 26(e) shows an example of the display after editing (customizing) the canvas of the template screen shown in Figure 26(b). The same UI components are designated by the same reference numerals in Figures 26(b) and 26(e). UI component 2641 is an output-type UI component added by the developer and displays the image file uploaded using the file management operation in S1217 of Figure 12. Using an icon or image representing the app makes it easier for the user to identify which app this authentication screen is for. UI component 2642 is a text message-type UI component added by the developer. The developer also opened the canvas's action board and set an action for this screen's canvas: obtain the current date, and if it is the end of the month, display the text "This is the end of the month, so don't forget to apply." In this way, it is possible to place UI components (components) whose display content changes depending on the conditions for displaying this authentication screen. Template component 2631 is the same UI component (UI component with the same ID) as template component 2631 in Figure 25(b), but the content (label) to be displayed can be changed by the developer's property editing operation, and "Login" is displayed. In this way, there is a high degree of freedom in screen design for actions other than those required for authentication. Therefore, for example, it is possible to create a screen that allows app users to easily recognize which app's authentication screen (login screen) it is for, to design it in accordance with an internal standard design agreed upon within the company, or to create a screen with a design that is more suitable for the nature of the app.

<Property box display example>
The property box that is displayed when you select "Properties" from the context menu of a UI component placed on the canvas will now be described.

Figure 28(a) shows an example of the display of a pie chart property box. Figure 28 shows a screen that is displayed by right-clicking pie chart 531, a UI component placed on canvas 530, in the display state shown in Figure 5(b) and selecting Properties from the displayed context menu. The process of displaying this screen and accepting editing processing for the displayed property box are performed in S706 of Figure 7, as described above. Property box 2810 is the property box for pie chart 531. Property box 2810 is displayed along with pie chart 531 displayed on canvas 530. The display format of the contents displayed in pie chart 531, such as the pie chart ratio and color coding, is displayed based on the settings made in property box 2810. When the settings made in property box 2801 are changed and the Apply button 2811 is pressed, the display format of pie chart 531 is updated based on the latest settings (changed settings) in property box 2801. In other words, the developer can perform setting operations for property box 2810 while checking how the display format of pie chart 531 changes.

When a pie chart is placed on the canvas by dragging and dropping it from the UI component list, if no values are set, the pie chart's respective zones will not be displayed, and it will simply appear as a circle. This means that developers cannot intuitively recognize that the placed UI component is a pie chart when they look at it. To solve this, we will set pre-defined initial values (default settings not set by the developer) as properties for the pie chart. By doing this, when a pie chart is placed on the canvas by dragging and dropping it from the UI component list, a pie chart with zones divided by zones will be displayed from the start, allowing developers to quickly and intuitively recognize that the placed UI component is a pie chart.

The Value input area 2812 of the property box 2810 is an area for entering the ID, numerical value, color, and label (display string) for each area shown in the pie chart 531. If the developer has not set anything, the initial value will be displayed as shown. In the example shown, only a portion of the initial value is displayed, and you can scroll to see the entire value. The full text of the initial value displayed in the Value input area 2812 is as follows. Note that "" represents double quotation marks.

[{″id″:″Jan″,″value″:Developer terminal 100.33,″color″:″#394E79″,″month″:″Jan″},{″id″:″F eb″, ″value″: 22.12, ″color″: ″#5E83BA″, ″month″: ″Feb″}, {″id″: ″Mar″, ″value″: 53.21 , "color": "#C2D2E9", "month": "Mar"}, {"id": "Apr", "value": 34.25, "color": "#9A8BA5 ″, ″month″: ″Apr″}, {″id″: ″May″, ″value″: 24.65, ″color″: ″#E3C5D5″, ″month″: ″May″}]
The initial value displayed in the Value input area 2810 is displayed in the same structure as when written in a programming language. Of the entire text of the initial value above, the portion enclosed in "{" and "}" is a dataset corresponding to one section in the pie chart. A pair of strings enclosed in "" and associated with a colon (:) is a pair of key name and key value. For example, in "id":"Jan", the key name is "id" and the key value is "Jan". The comma (,") separates the previous and next keys. That is, of the entire text of the initial value above, the portion containing multiple pairs {"id":"Jan", "value":developer terminal 100.33, "color":"#394E79", "month":"Jan"} is a dataset (one set), containing four key name-value pairs: id, value, color, and month. It can be seen that there are a total of five similar datasets. In this way, the initial values of the pie chart are a set of settings that includes multiple data sets each including a set of default settings.

Developers can freely edit the initial value displayed in the Value input area 2812 of the property box 2810 by selecting the Value input area 2812 and entering the value from the keyboard. However, because the initial value is displayed in a way that makes the structure clear, as shown above, it is easy to understand where and how to edit. Furthermore, by pressing the Apply button 2811, the edited content is reflected in the pie chart 531, so it is possible to see how the pie chart 531 changes when the value of a particular structure is changed. This makes it easy to understand what each part of a string displayed in a structure that can be written in a programming language means.

If the developer simply wanted to be able to set the pie chart's settings, one possible approach would be to separate the settings into categories like "Area 1 ID," "Area 1 Value," "Area 1 Color," "Area 1 Display Label," etc. in the property box 2810, and have the developer input or select values for each. However, this embodiment does not do this. Instead, the initial values are displayed in a structure similar to that used in programming languages, and developers are required to enter edits in a structure consistent with that used in programming languages. This is because the pie chart's settings can be changed by actions entered in JavaScript into other UI components or the canvas's action board. If the initial values are displayed as copyable text (character strings) in a structure compatible with programming languages, developers can simply copy this text to the clipboard using the well-known copy function and paste it into the action board (copy and paste). Then, by modifying only the text in the action board where the change is desired, developers can easily write actions to change the pie chart's display content. This prevents developers from being unable to write the intended action when they want to write an action that changes the display format of a pie chart because they don't know how to write it, or from spending a lot of time figuring out how to write it. In other words, it allows for more efficient software development. Because it is a programming language, there is a high degree of freedom when making other edits.

Figure 29 shows an example of the display of an action board when a developer enters an action that changes (specifies) the display format (display content) of pie chart 531 into the action board of a UI component (button) other than pie chart 531. The illustrated action board 2900 is a description area (input area) in which the action to be executed when the button is pressed in the constructed app is written in a programming language. Lines 2 through 32 of the string (JavaScript string) displayed on action board 2900 were created by copying and pasting the initial value displayed in the Value input field 2812 of property box 2810, with line breaks added for clarity. Only values 2901 through 2951 were edited (changed). Of course, other parts may be changed, and data sets (the parts enclosed in "{ }") may be added or deleted. This makes it extremely easy to enter actions in a programming language. In the created app, when the button corresponding to this action board is pressed, the pie chart will be displayed in a format based on the content described in this action board, rather than the default value.

Like pie charts, initial values (default settings) are also set for lists, which are UI components, and the initial values are displayed in the property box in accordance with the structure when written in a programming language. Figure 28(b) shows an example of the display of the property box 2820 for list 2802. As shown, the initial value is displayed in the Value input area 2821 in accordance with the structure when written in a programming language.

Like pie charts, LINE CHART (line charts, line graphs), a UI component, also has initial values (default settings) set, and the initial values are displayed in the property box according to the structure when written in a programming language. Figure 28(c) shows an example of the display of the property box 2830 for LINE CHART 2803. As shown, the initial values are displayed in input areas 2831 to 2834 according to the structure when written in a programming language.

Similar to pie charts, initial values (default settings) are set for UI components such as data grids (tables), combo boxes, tab components, steppers, and breadcrumbs, and the initial values are displayed in the property box in accordance with the structure when written in a programming language. Figure 28(d) shows an example of the display of the property box 2840 for data grid 2804. As shown, the initial values are displayed in the input area 2841 in accordance with the structure when written in a programming language. The initial values for a data grid include multiple rows of data sets, with the values of each column for each row of the data grid being one set of data set.

<Setting DataGrid properties and actions>
30 shows a flowchart of the context menu processing of the data grid in the developer terminal 100. This processing is a detailed flowchart of S705 in the above-mentioned FIG.

In S3001, the developer terminal 100 displays a context menu for the data grid. Figure 31(a) shows an example of the display of a context menu for the data grid. Data grid 3110, a UI component placed on canvas 530, has six columns, columns 3111 to 3116. Note that the dotted lines surrounding data grid 3110 are auxiliary lines on the drawing to show the entire data grid 3110 and are not displayed. A context menu 3120 for the data grid is displayed near the mouse cursor. The context menu 3120 displays at least properties 3121 and actions 3122 as options to be used as menu items.

In S3002, the developer terminal 100 determines whether or not Property 3121 has been pressed (selected) from the options included in the context menu 3120. If Property 3121 has been pressed (selected), the process proceeds to S3010; if not, the process proceeds to S3003.

In S3003, the developer terminal 100 determines whether action 3122 has been pressed (selected) from the options included in the context menu 3120. If action 3122 has been pressed (selected), the process proceeds to S3020; if not, the process proceeds to S3004.

In S3004, the developer terminal 100 determines whether any of the other options included in the context menu 3120 have been pressed (selected). If any of the other options have been pressed (selected), the process proceeds to S3005; if not, the process proceeds to S3006.

In S3005, the developer terminal 100 performs other processing in response to the pressing (selection) of other options. For example, if the option to delete is selected, the data grid, which is the specified UI component, is deleted (erased) from the canvas.

In S3006, the developer terminal 100 determines whether an operation to close the context menu has been performed (for example, an operation to click outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden in S3007, and the processing of FIG. 30 ends. If no operation to close the context menu has been performed, the process returns to S3002.

In S3010, the developer terminal 100 displays the property box of the data grid, which is the specified UI component. Figures 31(b) to 31(f) show display examples of the data grid property box. In Figures 31(b) to 31(f), the same display items are assigned the same symbols. The Apply button 3131 in Figure 31(b) is a button icon that instructs the application to reflect the contents entered in the property box (changed settings). When the Apply button 3131 is pressed, the display form of the data grid, which is the specified UI component placed on the canvas displayed together with the property box, changes based on the latest settings in the property box. The column selection field 3132 is a selection tab for selecting the column whose settings you want to change. The data grid property box displays a screen that accepts settings for each column and accepts property settings for each column. The Add Column button 3133 is a display item that instructs the application to add a column to the data grid, which is the specified UI component.

In S3011, the developer terminal 100 determines whether a tab corresponding to any column has been pressed in the column selection field 3132 in the property box. In other words, it determines whether any column has been selected as the setting target. If a tab corresponding to any column has been pressed, the process proceeds to S3012; if not, the process proceeds to S3013. Of the tabs (options) displayed in the column selection field 3132, the tab located on the far left (not shown) is labeled "DataGrid," and is a tab for displaying a settings screen for making settings related to the entire data grid, which is the specified UI component. Only this "DataGrid" tab does not relate to a specific column (it is not for selecting a specific column).

In S3012, the developer terminal 100 switches the display content of the area below the column selection field 3132 in the property box to a settings screen (element screen) for the selected column. Figure 31(c) shows an example of the display when tab 3132E (the tab labeled "CompanyE") is selected in the column selection field 3132. In the area below the column selection field 3132 in the property box, the upper area 3134t of the settings screen for tab 3132E is displayed as a screen for accepting settings for the column corresponding to tab 3132E. This area includes, for example, a type setting field 3135 for selecting the component type (part type) of the column. The settings screen for tab 3132E continues downward, and the lower part can be displayed by scrolling. Figure 31(d) shows an example of the display when scrolling to display the lower area 3134d of the settings screen for tab 3132E. The lower area 3134d includes a column deletion button 3136 for deleting the column corresponding to tab 3132E, and an apply button 3137 for applying the settings made on the settings screen for tab 3132E and reflecting them in the data grid displayed on the canvas. The column selection field 3132 moves upward as the user scrolls and is no longer visible within the property box, but it will reappear if the user scrolls back to display the upper area 3134t. Note that when the "DataGrid" tab is selected in S3011, the display content of the area of the property box below the column selection field 3132 is switched to a settings screen for configuring the entire data grid.

In S3013, the developer terminal 100 determines whether the Add Column button 3133 in the property box has been pressed. If the Add Column button 3133 has been pressed, the process proceeds to S3014; if not, the process proceeds to S3015.

In S3014, the developer terminal 100 performs column addition processing. In the column addition processing, first, the column addition form 3138 shown in FIG. 31(e) is displayed, and the developer (user) sets the ID and label (name of the column to be displayed) of the column (table column) to be added. Then, when the ADD TO VALUE button is pressed, a new column is added, and a tab corresponding to the new column is added to the column selection field 3132.

Figure 31(f) shows an example of how the properties box is displayed when a column is added. Compared to Figure 31(c), a tab 3032F (a tab labeled "CompanyF") corresponding to the new column has been added to the column selection field 3132. Immediately after addition, the added column is selected, and the upper area 3139t of the settings screen for tab 3032F corresponding to the added column is displayed in the area below the column selection field 3132. In this way, in this embodiment, adding a column to a data grid (table) is performed by operating the properties box, which is the settings screen for the data grid.

In S3015, the developer terminal 100 determines whether a setting operation has been performed on the selected column. Specifically, it determines whether an input operation has been performed on any of the setting fields on the setting screen displayed in the area below the column selection field 3132. If an input operation has been performed on any of the setting fields, the process proceeds to S3016; if not, the process proceeds to S3017.

In S3016, the developer terminal 100 accepts the setting operation and reflects it in the display. For example, it accepts the type setting for the type setting field 3135. In this way, the data grid allows the component type to be selected for each column. The following options are displayed for the component types that can be set in a column: TextInput, NumberInput, ComboBox, Multi-Select, CheckBox, DataPicker, Link, Button, and IconButton, and the developer can select and set one of them. In addition, at least some of the other configurable items (setting items) change depending on the type of the selected component. For example, if TextInput is selected as the type, other setting items include the following: ValueType, ID, Label (character string displayed as column name), Width (column width), NumberFormat, DataFormat, Options, Footer, FooterText, Sorting, Visibility. Additionally, settings that can be configured on the overall settings screen for the data grid corresponding to the "DataGrid" tab include the following: ID (data grid UI component ID), overall size of the DataGrid (width, height), whether to make it editable in the deployed app, whether to display an add row button to add a row to the data grid in the deployed app, whether to display a delete button for the datagrid, whether to display an update button for the datagrid, etc.

In S3017, the developer terminal 100 determines whether the Apply button 3131 or the Apply button 3137 has been pressed. If the Apply button 3131 has been pressed, the process proceeds to S3018; if not, the process proceeds to S3019.

In S3018, the developer terminal 100 records the content set in the property box in the definition information stored in memory 102, and changes the display format of the data grid, which is the specified UI component displayed on the canvas of the UI editor, to reflect the content set. For example, if a column has been added, the data grid is displayed in a format with one additional column added, and if the column width has been changed, the column width of the data grid on the canvas is changed and displayed.

In S3019, the developer terminal 100 determines whether the End button 3140 has been pressed. If the End button 3140 has been pressed, the property box is hidden and the processing in Figure 30 ends. If the End button 3140 has not been pressed, the process proceeds to S3011.

In this way, adding columns to a data grid (table) and configuring each column can be done more easily. In particular, adding a column to a data grid can be done by operating the data grid's property box, and you can then perform configuration operations for the added column in the same property box. In other words, the series of operations of adding a column and configuring the added column can be done smoothly with the same feel as operating the property box. Furthermore, after adding a column, you can set the type from the options that can be set as a column component, so you can add columns and configure the type without any confusion.

In S3020, the developer terminal 100 displays action options for each column as a submenu of the context menu. Figure 32(a) shows an example of the display in S3020. Figure 32(a) is an example of the display when action 3122 is pressed from the state of Figure 31(a). The same display elements are assigned the same symbols in Figures 31(a) and 32(a). Submenu 3210 is displayed as a submenu of action 3122 of context menu 3120. Submenu 3210 includes options 3211 to 3217. Option 3211 is an option for opening an action board for actions to be executed in response to an operation on the entire data grid 3110. Options 3212 to 3217 are options for opening action boards for actions for each column to be executed when each column of data grid 3110 is operated. Options 3212 to 3217 correspond to columns 3111 to 3116, respectively. In this case, options corresponding to the action board of a data grid column different from the data grid of the specified UI component will not be displayed.

In S3021, the developer terminal 100 determines whether either the action option for the entire data grid (option 3211) or the action options for each column (3212-3217) has been selected. If any action option has been selected, the process proceeds to S3022; if not, the process waits for a selection in S3021.

In S3022, the developer terminal 100 displays an action board corresponding to the selected action option.

Figure 32(b) shows an example of the display of an action board corresponding to the action options (options 3211) for the entire data grid. "DATA GRID" is selected in the overall or column selection area 3220, indicating that action board 3211a is the area for entering actions for the entire data grid. The trigger for executing the content set in action board 3211a is predetermined, and is triggered by pressing a global button displayed outside the column of the data grid area, which is the specified UI component in the built application. In other words, this trigger is related to the data grid (table), which is the specified UI component, and is not related to the columns of the data grid. A global button is a button that is displayed when it is set to display in the settings screen corresponding to the "DataGrid" tab in the properties box mentioned above. Examples include the aforementioned data grid delete button and data grid update button. Therefore, developers do not need to set what triggers execute actions (there is no need to write it in JavaScript). This action board 3211a can be configured by writing actions in JavaScript, such as calculating the total of all rows in a specific column and displaying it in another UI component, saving the content displayed in the data grid to a database, or transitioning to another UI screen.

Figure 32(c) shows an example of an action board display corresponding to an action option (option 3212) for a specific column in a data grid. "MONTH" is selected in selection area 3220, and action board 3212a indicates that it is the area for entering an action for the column (column 3111) whose label or column ID is "MONTH." The trigger for executing the content set in the column's action board 3212a is predetermined, and is triggered when a cell value in any row of the corresponding column among the specified UI components in the built application is changed, or when a button displayed in a cell in any row of the corresponding column is pressed. Therefore, developers do not need to specify the trigger for executing the action (there is no need to write it in JavaScript). For example, this action board 3212a can be configured with an action such as calculating the sum of the value of the row in which the column corresponding to action board 3212a has changed and the value of another first column in the same row, and displaying the sum in another second column in the same row. An example of this action is when a value in the first column of a table is changed, the sum of the changed values in the first and second columns is displayed in the third column of the same row. In other words, it is possible to accept settings for actions that affect other columns in the data grid, which is the specified UI component, other than the column corresponding to the selected option 3212.

In addition, by selecting another column in the selection area 3220, it is possible to switch to and display the action board of another column even after opening the action board.

In S3023, the developer terminal 100 accepts an input operation for an action on the displayed action board. This process is similar to the processes in S802 to S823 in Figure 8 described above.

In S3024, the developer terminal 100 determines whether an operation to close the action board (an operation to end action board processing) has been performed. If an operation to close the action board has not been performed, the process proceeds to S3023 and repeats the process. If an operation to close the action board has been performed, the action board is hidden, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor processing.

In this way, actions can be set more easily for each column included in the data grid (table). In particular, as shown in submenu 3210, a list of options corresponding to the action boards of all columns included in the data grid (table) is displayed, allowing developers to recognize that actions can be set for each column, reducing the possibility of forgetting to set an action for a column. Furthermore, because it is displayed as a submenu of the context menu of the data grid, which is the specified UI component, the relationship with the data grid, which is the specified UI component, can be clearly understood. In other words, design work can be carried out while understanding, without confusion, which data grid and which column the action set in the action board relates to.

<Action execution related processing>
33(a) shows a flowchart of the save process (recording control process) executed by the development environment 300, which is the recording destination of the definition information. This process is executed in conjunction with receiving the definition information sent from the developer terminal 100 in S422 of FIG. 4 described above.

Figure 34 also illustrates the transition of information recorded in the developer terminal 100, development environment 300, execution environment 400, and application user terminals 200 and 201. Figure 34 is a diagram that schematically illustrates the transition of information due to the processing of the flowcharts in Figures 33(a) to 33(c).

In S3301 of FIG. 33(a), the development environment 300 determines whether definition information (UI definition information) for the selected app has been received from the developer terminal 100. The definition information received here is the information sent from the developer terminal 100 in S422 of FIG. 4 described above. If a UI definition has been received, the process proceeds to S3302; if not, the process waits in S3301.

In Figure 34, UI definition information 3401 recorded in memory 102 of the developer terminal 100 is the definition information received in S3301. In this embodiment, the UI definition information is a text file written in JSON format with the file name "uiDef.json". JSON stands for JavaScript Object Notification, a document standard for handling values in JavaScript, and a data description language. UI definition information 3401 includes various settings related to the app, such as the initial UI, and information defining UI component (UI part) information for each UI screen (position, size, color, etc.). UI definition information 3401 also includes an action description portion 3402. This action description section 3402 is a string of characters entered into the action board or function setting screen (including the creation function setting screen) of each UI component or canvas. The action description section 3402 includes actions written in JavaScript and function definitions in Json format that describe the contents set on the function setting screen without having to enter JavaScript. This UI definition information 3401 is sent (uploaded) from the developer terminal 100 to the development environment 300 and received by the development environment 300 in S3301.

In S3302, the development environment 300 saves the UI definition information in an area of the storage 320 for the logged-in developer. As a result, as shown in FIG. 34, UI definition information 3411 is recorded in the development environment 300. Immediately after this saving, the UI definition information 3411 recorded in the development environment 300 is the same information as the UI definition information 3401 recorded in the developer terminal 100.

In S3303, the development environment 300 extracts action information from the UI definition information saved in S3302. That is, the development environment 300 extracts the action description portion 3412 from the UI definition information 3411 in Figure 34.

In S3304, the development environment 300 generates an execution environment program from the action description portion 3412 extracted in S3303 and saves it in an area of the storage 320 for the logged-in developer. That is, based on the action description portion 3412 extracted from the UI definition information 3411 in Figure 34, an execution environment program 3413 is generated and saved in the development environment. The execution environment program 3413 is text data written in JavaScript. The execution environment program 3413 is a program that adds supplementary parts necessary for execution by the execution engine of the execution environment to the character strings entered in the action board obtained from the action description portion 3412.

The UI definition information 3411 and execution environment program 3413 saved in the development environment 300 by the save process described in Figure 33 (a) are deployed (placed, saved, recorded, constructed) to the execution environment 400 by the deploy process. This process is performed at S2423 or S2424 in Figure 24 described above. As a result, as shown in Figure 34, the UI definition information 3421 and execution environment program 3423 are recorded in the execution environment 400. The UI definition information 3421 and execution environment program 3423 in the execution environment 400 are the same information as the UI definition information 3411 and execution environment program 3413, respectively. This state is the state in which the app has been generated.

Figure 33 (b) shows a flowchart of the application execution process in the execution environment 400. This process is executed by the execution engine of the execution environment 400 when a deployed (built, generated) application is accessed from the application user terminal 200 or 201.

Figure 33(c) shows a flowchart of application execution processing in application user terminal 200 or 201. This processing is executed by CPU 101 of application user terminal 200 or 201 when an application that has been deployed (built, generated) in execution environment 400 is accessed using the browser software on application user terminal 200 or 201. The application execution processing in execution environment 400 in Figure 33(b) and the application execution processing in application user terminal 200 or 201 in Figure 33(c) are performed in conjunction with each other. Below, the processing by application user terminal 200 or 201 will be described assuming that it is executed by application user terminal 200 as a representative (the description of application user terminal 201 is similar and will be omitted).

In S3311 of FIG. 33(b), the execution environment 400 determines whether or not a request to obtain UI definition information has been received from the application user terminal 200. The request to obtain UI definition information received here is the request sent from the application user terminal 200 in S3333 of FIG. 33(c), which will be described later. If a request to obtain UI definition information has been received, the execution environment 400 proceeds to S3312; if not, the execution environment 400 waits in S3311.

In S3312, the execution environment 400 sends the UI definition information to the application user terminal 200. As a result, as shown in FIG. 34, the UI definition information 3421 recorded in the execution environment 400 is downloaded to the application user terminal 200 and recorded as UI definition information 3431. The UI definition information 3421 and the UI definition information 3431 are the same information.

In S3313, the execution environment 400 determines whether or not an action request has been received from the application user terminal 200. An action request is a request to execute the content of an action entered in the action board. The action request received here is the one sent from the application user terminal 200 in S3345 of FIG. 33(c), which will be described later. If an action request has been received, the process proceeds to S3314; if not, the process proceeds to S3320.

In S3314, the execution environment 400 determines whether or not a value for an input item has been received from the application user terminal 200. The value of an input item is a value entered by the user on the application user terminal 200 for a UI component classified as an input item among the UI components displayed on the application screen. For example, it is text entered into a text field. In this embodiment, the determination in S3314 is a determination of whether or not the value of the input item was included in the action request received in S3313. If the value of the input item has been received (if the value of the input item was included in the action request), the process proceeds to S3315; otherwise, the process proceeds to S3316.

In S3315, the execution environment 400 temporarily stores the received input item values in memory included in the execution engine.

In S3316, the execution environment 400 executes the execution environment program 3424 to perform the requested action. If an input item value has been received, the action is performed using the input item value as well. For example, the requested action portion of the execution environment program 3424 is executed using the input item value as an argument.

In S3317, the execution environment 400 determines whether or not there is a value for the output item, which is a value to be displayed on the app screen displayed on the app user terminal 200, as a result of executing the action in S3316. For example, if the action is an action such as "performing arithmetic operations," the solution to the operation is obtained as the value of the output item. Also, for example, if the action is an action such as "transitioning to a screen" or "recording in a database," there may not be a value for the output item as a result of the action. If there is a value for the output item, proceed to S3318; if not, proceed to S3319.

In S3318, the execution environment 400 generates action result information including the values of the output items as result information of the action executed in S3316.

At S3319, the execution environment 400 sends result information of the action executed at S3316 to the application user terminal 200. If action result information including values of output items was generated at S3318, the values of the output items are also sent to the application user terminal 200. Then, at S3348 in FIG. 33(c) (described below), the values of the output items are displayed on the screen of the application user terminal 200. The action result information may also include an instruction for a screen transition. If an instruction for a screen transition is included, a screen transition occurs on the application screen displayed on the display 105 of the application user terminal 200 by processing at S3347 in FIG. 33(c) (described below).

In S3320, the runtime environment 400 determines whether or not to terminate the processing. If the runtime environment 400 determines to terminate the processing (Yes in S3320), the processing terminates. If the runtime environment 400 determines not to terminate the processing (No in S3320), the processing returns to S3313. For example, the runtime environment 400 determines to terminate the processing when an event occurs in S3350 that terminates the app, which will be described later.
33(c), application user terminal 200 (including application user terminal 201, but the following description will use application user terminal 200 as an example) uses internet browser software to access an application that has been deployed (constructed, generated) in execution environment 400. More specifically, in response to an operation to specify and access the URL of a deployed application (URL for accessing the execution environment) (for example, an operation to click on a link for the application's URL, or an operation to enter the application's URL in the address bar and press Enter), application user terminal 200 accesses (connects to) the application's URL.

In S3332, the application user terminal 200 determines whether or not a client program has been received. When the execution environment 400 detects access from the application user terminal 200, the execution environment's distribution engine (distribution engine 415, 455, 465, 475, etc., for the accessed execution environment) transmits the client program recorded in storage (client program 422, 456c, 466c, 476c, etc., for the accessed execution environment) to the application user terminal 200. In S3332, it determines whether or not the client program has been received. If the client program has been received, the process proceeds to S3333; if not, the process waits for reception of the client program in S3332.

In S3333, the application user terminal 200 sends a request to obtain UI definition information to the runtime environment 400. The client program received in S3332 defines that when the runtime environment is accessed, a request to obtain UI definition information is first issued. S3333 is processing that follows this definition. The UI definition information obtainment request sent here is received by the runtime environment 400 in S3311 of Figure 33 (b) described above.

In S3334, the application user terminal 200 determines whether UI definition information has been received from the execution environment 400. The UI definition information received here is the information sent from the execution environment 400 in S3312 of FIG. 33(b) described above. If UI definition information has been received, the UI definition information is recorded in memory 102 and the process proceeds to S3335; otherwise, the process waits for reception of UI definition information in S3334. The UI definition information is recorded as temporary information in memory 102 (work memory) and is automatically deleted when the application is terminated (when the connection to the application's URL is terminated). The application user terminal 200 also displays the application screen on the display 105 based on the UI definition information recorded in memory 102.

In S3335, the application user terminal 200 determines whether an action has been triggered. Specifically, it determines whether an operation has been performed on the application screen to instruct a screen transition (a trigger to activate an action on the canvas to which the transition will be made) or an operation has been performed on a UI component displayed on the application screen (a click or other action trigger on a UI component). If an action has been triggered, the process proceeds to S3336; if not, the process proceeds to S3350.

In S3336, the application user terminal 200 extracts a description portion related to the action to be executed in response to the trigger detected in S3335 from the UI definition information (UI definition information 3431 in FIG. 34) recorded in memory 102. This description portion is text (character string) information written in JavaScript (a programming language).

In S3337, the application user terminal 200 searches the description extracted in S3336 from the beginning for the character string "$ui" in half-width characters.

In S3338, the application user terminal 200 determines whether the search result of S3337 contains the character string "$ui." If "$ui" is found, the process proceeds to S3339; if not, the process proceeds to S3343.

In S3339, the application user terminal 200 determines whether the character string "$ui" found in S3338 is on the left side of a sentence containing that character. A "sentence" (one statement) is a string of characters in a programming language that is separated by a line terminator (for example, a semicolon ";") or a closing bracket "}". In other words, two statements are separated by a line terminator or a closing bracket ('}'). If the "$ui" found in the search is located to the left of the "=" (equal sign) in the sentence, it is determined to be on the left side. If "$ui" is on the left side, proceed to S3340; if not, proceed to S3341.

In S3340, the application user terminal 200 records information based on the element string ($ui.UI component ID.target information type) of a predetermined structure beginning with "$ui" found in S3338 as an output item in the item definition list (item definition list 3433 in Figure 34) generated in memory 102. Specifically, the application user terminal 200 obtains the UI component ID (item code, component identifier) from the element string ($ui.UI component ID.target information type) of a structure separated by a period (.") beginning with "$ui," and records that the UI component is an output item. For example, if a trigger related to action A occurs, and "$ui" is found in the description portion related to action A, and it is on the left side, and the UI component ID is "UI component ID3," then the presence of UI component ID3 in the output item is recorded, as in item definition list 3433 in Figure 34. Note that the item definition list 3433 is information temporarily stored in memory 102, which is the work memory, and is automatically deleted when the results of the action are received and reflected in the output items (No in S3348, described below, or processing in S3349 is completed) or when the app is terminated (Yes in S3350).

In S3341, the application user terminal 200 determines whether the character string "$ui" found in S3338 is located anywhere other than on the left side of a sentence containing the character. "Located somewhere other than on the left side" means that the character string is located on the right side (to the right of the "=") or in a portion not containing the "=". If the character string is located somewhere other than on the left side, the process proceeds to S3342; otherwise, the process proceeds to S3337. Note that if the determination in S3339 is No, this is equivalent to the character string "$ui" being located somewhere other than on the left side of a sentence containing the character, and therefore the process may proceed to S3342 without making the determination in S3341.

In S3342, the application user terminal 200 records information based on the element string of a predetermined structure beginning with "$ui" ($ui.UI component ID.target information type) found in S3338 as an input item in the item definition list (item definition list 3433 in Figure 34) generated in memory 102. Specifically, the application user terminal 200 obtains the UI component ID (item code, component identifier) from the element string of a predetermined structure beginning with "$ui" ($ui.UI component ID.target information type), and records that the UI component is an input item. For example, if a trigger related to action A occurs, and "$ui" is found in the description section related to action A, and it is on the right and the UI component ID is "UI component ID1," then it is recorded that UI component ID1 is present in the input item, as shown in item definition list 3433 in Figure 34. Also, for example, if a trigger related to action A occurs, "$ui" is found in the description section related to action A, it is in a sentence without "=", and the UI component ID is "UI component ID2", then it will be recorded that UI component ID2 is in the input item, as shown in item definition list 3433 in Figure 34.

After completing processing of S3342, the process proceeds to S3337, where the continuation of the description extracted in S3336 is searched for the character string "$ui", and the processes of S3339 to S3342 are repeated until it is determined in S3338 that "$ui" is not present. In other words, the processes of S3339 to S3342 are performed for all $ui character strings contained in the description extracted in S3336, and whether they are input items or output items is recorded in the item definition list 3433.

At S3343, when it is determined in S3335 that an action has been triggered, the application user terminal 200 determines whether the information targeted by the input item recorded in the item definition list 3433 contains a value. For example, if the description extracted in S3336 contains "$ui.UI component ID1.value," it determines whether the information of type "value" in the UI component with UI component ID1 contains a value. If the UI component with UI component ID1 is a TextField, the value is the text (character string) entered in that TextField. In other words, it determines whether the application user has entered text via the keyboard for UI component ID1, which is a TextField displayed on the application screen. If text has been entered, it determines Yes; if the field is blank, it determines No. This determination is made for all input items recorded in the item definition list 3433. If the information targeted for the input item has a value, proceed to S3344; if not, proceed to S3345.

In S3344, the application user terminal 200 generates an action request that requests the execution of an action corresponding to the trigger detected in S3335, and that includes the value of the input item. For example, the application user generates an action request that includes, as the value of the input item, information about the text entered by the application user on the keyboard for UI component ID1, which is a TextField displayed on the application screen displayed on the display 105 of the application user terminal 200.

At S3345, the application user terminal 200 transmits to the runtime environment 400 an action request requesting the execution of an action corresponding to the trigger detected at S3335. If an action with an input field value was generated at S3344, the value of the input field is also transmitted to the runtime environment 400. For example, as the input field value, text information entered by the application user via the keyboard for UI component ID 1, which is a TextField displayed on the application screen displayed on the display 105 of the application user terminal 200, is transmitted to the runtime environment 400. The transmitted action request is received by the runtime environment 400 at S3313 in Figure 33(b) described above, where it is executed in the runtime environment 400. As described in S3314 to S3319, the action corresponding to the trigger detected at S3335 is executed in the runtime environment 400.

In S3346, the application user terminal 200 determines whether or not it has received the results of the action corresponding to the action request sent in S3345 from the execution environment 400. If it has received the results of the action, it proceeds to S3347; if not, it waits for the results of the action in S3346.

In S3347, the application user terminal 200 updates the application screen displayed on the display 105 to reflect the result of the action received in S3346. At this time, the display is also based on the UI definition information stored in memory 102. For example, if the result of the action is an instruction to perform a screen transition, the screen transition is executed.

In S3348, the application user terminal 200 determines whether the action result received in S3346 includes a value for the output item. If a value for the output item is included, the process proceeds to S3349; if not, the process proceeds to S3350.

In S3349, the application user terminal 200 displays the value of the output item included in the result of the action received in S3346 in the output item displayed on the display 105, based on the information on the output item recorded in the item definition list 3433 held in memory 102. As a result, for example, if the type of information in question is "value," text or a numerical value that is the value of the output item is displayed in the UI component of the output item, or if the type of information in question is "color," the color of the UI component of the output item is changed to the color indicated by the value of the output item.

In S3350, the application user terminal 200 determines whether an event has occurred that will cause the application to terminate. Events that cause the application to terminate include, for example, disconnecting the connection to the access destination indicated by the application's URL (closing the internet browser, turning off the application user terminal 200, changing the connection to an unrelated URL, etc.). If there is no event that will cause the application to terminate, the process proceeds to S3335; if there is an event that will cause the application to terminate, the application screen is hidden and the process of FIG. 33(c) is terminated.

Using the example of a string in a programming language entered into the action board 910 shown in Figure 10(d), we will now provide a more detailed explanation of the process of determining whether a string containing "$ui" described in S3338 to S3342 is an input item or an output item and sorting it.

The second line states "const userid = $ui.text_field_a.value;" Because "$ui" is on the right-hand side of this statement, "text_field_a" is recorded as an input item in the item definition list at S3342. In other words, the value entered by the user into "text_field_a" on the app screen is obtained and set as the value of the variable "userid."

In the statement on line 4, the left side contains the string "$ui.text_area_a.value," which includes "$ui." Therefore, S3340 records "text_area_a" as an output item in the item definition list. In other words, the value indicated by the right side of the "=" (the output value obtained as a result of the action) is displayed in the UI component "text_area_a." In addition to defining "text_area_a" as an output item, this statement also contains processing (logic) that outputs the value indicated by the right side of the "=" (the output value obtained as a result of the action) to that output item. In this way, one of the distinctive features of this embodiment is that input and output items can also be defined within a statement that contains logic (processing that differs from the definition of at least one of the input and output items). Similarly, line 6 is also a logic part, and because "$ui.text_area_a.value" is on the left side, it is treated as an output item.

Also, below is an example of an action string that contains "$ui" in a statement without an "=".

(The numbers at the beginning of each line are auxiliary characters indicating the line number and are not the programming language text itself.)
1 SQLSave({
2 PREF_CODE: $ui. PREF_CODE. value,
3 PREF_NAME: $ui. PREF_NAME. value
4 });
5 // Screen transition 6 $fn. nextUI('List_ip_demo');
The character string in the above programming language is an action that uses the input values ('$ui.PREF_CODE.value', $ui.PREF_NAME.value) on the app screen as parameters for the SQLSave function to register them in the database. In this case, $ui.{component ID}.{target information type} used as a parameter for the SQLSave function is identified as indicating an input item (because it is not on the left side of =).

Furthermore, in element strings with a specified structure using "$ui," the type of information being targeted can be something other than value, such as color. For example, you can change the color of a UI component by writing "$ui.UIComponentID.color = "#008000";".

In this embodiment, when describing an action to be entered into an action board, it is possible to express (define) whether a UI component indicated by an element string with a specific identifier "$ui" is to be treated as an input item or an output item, depending on the element string's position in the string (more specifically, its position within a single sentence). Conventionally, the decision as to whether to treat a component as an input item or an output item was made in a settings screen separate from the area where the action content is entered in a programming language. Or, even when describing the action content in a programming language in the area where the action content is entered, it was necessary to declare whether the component was to be treated as an input item or an output item using a variable in a statement separate from the logic statement that describes the processing itself. In contrast, in this embodiment, the definitions of input and output items can be defined anywhere in the string describing the action logic in a programming language. Therefore, the input and output items used in the logic can be defined near the logic description section, making it easy to set the input and output items used in the logic when writing the logic. Furthermore, in this embodiment, there is no need to define variables for input and output fields when values are passed between the function setting screen and the action logic description section. This reduces the need for developers to perform cumbersome variable management, making variable management easier. This reduces the factors that can lead to errors when writing actions, making it possible to reduce errors. In this way, this embodiment makes it easier to set input and/or output fields used in logic entered in a programming language.

Furthermore, because the method of indicating whether an element string containing the specific identifier "$ui" is an input or output item based on its position is not common, programs executed using the normal JavaScript programming language do not properly interpret whether the item is an input or output item, and do not operate as intended. Therefore, in this embodiment, the system operates correctly by performing a process to identify and sort strings containing "$ui" as either input or output items, as explained in S3338 to S3342.

In this embodiment, an example has been described in which the specific identifier is the half-width character "$ui," but this is not limited to this. Any other character string that is not confused with other existing identifiers in the programming language may be used as the identifier, for example, the half-width character "_inputoutput." The half-width character "$" is the Unicode dollar character. The half-width character "_" is the Unicode underscore character.

In addition, in this embodiment, as described in S3304 of FIG. 33(a), the development environment 300 generates an execution environment program 3414, which is a program to be executed in the execution environment 400, based on the UI definition information, and deploys it to the execution environment 400. When the app is executed, the application user terminal 200 executes processing based on the UI definition information 3431, and the execution environment 400 executes processing based on the execution environment program 3423. Also, as described in S3338 to S3342 of FIG. 33(c), the application user terminal 200 generates an item definition list 3433 required for processing executed on the application user terminal 200 based on the UI definition information. By doing this, when the app developer accesses the development environment 300 on the developer terminal 100 to develop the app, there is no need to particularly distinguish between information required for processing executed in the execution environment 400 and information required for processing executed on the application user terminal 200 when the constructed app is executed. This allows developers to clearly separate and manage the information used in the execution environment and the terminal device when executing the application they are developing, reducing the development effort and making software development easier.

In this embodiment, an example has been described in which the execution environment program 3414 is generated during the save process in the development environment 300. However, the development environment 300 may not generate the execution environment program 3414, and instead, after recording the UI definition information 3421 in the execution environment 400, the execution environment 400 may generate the execution environment program 3423 based on the UI definition information 3421.

<Modification of Action Execution Related Processing>
35(a) shows a modified flowchart of the save process (recording control process) executed by the development environment 300, which is the destination for recording definition information. This process is executed in conjunction with receiving the definition information sent from the developer terminal 100 in S422 of FIG. 4 described above.

Furthermore, Figure 36 illustrates a modified example of the transition of information recorded in the developer terminal 100, development environment 300, execution environment 400, and application user terminals 200 and 201. Figure 36 is a diagram that schematically illustrates the transition of information due to the processing of the flowcharts in Figures 35(a) to 35(c). In Figure 36, the same information as in Figure 34 is assigned the same reference numerals.

In FIG. 36, instead of performing processing to generate item definition list 3433 based on UI definition information in application user terminal 200, client UI definition information 3615 is generated based on UI definition information in development environment 300. This client UI definition information 3615 is then deployed to execution environment 400 (recorded in execution environment 400 as client UI definition information 3625), and further transmitted from execution environment 400 to application user terminal 200 (recorded in application user terminal 200 as client UI definition information 3635). When an action is executed, application user terminal 200 performs processing based on client UI definition information 3635.

In Figure 36, unlike Figure 34, UI definition information is not sent to application user terminal 200 (it is not even temporarily stored on application user terminal 200). This prevents the detailed definition of a developed application from being leaked via application user terminal 200, and increases the confidentiality of the configuration of the developed application. This reduces the possibility that a third party will create an application that imitates at least a portion of the developed application (for example, JavaScript code written in an action board). Furthermore, application user terminal 200 does not need to perform the process of analyzing UI definition information and generating item definition list 3433 (processing S3338 to S3342 in Figure 33(c)) every time an action is triggered. This reduces the processing load on application user terminal 200 and enables application operation with a smooth response (speed of response).

Steps S3501 to S3504 in Figure 35(a) are the same as steps S3301 to S3304 in Figure 33(a) described above, so their explanation will be omitted. In Figure 35(a), in addition to the processing in Figure 33(a), processing from S3505 onwards is performed.

In S3505, the development environment 300 generates client UI definition information 3615. The client UI definition information 3615 is assumed to be a Json format file with the file name "uiDef2.json," for example. The client UI definition information 3615 includes information obtained from the UI definition information 3411, such as various setting information related to the application, such as the initial UI, information on UI components (components) for each UI screen (such as UI component IDs and property settings, and the placement and size of UI components), canvas action identifiers, and UI component action identifiers. The client UI definition information 3615 also records input/output item definitions for each action (definitions of which components are included in the input and output items). At the time of S3505, the contents of the input/output item definitions for each action have not yet been inserted (they will be inserted in the processing of S3506 to S3512, described below). Furthermore, the character string (action source code) written in JavaScript (a programming language) on the action board is not recorded. In other words, the generated client UI definition information 3615 includes the action identifier and information defining the input and output items for each action, but does not include information indicating the operation of the action.

In S3506, the development environment 300 extracts the action description portion 3412 from the UI definition information 3411. This process extracts not only descriptions related to specific actions, but also descriptions related to all actions.

In S3507, the development environment 300 searches for the string "$UI" from the beginning of the action description portion extracted in S3506.

In S3508, the development environment 300 determines whether the string "$ui" was found as a result of the search in S3337. If "$ui" was found, proceed to S3509; if not, end processing. S3508 returns No if all "$ui" searches have been completed or if there was no "$ui" at all in the action description section.

In S3509, the development environment 300 determines whether the character string "$ui" found in S3508 is on the left side of a sentence containing that character, similar to S3339 in FIG. 33(c). If "$ui" is on the left side, the process proceeds to S3510; if not, the process proceeds to S3511.

In S3510, the development environment 300 records information based on the element string of a predetermined structure beginning with "$ui" ($ui.UI component ID.target information type) found in S3338 as an output item in the client UI definition information 3615 generated in S3505. More specifically, in the array defining the output items in the client UI definition information 3615, the UI component ID is obtained from the element string of a predetermined structure beginning with "$ui" ($ui.UI component ID.target information type) found in S3338, and recorded in the "uiItemsOut" array in the input/output item definition for each action. For example, if "$ui", indicating that the UI component ID is "RESULT", is found on the left side, it is recorded as shown in FIG. 36.

In S3511, similar to S3341 in FIG. 33(c), the development environment 300 determines whether the "$ui" character string found in S3508 is found anywhere other than on the left side of the sentence containing the character. If it is found anywhere other than on the left side, the process proceeds to S3512; otherwise, the process proceeds to S3507. Note that if the determination in S3509 is No, this is equivalent to the "$ui" character string being found anywhere other than on the left side of the sentence containing the character, and therefore the process may proceed to S3512 without making the determination in S3511.

In S3512, the development environment 300 records information based on the element string of a predetermined structure beginning with "$ui" ($ui.UI component ID.target information type) found in S3338 as an input item in the client UI definition information 3615 generated in S3505. More specifically, in the array defining the input items in the client UI definition information 3615, the UI component ID is obtained from the element string of a predetermined structure beginning with "$ui" ($ui.UI component ID.target information type) found in S3338, and recorded in the "uiItemsIn" array in the input/output item definition for each action. For example, if "$ui", indicating that the UI component ID is "INPUT_1", is found on the right side, it is recorded as shown in FIG. 36. Also, for example, if "$ui", indicating that the UI part ID is "INPUT_2", is found in a sentence without "=", it will be recorded as shown in Figure 36.

After completing processing of S3512, the process proceeds to S3507, where the string "$ui" is further searched for in the continuation of the description extracted in S3506, and processing of S3507 to S3512 is repeated until it is determined in S3508 that "$ui" is not present. In other words, processing of S3509 to S3512 is performed for all $ui strings contained in the description extracted in S3506, and whether they are input items or output items is recorded in the client UI definition information 3615.

Figure 35 (b) shows a flowchart of a modified example of the application execution process in the execution environment 400. This process is executed by the execution engine of the execution environment 400 when an application that has been deployed (constructed, generated) is accessed from the application user terminal 200 or 201.

Figure 33(c) shows a flowchart of a modified example of application execution processing in application user terminal 200 or 201. This processing is executed by CPU 101 of application user terminal 200 or 201 when an application that has been deployed (constructed, generated) in execution environment 400 is accessed using the browser software on application user terminal 200 or 201. The application execution processing in execution environment 400 in Figure 35(b) and the application execution processing in application user terminal 200 or 201 in Figure 35(c) are performed in conjunction with each other. Below, the processing by application user terminal 200 or 201 will be described assuming that it is executed by application user terminal 200 as a representative (the description of application user terminal 201 is similar and will be omitted).

In S3521 of FIG. 35(b), the execution environment 400 determines whether a request to obtain UI definition information has been received from the application user terminal 200. The request to obtain UI definition information received here is the request sent from the application user terminal 200 in S3543 of FIG. 35(c). If a request to obtain UI definition information has been received, the execution environment 400 proceeds to S3522; if not, the execution environment 400 waits in S3521.

In S3522, the execution environment 400 sends client UI definition information 3615 to the execution environment 400 without sending UI definition information 3411 to the application user terminal 200. As a result, as shown in FIG. 36, client UI definition information 3625 recorded in the execution environment 400 is downloaded to the application user terminal 200 and recorded as client UI definition information 3635. The client UI definition information 3615 and the client UI definition information 3635 are the same information.

The processing of S3523 to S3530 is similar to S3313 to S3320 in Figure 33(b) described above, and therefore will not be described here.

Steps S3541 to S3543 in Figure 35(c) are similar to steps S3331 to S3333 in Figure 33(c) described above, and therefore will not be described here. However, in step S3543, a request to obtain client UI definition information is sent.

In S3544, the application user terminal 200 determines whether client UI definition information has been received from the execution environment 400. The client UI definition information received here is the information sent from the execution environment 400 in S3522 of FIG. 35(b) described above. If client UI definition information has been received, the application user terminal 200 records the client UI definition information in memory 102 and proceeds to S3545; otherwise, the application user terminal 200 waits for reception of client UI definition information in S3544. The client UI definition information is recorded as temporary information in memory 102 (work memory) and is automatically deleted when the application is terminated (when the connection to the application's URL is terminated). The application user terminal 200 also displays the application screen on the display 105 based on the client UI definition information 3635 recorded in memory 102.

In S3545, the application user terminal 200 determines whether an action trigger has occurred, similar to S3335 in FIG. 33(c) described above. If an action trigger has occurred, the process proceeds to S3546; if not, the process proceeds to S3553.

The processing of S3546 to S3553 is similar to the processing of S3343 to S3350 in FIG. 33(c) described above, respectively, and therefore will not be described again. In this modified example, the processing corresponding to S3336 to S3342 in FIG. 33(c) described above is not performed by the application user terminal 200.

The various controls described in each of the above flowcharts may be performed by a single piece of hardware, or the entire device may be controlled by multiple pieces of hardware (e.g., multiple processors or circuits) sharing the processing.
Furthermore, although the present invention has been described in detail based on its preferred embodiments, the present invention is not limited to these specific embodiments, and various forms within the scope of the gist of the present invention are also included in the present invention. Furthermore, each of the above-described embodiments merely represents one embodiment of the present invention, and each embodiment can be combined as appropriate.

(Other embodiments)
The present invention can also be realized by executing the following process. That is, software (programs) that realize the functions of the above-described embodiments are supplied to a system or device via a network or various storage media, and the computer (or CPU, MPU, etc.) of the system or device reads and executes the program code. In this case, the program and the storage media storing the program constitute the present invention.

<Multiple Perspectives>
As described in the above embodiment, the information processing system of this embodiment includes the following configuration. This embodiment also shows a control method for the information processing system having steps executed by each means of the following configuration. This embodiment can also be realized by a program that causes at least one computer to function as each means of the following configuration.

[Configuration 1-1]
a receiving means for receiving an input operation from a user on a setting screen for creating a creation function, the input operation being different from an input written by the user in a programming language;
a setting means for setting information about the creation function based on the input operation received by the receiving means;
a control means for, when acquiring a character string written in a programming language and including identification information of the created function, performing control to enable execution of a function indicated by the character string including a function of the created function based on the information set by the setting means;
An information processing system comprising:

[Configuration 1-2]
a setting means for setting information about the created function based on an input operation from the user on a setting screen for creating the created function, the input operation being different from an input written by the user in a programming language;
a display control means for controlling the display of options for the identification information of the created function when a character string that partially matches the identification information of the created function is entered in a description area of a programming language;
An information processing system comprising:

[Configuration 1-3]
a setting means for setting information about the created function based on an input operation from the user on a setting screen for creating the created function, the input operation being different from an input written by the user in a programming language;
a display control means for controlling the display of the identification information of the created function set by the setting means together with a description area of the programming language;
An information processing system comprising:

[Configuration 2]
a display control means for controlling, in response to an operation on a designated area (tab) of a first-type component arranged on a development screen of an application, to switch the display of at least a part of an area of the first-type component to an element screen corresponding to the operated designated area;
and control means for controlling, when an operation to place another component in an area of the first type component placed on the development screen is performed, to place the other component on a currently displayed element screen out of a plurality of element screens of the first type component.

[Configuration 3]
a placement means for placing a first component of a first type on a development screen of the application;
and a display control means for controlling the display of default setting values in the input area for setting values of the first component arranged by the arrangement means in a form that allows the structure to be identified when written in a programming language.

[Configuration 4]
An information processing system including a first type of environment (development environment) and a second type of environment (execution environment),
an acquisition means for acquiring access destination information in the specific environment from a specific area of a specific environment that is the second type of environment and that is accessible to a user connected to the first type of environment;
An information processing system characterized by having a transmission control means for controlling the transmission of a request to execute a predetermined process (e.g., a process for transmitting user information) to the access destination indicated by the access destination information acquired by the acquisition means.

[Configuration 5]
An information processing system including a first type of environment (development environment) and a second type of environment (execution environment),
an authentication means for performing user authentication to determine whether a user is permitted to access the first type environment;
an acquisition means for acquiring environment specification information that specifies the second type of environment that can be accessed by a user who has been authenticated by the authentication means as being able to access the first type of environment; and (acquisition of an accessible execution environment list).
a control means for controlling access to the environment identified by the environment identification information without acquiring authentication information related to the second type of environment from a user, based on the environment identification information acquired by the acquisition means;
An information processing system comprising:

[Configuration 6]
a display control means for controlling the display of an input area for inputting an action when a component to be arranged on a screen displayed by the application software to be built is operated, as a development screen in a client terminal for building the application software;
a recording control means for controlling recording of definition information of the application software including information on the action input in the input area;
a first control means for controlling generation of first information defining an action to be executed in the execution environment of the application software based on the definition information;
a second control means for controlling a terminal device that accesses the execution environment when executing the application software to generate second information used by the terminal device based on the definition information;
An information processing system comprising:

[Configuration 7]
A receiving means for receiving a selection of a table (data grid);
a display control means for controlling the display of a setting screen (property box) for the selected table;
Controlling to add a column to the table in response to a first operation on the setting screen;
and control means for controlling the setting of each column of the table in response to a second operation on the setting screen.

[Configuration 8]
Accepting means for accepting a table selection;
a display control means for controlling the display of a plurality of options corresponding to each of the columns included in the selected table on an action input screen;
and a control means for controlling, in response to a selection of one of the plurality of options, to display an input screen for an action in the column corresponding to the selected option and to accept an input operation for the action from the user.

[Configuration 9]
an acquisition means for acquiring a character string input into an input field of a programming language;
a specifying means for specifying, based on an element string to which a specific identifier is assigned, among the character strings acquired by the acquiring means, that the element string is information of either an input item which is information to be acquired as input, or an output item which is information to be output;
a control means for controlling execution of a program based on the character string, reflecting the content identified by the identification means;
An information processing system comprising:

[Configuration 10]
a control means for defining an action on a screen of application software to be constructed based on a group of operations including an operation of selecting from options and not including an operation of writing source code in a programming language, or for controlling the placement of automatically generated components with actions defined as components to be displayed on the screen of the application software to be constructed (for example, placement of a button with an action defined by workflow generation, a UI screen with an action defined on a canvas, placement of a button by CRUD button placement, generation of a UI screen, etc.);
a display control means for controlling the display of the action defined for the selected object as a character string in a programming language in response to a selection by the control means of either the screen on which the action is defined or the automatically generated component and an instruction to display the action;
a receiving means for receiving a modification operation of the character string in a programming language that represents an action and that is displayed by the display control means;
An information processing system comprising:

[Configuration 11]
a receiving means for receiving an operation for defining an application;
an instruction means for issuing an instruction to deploy the application in an environment on a network based on definition information defined based on the operation accepted by the accepting means;
a display control means for controlling, in response to completion of deployment of the application in response to an instruction from the instruction means, to display access destination information indicating the location where the application has been deployed, which is an address for executing the application;
An information processing system comprising:

[Configuration 12]
a display control means for controlling display of a layout editing screen for the authentication screen, on which template components for which predetermined actions are defined are pre-arranged, as a template for the authentication screen for user authentication in the application to be constructed;
a receiving means for receiving at least one of an editing operation for arranging a component different from the template component on the layout editing screen and an editing operation for changing a display form of the template component on the layout editing screen;
a control means for controlling recording of definition information for constructing an application in which the authentication screen reflecting the editing operation accepted by the accepting means is displayed;
An information processing system comprising:

[Configuration 13]
A receiving means for receiving an instruction to register a new account in the multi-tenant environment;
When the receiving means receives an instruction to register a new account,
If the number of active accounts registered in the multi-tenant environment has not reached a certain threshold, the new account connects to the first database environment;
- a control means for controlling a new account to be connected to a second database environment different from the first database environment when the number of valid accounts registered in the multi-tenant environment exceeds the specific threshold;
An information processing system comprising:

The invention is not limited to the above-described embodiments, and various modifications and variations are possible without departing from the spirit and scope of the invention. Therefore, the following claims are appended to clarify the scope of the invention.

100: Developer device, 200: App user device, 201: App user device 201, 300: Development environment, 400: Execution environment

Claims (12)

An information processing system including a terminal device,
The information processing system includes:
a display control means for controlling the display of an input area for inputting an action when a component to be arranged on a screen displayed by the application to be constructed is operated as a development screen for constructing the application;
a recording control means for controlling recording of definition information of the application including information on the action input in the input area;
a first control means for controlling generation of first information defining an action to be executed in the execution environment of the application based on the definition information;
a second control means for controlling a terminal device that accesses the execution environment when executing the application to generate second information used by the terminal device based on the definition information;
and
The second control means
generating the second information defining whether a component to be placed on a screen displayed by an application is an input item into which a value to be transmitted to the runtime environment is input or an output item into which a value transmitted from the runtime environment is to be displayed, based on information about the action among the definition information transmitted from the runtime environment;
The terminal device
a third control means for controlling, based on the second information, when the constructed application is executed, to transmit a value input via a screen of the application to the execution environment if the component is the input item, and/or to display a value received from the execution environment on the screen of the application if the component is the output item.
An information processing system comprising: the information processing system includes the execution environment ,
The information processing system according to claim 1, characterized in that the execution environment has a fourth control means for controlling, when executing the constructed application, the execution environment to execute an action corresponding to the operation performed on the terminal device based on the operation and the first information, and to send information regarding the results of the executed action to the terminal device. 2. The information processing apparatus according to claim 1, wherein the first information is a program. 2. The information processing system according to claim 1, wherein the first control means controls to generate the first information based on information about the action included in the definition information. the information processing system includes the terminal device,
2. The information processing system according to claim 1, wherein at least one of the terminal device, the development environment, and the execution environment has the second control means. the information processing system includes at least one of a development environment and the execution environment;
2. The information processing system according to claim 1, wherein at least one of the terminal device, the development environment, and the execution environment has the second control means. The second information is
2. The information processing system according to claim 1, wherein the information processing system does not include information indicating the operation content of the action. the second information generated by the second control means is transmitted to the terminal device, and information indicating the operation content of the action is not transmitted to the terminal device;
The information processing system described in claim 1, characterized in that when the constructed application is executed, the terminal device controls the transmission of values entered via the application screen to the execution environment based on the second information, and/or the display of values received from the execution environment on the application screen. The system further comprises a definition means for controlling the definition of components to be arranged on a screen displayed by the application to be constructed based on a user operation on the development screen,
2. The information processing system according to claim 1, wherein the definition information also includes definitions of components defined by the definition means. The display control means
The information processing system according to claim 1, characterized in that the input area for inputting an action to be taken when a specified component is operated is displayed based on an operation for specifying a component placed based on a user operation on the development screen. A control method for an information processing system including a terminal device, comprising:
a display control step in which a display control means of the information processing system controls to display, as a development screen for building an application, an input area for inputting an action when a component to be arranged on a screen displayed in the application to be built is operated;
a recording control step of controlling a recording control means of the information processing system to record definition information of the application including information on the action input in the input area;
a first control step of controlling a first control means of the information processing system to generate first information defining an action to be executed in the execution environment of the application based on the definition information;
a second control step in which a second control means of the information processing system controls to generate second information used by a terminal device that accesses the execution environment when executing the application based on the definition information;
and
The second control means of the information processing system
generating the second information defining whether a component to be placed on a screen displayed by an application is an input item into which a value to be transmitted to the runtime environment is input or an output item into which a value transmitted from the runtime environment is to be displayed, based on information about the action among the definition information transmitted from the runtime environment;
a third control means of the terminal device,
a third control step of controlling, based on the second information, when the constructed application is executed, to transmit a value input via a screen of the application to the execution environment if the component is the input item, and/or to display a value received from the execution environment on the screen of the application if the component is the output item.
1. A method for controlling an information processing system, comprising: A program for causing at least one computer to function as each means of the information processing system according to any one of claims 1 to 10 .