Information processing system, control method for information processing system, and program

Abstract

To facilitate settings for an input item or / and output item for use in a logic which is input in a programming language.SOLUTION: An information processing system includes: acquisition means which acquires character strings input in an input region in a programming language; specifying means which specifies that an element character string is information on an input item which is information to be acquired as an input or information on an output item which is information to be output, out of the character strings acquired by the acquisition means, on the basis of the element character string with a specific identifier; and control means which controls a program based on the character string to be executed while reflecting the content specified by the specifying means.SELECTED DRAWING: Figure 33

Description

[Technical Field]

[0001] The present invention relates to an information processing system, a control method for an information processing system, and a program, and in particular to a technique suitable for use in software development. [Background technology]

[0002] Conventionally, there are application building tools that build application software (hereinafter referred to as applications) according to a definition, as no-code development tools / low-code development tools that do not require or require little coding in a programming language.

[0003] Patent Document 1 discloses that application developers can input input binding settings and output binding settings by entering input that describes a bind data definition that matches item codes with variable names in the bind data definition setting section of the bind data setting screen for each input / output. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2022-110184 Summary of the Invention [Problem to be solved by the invention]

[0005] In Patent Document 1, input items (items from which information to be received as input is obtained) and output items (items from which information to be output on the screen is output) are set on a bind data setting screen, separate from the area where the content of the action is entered in a programming language. Therefore, it is not possible to define the input and output items at any desired location in the character string describing the action logic in a programming language. As a result, it is not possible to define the input and output items used in the logic near the logic description section, making it difficult to easily set the input and output items used in the logic when writing the logic. Furthermore, passing values ​​between the bind data setting screen and the action logic description section requires defining them as variables. This requires developers to manage variables in a complex manner, which is one of the causes of errors when writing actions.

[0006] In view of the above problems, the present invention aims to provide a mechanism that makes it easier to set input items and / or output items used in logic entered in a programming language. [Means for solving the problem]

[0007] The information processing system of the present invention comprises: 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; The present invention is characterized by having the following. [Effects of the Invention]

[0008] According to the present invention, input items and / or output items used in logic input in a programming language can be set more easily. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a system configuration diagram of an information processing system. [Figure 2] FIG. 2 is a hardware block diagram of a developer terminal 100, an application user terminal 200, and an application user terminal 201. [Figure 3] 10 is a flowchart of a login process. [Figure 4] 10 is a flowchart of a UI editor process. [Figure 5] This is a display example for login processing and UI editor processing. [Figure 6] This is an example of how tab components and AppBars are displayed in UI editor processing. [Figure 7] 10 is a flowchart of a context menu process. [Figure 8] 10 is a flowchart of an action board process. [Figure 9] 10 is a display example for explaining an action board process. [Figure 10] 10 is a display example in action board processing. [Figure 11] 10 is an example of source code generated by the development environment 300. [Figure 12] 10 is a flowchart of a screen switching process. [Figure 13] 10 is a flowchart of the processes executed in the developer terminal 100, the development environment 300, and the execution environment 400, respectively, relating to the display of user information for an application. [Figure 14] (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. [Figure 15] 10 is an example of user information display. [Figure 16] 10 is a flowchart of a workflow process. [Figure 17]10 is a display example relating to workflow processing. [Figure 18] This is an example of a display of a database, UI widgets, and actions generated by workflow processing. [Figure 19] 10 is a flowchart of a canvas context menu process. [Figure 20] 10 is a display example relating to CRUD generation processing. [Figure 21] This is an example of the database, actions, and functions generated by the CRUD generation process. [Figure 22] 10 is a flowchart of a developer account registration process. [Figure 23] Details of the DB set in the execution environment. [Figure 24] 10 is a flowchart of a deployment process. [Figure 25] This is a display example when deploying a mobile app. [Figure 26] 10 is a display example of a UI editor screen relating to a template screen. [Figure 27] 10 is a display example on the canvas of the template screen. [Figure 28] This is an example of how a property box is displayed. [Figure 29] 10 is a display example of an action board in which an action has been input. [Figure 30] 10 is a flowchart of a data grid context menu process. [Figure 31] This is an example of the display in the property box of a data grid. [Figure 32] This is an example of a display on the action board of a data grid. [Figure 33] 10 is a flowchart illustrating the execution of an action. [Figure 34] FIG. 10 is a transition diagram of UI definition information including action information. [Figure 35] 10 is a flowchart illustrating the execution of an action in a modified example. [Figure 36]FIG. 10 is a transition diagram of UI definition information including action information in a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the invention as claimed, 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 arbitrarily combined. Furthermore, the same reference numerals are used for the same or similar components, and redundant explanations will be omitted.

[0011] The various features shown in the following embodiments can be combined with each other. In the following, the terms "application" and "app" both refer to application software.

[0012] <System configuration> A system configuration diagram of an information processing system according to an embodiment of the present invention is shown in Fig. 1. Fig. 1 shows a system for developing software and a system for using the developed software.

[0013] The developer terminal 100 is an information processing device (information processing terminal) operated by a developer user that can be configured as a personal computer (hereinafter referred to as PC) or a smartphone. In other words, it is a 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.

[0014] The development environment 300 is an environment that uses at least one hardware resource built on a network (on the cloud or 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).

[0015] The developer information 301 is information that records the developer's account that can log in to the development environment 300, such as an email address (user ID) that serves as the developer's account ID, a password, etc. The developer information 301 is recorded on at least one recording medium included in the development environment 300. Details of the developer information 301 will be described later with reference to FIG. 14(a).

[0016] The execution engine 302 is at least one hardware resource for executing processing to be executed in the development environment 300, and includes a processor 303 and a memory 304. The processor 303 is composed of at least one processor, and may be a single processor on the cloud, or a processor group combining multiple processors. The memory 304 is at least one recording medium on which a program to be executed by the processor 303 is recorded. Of the various flowcharts described below, those that are described as being executed by the development environment 300 are executed by the execution engine 302. In other words, the processor 303 deploys the program recorded in the memory 304 into an area of ​​the development environment 300 that serves as a work memory, and executes it.

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

[0018] Storage 320 is a storage area of ​​at least one recording medium, and stores at least 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 developer A area 323, which is an area for developer A, developer B area 324, which is an area for developer B, and developer C area 325, which is an area for developer C. Each developer area stores definition information for the app developed by that developer. For example, developer A area 323 stores app definition 323a (including app UI definition information and an app execution environment program, which will be described later in FIG. 34).

[0019] A developer accesses the development environment 300 by accessing a URL for accessing the development environment 300 from the browser software of the developer terminal 100, and logs in to the development environment. After logging in to the development environment, the developer receives the client program 322 and the application definition (UI definition information) that is the content of previous development work and saved from the development environment. 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 application definition information (application definition, UI definition information) to the development environment 300. The development environment 300 stores the received application 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, a developer can develop an application regardless of location.

[0020] 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, and 470). Execution environment 400 is built by combining multiple web services (cloud services). Execution environment 400 is an environment for deploying application definition information (application 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 application user. Applications built in execution environment 400 on a network are so-called web applications.

[0021] The multi-tenant execution environment 410 is a multi-tenant execution environment shared by multiple developers, and is where applications developed by multiple developers are deployed. In other words, it is an environment shared by multiple developers, and is an environment where 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.

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

[0023] The execution engine 412 is at least one hardware resource for executing processing to be executed in the multitenant execution environment 410, and includes a processor 413 and a memory 414. The processor 413 is composed 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 a program to be executed by the processor 413 is recorded. Of the various flowcharts described below, those described as being executed by the multitenant execution environment 410 are executed by the execution engine 412. In other words, this is realized by the processor 413 expanding and executing the program recorded in the memory 414 in an area that serves as a work memory in the multitenant execution environment 410. The program executed here includes a program that executes the action of an application.

[0024] 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 storage 420 included in the execution environment 410.

[0025] The 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. Furthermore, access destination information 421 for accessing the execution environment (multi-tenant execution environment 410) is recorded in a predetermined area of ​​the storage 420 (a predetermined folder, a predetermined bucket, or a predetermined level below). The storage 420 also has developer areas, which are storage areas for each developer account. For example, the storage 420 includes a developer A area 423 for developer A, a developer B area 424 for developer B, and a developer C area 425 for developer C. Each developer area stores definition information for an app developed by the developer and deployed from the development environment 300. For example, the developer A area 423 stores application definition 423a.

[0026] The DB set 430 is a group of information relating to databases used by applications deployed in the execution environment 410. The DB set 430 is stored in a storage area of ​​at least one recording medium. Details of the DB set 430 will be described later with reference to FIG. 23.

[0027] 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 developer (owner) 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) 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, respectively. Apart from the fact that these are dedicated to one developer, they have the same functions as the user information 411, execution engine 412, delivery 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.

[0028] Using the system of FIG. 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 must 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 bear the maintenance costs of the multi-tenant execution environment 410 and provide it free of charge to multiple developers, developers do 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 recovers costs by charging developers for the single-tenant execution environments.

[0029] There is a limit to the number of processing requests that can be processed per unit time in a single execution environment, and if many applications are built in a multi-tenant execution environment and many app users access the environment 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 the applications from demonstrating sufficient performance. Developers can avoid (or reduce) 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.

[0030] 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, developers can build and test an application developed using the system in the multi-tenant execution environment 410. After determining that the system is useful for their software development, developers can purchase a single-tenant execution environment for a fee. Furthermore, when developing a specific application X, developers 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. The developer tests application X there, makes corrections, and further develops it. Then, once development is complete to a level where it can be released to general users without any problems, the developer builds a production version of application X in the single-tenant execution environment and releases it to general users. Using the system in this way allows developers to reduce development costs during the development period and operate applications without any problems even when used by a large number of general users.

[0031] 2 shows a hardware block diagram of an information processing device as an example of a device (electronic device) applicable as developer terminal 100, application user terminal 200, and application user terminal 201. In Fig. 2, CPU 101, memory 102, nonvolatile 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. The components connected to internal bus 150 are able to exchange data with each other via internal bus 150.

[0032] The memory 102 is, for example, a RAM (a volatile memory using semiconductor elements, etc.). The CPU 101 controls each unit of the information processing device using the memory 102 as a work memory in accordance with a program stored in, for example, the nonvolatile memory 103. The nonvolatile memory 103 stores image data, audio data, other data, various programs for the operation of the CPU 101, etc. The nonvolatile memory 103 is, for example, formed from a hard disk (HD) or a ROM.

[0033] Under the control of the CPU 101, the image processing unit 104 performs various image processing on image data stored in the nonvolatile memory 103 or the 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.

[0034] Display 105 displays images, GUI screens constituting a GUI (Graphical User Interface), and the like under the control of CPU 101. CPU 101 generates display control signals in accordance with a program, and controls each unit of the information processing device to generate video signals for display on display 105 and output them to display 105. Display 105 displays video based on the output video signals. Note that the information processing device itself may only include 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 is assumed to be the display 105 of each operator.

[0035] The operation unit 106 is an input device for receiving user operations, including a character information input device such as a keyboard, a pointing device such as a mouse or a touch panel, a button, a dial, a joystick, a touch sensor, a touch pad, etc. The touch panel is an input device that is configured as a plane overlaid on the display 105 and outputs coordinate information according to the position of contact.

[0036] 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 for connecting to an external device via a wired cable or wirelessly, and for inputting and outputting video and audio signals. The communication I / F 110 is an interface for communicating with external devices, the Internet 111, and the like, and for sending and receiving various data such as files and commands. The developer terminal 100 can communicate with (send and receive information from) a 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) an execution environment 400 on the Internet 111 using the communication I / F 110.

[0037] <Login process> FIGS. 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 being executed by the developer terminal 100 will be understood to mean 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.

[0038] When the developer terminal 100 starts up 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.

[0039] In S301, the developer terminal 100 determines whether or not 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.

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

[0041] 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).

[0042] In S304, the developer terminal 100 accepts input operations into the input fields of the login screen for the developer ID and password. The user's input operations are performed using the operation unit 106. The developer ID is user identification information for identifying (specifying) 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 information is assumed to be an arbitrary character string, but it may also be other secret information 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).

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

[0044] In S306, the developer terminal 100 performs developer account registration processing. Details of the developer account registration processing will be described later with reference to FIG.

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

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

[0047] In S309, the developer terminal 100 determines whether or not it has received information indicating a login error from the development environment 300. 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.

[0048] In S310, the developer terminal 100 determines whether or not it has received an execution environment list from the development environment 300. If the 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 the login authentication was successful (login was successful). If the execution environment list has been received, the process proceeds to S311; if not, the process returns to S309.

[0049] In S311, the developer terminal 100 records the execution environment list received in S310 in memory 102 as a development screen for the application after login, and displays execution environment options based on the received execution environment list on display 105. 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 application after construction are collectively referred to as development screens.

[0050] FIG. 5(a) shows an example of the display of execution environment options in S311. In the display example of FIG. 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 can confirm the selection by pressing the SAVE button 553. The selection made here is the destination to which the application updated in the subsequent work during this login will be deployed. At this point, the execution environment is not accessed. Furthermore, the execution environment selected here can be changed by the operation described below.

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

[0052] In S313, the developer terminal 100 records information (such as an execution environment ID) that identifies the execution environment selected in S312 in memory 102 as the "selected execution environment," and transmits the information to the development environment 300. In response to receiving the information that identifies the selected execution environment (selected environment), the development environment 300 transmits, as application information, information (such as application IDs and application names) that identifies all applications owned by the logged-in developer (applications that were previously generated and recorded in storage 320).

[0053] In S314, the developer terminal 100 determines whether or not application information has been received from the development environment 300. If application information has been received, the process proceeds to S315; if not, the developer terminal 100 waits in S314 for the application information to be received.

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

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

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

[0057] In S318, the developer terminal 100 determines whether definition information (UI definition information) of the selected application has been received from the development environment 300. If definition information of the selected application has been received, the developer terminal 100 stores the received definition information of the selected application in memory 102 and proceeds to S319. If not, the developer terminal 100 waits for reception of definition information in S318. In this embodiment, this definition information is a JSON file in which various definitions related to the application are written in JSON format. Thereafter, when the selected application is displayed on the display 105, the display is based on the definition information stored in memory 102. When an operation to update the selected application (e.g., changing the layout of UI widgets) is performed, such as in a UI editor process (described later), the definition information in memory 102 is updated to define the updated content. Then, when a save instruction is received, the latest definition information stored in memory 102 is sent to the development environment 300 and stored 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.

[0058] In S319, the developer terminal 100 displays a UI editor screen on the display 105 and performs display based on the received definition information. For example, a canvas (editing area of ​​the UI screen) with a shape corresponding to whether the selected application is for desktop or mobile use (i.e., a shape corresponding to the type of device on which the application 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 application is displayed in the submenu area (described later). (Strictly speaking, this process is performed in S401 of FIG. 4, described later). The canvas also displays components (UI widgets to be placed on the UI screen) that will be 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 FIG. 4.

[0059] Meanwhile, 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 applications has been pressed, and whether a command to create a new application has been issued. 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.

[0060] In S321, the developer terminal 100 displays a selection screen for whether the newly created application is for desktop use (for PC) or for mobile use, and accepts an operation to select one of them. 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.

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

[0062] 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 corresponding 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 process then proceeds to S401 in FIG. 4.

[0063] 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 a program recorded in memory 304 into an area of ​​the development environment 300 that serves as work memory, and executing the program. Hereinafter, what is simply described as a process executed by the development environment 300 will be understood to mean a process executed by the execution engine 302 of the development environment 300, or more specifically, by the processor 303.

[0064] In S331, the development environment 300 determines whether or not the login information transmitted in S308 from the developer terminal 100 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.

[0065] 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 pair contained in the received login information. If so, authentication is successful.

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

[0067] In S335, the development environment 300 transmits to the developer terminal 100 a list of execution environments of developers (login developers) whose login has been approved and that are included in the developer information 301. As shown in FIG. 14(a), the developer information 301 records, for each developer, an accessible execution environment ID 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. In the case of a developer 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 login developer are transmitted to the developer terminal 100. That is, in S335, the developer information 301 is referenced to identify the execution environments that the login developer can access. In this way, the accessible execution environments of each developer (the execution environments that each developer can use) are recorded in the developer information 301 recorded in the development environment 300. Only developers who have been granted permission to log in can obtain this runtime environment that can be logged in. Furthermore, only developers who have been granted permission to log in can obtain their own accessible runtime environment. This eliminates the need for developers to manage information for accessing their own accessible runtime environment separately from information for logging in to the development environment 300. It also prevents other users from accessing the runtime environment illegally.

[0068] In S336, the development environment 300 determines whether or not it has received information (environment identification information) identifying the selected execution environment that was sent in S313 from the developer terminal 100. 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.

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

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

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

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

[0073] In S341, the development environment 300 determines whether it has received information identifying the selected app transmitted from the developer terminal 100 in S317. If it has received the information identifying the selected app, it proceeds to S342; otherwise, it returns to S339.

[0074] In S342, based on the information identifying the selected app received in S341, the development environment 300 acquires the definition information (app definition) of the selected app from the area of the logged-in developer in the storage 320 and transmits it to the developer terminal 100. The definition information transmitted here includes detailed definition information regarding the selected app (such as the arrangement of components and information indicating actions described later). Then, the login process is terminated.

[0075] <UI Editor Process> The UI editor process will be described using FIGS. 4 and 5(b). The UI editor process is a process for performing various definitions (UI component definitions, action definitions) of the application to be constructed in response to operations from the developer (user) on the UI editor screen (application development screen).

[0076] FIG. 5(b) shows an example display of the layout editing screen displayed in the UI editor process on the display 105. The screen in FIG. 5(b) includes a header menu area 500, a main menu area 510, a sub-menu area 520, and a canvas 530 (the editing reception area for the UI screen).

[0077] In the header menu area 500, 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 are displayed.

[0078] The selected execution environment box 501 displays the selected execution environment ID as information indicating the selected execution environment. Pressing the arrow icon on the right end of the selected execution environment box 501 displays a pull-down menu listing execution environments accessible to the logged-in developer obtained in S310, 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.

[0079] The selected app box 502 displays the name of the selected app as information representing the selected app. Pressing the arrow icon on the right end of the selected app box 502 displays a pull-down menu listing the apps owned by the logged-in developer acquired in S314, 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.

[0080] 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 acquired in S318, and by selecting any UI screen from the list, it is possible to change the UI screen to be edited and displayed on the canvas 530.

[0081] In the main menu area 510, as selection icons for menu items of the main menu, an application 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 are displayed. Processing in response to pressing of these selections will be described later in the screen switching processing of FIG. 12.

[0082] A submenu corresponding to an item selected in the main menu is displayed in the submenu area 520. In the example of Fig. 5(b), a UI component list (UI widget list) is displayed as a lower-level menu of the UI screen button 512.

[0083] The canvas 530 is a layout editing area for the selected UI screen of the selected application (the UI screen whose UI screen name is displayed in the selected UI screen box 503). The canvas 530 in FIG. 5(b) is an example of a canvas display for a desktop application, displayed in a desktop format. The user can select any UI widget (UI component) from the list of UI widgets displayed in the submenu area 520 and place it in the canvas area 530 by dragging and dropping it. The user can select a UI widget placed in the canvas area 530 and adjust its size and position. In addition, by selecting a UI widget placed 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 an action to be executed when the UI widget is operated. The canvas context menu can be displayed by right-clicking with the cursor in a blank area of ​​the canvas 530. By selecting an action from the context menu, the user can set an action to be executed when the UI screen of that canvas is loaded in the constructed application (to be executed when the UI screen is displayed).

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

[0085] A flowchart of the UI editor process is shown in Fig. 4. This process is executed by the developer terminal 100, and is performed following S319 or S323 in Fig. 3.

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

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

[0088] In S403, it is determined whether or not an operation has been performed to select one of the options displayed in the main menu area 510. If an option displayed in the main menu area 510 has been selected, the UI editor process ends and the process proceeds to screen switching process 112, which will be described later. If not, the process returns to S402.

[0089] 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 application recorded in memory 102. If the UI screen has UI widgets previously placed on it, the UI widgets previously placed according to the definition information are displayed on the canvas 530. In other words, if a UI screen was partially created in the past, 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 widgets 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 at a predetermined position on the canvas 530, even if the user has not previously placed UI widgets on that UI screen.

[0090] In S405, the developer terminal 100 displays a list of UI widgets in the submenu area 520. That is, the display switches from the UI screen list of the selected application to the UI widget list. UI widgets that can be arranged on the canvas 530 include types: INPUT, Button, Display (a widget for displaying information), Navigation, Layout, and Chart, and multiple UI widgets are categorized into each type. In the UI widget list, as shown in FIG. 5(c), a list of UI widget types is first displayed. When an operation to select one of the displayed types is performed, UI widgets classified into the selected type are expanded and displayed. The above-mentioned FIG. 5(b) shows an example in which option 522 of the type corresponding to INPUT is selected and a list of UI widgets categorized under INPUT is displayed. UI widgets categorized 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 of the UI widget of the expanded type or options of other types) can be scrolled to display them. When an expanded type option 522 is operated as shown in FIG. 5(b), the expanded list of UI widgets for that type is collapsed, and a list of UI widget types is displayed.

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

[0092] 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 in S407 for specification of a position on the canvas 530. Note that, although an example of drag and drop will be 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.

[0093] 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 FIG. 5(b). A tab component has multiple tabs (in the example of FIG. 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.

[0094] The tab component will be described with reference to FIGS. 6(a) and 6(b). FIG. 6(a) shows an example of a display on the display 105 in which a tab component 601 is placed on a canvas 530 displaying a UI screen different from that shown in FIG. 5(b). The area indicated by an 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 screens, can be changed. The tab component 601 has three tabs: tabs 610, 620, and 630. Each tab displays a label that can be set by the developer in the tab component property settings as the tab name. In the illustrated example, Tab0, Tab1, and Tab2 are displayed, respectively. The number and order of tabs can be changed in the tab component property settings. Tab properties are set by opening the tab property box from the tab context menu in S706 of the context menu processing described later in FIG. 7, and then setting the tab property box (setting screen) that is displayed in response to the operation. The element screen area 602 indicated by the dashed-dotted line (illustrated for the purpose of explanation 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 that tab. Different UI widgets can be arranged on the element screen corresponding to each tab. The example in FIG. 6(a) is an example in which tab 610 is selected and the element screen corresponding to tab 610 is displayed. In the example shown, UI widgets 611 and 612 are arranged on the element screen corresponding to tab 610. The example in FIG. 6(b) is an example of a display in which tab 620 is clicked from the state in FIG. 6(a) and the selected tab is changed from tab 610 to tab 620. In FIG. 6(b), the element screen area 602 displays the element screen corresponding to the selected tab 620. In the example shown, UI widget 621 is arranged on the element screen corresponding to tab 620. In the examples of Figures 6(a) and 6(b), the definition information records at least the UI widget ID (UI widget identification information) of the tab component 601 and the position of the tab component 601 in the UI screen, in association with the ID (UI screen identification information) of the UI screen being edited on the canvas 530.Also, the IDs of UI widgets 611 and 612 and the respective positions of UI widgets 611 and 612 in the element screen of tab 610 are recorded in association with the ID of tab 610 of tab component 601 (identification information of the element screen). Also, the ID of UI widget 621 and the position of UI widget 621 in the element screen of tab 620 are recorded in association with the ID of tab 620 of tab component 601. Returning to the description of FIG. 4.

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

[0096] In S410, the developer terminal 100 places the UI widget selected in S406 from the submenu area 520 in a default size on the element screen (the currently displayed element screen) corresponding to the selected tab among the tab widgets at the specified position on the canvas 530, and records information defining this in the definition information stored in the 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 widget placed in S410, the ID of the tab widget as a UI widget ID, the ID of the selected tab in the tab widget, the placement coordinates in the element screen corresponding to the selected tab, the placement size, and the like. In this way, in this embodiment, it is possible to place and layout different UI widgets on each element screen corresponding to each tab of the tab widget. Furthermore, at this time, there is no need for complicated operations to define the tab of the element screen on which the UI widget is to be placed. Instead, the destination element screen can be selected and displayed when placing the UI widget by dragging and dropping.

[0097] In S411, the developer terminal 100 determines whether a UI widget already placed on the canvas 530 has been selected by clicking, etc. If a placed UI widget has been clicked (selected), the process proceeds to S412, and if not, the process proceeds to S415.

[0098] In S412, the developer terminal 100 displays an operation path for the UI widget clicked in S411. Examples of operation path displays are the above-mentioned operation path 531a and operation path 601a.

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

[0100] In S414, the developer terminal 100 switches the display of the element screen area of ​​the tab component to the element screen corresponding to the tab at the position specified by the click in S411. For example, in response to clicking on one of the three tabs displayed as ITEM1, ITEM2, or ITEM3 among the tab component 536 in S411, an operation path for the tab component 536 is displayed in S412, and the display content of the element screen area 436a is switched to that of the element screen corresponding to the clicked tab. Also, for example, when the display shown in FIG. 6(a) is displayed, the display is switched to that shown in FIG. 6(b) in response to the specification of tab 620. That is, UI components 611 and 612 arranged on the element screen displayed before the click are hidden, and instead, UI component 621 arranged 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 widget on the component screen of a desired tab of a tab component, the developer can simply click the desired tab to display the desired component screen before dragging and dropping the desired UI widget.

[0101] In this embodiment, for the sake of simplicity, the processes of S409, S410, S413, and S414 have been described using a tab widget as an example, but the present invention is not limited to this. The processes of S409, S410, S413, and S414 can be applied to a UI widget other than a tab widget, as long as the UI widget is of a predetermined type in which part of the display content within the UI widget changes in response to an operation on the UI widget after the application is constructed.

[0102] On the other hand, in the case of other UI widgets that are not of a predetermined type, such as tab widgets, the display content of the UI widget is not changed in response to the selection of the UI widget on canvas 530. The only processing performed in response to the selection of a UI widget is processing related to the display of an operation path, and no other actions are performed. For example, when button 532 is selected on canvas 530 in FIG. 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 application) 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 in text field 533 is not performed.

[0103] Using Figures 6(c), 6(d), and 6(e), an example of an AppBar will be described as an example of a type of UI widget to which the processes of S409, S410, S413, and S414 can be applied, similarly to tab widgets. Figure 6(c) shows an example in which UI widgets, an AppBar 650, a TextField 661, and a Button 662, are arranged on a canvas 530. The AppBar 650 is a single UI widget, and includes an element icon 651 and an element icon 652. In a constructed application, the element icon 651 is a display item that accepts an instruction to display a drawer menu. In a constructed application, the element icon 652 is a display item that accepts an instruction to display a pop-up menu. When the positions of the element icons 651 and 652 in the arranged AppBar 650 on the canvas 530 are clicked, the same control is performed as for the tab portion of a tab widget. More specifically, the control is performed as follows.

[0104] When the position of element icon 651 in the arranged AppBar 650 is clicked (Yes in S411), an operation path for AppBar 650 is displayed (S412), and a determination of Yes is made in S413, and a drawer menu is displayed as an element screen (S414). This causes a transition from the display state of FIG. 6(c) to the display state of FIG. 6(d). In FIG. 6(d), an operation path 650a for AppBar 650 is displayed, and a drawer menu 651a, which is an element screen corresponding to element icon 651, is also displayed. Drawer menu 651a is an area that is displayed by being pulled out from the left edge of the screen to the right, and displays one or more menu items. With drawer menu 651a displayed, other UI components can be arranged in drawer menu 651a by dragging another UI component from submenu area 520 and dropping it on drawer menu 651a, similar to the processing described in S408 and S410 using a tab component as an example.

[0105] When the position of element icon 652 in the arranged AppBar 650 is clicked (Yes in S411), an operation path for AppBar 650 is displayed (S412), and a Yes determination is made in S413, and a pop-up menu is displayed as an element screen (S414). This causes a transition from the display state of FIG. 6(c) to the display state of FIG. 6(e). In FIG. 6(e), an operation path 650a for AppBar 650 is displayed, and a pop-up menu 652a, which is an element screen corresponding to element icon 652, is also displayed. Pop-up menu 652a is an area displayed near element icon 652, and displays one or more menu items (options). With pop-up menu 652a displayed, other UI components can be arranged in pop-up menu 652a by dragging another UI component from submenu area 520 and dropping it onto 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.

[0106] In S415, the developer terminal 100 determines whether an operation to drag an already-placed UI widget has been performed on the canvas 530. If an operation to drag an already-placed UI widget 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 widget (selected component) in response to the drag operation. Specifically, it places the UI widget at the dropped position. When the placement is changed, the definition information recorded in memory 102 is also updated to indicate the new position.

[0107] In S417, the developer terminal 100 determines whether or not an operation has been performed on the operation path of a UI widget 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 widget (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 indicate the changed size.

[0108] In S419, the developer terminal 100 determines whether an instruction operation 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; if not, the process proceeds to S421. In S420, a context menu (right-click menu) is displayed according to the position of the mouse cursor when the right-click occurred, 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 (designated UI component) as shown in FIG. 5(d) is displayed. The context menu 540 displays property 541, action 542, and delete 543 as menu items to be selected. When property 541 is selected, a property box (detailed setting dialog) related to button 532 is displayed, allowing detailed settings such as the button name (label) to be displayed on button 532, the color of button 532, and the size specified by a numerical value. When action 542 is selected, an action board related to button 532 is displayed, and an action can be entered into the action board using JavaScript, a programming language. The action entered here is the process to be executed when button 532 (designated UI widget) is pressed in the constructed application. When Delete 543 is selected, button 532 is deleted (deleted) from canvas 530. Details of the context menu process will be described later with reference to FIG. 7.

[0109] In S421, the developer terminal 100 determines whether or not 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 recorded in memory 102, to the development environment 300. Upon receiving the definition information, the development environment 300 performs a save process, which will be described later with reference to FIG. 33(a) or FIG. 35(a).

[0110] In S423, the developer terminal 100 determines whether the preview button 505 has been pressed. If it is determined 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 recorded in the memory 102 or the definition information recorded in the development environment 300, so that the UI screen will look the same as when viewed in the constructed application. The preview does not display the operation path for operating UI widgets. Also, 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 widget for screen transitions or a link is operated, a screen transition or transition to the link destination is performed. Also, operations such as moving the selection frame for an item by operating the tab key on the keyboard are performed. Note that operations such as actions entered by the developer in the action board or database references are not performed. As a result, the preview process can be displayed faster than if you actually deploy and check it.

[0111] In S425, the developer terminal 100 determines whether the deploy button 506 has been pressed. If the deploy button 506 has been 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 with reference to 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 execution environment to which the application will be deployed; the deployment is performed 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 execution environment to which the application will be deployed (S311 in FIG. 3) before selecting the application to be updated, 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 which the development environment is deployed. This prevents an increase in the amount of work required and allows for efficient work. In other words, the developer terminal 100 does not acquire authentication information related to the execution environment to which the development environment is deployed from the developer user.

[0112] 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 indicate 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 an area for logged-in developers in storage 320 based on the information.

[0113] 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 application has been performed in the selected application box 502. If an operation to change the selected application has been performed, the process proceeds to S317 in FIG. 3, and the processing from S317 onwards is executed based on the changed selected application. In other words, the display contents of the submenu area 520 and canvas 530 are updated. If an operation to change the selected application has not been performed, the process proceeds to S430.

[0114] In S430, the developer terminal 100 determines whether or not an operation to change the UI screen to be edited has been performed. Specifically, it determines whether or not 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 content of the changed selected UI screen. If no operation to change the selected UI screen has been performed, the process proceeds to S431.

[0115] In S431, the developer terminal 100 determines whether or not an operation has been performed to select one of the options displayed in the main menu area 510. 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 with reference to Figure 12. If not, the process returns to S406.

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

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

[0118] 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 by the mouse when the right-click was accepted in S419 was a blank area of ​​the canvas 530 where no UI widget was 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.

[0119] In S703, the developer terminal 100 performs canvas context menu processing, which will be described later with reference to FIG.

[0120] In S704, the developer terminal 100 determines whether the context menu to be displayed is related to a UI widget of type data grid (table). More specifically, it determines whether the type of the UI widget (specified UI widget) 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.

[0121] In S705, the developer terminal 100 performs context menu processing of the data grid. The context menu processing of the data grid will be described later with reference to FIG.

[0122] 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 will be omitted.

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

[0124] In S711, the developer terminal 100 displays the button context menu shown in FIG. 5(d) as a context menu related to the specified UI widget, superimposed near the specified position (mouse cursor position).

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

[0126] 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 widget. Various setting operations for the property box are then accepted. Here, detailed settings can be made, for example, such as the button name (label) to be displayed on the button that is the specified UI widget, the button color, and the size specified by a numerical value. When the settings are made and an operation to reflect them is performed, the specified UI widget is displayed on the canvas 530 in a display format that reflects the settings.

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

[0128] In S715, the developer terminal 100 performs action board processing for the button, which is the specified UI widget. The action board processing will be described later with reference to FIG.

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

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

[0131] 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 according to the selected option is performed. If not, the process proceeds to S720.

[0132] In S720, the developer terminal 100 determines whether or not 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 of Fig. 7 ends. If no operation to close the context menu has been performed, the process returns to S712.

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

[0134] 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 process of S723 is the same as S713.

[0135] In S724, the developer terminal 100 determines whether or not 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 of Fig. 7 ends. If no operation to close the context menu has been performed, the process returns to S722.

[0136] <Action Board Processing> The following describes processing related to the action board. When a UI widget placed on the canvas is specified and an action is selected from the context menu, an action board for setting an action related to the specified UI widget is displayed. For example, consider the case where a UI screen such as that shown in FIG. 9(a) is being edited. FIG. 9(a) is a diagram showing a portion of the UI editor screen on the display 105. In FIG. 9(a), a list of UI widgets is displayed in the submenu area 520, and the UI screen to be edited is displayed on the canvas 900. A UI widget 901, which is a button, and other UI widgets are placed on the canvas 900. When the UI widget 901 is specified and an action option is selected from the context menu, an action board such as that shown in FIG. 9(b) is displayed.

[0137] FIG. 9B shows an example of an action board display for UI widget 901. Action board 910 is displayed in place of canvas 900 in the area where canvas 900 was displayed. If the specified UI widget is not a template component pre-placed on the template screen, or if the developer has not previously set an action for the specified UI widget, action board 910 is displayed blank, as shown in FIG. 9B. Note that the "1" displayed on action board 910 is a guide indicating the line number and does not represent the action itself. A developer can set any action on action board 910 by operating the keyboard included in operation unit 106 and entering any character string in JavaScript, a programming language. The trigger for executing the content set on the action board is predetermined and is the operation of the specified UI widget. Therefore, the developer does not need to set the trigger for executing the action (it does not need to be written in JavaScript). For example, if the specified UI widget is a button, pressing the button in the constructed application is the trigger, and the action set in the action board for that button is executed in response to the trigger.

[0138] In addition to the action board 910, a function list 920 is displayed in the submenu area instead of the UI widget list or UI screen list shown in FIG. 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 a developer (user) by pressing an add function button 921 (described later) is referred to as an "created function" (created function, added function, self-created function). If there are no automatically created functions or pre-prepared functions and the developer has not previously created a created function for the specified UI widget, the function list 920 does not display function options, and only the option 922 and the add function button 921 are displayed, as shown in FIG. 9(b).

[0139] When the Add Function button 921 is pressed, a dialog box (referred to as the Add dialog 930) for adding a created function is displayed. An example of the display of the Add dialog 930 is shown in FIG. 9(c). The Add dialog 930 displays a type selection field 931 for accepting selection of the function type (Function Type), a function name input field 932 for accepting input of the function name (Function Name), and a SAVE button 933. When input is made to the Add dialog and the SAVE button 933 is pressed, a function setting 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.

[0140] FIG. 9(d) is an example of a REST function setting screen that is displayed when REST is selected in the type selection field 931. Instead of the action board 910, a REST function setting screen 940 is displayed for accepting various settings required to create a function (REST function) using REST (REpresentational State Transfer). Furthermore, the function list 920 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 have not been set on the function setting screen (if information to 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.

[0141] The REST function setting screen 940 in FIG. 9(d) displays setting fields 941 to 944. Setting field 941 is a setting screen for setting the function name. 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. Setting field 942 is a setting field for setting the variable name for setting arguments. In this embodiment, param is set by default and cannot be changed. This field 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 end of this area, a pull-down menu appears, displaying options GET, POST, PUT, and DELETE, allowing the developer to select and set one of the options. The type set here is 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, the developer does not need to write source code strings in a programming language.

[0142] 10(a) to 10(d) show examples of the creation function setting screen and the action board display. In Fig. 10, the same elements as in Fig. 9 are given the same reference numerals as in Fig. 10, and the description thereof will be omitted.

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

[0144] FIG. 10B shows an example of a display at the stage when the developer has created functions 923 to 925, which are original functions, and then inputted (written) some code (character strings) in JavaScript into the action board 910 and then inputted "sq." In this embodiment, when the developer user inputs a character string, if the input character string matches the prefix of the function name (identification information) of an already-created original function, the code assist field 911 displays the prefix-matched function name as an input candidate option. In the illustrated example, the input "sq" matches the prefix of the function name "sql01" of function 924, which is an already-created original 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 input into the action board 910 as shown in FIG. 10C, even without performing an operation to input "l01." This code assist function allows the developer (user) 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 the function name does not match (i.e., if there is no function starting with that character string), the code assist field 911 is not displayed. This allows the developer to confirm that the function name they are entering is correct for the previously created created function before entering it, preventing input errors in the function name. If there are multiple previously created functions that match the prefix, the code assist field 911 displays multiple options. Furthermore, the function names of the created functions displayed in the code assist field 911 are functions created for the specified UI widget (UI widget 901 in the illustrated example) that is the target of the action board 910; created functions created for other UI widgets are not displayed. This also prevents the mistake of accidentally entering the name of a created function created for another UI widget on the action board 910, a function name that does not exist as a created function for the specified UI widget.

[0145] 10(c), along with the action board 910, the function list 920 displays the function type (icon before the character string) and function name for each of the functions 923 to 925 of the created functions created by the developer. Therefore, while inputting (writing) the action code (character string in JavaScript) into the action board 910, the developer user can check the type and name of the created functions that have already been created. This reduces the effort required to check and manage valid created functions that can be written into the action board 910 (for example, the effort required to make a note of them or to open another screen to check). This also helps prevent input errors in function names. The functions displayed in the function list 920 are functions created for the specified UI widget (UI widget 901 in the illustrated example) that is the target of the action board 910, and created functions created for other UI widgets are not displayed. This prevents the mistake of accidentally entering the name of a created function created for another UI widget in the action board 910, but that does not exist as a created function for the specified UI widget. Furthermore, creation functions are valid only when defining actions for a specified UI widget and do not affect the definitions of actions for other UI widgets. Therefore, if the function name of a creation function created for a specified UI widget is the same as that of a creation function created for another UI widget, even if that function name is entered on the action board 910, only the function settings set for the specified UI widget will be reflected, not the function settings set for the other UI widget. Therefore, using the same function name as a creation function already created for another UI widget will not result in an error. Therefore, the user can decide on a function name for a creation function and enter it on the action board 910 without worrying about duplicate function names with creation functions already created for other UI widgets. In other words, although many creation functions will be created throughout the entire application development process, they are automatically managed and organized in association with the specified UI widget and displayed in the code assist field 911 and function list 920, making it extremely easy for developers to manage numerous creation functions. This reduces the effort and time required to check function names.It also reduces the chance of inputting incorrect function names. This reduces the amount of debugging work (debug removal) required when inputting a wrong function name. This reduces the workload and man-hours required for software (application) development, allowing for more efficient software (application) development.

[0146] FIG. 10(d) is a display example when action code has been entered in a programming language into the action board 910. In the illustrated example, the created function "rest01" (function 923 in the function list 920) is used in the portion indicated by the dotted line 960 on the third line. The code string illustrated on the action board 910 in FIG. 10(d) does not define the details of the created function rest01. Furthermore, when the developer configures rest01 on the REST function configuration screen 940, the details of rest01 are 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 creates source code in the programming language including the function definition in the programming language as an execution environment program in the save process of FIG. 33(a) or FIG. 35(a) described below, from the uploaded definition information, based on the function configuration contents and the string entered 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 function (action) indicated by the string containing the function of the created function (action written on the action board) to be executed based on the information set on the function setting screen.

[0147] FIG. 11 shows an example of source code in a programming language generated by the development environment 300 based on the character string entered on the action board 910 in FIG. 10(d) and the settings for rest01 configured on the REST function setting screen 940. Note that in the illustrated example, the numbers 1 through 75 on the left side are used to indicate line numbers and are not part of the source code. The example in FIG. 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. By configuring the REST function setting screen 940 and entering the amount of character string (7 lines) shown on the action board 910 in FIG. 10(d), the content of the source code shown in FIG. 11 can be defined. In other words, efficient development can be achieved using low code.

[0148] A flowchart of the action board process is shown in Figure 8. This process is a detailed flowchart of the action board process described above in S715 of Figure 7, and is a process for controlling the operation described using the display examples in Figures 9(b) to (d) and 10(a) to (d).

[0149] In S801, the developer terminal 100 displays an action board on the display 105. If no action has been defined for the specified UI widget, 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 widget, a screen including an action board 910 with the action string entered as described in Fig. 10(d) is displayed.

[0150] In S802, the developer terminal 100 determines whether or not an operation (writing operation) to write an action has been performed on the action board 910. The operation to write 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 write an action has been performed, the process proceeds to S803; if not, the process proceeds to S810.

[0151] In S803, the developer terminal 100 accepts an action input operation by an operation to describe the action, and displays the input characters on the action board 910.

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

[0153] In S805, the developer terminal 100 displays the function names of the created functions determined to 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 character string.

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

[0155] In S808, the developer terminal 100 determines whether or not the operation of describing the action has continued. If the operation of describing the action has continued, the process proceeds to S803; if not, the process proceeds to S802.

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

[0157] In S811, the developer terminal 100 displays the addition dialog 930 for adding a created function and accepts input to 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 the input is made to the addition dialog and the SAVE button 933 is pressed, the process proceeds to S812.

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

[0159] 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, and if not, the process proceeds to S815. In S814, the developer terminal 100 displays a script function setting screen (not shown) and accepts setting operations from the developer user.

[0160] 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 with reference to FIG. 10(a).

[0161] In S817, the developer terminal 100 displays a 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 FIG. 9(d).

[0162] In S818, the developer terminal 100 determines whether input into the setting items predetermined as required items has been completed (whether the setting has 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.

[0163] 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 created function being set. This allows the user (developer) to recognize that the created function being set is in a valid setting state that can be used on the action board 910.

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

[0165] In S821, the developer terminal 100 determines whether or not a save instruction operation has been performed (for example, pressing the Save button 915). If a save instruction operation has been performed, the process proceeds to S822, and if not, the process proceeds to S823.

[0166] In S822, the developer terminal 100 records the details of the action board processing performed up to now in the definition information held in the memory 102, and also transmits this to the development environment 300.

[0167] 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, where the action board of the specified UI widget is displayed. As a result, if the function setting screen was displayed, it switches to displaying the action board. If option 922 has not been pressed, the process proceeds to S824.

[0168] In S824, the developer terminal 100 determines whether or not 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.

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

[0170] In S1201, the developer terminal 100 determines whether or not the application list button 511 has been pressed. If the application list button 511 has been pressed, the process proceeds to S315 in Fig. 3, and if not, the process proceeds to S1202.

[0171] In S1202, the developer terminal 100 determines whether or not the UI screen button 512 has been pressed. If the UI screen button 512 has been pressed, the process proceeds to S1203, and if not, the process proceeds to S1204. In S1203, the UI editor process of FIG. 4 is performed.

[0172] In S1204, the developer terminal 100 determines whether or not the workflow button 513 has been pressed. If it is determined that the workflow button 513 has been pressed, the process proceeds to S1205, and if not, the process proceeds to S1206.

[0173] In S1205, the developer terminal 100 performs a workflow creation process, which will be described later with reference to FIG.

[0174] In S1206, the developer terminal 100 determines whether or not the setting button 514 has been pressed. If the setting button 514 has been pressed, the process proceeds to S1207, and if not, the process proceeds to S1209.

[0175] In S1207, the developer terminal 100 displays an application setting screen. The application setting screen is a screen that accepts setting operations related to the selected application. In S1208, the developer terminal 100 accepts the setting operations on the application setting 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 of whether to build an application that can be used as a PWA (Progressive Web App). Another setting is a setting of which UI screen among multiple UI screens belonging to the application is to be set as the initial UI. The initial UI is the screen that is first displayed when accessing a built application deployed in the execution environment, or the screen that is first displayed after authentication is successful on the application authentication screen after accessing the built application.

[0176] In S1209, the developer terminal 100 determines whether or not the environment list button 515 has been pressed. If the environment list button 515 has been pressed, the process proceeds to S311 in Fig. 3, and if not, the process proceeds to S1210.

[0177] In S1210, the developer terminal 100 determines whether or not 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.

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

[0179] In S1212, the developer terminal 100 acquires database information acquired by the development environment 300 from the currently selected execution environment. More specifically, the development environment 300 determines whether the currently 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 currently selected single-tenant execution environment and acquires the contents recorded in the database. The development environment 300 then transmits the database information acquired from the currently 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.

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

[0181] In S1214, the developer terminal 100 displays the database management screen, and displays the database information acquired in S1212 or S1213. Then, various settings related to the database of the selected execution environment and DB management operations to instruct content updates are accepted.

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

[0183] In S1216, the developer terminal 100 displays a file management screen for managing files to be saved in the selected execution environment, and in S1217, accepts an operation to manage files to be saved in the selected execution environment. For example, an image file to be displayed on the screen of an application to be 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 an instruction to save is given, the developer terminal 100 transmits the selected file to the development environment 300. When the development environment 300 receives the selected file, it transmits 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 be authenticated before logging in to the development environment 300. Therefore, by restricting access to various execution environments to those other than through the development environment 300, other users who cannot log in to the development environment 300 cannot access the execution environment illegally, thereby improving security.

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

[0185] In S1218, the developer terminal 100 determines whether or not the user management button 518 has been pressed. If it is determined that the user management button 518 has been pressed, the process proceeds to S1219, and if not, the process proceeds to S1220.

[0186] In S1219, the developer terminal 100 performs user information display processing. The user information display processing is processing for displaying user information (such as user information 411, 451, 461, and 471 in each execution environment shown in FIG. 1) that is information about application users (information managed separately from the developer) who can log in to the application built in the selected execution environment, and accepting management operations from the developer. The user information display processing will be described later with reference to FIG. 14.

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

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

[0189] <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: email address (username) which becomes the developer's account ID (developer ID), password, last name, first name, accessible execution environment ID, Verify, and 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).

[0190] FIG. 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 application user as account information for each application user, as shown in each row in the figure. The account information for each application user includes an email address (username) that serves as the application user's account ID, a password, a last name, a first name, information indicating whether the email address has been approved, and an owner ID. In the multi-tenant execution environment, multiple applications owned by multiple developers are deployed together. Therefore, to identify which developer (owner) created each application, a developer ID is also recorded as an owner ID. Note that information recorded in association with one account may be other than the information shown in FIG. 14(b). For example, the creation date and time, the update date and time, etc. may be recorded.

[0191] 14(c) shows a specific example of user information (user information 451, 461, 471, etc.) held in the single tenant execution environment. The user information in the single tenant execution environment records two types of information: user information shown in FIG. 14(c1) and group information shown in FIG. 14(c2).

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

[0193] In the group information shown in FIG. 14(c2), as shown in each row, the usernames of one or more users who belong to each of a plurality of group IDs are recorded in association with each other.

[0194] 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 FIG. 12 mentioned above.

[0195] In S130, the developer terminal 100 transmits a user information acquisition instruction for the development environment 300 (information instructing the acquisition of user information for the selected execution environment).

[0196] In S1302, the developer terminal 100 determines whether or not 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.

[0197] In S1303, the developer terminal 100 displays user information on the display 105 based on the user information received in S1302. FIG. 15 shows an example of the user information display on the developer terminal 100 displayed in S1303. In FIG. 15, the same display items as those in the display example of FIG. 5(b) described above are assigned the same reference numerals, and their descriptions are omitted. Display item 1501 is an instruction item for instructing a display based on the per-user information shown in FIG. 14(c1). Display item 1502 is an instruction item for instructing a display based on the group information shown in FIG. 14(c2). Either display item 1501 or 1502 can be switched to select. 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 receive an instruction to delete the user account of that row. Add user button 1503 is an operation icon that adds a row to group information 1505 and issues an instruction to register information about 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.

[0198] In S1304, the developer terminal 100 accepts an operation to edit the user information displayed in S1303. For example, an operation to add a user account by pressing the Add User button 1503, an operation to delete a user account by pressing the button icon displayed in the Delete column, or an operation to edit the content of an editable item by operating the keyboard.

[0199] In S1305, the developer terminal 100 determines whether or not the save button 1504 has been pressed. If the save button 1504 has been pressed, the process proceeds to S1306, and if not, the process proceeds to S1307.

[0200] In S1306, the developer terminal 100 sends to the development environment 300 an instruction to update the user information with content that reflects the editing operation accepted in S1304.

[0201] In S1307, the developer terminal 100 determines whether or not an operation to change the execution environment has been performed. If an operation to change the execution environment 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.

[0202] 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 the process is performed again.

[0203] In S1309, the developer terminal 100 determines whether or not 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 there has been no screen switching operation, the process returns to S1304, and if there has been a screen switching operation, the user information display process ends and the process proceeds to the screen switching process described above.

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

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

[0206] In S1312, the development environment 300 acquires 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 acquired access destination information is access destination information 421. If the selected execution environment is the single-tenant execution environment of FIG. 1, the acquired access destination information is the access destination information of the selected execution environment among access destination information 456b, 466b, 476b, etc. More specifically, the development environment 300 acquires 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 the execution environment ID in the memory 304. The development environment 300 accesses a file recorded in a specific path (a path that is determined once the execution environment ID is known) in the selected execution environment and acquires the URL of the access destination stored in the file as the access destination information. The specific path is, for example, 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 character string + execution environment ID." The predetermined file name is, for example, a common file name that is predetermined and common across all execution environments. In this case, the predetermined path is "fixed string + execution environment ID / common file name.json." That is, once the execution environment ID is known, a predetermined file (access destination information file) in a predetermined 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. Retrieval or updating of user information stored in the execution environment cannot be made without a request to this URL. Thus, without knowing the execution environment ID, access destination information for retrieval or updating of user information cannot be obtained. The execution environment ID is information that can only be obtained by a developer logging in after completing authentication processing to the development environment 300. Furthermore, a developer who can log in to the development environment 300 can only obtain the execution environment ID that they can access. This prevents unauthorized access to the execution environment and the leakage of user information by a person who cannot log in to the development environment 300 or a person who can log in to the development environment 300 but has a different accessible execution environment.That is, security is improved.

[0207] In S1313, the development environment 300 transmits 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 of information for the currently logged-in developer in the table of developer information 301 shown in FIG. 14(a). In other words, it includes information about the email address, password, last name, first name, and accessible runtime environment ID. This information is encrypted and converted into a single data string. Even if only this encrypted information is leaked, the email address, password, last name, first name, and accessible runtime environment ID will not be leaked because it is encrypted.

[0208] In S1314, the development environment 300 determines whether or not it has received user information from the currently 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, which will be described later. If user information has been received, the process proceeds to S1315; if not, the development environment waits for reception of user information in S1314.

[0209] In S1315, the development environment 300 transmits the user information received in S1314 to the developer terminal 100. The user information transmitted here is received in S1302 described above.

[0210] In S1316, the development environment 300 determines whether or not 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.

[0211] 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 by 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.

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

[0213] In S1319, the development environment 300 stores the execution environment ID of the new selected execution environment in the memory 304 as the new selected execution environment.

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

[0215] 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, the process proceeds to S1322; if not, the process proceeds to S1327.

[0216] In S1322, the execution environment 400 performs an access right confirmation process. This process is for determining whether the sender of the user information acquisition request is a developer with legitimate access rights, and this process reduces the possibility of user information being leaked to anyone other than the developer with legitimate access rights, thereby improving security. The access right confirmation process will be described later with reference to FIG. 13(d).

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

[0218] In S1324, the execution environment 400 determines whether or not it is a multi-tenant execution environment 410. If it is a multi-tenant execution environment 410, the process proceeds to S1326, and if it is a single-tenant execution environment, the process proceeds to S1325.

[0219] In S1325, the execution environment 400 transmits 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, which will be described later, the entire user information is transmitted, rather than a 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 transmitted to the development environment 300. The transmitted user information is received by the development environment 300 in S1314 and transmitted to the developer terminal 100 in S1315.

[0220] In S1326, the execution environment 400 transmits to the development environment 300, of the user information held in its own execution environment, the portion of the user information whose owner ID matches the received developer information. The encrypted developer information is transmitted from the development environment 300, received in S1341 (described later), decoded (decrypted) in S1343, and stored in the memory 414. This is the received developer information. Of the user information 411 in the multitenant execution environment 410 shown in FIG. 14(b), information on 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 multitenant execution environment 410, information on 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 multitenant 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.

[0221] In S1327, the execution environment 400 determines whether or not 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.

[0222] In S1328, the execution environment 400 performs an access right confirmation process. This process is for determining whether the source of the user information update request is a developer with legitimate access rights, and this process reduces the possibility that user information will be rewritten (updated) by a request from someone other than a developer with legitimate access rights, thereby improving security. The access right confirmation process will be described later with reference to FIG. 13(d).

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

[0224] In S1330, the execution environment 400 updates the user information stored in its own environment in response to the user information update request. At this time, if a new user is registered in 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.

[0225] Fig. 13(d) shows a flowchart of the access right confirmation process, which is a detailed flowchart of steps S1322 and S1328 in Fig. 13(c) described above.

[0226] In S1341, the execution environment 400 determines whether or not 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.

[0227] In S1342, the execution environment 400 records (outputs) the fact that the access right verification process resulted in an error. In this case, an error is determined in S1323 or S1329 described above. In this way, even if a user information acquisition request or a 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). Therefore, processing in response to unauthorized access can be suppressed.

[0228] In S1343, the runtime environment 400 decodes (decrypts, decrypts) the developer information received in S1341 using a decryption key stored in advance. The decrypted developer information is not transmitted outside the runtime environment, so there is little possibility of it being leaked.

[0229] In S1344, the runtime environment 400 determines whether the runtime environment ID of its own runtime environment (the relevant runtime environment) is included in the portion of the developer information decoded in S1342 that indicates accessible runtime environments. If it is included, the process ends (in this case, the access is deemed valid); if it is not included, the process proceeds to S1342, where an error is recorded (output) as a result of the access right confirmation process. 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 runtime environment. Therefore, processing in response to unauthorized access can be suppressed.

[0230] The execution environment 400 does not accept access from any source other than the development environment 300, and is controlled so as not to process a user information acquisition request or user information update request even if the request originates from a source other than the development environment 300. As a result, even if developer information encrypted by a device other than the development environment 300 and a user information acquisition request or user information update request are forged and sent, no processing is performed in response to the request, thereby improving security.

[0231] The user information display process described above can prevent unauthorized processing due to unauthorized access to the runtime environment 400, reduce the risk of information leakage, and improve security. While the above-described user information display process describes processing related to user information stored in the runtime environment, it can also be applied to other processing related to the runtime 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 runtime environment 400 to improve security.

[0232] For example, this can be applied to the processing related to displaying and updating a database described in S1210 to S1214 of Fig. 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 acceptance URL, which is the request destination for accepting DB operation requests, and the execution environment 400 sends the DB operation request and developer information to this URL, as in S1313. Similar to the processing described in Figs. 13(c) and 13(d), the execution environment 400 performs processing to determine whether the sender of the DB operation request is legitimate, and only if it is legitimate performs processing related to the DB set held in its own execution environment in response to the DB operation request.

[0233] Further, for example, the present invention can be applied to the file management processing described in S1215 to S1217 of Fig. 12. In this case, in response to a file management instruction from the developer terminal 100, the development environment 300 acquires 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 a file management request, and the execution environment 400 sends the file management request and developer information to that URL, as in S1313. As in the processing described in Figs. 13(c) and 13(d), the execution environment 400 performs processing to determine whether the sender of the file management request is legitimate, and only if the sender is legitimate performs processing related to the file held in its own execution environment in response to the file management request.

[0234] <Workflow processing> A flowchart of the workflow process is shown in Figure 16. This process is a detailed flowchart of S1205 in Figure 12. This process is executed by the developer terminal 100.

[0235] 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, as node options, a start 1711, which is the starting point, an end 1712, which is the end point, and a status 1713, which is an 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 dragging and dropping. That is, any of the multiple options displayed in the node list 1710 can be placed by dragging and dropping it into the WF placement area 1700.

[0236] 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 multiple 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.

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

[0238] In S1604, the developer terminal 100 determines whether or not an operation to draw an arrow has been performed. An arrow connects placed nodes and indicates the processing content when transitioning from the node at the origin of the arrow to the node at the destination. When a placed node is selected, an operation path is displayed for the selected node, and 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 button). The node from which the drag was started becomes the origin of the arrow, and the node at the dropped position becomes the tip of the arrow. If an operation to draw an arrow has been performed, the process proceeds to S1605; if not, the process proceeds to S1606.

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

[0240] FIG. 17(b) shows an example of a 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 indicates one procedure (step) in a workflow that includes multiple procedures (steps), and the arrows indicate the order of the procedures. That is, in the illustrated example, nodes 1701 to 1705 are shown to be the first to fifth steps, respectively.

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

[0242] In S1607, the developer terminal 100 displays a property box for setting properties for the node and accepts operations for setting 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 options, and the user can select and set one from the options.

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

[0244] In S1609, a property box for setting properties for the arrow is displayed, and the setting operation for the operation property, which is a property of the arrow, is 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 (Creat), or rejection (Remand). The user can set it by selecting one of the options corresponding to SelectUser and CurrentUser. The type indicates the type of action when transitioning from the original step of the arrow to the next step. Based on this type, the action of the UI widget that is automatically placed, which will be described later, is automatically set.

[0245] In S1610, the developer terminal 100 determines whether or not the create workflow button 1730 has been pressed. If the create workflow button 1730 has been pressed, the process proceeds to S1611, and if not, the process proceeds to S1615.

[0246] 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 Unapplied can be selected as the status to be created.

[0247] 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 add a task table to the creation target. Here, it is possible to select whether to create a task table and the ID of the UI screen to be added. When selecting the ID of the UI screen, a list of UI screen IDs is displayed as options, and the user can select from the options.

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

[0249] 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 properties, and the settings made by selecting from the options in S1611 to S1614, and records the created workflow definition in the definition information in the memory 102. As a result, UI widgets (UI components) based on the workflow are automatically placed on the UI screen. Actions corresponding to the workflow are automatically set for the automatically placed UI widgets. In this way, UI widgets with automatically defined actions are generated based on the workflow generated by selecting options, without the developer user having to write in a programming language. In addition, a table used in the workflow is created in the database specified in the specification reception form shown in FIG. 17(g). In addition, actions are set (defined) in the canvas of the UI screen according to the settings. The action set in the canvas is the process performed when the UI screen is loaded in the constructed application. In other words, it is the process performed as the initial operation when the screen is displayed.

[0250] In S1615, the developer terminal 100 determines whether a screen switching operation has been performed. 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 with reference to FIG. 12. If not, the processing proceeds to S1602.

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

[0252] FIG. 18(b) shows an example of a canvas display of a UI screen on which UI widgets are automatically arranged in S1614 of FIG. 16. UI widgets 1811 to 1813 arranged on canvas 530 are UI widgets that are automatically arranged in response to the generation of a workflow. In other words, UI widgets 1811 to 1813 are not arranged by the developer by dragging and dropping from the UI widget list in the submenu area. An action is automatically set (defined) in UI widget 1813. UI widget 1813 is an automatically generated widget in which an action for transitioning to the next step in the workflow is defined. Furthermore, the UI screen on which UI widget 1813 is arranged is the transition source screen in the transition to the next step in the workflow by executing the action automatically defined in UI widget 1813.

[0253] FIG. 18(c) shows an example of a display when an action board is displayed with a button UI widget 1813 as the designated UI widget. That is, this action board is displayed in S801 described above in FIG. 8 when the designated UI widget is UI widget 1813. The action board 910 displays the character string of the action written in a programming language as shown in FIG. 18(c) as the default 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 FIG. 18(c) as the default 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 FIG. 18(c) defines at least a database (line 3) and a UI screen to be displayed next (line 6) based on the operations received from the user in the workflow creation process of FIG. 16. The user can edit this automatically defined action by the processes of S802 to S808 described above. In other words, the programming language can be input by using the string of an automatically defined action as a base, partially reusing it, and partially modifying or adding strings. In other words, it is possible to 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, it is possible to easily set an action with fewer steps (amount of text input) than if a developer were to write an action in a programming language from scratch. Furthermore, because automatically generated actions can be customized by making modifications rather than using them as is, it is possible to generate actions that meet more detailed requests.

[0254] FIG. 18(d) shows an example of a display when an action board is displayed on the canvas of a UI screen in which actions are automatically set in response to the generation of a workflow. This action board is displayed when a blank area on the canvas is designated and a context menu process is performed to instruct the display of the action board. It is displayed in S1903 of FIG. 19 (described later). The action board displays the action string, as shown in FIG. 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 FIG. 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 such automatically defined actions by processing S1904 (described later). In other words, similar to the actions automatically set in the UI widgets described in FIG. 18(c), actions can be easily set with minimal operation steps (text input), and actions that meet more detailed requests can be generated.

[0255] For example, the following customizations can be added to the UI widgets and actions that are automatically generated in response to the creation of the workflow described above. -Set an action to display the name of the current step in the workflow on the canvas action board. - Place an input field (UI widget) for the reason for application and modify the action board of UI widget 1813 so that the data entered there is sent to the next step. Modify the action board of part 1813 to save data in a different table. For example, customize it so that the reason for application and case ID are also recorded in a separate database. · On the campus action board, set the user who initially inputs to the UI component 1812 (combobox) as the person who applied last time by writing an action within the programming limit. Alternatively, write an action to display eligible persons as options.

[0256] Thus, according to this embodiment, the basic part of the workflow can be quickly created with simple operations along with the operations on the workflow creation screen and the input content to the wizard (i.e., based on an operation group including operations of selecting from options and not including the operation of writing source code in a programming language). Moreover, by presenting the actions set on the automatically created UI components and the canvas of the UI screen in a modifiable manner in a programming language, a more flexible design becomes possible.

[0257] <CRUD generation process> FIG. 19 shows a flowchart of the canvas context menu process. This process is the 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 CRUD.

[0258] In this embodiment, as an example for explaining CRUD generation, a case will be described in which a canvas of a selected UI screen as shown in FIG. 20(a) is displayed before CRUD generation (before CRUD buttons are placed), and a blank area of ​​the canvas is right-clicked to display a canvas context menu. CRUD is an acronym formed from the initial letters of four basic functions required for software: data creation (Create), data read (Read), data update (Update), and data deletion (Delete). The canvas in FIG. 20(a) displays UI widgets 2001 to 2003 placed by a developer in UI editor processing. All of the UI widgets 2001 to 2003 are input-type UI widgets. The UI widget 2001 displays "ID" as the label, the UI widget 2002 displays "Name" as the initial value, and the UI widget 2003 displays "Age" as the label. In other words, the canvas in FIG. 20(a) is a canvas for a UI screen designed to be used for some kind of user registration screen. UI widget 2001 is an input field for entering the ID of the newly registered user, UI widget 2002 is the name of the newly registered user, and UI widget 2003 is the age of the newly registered user. The UI widget IDs of UI widgets 2001 to 2003 are "number_field_ID", "text_field_Name", and "number_field_age", respectively.

[0259] In S1901, the developer terminal 100 displays a canvas context menu superimposed near the mouse cursor. An example of the canvas context menu display is shown in Figure 20(b). The canvas context menu displays options 2011 to 2015, which are menu items.

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

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

[0262] 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 of S802 to S823 in Fig. 8 described above, and therefore details will be omitted.

[0263] In S1905, the developer terminal 100 determines whether or not 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 is switched to the canvas of the selected UI screen, and the process returns to the UI editor processing.

[0264] In S1906, it is determined whether or not the menu item (option 2015) that instructs the creation of a CRUD has been pressed in the context menu of the canvas of the developer terminal 100. If the menu item (option 2015) that instructs the creation of a CRUD has been pressed, the process proceeds to S1907, and if not, the process proceeds to S1914.

[0265] 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 widget from which data is to be acquired in CRUD. FIG. 20(c) shows an example of the display of CRUD input form 1. Area 2021 displays the UI widget IDs of all UI widgets 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 selected area 2022 to make the selection.

[0266] In S1908, the developer terminal 100 determines whether a selection operation is performed in the 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.

[0267] 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 is the target of CRUD. Figure 20(d) shows an example of the display of CRUD input form 2. In area 2031, the UI widget IDs of the UI widgets selected in input form 1 are displayed as options. The user (developer) selects the option they want to use as the target column of CRUD from the options displayed in area 2031 and displays it in selected area 2032 to make the selection.

[0268] In S1910, the developer terminal 100 determines whether a selection operation has been performed in 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.

[0269] In S1911, the developer terminal 100 displays a CRUD input form 3 (a dialog box) and accepts the selection of a database and table to be the target of CRUD. Figure 20(e) shows an example of the display of the 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 right end. Area 2042 is an area for accepting the input of the table name.

[0270] In S1912, the developer terminal 100 determines whether a selection / input operation has been performed in the 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.

[0271] 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 transitions to and is displayed in response to pressing the CRUD button. That is, a UI screen is automatically generated for the selected application. It also automatically generates a database table for the content entered in input form 3 in the DB set of the selected execution environment.

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

[0273] In S1915, the developer terminal 100 performs other processing, which is processing according to the pressed menu item.

[0274] In S1916, the developer terminal 100 determines whether or not an operation to close the context menu of the canvas 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 of Fig. 19 ends. If no close operation has been performed, the process returns to S1902.

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

[0276] FIG. 20(g) shows a display example of a UI screen (UI screen ID: crud-newui-UI01) automatically generated by the processing in S1913. FIG. 20(g) is a display example of a canvas for a UI screen different from that shown in FIG. 20(a), in which a data grid 2061, a UI widget, is placed. The 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 widgets selected in Input Form 2. In addition, a UI widget 2062, a button, is automatically placed. A canvas action is also automatically set for this UI screen (crud-newui-UI01). The automatically set canvas action controls the display of data for rows that are the target of CRUD in the database table set in Input Form 3 when various CRUD buttons on the transition source screen are pressed in the data grid 2061. This canvas action can also be customized by the developer (user) based on the action automatically set by the processing in S1904 described above.

[0277] The automatically generated data grid 2061 can also be edited in various ways using the grid property box and action board (described later). For example, you can change the grid decoration or change the column name label from "text_field_Name" to "Name." You can also modify the grid so that some columns are not 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. Editing the UI widgets and screens automatically generated based on input into the CRUD input form (fizzard) allows you to easily and flexibly accommodate future changes to the application's operation with minimal effort.

[0278] FIG. 21(a) shows an example of a database table automatically added by the processing of S1913. This display example is an example displayed when the database button 516 in the main menu area is pressed. That is, FIG. 21(a) is one of the database-related screens displayed in S1214 of FIG. 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 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 widget ID of the UI widget selected in Input Form 2. For these columns, properties such as data type are also automatically set according to the properties of the UI widget selected in Input Form 2.

[0279] FIG. 21(b) shows an example of a display when an action board for UI widget 2051, a CRUD button, is automatically placed in the process of S1913 in FIG. 19 is displayed. That is, this action board is displayed in S801 described above in FIG. 8 when the specified UI widget is UI widget 2051. The action board 910 displays the action string as shown in FIG. 21(b) written in a programming language (JavaScript) as the default 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 FIG. 21(b) as the default 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 by the processes 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 partially modify or add text. That is, the user can accept modifications to the automatically defined action string. 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.In addition, automatically generated actions can be customized by making modifications rather than using them as is, making it possible to generate actions that meet more detailed requests.

[0280] 21(b), function list 920 in the submenu area displays functions 2121 and 2122 as options of pre-prepared functions. Functions 2121 and 2122 are functions automatically generated in the process of S1913 in FIG.

[0281] FIG. 21(c) shows an example of a display when function 2121 is selected from function list 920 and the function setting screen is displayed. Function 2121 is an SQL function, and the SQL function setting screen is displayed. Since the SQL function setting screen has the same configuration as that described above in FIG. 10(a), the same setting / input fields in FIG. 21(c) as those in FIG. 10(a) are denoted with the same reference numerals and their descriptions are omitted. In setting field 951, "SQL_Save" is automatically set as the function name. In setting field 953, an SQL statement is 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. In addition, the character string that follows indicates the column values ​​included in the row to be added, and reflects the content entered in Input Form 1. The contents of the setting fields 951 and 953 can be edited (corrected, deleted, added to, customized) by the developer through the processes of S813 to S820 in FIG. 8, based on the automatically generated contents.

[0282] FIG. 21(d) shows an example of a display when function 2122 is selected from function list 920 and the function setting screen is displayed. Function 2122 is an SQL function, and the SQL function setting screen is displayed. Since the SQL function setting screen has the same configuration as that described above in FIG. 10(a), the same setting / input fields in FIG. 21(d) as those in FIG. 10(a) are denoted with the same reference numerals and their descriptions are omitted. In setting field 951, "SQL_Update" is automatically set as the function name. In setting field 953, an SQL statement is pre-entered. In this SQL statement, the character string "UPDATE" indicates that the database processing type is "UPDATE" and that this is a process to update the value of an existing row 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. In addition, the character string that follows indicates the value of the column to be updated, and reflects the content entered in Input Form 1. The contents of the setting fields 951 and 953 can be edited (corrected, deleted, added to, customized) by the developer through the processes of S813 to S820 in FIG. 8, based on the automatically generated contents.

[0283] The content of the automatically generated actions shown in the action board 910 in Fig. 21(b) will be explained in detail below. 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 variable named params that contains the values ​​from lines 2 to 5. Line 2: Defines the ID number. It will be a serial number. Lines 3 to 5: Obtain the value entered in the UI widget selected in Input Form 1. Note that "$ui.UI widget ID.Target information type" 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 SQLUpdate function with 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 value entered in the UI widget selected in Input Form 1. Line 7: Get the rows affected by the update. Line 8: Determines whether any rows were retrieved in line 7. In other words, determines whether any rows were updated. Line 9: If line 8 is true, display "Successfully Updated." Line 10: NextUI transitions to the UI screen whose UI screen ID is "crud-newui-UI01". 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 SQLSave function with the params defined in lines 2 to 5 as arguments. In other words, add a row to the database table set in input form 3 with the values ​​entered in the UI widget selected in input form 1 and save it as a new row. Line 14: Get the rows affected by the new save on line 13 (i.e., the added rows). Line 15: Determines whether any rows were retrieved in line 14. In other words, determines whether the new row was successfully added and registered. Line 16: If line 15 is true, display "Successfully Inserted." Line 17: NextUI transitions to the UI screen whose UI screen ID is "crud-newui-UI01". Lines 19 and 20: If both lines 8 and 12 are false, display "Insertion Failed."

[0284] The content is automatically generated in this way and presented on the action board in a programming language so that the developer (user) can modify it. The developer (user) can then customize it, 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 (crud-newui-UI01) on lines 10 and 17. Since we want to change the operation so that age is not registered, we will delete line 5. In other words, we will change the component that obtains and / or outputs information when the action is executed. Since 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 setting field 953, and modify only the target database and table parts.

[0285] 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 without any action description in a programming language. Furthermore, since customization is possible freely, there is also a high degree of freedom in the content of the actions that can be created. According to this embodiment, the developer (user) can more flexibly modify and use actions defined without having to write them in a programming language (actions defined based on the group of operations entered into input forms 1 to 3).

[0286] <Developer account registration process> 22(a) shows a flowchart of the developer account registration process on the developer terminal 100. This process is a detailed flowchart of S306 in FIG.

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

[0288] In S2202, the developer terminal 100 sends to the development environment 300 the account information entered in S2201 and a registration request that requests new registration of the account information.

[0289] 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, a one-time password is sent from the development environment 300 to the email address included in the account information to confirm that the email address is valid. Since 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.

[0290] In S2204, the developer terminal 100 transmits the one-time password entered in S2203 to the development environment 300.

[0291] 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, and if not, the process proceeds to S2206.

[0292] In S2206, the developer terminal 100 displays a resend instruction screen for requesting the development environment 300 to resend the one-time password.

[0293] In S2207, the developer terminal 100 determines whether or not there has been an operation from the developer (user) to instruct resending of the one-time password. If there has been an operation to instruct resending, the process proceeds to S2208. If there has not been an operation to instruct resending, the developer terminal 100 waits until there has been an operation to instruct resending.

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

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

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

[0297] 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 is linked to the developer account registration process in the developer terminal 100 in FIG. 22(a).

[0298] In S2221, the development environment 300 determines whether or not account information and a registration request (registration instruction) that is a request to newly register that account information have been received from the developer terminal 100. This account information and registration request were sent from the developer terminal 100 in S2202 of Figure 22(a). If account information and a registration request that is a request to newly register that account information have been received from the developer terminal 100, the process proceeds to S2222; otherwise, the process waits until they are received.

[0299] 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 column "Verify" in this row is recorded as "unconfirmed." The columns in the developer information 301 are those shown in FIG. 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.

[0300] In S2223, the development environment 300 instructs an 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.

[0301] In S2224, the development environment 300 determines whether or not 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 Figure 22(a). If a one-time password has been received, the process proceeds to S2225; if not, the process waits at S2224.

[0302] In S2225, the development environment 300 sends the one-time password received in S2225 to the external one-time password issuing system, and issues a command to verify whether it matches the issued one-time password. In other words, it issues a command to verify the one-time password.

[0303] In S2226, the development environment 300 determines whether or not a notification has been received from the external one-time password issuing system indicating that the one-time password is correct (verification was successful). If the result is positive (verification was successful), the process proceeds to S2228; if not, the process proceeds to S227.

[0304] In S2227, the development environment 300 determines whether or not 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 Figure 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.

[0305] 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 regarded as 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.

[0306] 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 value of "Verify" is "confirmed") is greater than a predetermined threshold 2 (for example, 9000). If the number of valid accounts is greater than threshold 2, the process proceeds to S2230, and if the number of valid accounts is equal to or less than threshold 2, the process proceeds to S2232.

[0307] In S2230, the development environment 300 determines whether or not a DB instance has been added to the multi-tenant execution environment 410. If a DB instance has been added, the process proceeds to S2232, and if not, the process proceeds to S2231.

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

[0309] 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 value of "Verify" 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, and if the number of valid accounts is equal to or less than threshold 1, the process proceeds to S2236.

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

[0311] In S2234, the development environment 300 updates the DB instance name stored in memory 304 as the DB instance name of the multitenant 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 before this, "DB instance name 2" is assigned to accounts added thereafter. As the number of accounts connecting to one DB instance (database environment) increases, the number of simultaneous accesses to the database 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 as a result of the processing in S2233, 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 one DB instance. This reduces the possibility of performance degradation, such as slower response times when accessing the database.

[0312] In S2235, development environment 300 updates threshold 1 to threshold 1 = threshold 1 + threshold 1. Also, threshold 2 is updated 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 becomes 20,000 and threshold 2 becomes 19,000. In other words, every time the number of accounts on developer devices increases by another 10,000 (every time the number of valid accounts increases by the number of threshold 1), the processes of S2231 and S2234 are performed.

[0313] In S2236, the development environment 300 assigns the DB instance name held in memory 304 as the DB instance to be connected to for the account information added in S2222 (the currently added account). More specifically, the DB instance name held in memory 304 as the DB instance to be connected to is recorded in the column indicating the DB instance name to be connected to (the rightmost column in FIG. 14(a)) in 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 terminal 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 terminal 10001, "DB instance name 2" is recorded.

[0314] In S2237, the development environment 300 transmits a login OK notification to the developer terminal 100. The transmitted login OK notification is received by the developer terminal 100 in S2205 described above.

[0315] 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 account information added this time. More specifically, it records it in the password column of the row for the account added this time in the developer information 301.

[0316] FIG. 23(a) shows details of the DB set 430 in the multi-tenant execution environment 410. The DB set 430 is initially prepared with a fixed number of DB environments (DB instances), which may 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. The 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 the DB for developer A is DB1. The DBs for each developer include DB1 (2314), DB2 (2315), DB3 (2316), etc., and the number increases each time a valid account is registered in the 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 for the 10,000th developer device, and subsequent DBs are created in separate DB instances. Each inventor's DB 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.

[0317] By the processing of 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 a valid developer account is additionally registered in the developer information 301 after DBmax (2317) has been created in DB instance 1, the result of S2232 becomes Yes, and the additionally registered developer is registered in the developer information 301 so that he or she connects to DB instance 2 (2320). Then, DBs for accounts (developers) added thereafter are 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.

[0318] FIG. 23(b) shows details of DB set 457 of the single-tenant execution environment. Because the 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 possibility of an increase in DBs or concentrated access to the extent that response will be reduced. Therefore, only one DB environment, DB instance 1 (2350), is prepared in DB set 457. Furthermore, the developer information DB 2351 records only information for one account statement (for example, DB information 2352 for developer A). There is no upper limit threshold for the number of DBs that can be stored. Furthermore, as described in FIG. 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.

[0319] <Deployment process> 24(a) 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.

[0320] Fig. 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 Fig. 24(a) starts.

[0321] In S2401, the developer terminal 100 transmits information instructing the development environment 300 to deploy the selected application. 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.

[0322] In S2402, the developer terminal 100 displays a waiting screen, which displays guide information indicating that the deployment is currently in progress.

[0323] 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, and if not, the process proceeds to S2405.

[0324] 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, which will be described later, are not performed.

[0325] In S2405, the developer terminal 100 determines whether or not 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 application. If a success notification has been received, the process proceeds to S2406; if not, the process proceeds to S2403.

[0326] In S2406, the developer terminal 100 determines whether the selected application (deployed application) is for mobile use. If it is for mobile use, the process proceeds to S2408, and 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.

[0327] In S2407, the developer terminal 100 displays a screen accessed by the URL of the deployed app (the URL for accessing the runtime 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 developer can immediately confirm and verify the display content and operation of the actual deployed app (built in the runtime environment). The processing of S2407 accesses the URL of the deployed app (the URL for accessing the runtime environment) and executes the app. Details of the app execution processing will be described using the flowcharts of FIG. 33(c) or FIG. 35(c).

[0328] In S2408, the developer terminal 100 performs a process of converting the URL of the application included in the success notification into a QR code, that is, generates a QR code (two-dimensional code) that includes information about the URL of the application.

[0329] In S2409, the developer terminal 100 displays the QR code generated in S2409. Because the QR code is displayed when deployment is completed (successful), the developer can recognize when deployment was successful. FIG. 25(b) shows an example of the QR code displayed in S2409. FIG. 25(b) shows an example of the screen transition when the deploy button 506 is pressed from the state of FIG. 25(a) to issue a deployment instruction and the 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, which is information contained in the 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. The QR code 2511 is displayed when the deployment is completed, and is an address for executing the deployed application, and is access destination information indicating the location (execution environment) where the deployment has been performed.

[0330] By capturing and reading the QR code 2511 displayed on the display 105 of the developer terminal 100 with a handheld smartphone (mobile terminal), the developer (user) can display a screen on the handheld smartphone that allows access to the URL of the deployed app (the URL for accessing the execution environment). This allows easy access to the deployed URL with minimal operations. In this case, the handheld smartphone functions as the application user terminal 201. As a result, the authentication screen or initial UI of the deployed app is displayed on the handheld smartphone, and the user can immediately check and verify the display content and operation of the actual deployed app (built in the execution environment) by operating the handheld smartphone. Because the operation of a mobile app can be checked 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 checking 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 URL included in the success notification can be read. For example, a barcode or Chameleon Code (registered trademark) may be used. Furthermore, the URL of the application included in the success notification may be displayed as a character string in the QR code dialog 2510.

[0331] In S2410, the developer terminal 100 determines whether or not 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, and if not, the process proceeds to S2411.

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

[0333] Fig. 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 Fig. 24(a).

[0334] In S2421, the development environment 300 acquires the definition information of the selected application to be deployed from the definition information of the application 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 UI definition information (uiDef.json) and the execution environment program (JavaScript), which will be described later.

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

[0336] 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 multitenant execution environment 410. More specifically, the development environment 300 sends the definition information of the selected app acquired in S2421 to the multitenant execution environment 410 and instructs the multitenant 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.

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

[0338] In S2425, the development environment 300 determines whether the deployment has failed. If the deployment fails, it proceeds to S2426; otherwise, it proceeds to S2427. The deployment may fail if the definition information cannot be transmitted to and recorded in the execution environment due to a communication failure or the like.

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

[0340] In S2427, the development environment 300 determines whether the deployment has completed (succeeded). If the deployment has completed, it proceeds to S2428; otherwise, it proceeds to S2425.

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

[0342] <UI screen template> The UI screen template will be described. In addition to the UI screens created by the user, there are UI screens (template screens) prepared in advance as templates on the UI screen. The template screen is a screen in which at least one prototype component with a predefined action is arranged at a predefined position even if the user has not arranged UI components on that UI screen in the past. The template screen can be customized for the pre-prepared information. More specifically, the template screen can be displayed on the canvas in the UI editor and edited by the UI editor processing described in FIG. 4.

[0343] FIG. 26(a) shows an example of how template screen options are displayed when a list of UI screens is displayed as options in submenu area 520. This display is performed by the processing of S401 in FIG. 4 described above. FIG. 26(a) shows an example of an expanded display of a list of UI screen options that are classified into the Authentication UI group (UI screen for authentication, authentication screen) among 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 expansion of the Authentication UI option is collapsed, and the group names of the other groups are displayed in submenu area 520. Options 2611 to 2622 are each options for one UI screen, and all of them are prepared in advance as template screens.

[0344] FIG. 26(b) shows a display example 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 widget list in submenu area 520, but are template UI widgets whose display position (placement), color, size, and display content are defined in advance. Template components 2631 to 2634 are the following UI widgets, respectively. Template Component 2631: UI component for displaying "Sign In" in the Output Field. Template 2632: A UI widget for receiving input of an email address, which is the user name (user ID) of the application, in the TextField type of Input. In other words, a UI widget for receiving input of user-specific information. Template component 2633: A button UI component that is set (labeled) to display "CREATE ACCOUNT?". When pressed, it is preset (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 2634: A button UI component that is set (labeled) to display "NEXT." When pressed, a predetermined action is set (predefined) to acquire the value (email address) entered in template 2632 and transition to a "Sign in Password" screen (a UI screen corresponding to option 2612 on the screen shown in FIG. 27(a)), which is a type of template screen.

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

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

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

[0348] Each of the template screens described above can be customized. As explained in the process from S405 onward in Figure 4, developers can edit them using a UI editor. Editable content includes 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 of regular UI components (UI components that are not template components) added to a template screen cannot be changed or deleted. This prevents unintended errors that could cause authentication processing to malfunction due to modifications to actions required for authentication processing using a cloud service. In other words, the actions required for error-free authentication are predefined in the template components and cannot be modified. This ensures that authentication processing using a cloud service will operate reliably even if a developer customizes the template screen. The reason why actions cannot be set for normal UI widgets added to template screens is to prevent the setting of actions that will 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 that transitions to a UI screen unrelated to authentication is set for that button, 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 destination UI screen 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 widgets added to template screens.

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

[0350] Fig. 26(d) shows an example of a display in which a context menu 2635 is displayed for a button 2634 placed on the canvas of the template screen. As such, the options for action and deletion 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 Fig. 7, only the properties of the template component can be edited (the display form can be changed).

[0351] Figure 26(e) shows an example of the display after editing (customization) the canvas of the template screen shown in Figure 26(b). The same UI widgets are designated by the same reference numerals in Figures 26(b) and 26(e). UI widget 2641 is an output-type UI widget added by the developer and is displayed by specifying the image file uploaded using the file management operation in S1217 of Figure 12. If this image is an icon or image representing the application, the user can easily identify which application the authentication screen belongs to. UI widget 2642 is a text message-type UI widget added by the developer. The developer also set an action for the canvas of this screen by opening the canvas's action board: 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 widgets (components) whose display content changes depending on the conditions for displaying this authentication screen. Template 2631 is the same UI widget (UI widget with the same ID) as template 2631 in Figure 25(b), but the content (label) displayed can be changed by the developer by editing the properties, and it will display "Login." 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 company standard design, or to create a screen with a more suitable design that suits the nature of the app.

[0352] <Example of the property box> This section explains the properties box that appears when you select Properties from the context menu of a UI widget placed on the canvas.

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

[0354] When a pie chart is placed on the canvas by dragging and dropping it from the UI widget 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 widget is a pie chart when they look at it. To solve this, we will set pre-defined initial values ​​(default settings that are 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 widget 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 widget is a pie chart.

[0355] Within the property box 2810, the Value input area 2812 is an area for inputting the ID, numerical value, color, and label (display string) of each section shown by the pie chart 531. If the developer has not set anything, the initial value will be displayed as shown in the figure. In the example shown, only a portion of the initial value is displayed, and it is possible to view the entire value from start to finish by scrolling. The full text of the initial value displayed in the Value input area 2812 is as follows. Note that "" is assumed to be a double quotation mark

[0356] [{″id″:″Jan″,″value″:Developer terminal 100.33,″color″:″#394E79″,″month″:″Jan″},{″id″:″Feb″,″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 field 2810 is displayed in the same structure as when written in a programming language. Of the full 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 ":" 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. In other words, of the full text of the initial value above, the portion containing multiple pairs, {"id":"Jan", "value":Developer's Terminal 100.33, "color":"#394E79", "month":"Jan"}, is a dataset (one set), containing four key name and 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 value of the pie chart is a set of setting values, each containing multiple datasets containing default setting values.

[0357] A developer 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 a 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 confirm how the pie chart 531 changes when the value of a certain 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.

[0358] If the developer simply wanted to be able to set the settings for the pie chart, one possible setting method would be to separate the settings into items such as "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 item. However, in this embodiment, instead, the initial values ​​are displayed in a structure that is appropriate for writing in a programming language, and when the developer edits, the initial values ​​are entered in a structure that is appropriate for writing in a programming language. This is because the settings for the pie chart can be changed by actions entered in JavaScript on other UI widgets or the action board of the canvas. If the initial values ​​are displayed as copyable text (character strings) in a structure that can be written in a programming language, the developer can copy this character string to the clipboard using a known copying method and paste it into the action board (copy and paste). Then, by modifying only the text in the action board that the developer wants to change, the developer can easily write an action that changes the display content of the pie chart. This prevents the developer from being unable to write the intended action because they do not know how to write it, or from spending a lot of time figuring out how to write it. In other words, software development can be carried out more efficiently. Because it is a programming language, it can be freely edited if other edits are required.

[0359] FIG. 29 shows an example of the display of an action board when a developer has entered an action to change (specify) the display format (display content) of pie chart 531 into the action board of a UI widget (button) other than pie chart 531, which the developer has placed. 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 application is written in a programming language. Among the character strings (character strings in JavaScript) displayed on action board 2900, lines 2 to 32 are based on the initial value displayed in Value input field 2812 of property box 2810, which has been copied and pasted, with line breaks added for readability. Only numerical values ​​2901 to 2951 have been 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 input actions in a programming language. In the constructed application, when a button corresponding to this action board is pressed, the pie chart is displayed in a display format based on the content described in this action board, rather than the initial value.

[0360] Like pie charts, lists, which are UI widgets, also have initial values ​​(default settings) set, 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 how the property box 2820 of the list 2802 is displayed. As shown in the figure, the value input area 2821 displays the initial value in accordance with the structure when written in a programming language.

[0361] Like the pie chart, the LINE CHART (line chart, line graph) UI widget also has an initial value (default setting value) set, and the initial value is 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 in the figure, the initial values ​​are displayed in input areas 2831 to 2834 according to the structure when written in a programming language.

[0362] Like the pie chart, initial values ​​(default settings) are set for the data grid (table), combo box, tab, stepper, and breadcrumbs UI widgets, and the initial values ​​are displayed in the property box according to the structure when written in a programming language. Figure 28(d) shows an example of the display of the property box 2840 for the data grid 2804. As shown in the figure, the initial values ​​are displayed in the input area 2841 according to the structure when written in a programming language. The initial values ​​for the 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.

[0363] <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. 7. This processing is executed by the developer terminal 100.

[0364] In S3001, the developer terminal 100 displays a context menu for the data grid. FIG. 31(a) shows an example of the display of the context menu for the data grid. Data grid 3110, which is a UI widget 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.

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

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

[0367] In S3004, the developer terminal 100 determines whether or not another option has been pressed (selected) from among the options included in the context menu 3120. If another option has been pressed (selected), the process proceeds to S3005, and if not, the process proceeds to S3006.

[0368] 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 widget, is deleted (erased) from the canvas.

[0369] In S3006, the developer terminal 100 determines whether or not 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 in Fig. 30 ends. If no operation to close the context menu has been performed, the process returns to S3002.

[0370] In S3010, the developer terminal 100 displays a property box for the data grid, which is the specified UI widget. FIGS. 31(b) to 31(f) show display examples of the data grid property box. In FIGS. 31(b) to 31(f), the same display items are denoted by the same reference numerals. The Apply button 3131 in FIG. 31(b) is a button icon that instructs the application of the contents (changed settings) entered in the property box. Pressing the Apply button 3131 changes the display form of the data grid, which is the specified UI widget arranged on the canvas displayed together with the property box, 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 of a column to the data grid, which is the specified UI widget.

[0371] 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 a 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 (not shown) located on the far left is labeled "DataGrid," and is a tab for displaying a setting screen for making settings related to the entire data grid, which is the specified UI widget. Only this "DataGrid" tab does not relate to a specific column (it is not for selecting a specific column).

[0372] 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 setting screen (element screen) related to the selected column. FIG. 31(c) shows an example of the display when tab 3132E (a tab labeled "CompanyE") is selected in the column selection field 3132. In the area below the column selection field 3132 in the property box, an upper area 3134t of the setting 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 (type) of the column. The setting screen for tab 3132E continues downward, and the lower part can be displayed by scrolling. FIG. 31(d) shows an example of the display when scrolling to display lower area 3134d of the setting screen for tab 3132E. Lower region 3134d includes a column deletion button 3136 for instructing the deletion of the column itself corresponding to tab 3132E, and an apply button 3137 for instructing that the contents set in the setting screen of tab 3132E be applied and reflected in the data grid displayed on the canvas. Column selection field 3132 moves upward as the user scrolls and is no longer visible in the property box, but it will reappear if the user scrolls back so that upper region 3134t is visible. Note that when the "DataGrid" tab is selected in S3011, the display content of the area of ​​the property box below column selection field 3132 is switched to a setting screen for making settings related to the entire data grid.

[0373] In S3013, the developer terminal 100 determines whether or not 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, and if not, the process proceeds to S3015.

[0374] In S3014, the developer terminal 100 performs a column addition process. In the column addition process, first, a column addition form 3138 shown in FIG. 31(e) is displayed, and settings of the ID and label (name of the column to be displayed) of the column (column of the table) to be added are accepted from the developer (user). 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.

[0375] 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 the addition, the added column is selected, and the upper region 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, a column is added to a data grid (table) by operating the properties box, which is the settings screen for the data grid.

[0376] In S3015, the developer terminal 100 determines whether or not a setting operation has been performed on the selected column. Specifically, it determines whether or not 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.

[0377] 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 selection of the component type for each column. The following options are displayed for the component types that can be set for 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 (the character string displayed as the column name), Width (column width), NumberFormat, DataFormat, Options, Footer, FooterText, Sorting, and Visibility. In addition, the setting items that can be set on the setting screen for the entire data grid corresponding to the "DataGrid" tab include the following. ID (data grid UI component ID), overall size of the DataGrid (width, height), whether it will be 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 data grid, whether to display an update button for the data grid, etc.

[0378] In S3017, the developer terminal 100 determines whether or not 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, and if not, the process proceeds to S3019.

[0379] In S3018, the developer terminal 100 records the content set in the property box in the definition information stored in memory 102, and also changes the display format of the data grid, which is the specified UI widget 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 display format with one column added, and if the column width has been changed, the column width of the data grid on the canvas is changed and displayed.

[0380] In S3019, the developer terminal 100 determines whether or not 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.

[0381] In this way, adding columns to a data grid (table) and configuring each column can be done with greater ease. In particular, adding a column to a data grid can be done by operating the data grid's property box, and the settings for the added column can be performed 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, the type can be set from the options that can be set as a column component, so adding a column and configuring the type can be done without confusion.

[0382] In S3020, the developer terminal 100 displays action options for each column as a submenu of the context menu. FIG. 32(a) shows an example of the display in S3020. FIG. 32(a) is an example of the display when action 3122 is pressed from the state of FIG. 31(a). The same display elements are assigned the same reference numerals between FIG. 31(a) and FIG. 32(a). Submenu 3210 is displayed as a submenu of action 3122 of context menu 3120. Submenu 3210 includes options 3211 to 3217. Options 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 an action board 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. At this time, options corresponding to the action board of a column of a data grid different from the data grid of the specified UI widget are not displayed.

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

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

[0385] Figure 32(b) shows an example of the display of an action board corresponding to the options (options 3211) for actions on the entire data grid. "DATA GRID" is selected in the overall or column selection area 3220, indicating that the action board 3211a is the area for entering actions for the entire data grid. The trigger for executing the content set in the action board 3211a is predetermined, and is triggered by pressing a button related to the entire data grid that appears outside the columns of the data grid area, which is the specified UI widget in the pre-built application. In other words, this trigger is related to the data grid (table), which is the specified UI widget, and is not related to the columns of the data grid. The button related to the entire data grid 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 delete button for the data grid and the update button for the data grid mentioned above. Therefore, developers do not need to set the trigger for executing the action (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 contents displayed in the data grid to a database, or transitioning to another UI screen.

[0386] FIG. 32(c) shows an example of an action board display corresponding to an action option (option 3212) for a specific column of a data grid. "MONTH" is selected in the selection area 3220, and action board 3212a indicates that it is an 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. The trigger occurs when, in a pre-built application, a cell value in any row of the corresponding column among the designated UI widgets 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, an action can be set in this action board 3212a, 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 the setting of an action that affects another column of the data grid, which is the specified UI widget, other than the column corresponding to the selected option 3212.

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

[0388] In S3023, the developer terminal 100 accepts an input operation of an action for the displayed action board. This process is the same as the processes of S802 to S823 in FIG.

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

[0390] 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, options corresponding to the action boards of all columns included in the data grid (table) are displayed in a list, allowing the developer to recognize that actions can be set for each column, reducing the possibility of forgetting to set an action for a column. In addition, because it is displayed as a submenu of the context menu of the data grid, which is the specified UI widget, the relationship with the data grid, which is the specified UI widget, can be clearly understood. In other words, the design work can be performed while understanding, without confusion, which column of which data grid the action set in the action board relates to.

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

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

[0393] In S3301 of Figure 33(a), the development environment 300 determines whether or not definition information (UI definition information) of the selected application 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 Figure 4 described above. If a UI definition has been received, the process proceeds to S3302; otherwise, the process waits in S3301.

[0394] In FIG. 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. The UI definition information 3401 includes various settings related to the application, such as the initial UI, and information defining information (such as placement position, size, and color) of UI components (UI widgets) for each UI screen. The UI definition information 3401 also includes an action description section 3402. This action description section 3402 is a string entered in the action board or function setting screen (including the creation function setting screen) of each UI widget or canvas. The action description section 3402 includes actions written in JavaScript and function definitions in JSON format that describe settings made on the function setting screen without entering JavaScript. This UI definition information 3401 is sent (uploaded) from the developer terminal 100 to the development environment 300, and is received by the development environment 300 in S3301.

[0395] In S3302, the development environment 300 saves the UI definition information in an area for the logged-in developer in the storage 320. As a result, UI definition information 3411 is recorded in the development environment 300, as shown in Fig. 34. 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.

[0396] 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 part 3412 from the UI definition information 3411 in FIG.

[0397] 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 for the login developer in the storage 320. That is, based on the action description portion 3412 extracted from the UI definition information 3411 in Fig. 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 in which, in addition to the character strings input to the action board obtained from the action description portion 3412, supplementary portions necessary for execution by the execution engine of the execution environment are added.

[0398] The UI definition information 3411 and the program for execution environment 3413 saved in the development environment 300 by the save process described in FIG. 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 FIG. 24 described above. As a result, the UI definition information 3421 and the program for execution environment 3423 are recorded in the execution environment 400, as shown in FIG. The UI definition information 3421 and the program for execution environment 3423 in the execution environment 400 are the same information as the UI definition information 3411 and the program for execution environment 3413, respectively. This state is the state in which the application has been generated.

[0399] 33(b) shows a flowchart of application execution processing in the execution environment 400. This processing 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.

[0400] 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 (constructed, generated) in execution environment 400 is accessed using the browser software of application user terminal 200 or 201. The application execution processing in execution environment 400 in FIG. 33(b) and the application execution processing in application user terminal 200 or 201 in FIG. 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).

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

[0402] In S3312, the runtime environment 400 transmits the UI definition information to the application user terminal 200. As a result, as shown in Fig. 34, UI definition information 3421 recorded in the runtime 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.

[0403] In S3313, the runtime 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.

[0404] 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 widget that is classified as an input item among the UI widgets displayed on the screen of the application. For example, it is text entered in 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.

[0405] In S3315, the execution environment 400 temporarily stores the received values ​​of the input items in a memory included in the execution engine.

[0406] In S3316, the execution environment 400 executes the requested action by executing the execution environment program 3424. If the value of the input item has been received, the action is executed using the value of the input item as well. For example, the part of the execution environment program 3424 that executes the requested action is executed using the value of the input item as an argument.

[0407] In S3317, the execution environment 400 determines whether or not there is a value for an output item, which is a value to be displayed on the application screen displayed on the application 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, the process proceeds to S3318; if not, the process proceeds to S3319.

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

[0409] In S3319, the execution environment 400 sends result information of the action executed in S3316 to the application user terminal 200. If action result information including values ​​of output items was generated in S3318, the values ​​of the output items are also sent to the application user terminal 200. Then, in S3348 of FIG. 33(c) (to be described later), 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 screen of the application displayed on the display 105 of the application user terminal 200 by the processing of S3347 of FIG. 33(c) (to be described later).

[0410] 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), it terminates the processing. 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), in S3331, application user terminal 200 (which includes 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 (built, generated) in execution environment 400. More specifically, in response to an operation to specify and access the URL of a deployed application (the URL for accessing the execution environment) (for example, an operation to click on the link of the application's URL, or an operation to enter the application's URL in the address bar and press the Enter key), the application accesses (connects) the URL of the application.

[0411] In S3332, the application user terminal 200 determines whether or not a client program has been received. When the runtime environment 400 detects access from the application user terminal 200, the distribution engine of the runtime environment (distribution engine 415, 455, 465, 475, etc., that corresponds to the accessed runtime environment) transmits the client program recorded in storage (client program 422, 456c, 466c, 476c, etc., that corresponds to the accessed runtime 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.

[0412] In S3333, the application user terminal 200 transmits a request to acquire 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 acquire UI definition information is first issued. S3333 is processing that follows this definition. The UI definition information acquisition request transmitted here is received by the runtime environment 400 in S3311 of FIG. 33(b) described above.

[0413] In S3334, the application user terminal 200 determines whether or not UI definition information has been received from the runtime environment 400. The UI definition information received here is the information transmitted from the runtime environment 400 in S3312 of FIG. 33(b) described above. If UI definition information has been received, the process records the UI definition information in memory 102 and 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.

[0414] 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 at the transition destination) or an operation has been performed on a UI widget displayed on the application screen (a click or the like to trigger an action on a UI widget). If an action has been triggered, the process proceeds to S3336; if not, the process proceeds to S3350.

[0415] In S3336, the application user terminal 200 extracts a description portion relating 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 the memory 102. This description portion is text (character string) information written in JavaScript (a programming language).

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

[0417] In S3338, the application user terminal 200 determines whether or not the character string "$ui" is found as a result of the search in S3337. If "$ui" is found, the process proceeds to S3339; if not, the process proceeds to S3343.

[0418] 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 sentence) is a string of characters in a programming language that ends with a line terminator (for example, a semicolon ";") or a closing parenthesis "}". In other words, two sentences are separated by a line terminator or a closing parenthesis ('}'). If "$ui" found by 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.

[0419] In S3340, the application user terminal 200 records information based on the element character string ($ui.UI widget 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 FIG. 34) generated in memory 102. Specifically, the application user terminal 200 obtains a UI widget ID (item code, component identifier) ​​from the element character string ($ui.UI widget ID.Target Information Type) of a structure separated by a period (.") beginning with "$ui," and records that the UI widget 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 widget ID is "UI widget ID3," then the application user terminal 200 records that UI widget ID3 is included in the output items, as shown in item definition list 3433 in FIG. 34. The item definition list 3433 is information temporarily stored in the 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 the processing of S3349 is terminated), or when the app is terminated (Yes in S3350).

[0420] 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" refers to the case where 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.

[0421] In S3342, the application user terminal 200 records information based on the element character string of a predetermined structure beginning with "$ui" ($ui.UI widget ID.Target Information Type) found in S3338 as an input item in the item definition list (item definition list 3433 in FIG. 34) created in memory 102. Specifically, the application user terminal 200 obtains a UI widget ID (item code, component identifier) ​​from the element character string of a predetermined structure beginning with "$ui" ($ui.UI widget ID.Target Information Type), and records that the UI widget is an input 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 right and the UI widget ID is "UI widget ID1," then the application user terminal 200 records that UI widget ID1 is present in the input item, as in item definition list 3433 in FIG. 34. Also, 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 in a sentence without "=", and the UI widget ID is "UI widget ID2", it will be recorded that UI widget ID2 is in the input item, as shown in item definition list 3433 in Figure 34.

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

[0423] In 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 has a value. For example, if "$ui.UI widget ID1.value" is entered in the description extracted in S3336, it determines whether the information of the type "value" in the UI widget with UI widget ID1 has a value. If the UI widget with UI widget ID1 is a TextField, the value is the text (character string) entered in the TextField. In other words, it determines whether the application user has entered text using the keyboard for UI widget 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 by the input item has a value, it proceeds to S3344; otherwise, it proceeds to S3345.

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

[0425] In 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 in S3335. If an action with a value for an input item was generated in S3344, the value of the input item is also transmitted to the runtime environment 400. For example, as the value of the input item, text information entered by the application user using the keyboard for UI widget ID1, which is a TextField displayed on the screen of the application 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 FIG. 33(b) described above, which is executed in the runtime environment 400, and the action corresponding to the trigger detected in S3335 is executed in the runtime environment 400, as described in S3314 to S3319.

[0426] In S3346, the application user terminal 200 determines whether or not the result of the action corresponding to the action request sent in S3345 has been received from the runtime environment 400. If the result of the action has been received, the process proceeds to S3347; if not, the process waits for the result of the action in S3346.

[0427] 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 the memory 102. For example, if the result of the action is an instruction to perform a screen transition, the screen transition is executed.

[0428] In S3348, the application user terminal 200 determines whether the result of the action 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.

[0429] In S3349, the application user terminal 200 displays the values ​​of the output items included in the result of the action received in S3346 in the output items displayed on the display 105, based on the information of the output items recorded in the item definition list 3433 held in the 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 widget for the output item, or if the type of information in question is "color," the color of the UI widget for the output item is changed to the color indicated by the value of the output item.

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

[0431] Using the example of a string in a programming language entered into the action board 910 shown in Figure 10(d), we will now explain in more detail 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.

[0432] The second line states "const userid = $ui.text_field_a.value;". Because "$ui" is on the right side of this statement, "text_field_a" is recorded as an input item in the item definition list in the processing of 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".

[0433] In the statement on line 4, because the character string "$ui.text_area_a.value" containing "$ui" is on the left side, "text_area_a" is recorded as an output item in the item definition list by the processing of S3340. That is, the value indicated on the right side of "=" (the output value obtained as a result of the action) is displayed in the UI widget "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 on the right side of "=" (the output value obtained as a result of the action) to the 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 includes logic (processing that is different from the definition of at least one of the input and output items). Similarly, line 6 is a logic portion, and because "$ui.text_area_a.value" is on the left side, it is treated as an output item.

[0434] Also, below is an example of an action string with "$ui" in a statement without "=".

[0435] (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 above string in the programming language is an action that registers the input values ​​(`$ui.PREF_CODE.value`, $ui.PREF_NAME.value) of the app screen to the database as parameters of the SQLSave function. In this case, $ui.{Component ID}.{Target Information Type} used as a parameter of the SQLSave function is identified as indicating an input item (because it is not on the left side of =).

[0436] In addition, in an element string with a predetermined structure using "$ui," the type of information to be targeted may be something other than a value, such as a color. For example, you can change the color of a UI widget by writing "$ui.UI widget ID.color = "#008000";".

[0437] In this embodiment, when describing an action to be entered into an action board, it is possible to express (define) whether a UI widget 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 position of the element string in the string (more specifically, its position within a single sentence). Conventionally, whether a UI widget is to be treated as an input item or an output item has been determined in a setting screen separate from the area where the content of the action is entered in a programming language. Conventionally, even when describing the content of the action in a programming language in the area where the content of the action is entered, it was necessary to declare whether the UI widget is to be treated as an input item or an output item using a variable in a statement separate from the statement of the logic portion that represents the processing itself. In contrast, in this embodiment, the definitions of input items and output items can be defined at any part of the string describing the action logic in a programming language. Therefore, the input items and output items used in the logic can be defined near the logic description portion, making it easy to set the input items and output items used in the logic when describing the logic. Furthermore, in this embodiment, there is no need to define variables for input and output items 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, in this embodiment, it is possible to more easily set input and / or output items used in logic entered in a programming language.

[0438] Furthermore, since the method of expressing whether an item is an input item or an output item depending on the position of an element string with a specific identifier "$ui" is not common, when a program is executed based on the normal JavaScript programming language, it does not properly interpret whether the item is an input item or an output item, and does not operate as intended. Therefore, in this embodiment, a mechanism is provided that operates correctly by performing a process of identifying and sorting whether a string containing "$ui" as an input item or an output item, as explained in S3338 to S3342.

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

[0440] Furthermore, in this embodiment, as described in S3304 of FIG. 33( a), development environment 300 generates execution environment program 3414, which is a program to be executed in execution environment 400, based on the UI definition information, and deploys it to execution environment 400. When executing an application, application user terminal 200 executes processing based on UI definition information 3431, and execution environment 400 executes processing based on execution environment program 3423. Furthermore, as described in S3338 to S3342 of FIG. 33( c), application user terminal 200 generates item definition list 3433 required for processing executed on application user terminal 200 based on the UI definition information. In this way, when accessing development environment 300 with developer terminal 100 to develop an application, the application developer does not need to be particularly conscious of distinguishing between information required for processing executed in execution environment 400 and information required for processing executed on application user terminal 200 when the constructed application is executed. Therefore, the developer can clearly distinguish and manage the information used in the execution environment and the terminal device when executing the application being developed, reducing the effort required for development and making software development easier.

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

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

[0443] Moreover, Fig. 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, 201. Fig. 36 is a diagram that schematically illustrates the transition of information due to the processing of the flowcharts in Fig. 35(a) to Fig. 35(c). In Fig. 36, the same information as in Fig. 34 is assigned the same reference numerals.

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

[0445] Unlike FIG. 34, FIG. 36 is configured such that UI definition information is not sent to application user terminal 200 (it is not even temporarily stored in application user terminal 200). This prevents detailed definitions of a developed application from being leaked via application user terminal 200, and improves 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 part of the developed application (for example, JavaScript code written in the 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 (the process of S3338 to S3342 in FIG. 33(c)) every time an action trigger occurs. This reduces the processing load on application user terminal 200, enabling application operation with a smooth response (response speed).

[0446] Steps S3501 to S3504 in Fig. 35(a) are the same as steps S3301 to S3304 in Fig. 33(a) described above, and therefore description thereof will be omitted. In Fig. 35(a), in addition to the processing in Fig. 33(a), processing from S3505 onwards is performed.

[0447] In S3505, the development environment 300 generates UI definition information for the client 3615. The UI definition information for the client 3615 is assumed to be a JSON file with the file name "uiDef2.json," for example. The UI definition information for the client 3615 includes, as information acquired from the UI definition information 3411, various setting information related to the application, such as the initial UI, information on UI widgets (components) for each UI screen (such as UI widget IDs and property settings, and the layout position and size of UI widgets), canvas action identifiers, and UI widget action identifiers. The UI definition information for the client 3615 also records input / output item definitions for each action (definitions of which components are included in the input and output fields). 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, which will be described later). Furthermore, the character strings (action source code) written in JavaScript (a programming language) on the action board are not recorded. That is, the generated UI definition information for client 3615 includes the action identifier and information on the input / output item definition for each action, but does not include information indicating the operation content of the action.

[0448] In S3506, the development environment 300 extracts the action description portion 3412 from the UI definition information 3411. In this process, not only descriptions relating to specific actions but also descriptions relating to all actions are extracted.

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

[0450] In S3508, the development environment 300 determines whether the character string "$ui" was found as a result of the search in S3337. If "$ui" was found, the process proceeds to S3509; if not, the process ends. The result in S3508 is No when all "$ui" searches have been completed or when there is no "$ui" at all in the action description portion.

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

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

[0453] In S3511, similar to S3341 in Figure 33(c), the development environment 300 determines whether the character string "$ui" 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; if not, the process proceeds to S3507. Note that if the determination in S3509 is No, this is equivalent to the character string "$ui" being found anywhere other than on the left side of the sentence containing the character, so the process may proceed to S3512 without making the determination in S3511.

[0454] In S3512, the development environment 300 records information based on the element character string ($ui.UI widget ID.Target Information Type) of the predetermined structure beginning with "$ui" found in S3338 as an input item in the client-use UI definition information 3615 generated in S3505. More specifically, in the array defining the input items in the client-use UI definition information 3615, a UI widget ID is obtained from the element character string ($ui.UI widget ID.Target Information Type) of the predetermined structure beginning with "$ui" found in S3338, and recorded in the "uiItemsIn" array of the input / output item definition for each action. For example, if "$ui" indicating that the UI widget ID is "INPUT_1" is found on the right side, it is recorded as shown in FIG. 36. Furthermore, if "$ui" indicating that the UI widget ID is "INPUT_2" is found in a sentence without "=", it is recorded as shown in FIG. 36.

[0455] After the process of S3512 is completed, the process proceeds to S3507, where the character string "$ui" is further searched for in the continuation of the description extracted in S3506, and the processes of S3507 to S3512 are repeated until it is determined in S3508 that "$ui" is not present. That is, the processes of S3509 to S3512 are performed for all character strings of $ui included in the description extracted in S3506, and whether they are input items or output items is recorded in the client UI definition information 3615.

[0456] 35(b) shows a flowchart of a modified example of application execution processing in the execution environment 400. This processing 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.

[0457] 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 of application user terminal 200 or 201. The application execution processing in execution environment 400 in FIG. 35(b) and the application execution processing in application user terminal 200 or 201 in FIG. 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).

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

[0459] In S3522, the runtime environment 400 transmits client-use UI definition information 3615 to the runtime environment 400 without transmitting UI definition information 3411 to the application user terminal 200. As a result, as shown in Fig. 36, client-use UI definition information 3625 recorded in the runtime environment 400 is downloaded to the application user terminal 200 and recorded as client-use UI definition information 3635. The client-use UI definition information 3615 and the client-use UI definition information 3635 are the same information.

[0460] The processing in S3523 to S3530 is similar to the processing in S3313 to S3320 in FIG. 33(b) described above, respectively, and therefore a description thereof will be omitted.

[0461] Steps S3541 to S3543 in Fig. 35(c) are similar to steps S3331 to S3333 in Fig. 33(c), respectively, and therefore description thereof will be omitted. However, in step S3543, a request to obtain UI definition information for a client is transmitted.

[0462] In S3544, the application user terminal 200 determines whether or not it has received client-use UI definition information from the runtime environment 400. The client-use UI definition information received here is the information transmitted from the runtime environment 400 in S3522 of FIG. 35(b) described above. If client-use UI definition information has been received, the process records the client-use UI definition information in memory 102 and proceeds to S3545; otherwise, the process waits for reception of client-use UI definition information in S3544. The client-use 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). Furthermore, the application user terminal 200 displays the application screen on the display 105 based on the client-use UI definition information 3635 recorded in memory 102.

[0463] In S3545, the application user terminal 200 determines whether or not 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; otherwise, the process proceeds to S3553.

[0464] The processes of S3546 to S3553 are similar to the processes of S3343 to S3350 in Fig. 33(c) described above, respectively, and therefore will not be described again. In this modification, the processes corresponding to S3336 to S3342 in Fig. 33(c) described above are not performed in the application user terminal 200.

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

[0466] (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.

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

[0468] [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:

[0469] [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:

[0470] [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:

[0471] [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; a control means for controlling, when an operation for placing 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 among a plurality of element screens of the first type component; An information processing system comprising:

[0472] [Configuration 3] a placement means for placing a first component of a first type on a development screen of the application; In the input area for the setting value of the first component arranged by the arrangement means, a default setting value is displayed in a form that allows a structure to be identified when written in a programming language. A display control means for controlling the display An information processing system comprising:

[0473] [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 ​​the specific environment, the specific environment being the second type environment and accessible to a user connected to the first type environment; a transmission control means for controlling 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; An information processing system comprising:

[0474] [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 or not 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:

[0475] [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:

[0476] [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; a control means for controlling the setting of each column of the table in response to a second operation on the setting screen; An information processing device comprising:

[0477] [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; 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 a column corresponding to the selected option and to receive an input operation for the action from a user; An information processing system comprising:

[0478] [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:

[0479] [Configuration 10] A control means for defining actions 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 defined actions as components to be displayed on the screen of the application software to be constructed (for example, placement of buttons with defined actions by workflow generation, UI screens with defined actions on canvases, placement of buttons by CRUD button placement, generation of UI screens, 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:

[0480] [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 acceptance 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:

[0481] [Configuration 12] a display control means for controlling display of a layout editing screen for the authenticatio...

Claims

1. an acquisition means for acquiring a character string input into an input field of a programming language; a specifying means for specifying whether the element string is information of an input item that is information to be acquired as input or information of an output item that is information to be output, based on the position of the element string to which a specific identifier is assigned in one sentence of the character string acquired by the acquiring means; 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:

2. The sentence is a semicolon-delimited sentence in the string.

2. The information processing system according to claim 1, wherein:

3. The content expressed by the above sentence includes processing that differs from the definition of at least one of the input item and output item.

2. The information processing system according to claim 1, wherein:

4. The specifying means specifies that the element character string is information of an output item if the element character string is located on the left side of an equal sign in a sentence in the character string.

2. The information processing system according to claim 1, wherein:

5. The identifying means identifies the element character string as information of an input item if the element character string is located at a position other than the left side of an equal sign in a sentence in the character string.

2. The information processing system according to claim 1, wherein:

6. The identifying means identifies the element character string as information of an input item if the element character string is in a sentence that does not include an equal sign.

2. The information processing system according to claim 1, wherein:

7. A specific identifier must begin with a Unicode dollar or underscore character and contain at least one character.

2. The information processing system according to claim 1, wherein:

8. The specific identifier is a half-width $ui.

8. The information processing system according to claim 7, wherein:

9. The element character string includes the specific identifier, an identifier of an item to be displayed on the screen, and an identifier of the type of information to be output or input for the item.

2. The information processing system according to claim 1, wherein:

10. The element character string is a character string in which the specific identifier, the identifier of the item to be displayed on the screen, and the identifier of the type of information to be output or input for the item are separated by periods.

10. The information processing system according to claim 9, wherein:

11. a display control means for controlling the display of the 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 the character string input in the input area; and The specifying means is included in a terminal device that accesses the execution environment of the application when executing the application.

2. The information processing system according to claim 1, wherein:

12. The information processing system includes: a display control means for controlling the display of the 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 the character string input in the input area; and The information processing system includes: the recording control means includes at least one of a development environment in which the definition information is recorded and an execution environment of the application; At least one of the development environment and the execution environment has the identifying means.

2. The information processing system according to claim 1, wherein:

13. A control method for an information processing system, comprising: an acquisition step in which acquisition means of the information processing system acquires a character string input into an input field of a programming language; an identifying step in which an identifying means of the information processing system identifies whether the element string is an input item, which is information to be acquired as input, or an output item, which is information to be output, based on the position of the element string to which a specific identifier is assigned in one sentence of the character string acquired in the acquiring step; a control step in which a control means of the information processing system controls the execution of a program based on the character string, reflecting the content identified in the identification step; 1. A method for controlling an information processing system, comprising:

14. A program for causing at least one computer to function as each of the means of the information processing system according to any one of claims 1 to 12.