JP2024149188A - Information processing system, information processing method, and program - Google Patents

Abstract

To provide a control method and a program of an information processing system allowing a developer to develop applications anywhere on a terminal connected to the Internet.SOLUTION: An information processing system includes: a developer terminal operated by a developer user; a development environment, the multi-tenant environment; an execution environment constructed by combining a plurality of Web services (cloud services); single-tenant execution environments 1 to 3 in which an application developed by a developer, the owner, using the development environment is deployed; and an application user terminal used by the user who uses the application. The developer logs into the development environment, receives a client program and application definitions (UI definition information), the content saved by performing the development work in the past, performs an operation for newly designing an application or an operation for updating the design of an existing application, and stores definition information of the application as a result thereof in the development environment.SELECTED DRAWING: Figure 1

Description

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

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

Patent document 1 discloses providing the generated application package to the user for download.

JP 2019-8598 A

When downloading a file using the method of Patent Document 1, it is only possible to download files that are located on a server. Furthermore, when dynamically generating and downloading data, the application developer must write complex processing. As a result, it has not been possible to generate a screen that includes download processing in a versatile manner.

The present invention aims to provide a mechanism for easily building an application that executes the desired processing related to downloading data.

The information processing system of the present invention comprises:
A reception control means for controlling reception of instructions regarding the processing contents of components to be arranged on an application screen;
A construction control means for controlling construction of an application including a screen displaying the component;
When the component is a component related to data downloading, the construction control means is characterized in that it comprises an execution control means for controlling, when an operation on the component is received from a user of an application constructed by the construction control means, to execute processing based on the processing content received by the reception control means.

The present invention makes it easy to build an application that executes the desired processing related to downloading data.

FIG. 1 is a system configuration diagram of an information processing system. FIG. 2 is a hardware block diagram of a developer terminal 100, an application user terminal 200, and an application user terminal 201. 13 is a flowchart of a login process. 13 is a flowchart of a UI editor process. 13 is a display example in login processing and UI editor processing. 13 is a display example of a tab part and an AppBar in a UI editor process. 13 is a flowchart of a context menu process. 13 is a flowchart of an action board process. 13 is a display example for explaining an action board process. 13 is a display example in action board processing. 3 is an example of source code generated by the development environment 300. 13 is a flowchart of a screen switching process. 11 is a flowchart of processes executed in the developer terminal 100, the development environment 300, and the execution environment 400, respectively, for displaying user information of an application. 1A is a specific example of developer information 301. FIG. 1B is a specific example of user information 411 in a multi-tenant execution environment. FIG. 1C is a specific example of user information in a single tenant execution environment. 13 is an example of user information display. 1 is a flowchart of a workflow process. 13 is a display example relating to a workflow process. 11 is a display example of a database, UI parts, and actions generated by workflow processing. 13 is a flowchart of a canvas context menu process. 13 is a display example relating to the CRUD generation process. 13 is a display example of databases, actions, and functions generated by the CRUD generation process. 13 is a flowchart of a developer account registration process. 1 shows details of a DB set in an execution environment. 13 is a flowchart of a deployment process. This is a display example when deploying a mobile app. 13 is a display example of a UI editor screen relating to a template screen. 13 is a display example on a canvas of a template screen. This is an example of the property box. 13 is a display example of an action board in which an action has been input. 13 is a flowchart of a data grid context menu process. This is an example of the display in the property box of a data grid. This is an example of a display on the action board of a data grid. 13 is a flowchart showing the execution of an action. FIG. 11 is a transition diagram of UI definition information including action information. 13 is a flowchart showing the execution of an action in a modified example. FIG. 11 is a transition diagram of UI definition information including action information in the modified example. 13 is a flowchart illustrating an upload/download process. This is an example of component settings related to upload. 13 is a display example of an action board related to upload processing. This is an example of a file upload operation by an app user. 13 is a diagram showing an example of an action execution result related to upload processing. 13 is a display example of an action board related to a download process. 13 is a display example of a screen on which a download process can be executed.

The embodiments are described in detail below with reference to the attached drawings. Note that the following embodiments do not limit the invention according to the claims, and not all combinations of features described in the embodiments are necessarily essential to the invention. Two or more of the features described in the embodiments may be combined in any desired manner. In addition, the same reference numbers are used for the same or similar configurations, and duplicate descriptions are omitted.

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

<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.

The developer terminal 100 is an information processing device (information processing terminal) operated by a developer user that can be configured using 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.

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

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

The execution engine 302 is at least one hardware resource for executing the 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. Among the various flowcharts described below, those described as being executed by the development environment 300 are executed by the execution engine 302. In other words, the program recorded in the memory 304 is expanded by the processor 303 into an area of the development environment 300 that serves as a work memory, and executed.

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

Storage 320 is a memory area of at least one recording medium, and stores at least a client program 322 that is common to each developer. It also has a developer area, which is a memory area for each developer account. For example, if there are developer A, developer B, and developer C as developers who can 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 each developer. For example, developer A area 323 stores app definition 323a (including app UI definition information and app execution environment program, which will be described later in FIG. 34).

The developer accesses the development environment 300 by accessing the URL for accessing the development environment 300 from the browser software of the developer terminal 100, and logs in to the development environment. When the developer logs in to the development environment, the developer receives the client program 322 and the application definition (UI definition information) that is the content of the past development work and saved from the development environment. The developer then performs an operation to design a new application or an operation to update and design 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 saves 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 there is a terminal that can connect to the Internet, the developer can develop an application regardless of location.

The execution environment 400 is an environment using at least one hardware resource constructed on a network (on a cloud or on the Internet). The execution environment 400 includes a multi-tenant execution environment 410 and multiple single-tenant execution environments (for example, single-tenant execution environments 450, 460, 470). The execution environment 400 is constructed by combining multiple Web services (cloud services). The execution environment 400 is an environment for deploying definition information (application definition) of an application developed using the developer terminal 100 and the development environment 300. The application user terminals 200 and 201 used by users who use the application access the execution environment 400 by accessing a URL for executing the application. The execution environment 400 executes various actions according to operations performed on the application user terminals 200 and 201, thereby executing the developed application and providing the application user with the functions of the application. The application constructed in the execution environment 400 on the network is a so-called WEB application.

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

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

The execution engine 412 is at least one hardware resource for executing processing to be executed in the 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 may be 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. Among 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, the processor 413 deploys and executes the program recorded in the memory 414 in an area of the multitenant execution environment 410 that serves as a work memory. The program executed here includes a program that executes the action of an application.

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

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

The DB set 430 is a group of information about a database used by an application deployed in the execution environment 410. The DB set 430 is stored in the storage area of at least one recording medium. Details of the DB set 430 will be described later with reference to FIG. 23.

Single tenant execution environments 1 (450), 2 (460), and 3 (470) are each execution environments dedicated to one developer (one developer account), and applications developed by the developer who is the owner using the development environment 300 are deployed. 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 way, one developer can own multiple single tenant execution environments. Single tenant execution environments 1 (450), 2 (460), and 3 (470) each include user information 451, 461, and 471, execution engines 452, 462, and 472, distribution engines 455, 465, and 475, storage 456, 466, and 476, and DB sets 457, 467, and 477. These 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, except that they are dedicated to one developer, so detailed explanations will be omitted. It is possible to build many more single-tenant execution environments than the three shown in the figure.

Using the system 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 environment for a fee. The operator of this system must pay maintenance costs to the resource and service provider (cloud service operator) 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 bear the costs for trialing the system, making it easy 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.

There is an upper limit to the number of processing requests that can be processed per unit time in one execution environment, and if many applications are built in a multi-tenant execution environment and many app users access it simultaneously, it is possible that the requests cannot be processed and the applications may run slowly. In addition, there are some restrictions on the deployment and execution of many applications developed by many developers in a multi-tenant execution environment, and these restrictions may prevent the applications from performing adequately. If developers pay to own a dedicated single-tenant execution environment, they can avoid (or reduce) problems caused by the restrictions of such multi-tenant execution environments. In other words, by building applications in a single-tenant execution environment, applications that perform adequately can be built.

Considering the characteristics of both the multi-tenant single environment and the single-tenant execution environment, developers can use this system as follows. For example, when using this system for the first time, developers can build an application developed using this system in the multi-tenant execution environment 410 and test it, and then, if they determine that this system is useful for the developer's software development, they can introduce the single-tenant execution environment for a fee. In addition, when a developer develops a specific application X, an alpha version of application X is built in the multi-tenant execution environment 410 for a limited number of test users to try out before releasing it to general users. There, application X is tested, and modifications are made to application X, and further development is carried out. Then, after the development is completed to a level where it can be released to general users without any problems, a production version of application X is built in the single-tenant execution environment and released to general users. By using it in this way, developers can reduce development costs during the development period and operate applications that can be used by a large number of general users without any problems.

Figure 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 Figure 2, CPU 101, memory 102, non-volatile memory 103, image processing unit 104, display 105, operation unit 106, recording medium I/F 107, external I/F 109, and communication I/F 110 are connected to internal bus 150. Each unit connected to internal bus 150 is capable of exchanging data with each other via internal bus 150.

The memory 102 is, for example, a RAM (such as a volatile memory using semiconductor elements). The CPU 101 uses the memory 102 as a work memory to control each part of the information processing device according to a program stored in, for example, the non-volatile memory 103. The non-volatile memory 103 stores image data, audio data, other data, various programs for the operation of the CPU 101, and the like. The non-volatile memory 103 is, for example, a hard disk (HD) or a ROM.

Based on the control of the CPU 101, the image processing unit 104 performs various image processing on image data stored in the non-volatile memory 103 or 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. Also, depending on the type of image processing, it is possible for the CPU 101 to perform image processing according to a program without using the image processing unit 104.

Under the control of CPU 101, display 105 displays images and GUI screens constituting a GUI (Graphical User Interface). CPU 101 generates a display control signal according to a program, and controls each part of the information processing device to generate a video signal for display on display 105 and output it to display 105. Display 105 displays an image based on the output video signal. Note that the configuration of the information processing device itself is limited to an interface for outputting a video signal 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 in the 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.

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 planar panel overlaid on the display 105 and outputs coordinate information according to the touched position.

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

<Login process>
3A and 3B show flow charts of the login process. This process is a process from logging in to the development environment 300 from the developer terminal 100 to displaying a UI editor. When the developer terminal 100 starts 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 of FIG. 3A is started. The process of FIG. 3A is realized by the CPU 101 of the developer terminal 100 expanding a program recorded in the non-volatile memory 103 for executing the Internet browser software and a client program 322 received from the development environment 300 in the memory 102 and executing them. Hereinafter, what is simply described as a process executed by the developer terminal 100 is assumed to be a process in which the CPU 101 of the developer terminal 100 expands a program recorded in the non-volatile memory 103 for executing the Internet browser software and a client program 322 received from the development environment 300 in the memory 102 and executes them.

When an internet browser software is launched on the developer terminal 100 and the URL of the development system (application development platform) of this embodiment is specified and accessed, the distribution engine 305 of the development environment 300 detects the access and transmits the client program 322 to the developer terminal 100 that is the source of the access.

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.

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

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

In S304, the developer terminal 100 accepts input operations into the input fields 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 an email address. In addition, the password used as the secret information is an arbitrary character string, but it may be other secret information such as biometric authentication information (fingerprint authentication is information used for face authentication) or pattern authentication information (information of a trajectory pattern entered on the screen).

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

In S306, the developer terminal 100 performs a developer account registration process. Details of the developer account registration process will be described later with reference to FIG. 22(a).

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

In S308, the developer terminal 100 transmits the information entered in the developer ID and password input fields on the login screen (the entered developer ID and password) as login information to the development environment 300. After transmission, an authentication process is performed in the development environment 300, and the result is awaited.

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

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, proceed to S311; if not, return to S309.

In S311, the developer terminal 100 records the execution environment list received in S310 in memory 102 as the development screen for the app after login, and displays execution environment options based on the received execution environment list on the 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 are different from the screen of the constructed app are collectively referred to as development screens.

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

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

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 it 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 app information, information (such as app IDs and app names) that identifies all applications owned by the logged-in developer (applications that have been generated in the past and recorded in storage 320).

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

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

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

In S317, the developer terminal 100 records the application selected from the list of apps as the "selected app" in memory 102, along with information identifying the selected app (such as the app ID and app name), and transmits it to the development environment 300. When the development environment 300 receives the information identifying the selected app, it retrieves definition information (app definition) for the selected app from the area of storage 320 that is associated with the logged-in developer, and transmits it to the developer terminal 100.

In S318, the developer terminal 100 determines whether or not it has received definition information (UI definition information) of the selected application from the development environment 300. If it has received definition information of the selected application, it records the received definition information of the selected application in memory 102 and proceeds to S319, otherwise, it waits for the 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 described in Json format. Thereafter, when the selected application is displayed on the display 105, it is displayed based on the definition information recorded in memory 102. When an operation for updating the selected application (for example, changing the arrangement of UI parts) is performed 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 given, the latest definition information recorded in memory 102 is sent to the development environment 300 and saved in the login developer's area of the storage 320. In this way, an increase in the frequency of communication with the development environment 300 is suppressed, and a decrease in response due to communication is suppressed, making it possible to perform a comfortable update operation.

In S319, the developer terminal 100 displays a UI editor screen on the display 105 and displays based on the received definition information. For example, a canvas (editing area of the UI screen) with a shape according to whether the selected application is for desktop or mobile (i.e., a shape according to the type of device using the application) is displayed. If it is for desktop, a rectangular canvas with a ratio of 16:9 is used, and if it is for mobile, a canvas with a vertical aspect ratio imitating a smartphone is used. In the submenu area (described later), a list of UI screens that the selected application has (belongs to the selected application) is displayed (this process is strictly performed in S401 in FIG. 4 described later). In addition, the canvas displays components (UI parts to be placed on the UI screen) that are placed on the UI screen selected by default (initial UI or the UI screen that was edited when last saved). 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 is terminated in the process of S319, and the process proceeds to S401 in FIG. 4.

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

In S321, the developer terminal 100 displays a selection screen for whether the newly created application is for desktop (PC) or 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 app user terminal 200 such as a desktop PC or notebook PC. A mobile application is an application that is intended to be accessed and operated from an app user terminal 201 such as a smartphone.

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

In S323, the developer terminal 100 displays a UI editor screen as an editing screen for the newly created application. In this case, the canvas is displayed in a shape according 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 the process of S323, and the process proceeds to S401 in FIG. 4.

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

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

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

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

In S335, the development environment 300 transmits to the developer terminal 100 a list of execution environments of the developer (login developer) whose login has been approved, which is included in the developer information 301. In addition to the email address (username, developer ID) and password, the developer information 301 records the accessible execution environment ID for each developer, as shown in FIG. 14(a). Each execution environment ID is an account ID in a cloud service (Web service), and is a 12-digit ID in this embodiment. In the case of a developer who can access multiple execution environments, the 12-digit execution environment ID is recorded separated by a comma. In S335, the accessible execution environment ID (one or more execution environment IDs separated by a comma) for the login developer is transmitted to the developer terminal 100. That is, in S335, the execution environment that the login developer can access is specified by referring to the developer information 301. In this way, the accessible execution environment of each developer (the execution environment that each developer can use) is recorded in the developer information 301 recorded in the development environment 300. This execution environment that can be logged in can only be obtained by the developer who has been granted permission to log in. Furthermore, only the execution environment that can be accessed by the developer who has been granted permission to log in can be obtained. In this way, the developer does not need to manage information for accessing the execution environment that can be accessed by the developer separately from information for logging in to the development environment 300. It is also possible to prevent other users from illegally accessing the execution environment.

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

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

In S338, the development environment 300 retrieves app information indicating all applications owned by the logged-in developer (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 app information transmitted here is only the app definition information necessary to display the app list mentioned above in S315, and does not include detailed definition information about each app (such as component placement and information indicating actions, which will be described later).

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

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

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

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

<UI Editor Processing>
The UI editor process is described below with reference to Fig. 4 and Fig. 5B. The UI editor process is a process for performing various definitions (UI part definitions, action definitions) of an application to be constructed in response to operations by a developer (user) on a UI editor screen (application development screen).

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

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

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

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

The selected UI screen box 503 displays the name of the UI screen being edited as information representing the UI screen being edited in 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 based on the definition information of the selected app acquired in S318 is displayed as a pull-down menu, and it is possible to change the UI screen to be edited and displayed on the canvas 530 by selecting any UI screen from the list.

In the main menu area 510, an app list button 511, a UI screen button 512, a workflow button 513, a settings button 514, an environment list button 515, a database button 516, a file manager button 517, a user management button 518, and a snapshot button 519 are displayed as option icons for the menu items of the main menu. The processing in response to pressing these options will be described later in the screen switching processing of FIG. 12.

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

The canvas 530 is a layout editing area for the selected UI screen of the selected application (the UI screen of the UI screen name displayed in the selected UI screen box 503). The canvas 530 in FIG. 5B is an example of a canvas display for a desktop application, and is displayed in a desktop shape. The user can select any UI part (UI component) from the UI parts list displayed in the submenu area 520 and place it in the canvas area 530 by dragging and dropping it. The size and position of the UI part placed in the canvas area 530 can be adjusted by selecting it. In addition, by selecting a UI part placed in the canvas area 530 and right-clicking it to display a right-click menu (context menu), more detailed settings such as color scheme can be made. Furthermore, by selecting an action also included in the context menu, an action board is displayed, and an action to be executed when the UI part is operated can be set. By right-clicking with the cursor in a blank area of the canvas 530, the canvas's context menu can be displayed, and by selecting an action from the menu, it is possible to set the 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).

Figure 5 (b) shows an example in which a pie chart 531, a button 532, text fields 533 and 534, an output field 535, and a tab component 536 are arranged as UI components on a canvas 530 with a UI screen name "ui1" of an application with an application name "UI1". 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.

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

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

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

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

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

In S405, the developer terminal 100 displays a list of UI parts in the submenu area 520. That is, the display is switched from the UI screen list of the selected application to the UI parts list. UI parts that can be arranged on the canvas 530 include types INPUT, Button, Display (information display part), Navigation, Layout, and Chart, and multiple UI parts are classified into each type. In the UI parts list, first, as shown in FIG. 5(c), a list of UI part types is displayed, and in response to an operation to select one of the displayed types, UI parts classified into the selected type are expanded and displayed. The above-mentioned FIG. 5(b) is an example in which the option 522 of the type corresponding to INPUT is selected and a list of UI parts classified into INPUT is displayed. UI parts classified into INPUT include, for example, a text field 523 and a text area 524. The submenu area 520 is scrollable, and options that cannot be displayed (options for the UI part of the expanded type and options for other types) can be scrolled to display them. When an option 522 for an expanded type is operated as in FIG. 5(b), the list of UI parts of the expanded type is collapsed, and a list of UI part types is displayed.

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

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

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

The tab part will be described with reference to Figures 6(a) and (b). Figure 6(a) is an example of a display on the display 105 when a tab part 601 is placed on a canvas 530 that displays a UI screen different from that shown in Figure 5(b). The range indicated by the operation bus 601a of the tab part 601 is the occupied area of the tab part 601. By operating the operation bus 601a, the overall display position and overall display size of the tab part 601 including the element screen can be changed. The tab part 601 has three tabs, tab 610, tab 620, and tab 630. Labels that can be set by the developer in the property settings of the tab part are displayed as tab names on each tab. In the illustrated example, Tab0, Tab1, and Tab2 are displayed, respectively. The number and order of tabs can be changed from the property settings of the tab part. Tab property setting is performed by an operation to open a tab property box from the tab's context menu in S706 of the context menu process described later in FIG. 7, and a setting operation for the tab property box (setting screen) displayed in response to the operation. The element screen area 602 indicated by the dashed line (illustrated for explanation purposes, not displayed) is an area in which the display contents change depending on the selected tab. The display contents corresponding to each tab displayed in the element screen area 602 are called the element screen corresponding to each tab. Different UI parts can be arranged on the element screen corresponding to each tab. The example of FIG. 6(a) is an example in which the tab 610 is selected and the element screen corresponding to the tab 610 is displayed. In the illustrated example, the UI parts 611 and 612 are arranged on the element screen corresponding to the tab 610. The example of FIG. 6(b) is an example of a display in which the tab 620 is clicked from the state of FIG. 6(a) and the selected tab is changed from the tab 610 to the tab 620. In FIG. 6(b), the element screen area 602 displays the element screen corresponding to the selected tab 620. In the illustrated example, a UI part 621 is arranged on the element screen corresponding to the tab 620. In the examples of FIGS. 6A and 6B, the definition information records at least the UI part ID (UI part identification information) of the tab part 601 and the position of the tab part 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 the UI parts 611 and 612 and the respective positions of the UI parts 611 and 612 in the element screen of the tab 610 are recorded in association with the ID of the tab 610 of the tab part 601. Also, the ID of the UI part 621 and the position of the UI part 621 in the element screen of the tab 620 are recorded in association with the ID of the tab 620 of the tab part 601. Return to the description of FIG. 4.

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

In S410, the developer terminal 100 places the UI part selected in S406 from the submenu area 520 in the element screen (currently displayed element screen) corresponding to the selected tab among the tab parts at the specified position on the canvas 530 in a default size, and records the information defining this in the definition information recorded in the memory 102. That is, in the definition information, the type of the UI part placed in S410, the ID of the tab part as the UI part ID, the ID of the tab selected in the tab part, the placement coordinates in the element screen corresponding to the selected tab, the placement size, etc. are associated with the ID of the UI screen to which the UI part is to be placed (the UI screen being edited), and recorded. In this way, in this embodiment, it is possible to place and layout different UI parts on each element screen corresponding to each tab of the tab part. In addition, at this time, there is no need to perform complicated operations to define the tab of the element screen to which the UI part is to be placed, and it is sufficient to simply select and display the element screen to which the UI part is to be placed when placing the UI part to be placed by dragging and dropping it.

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

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

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

In S414, the developer terminal 100 switches the display of the element screen area of the tab part to the element screen corresponding to the tab at the position specified by clicking in S411. For example, in response to clicking on any of the three tabs displayed as ITEM1, ITEM2, and ITEM3 among the tab parts 536 in S411, the operation path is displayed for the tab part 536 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 is as shown in FIG. 6(a), the display is switched to that of FIG. 6(b) in response to the specification of the tab 620. That is, the UI parts 611 and 612 arranged on the element screen displayed before the click are hidden, and instead, the UI part 621 arranged on the element screen corresponding to the clicked tab 620 is displayed. Such control is performed in order to simplify the operation of defining the element screen of the desired tab to be placed when the developer wants to place another UI part on the element screen of the desired tab of the tab part. If a developer wants to place another UI component on the element screen of a desired tab of a tab component, they can simply click on the desired tab to display the desired element screen before dragging and dropping the desired UI component.

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

On the other hand, in the case of other UI parts that are not of a specific type, such as tab parts, the display content within the UI part is not changed in response to the selection of the UI part on canvas 530. The only processing performed in response to the selection of the UI part is processing related to the display of the operation bus, 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 (processing executed when button 532 is pressed in the constructed app) is not executed. Also, when text field 533 is selected on canvas 530, only the operation path is displayed, and processing such as displaying a character input cursor within text field 533 is not performed.

Using Fig. 6(c), Fig. 6(d), and Fig. 6(e), an example of AppBar will be described as an example of a type of UI part to which the processes of S409, S410, S413, and S414 can be applied in the same way as with the tab part. Fig. 6(c) is an example in which UI parts AppBar650, TextField661, and Button662 are arranged on the canvas 530. AppBar650 is one UI part, and includes element icons 651 and 652. In the constructed application, element icon 651 is a display item that accepts an instruction to display a drawer menu. In the constructed application, element icon 652 is a display item that accepts an instruction to display a pop-up menu. In the canvas 530, when the positions of element icons 651 and 652 of the arranged AppBar650 are clicked, they are controlled in the same way as the tab part of the tab part. More specifically, it is controlled as follows:

When the position of element icon 651 in placed 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 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), operation path 650a for AppBar 650 is displayed, and 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 pulling out from the left edge of the screen to the right, and displays one or more menu items. With the drawer menu 651a displayed, other UI components can be dragged from the submenu area 520 and dropped onto the drawer menu 651a, similar to the process described in S408 and S410 using the tab component as an example, to place other UI components on the drawer menu 651a.

When the position of the element icon 652 in the placed AppBar 650 is clicked (Yes in S411), the operation path for the AppBar 650 is displayed (S412), and the result of the determination in S413 is Yes, 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), the operation path 650a for the AppBar 650 is displayed, and a pop-up menu 652a, which is an element screen corresponding to the element icon 652, is displayed. The pop-up menu 652a is an area displayed near the element icon 652, and displays one or more menu items (options). With the pop-up menu 652a displayed, other UI parts can be placed on the pop-up menu 652a by dragging another UI part from the submenu area 520 and dropping it on the pop-up menu 652a, similar to the processing described in S408 and S410 using the tab part as an example. Return to the description of FIG. 4.

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

In S417, the developer terminal 100 determines whether or not an operation has been performed on the operation path of a UI component already placed on the canvas 530. If an operation has been performed on the operation path, the process proceeds to S418; if not, the process proceeds to S419. In S418, the developer terminal 100 changes the size of the UI component (selected component) to which the operation path has been assigned in response to 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.

In S419, the developer terminal 100 determines whether or not an instruction operation (in this embodiment, a right click of the mouse) to display a context menu has been performed in any area of the canvas 530. If a right click has been performed, the process proceeds to S420, and 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 has been performed, and a context menu process is performed to perform a process according to the operation on the context menu. For example, if a right click is performed with the mouse cursor on the button 532 in FIG. 5(b), a context menu 540 related to the button 532 (designated UI part) as shown in FIG. 5(d) is displayed. The context menu 540 displays properties 541, actions 542, and delete 543 as menu items to be selected. When properties 541 is selected, a property box (detailed settings dialog) related to the button 532 is displayed, and detailed settings such as the button name (label) to be displayed on the button 532, the color of the button 532, and the size specified by a numerical value can be performed. When action 542 is selected, an action board related to button 532 is displayed, and an action can be input to the action board in JavaScript, a programming language. The action input here is the process to be executed when button 532 (designated UI component) is pressed in the constructed application. When delete 543 is selected, button 532 is deleted (removed) from canvas 530. Details of the context menu process will be described later with reference to FIG. 7.

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

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, and if not, the process proceeds to S425. In S424, the developer terminal 100 performs a preview process. In the preview process, the canvas 503 is hidden, and a preview is displayed of the UI screen being edited on the canvas 503, 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 if the UI screen were viewed in the constructed application. In the preview, the operation path for operating the UI parts is not displayed. In addition, some operations that are not performed on the UI editor screen (not performed by operations on the canvas 530) are performed in the preview. For example, when a UI part for screen transition or a link part is operated, a screen transition or a transition to a link destination is performed. In addition, an operation such as moving a selection frame for an item by operating the tab key on the keyboard is also performed. Note that actions entered by the developer in the action boat and database references will not be performed. Instead, the preview process can be displayed faster than if you were to actually deploy and check the results.

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 deploy process. The deploy process will be described later with reference to FIG. 24(a). When the deploy button 506 is pressed to execute the deploy process, the developer does not need to select the execution environment to which the application is to be deployed, and the deployment is performed to the selected execution environment that has been selected in advance and is displayed in the selected execution environment box 501. In many cases, developers work to update the contents to be deployed to a specific execution environment all at once. Therefore, in this system, the execution environment to which the application is to be deployed is selected before the selection of the application to be updated (S311 in FIG. 3), and the execution environment is not selected each time the application is deployed. This prevents operational errors such as accidentally deploying to an unintended execution environment, and also makes the work more efficient. Furthermore, although an operation for authentication processing is performed when logging in to the development environment 300, there is no need to perform a separate operation for account authentication processing for the execution environment to be deployed to. This makes it possible to prevent an increase in the amount of work required and to work efficiently. In other words, the developer terminal 100 does not obtain authentication information related to the execution environment to which the development is to be performed from the developer user.

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

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

In S430, the developer terminal 100 determines whether 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 for 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.

In S431, the developer terminal 100 determines whether or not an operation has been performed to select any 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 the screen switching process described later in FIG. 12. If not, the process returns to S406.

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

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

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

In S703, the developer terminal 100 performs canvas context menu processing. Canvas context menu processing will be described later with reference to FIG. 19.

In S704, the developer terminal 100 determines whether the context menu to be displayed is related to a UI component of type data grid (table). More specifically, it determines whether the type of the UI component (specified UI component) specified 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, and if not, the process proceeds to S706.

In S705, the developer terminal 100 performs context menu processing of the data grid. Context menu processing of the data grid will be described later with reference to FIG. 30.

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

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

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

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

In S713, the developer terminal 100 displays a property box for the button superimposed on the canvas 530 as a property box (detailed settings dialog) for the specified UI part. Then, various setting operations for the property box are accepted. Here, detailed settings can be made, for example, such as the button name (label) to be displayed for the button, which is the specified UI part, 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 part is displayed on the canvas 530 in a display form that reflects the settings.

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

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

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

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

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

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

Meanwhile, in S721, the developer terminal 100 displays a context menu for the template screen and for a button, as shown in FIG. 26(d), superimposed near the specified position (mouse cursor position) as a context menu for the specified UI part. 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 part 2634 in FIG. 26(d)) does not display options such as action or delete, but only properties. In other words, for UI parts placed on the template screen among the UI screens, the developer is not allowed to set the action to be taken when the UI part is operated. The reason for this will be explained later.

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

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

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

9B is an example of the display of an action board for a UI part 901. The action board 910 is displayed in place of the canvas in the area where the canvas 900 was displayed. If the part is not a template part (template component) that is placed in advance on the template screen, and if the developer has not previously set an action for the specified UI part, the action board 910 is displayed blank as shown in FIG. 9B. Note that the "1" displayed on the action board 910 is a guide display indicating the number of lines, and is not the content of the action. The developer can set any action on this action board 910 by operating the keyboard included in the operation unit 106 and inputting any character string in JavaScript, which is a programming language. The trigger for executing the content set on the action board is predetermined, and is the operation of the specified UI part. Therefore, the developer does not need to set what the trigger for executing the action is (it is not necessary to write it in JavaScript). For example, if the specified UI part is a button, pressing that button in the constructed app will be the trigger, and when the trigger occurs, the action set in the action board for that button will be executed.

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

When the Add Function button 921 is pressed, a dialog box for adding an original function (called the Add dialog 930) is displayed. FIG. 9(c) shows an example of the Add dialog 930. The Add dialog 930 displays a type selection field 931 that accepts the selection of the function type, a function name input field 932 that accepts the input of the function name, and a SAVE button 933. When input is made to the Add dialog and the SAVE button 933 is pressed, a setting screen for the function 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.

9D 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). In addition, 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 in front of "rest01" indicates that the type of the function 923 is a REST function. If all required setting items are not 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, and the corresponding function 923 is identifiably in an incomplete state.

The REST function setting screen 940 in FIG. 9D displays setting fields 941 to 944. The setting field 941 is a setting screen for the function name, and in the initial state, the function name entered in the function name input field 932 is displayed, but it can be changed according to input operations from the developer. The 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. It is displayed grayed out to indicate that it cannot be changed. The setting field 943 is a setting field for setting the type of the REST function. By operating the triangular icon on the right end of this area, GET, POST, PUT, and DELETE are displayed as options in a pull-down menu, and one of the options can be selected and set. The type set here is the type of request made by this function. The 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 the source code string in a programming language.

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

10A is an example of a display 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, in the function list 920, the function 924 with the function name "sql01" entered in the function name input field 932 is displayed as a function option together with an incomplete mark 929. The icon displayed in front of "sql01" indicates that the type of the function 924 is an SQL function. The setting field 951 is a setting screen for the function name, and in the initial state, the function name entered in the function name input field 932 is displayed, but it 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 as the default and cannot be changed. It is displayed as grayed out to indicate that it cannot be changed. The setting field 953 is an input field for inputting a character string (SQL sentence, SQL statement) that issues an instruction to a database in SQL (a database language, not a programming language), which is a type of computer language. The developer can input any SQL STATEMENT into the setting field 953 using a keyboard included in the operation unit 106 or the like. 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 the source code in a programming language.

FIG. 10B shows an example of the display at the stage where the developer has created functions 923-925, input (describe) some code (character string) in JavaScript into the action board 910, and then inputs "sq". In this embodiment, when the developer user inputs a character string, if the input character string matches the function name (identification information) of an already created created function, the code assist field 911 displays the matching function name as an input candidate option. In the example shown, the input "sq" matches the function name "sql01" of function 924, which is an already created created function, so "sql01" is displayed as an option. When the user performs an operation to select "sql01" displayed in the code assist field 911, "sql01" is input into the action board 910 as shown in FIG. 10C, even if the user does not perform an operation to input "sql01". This code assist function allows the developer (user) to input the function name (identification information) of the created function without typing all the characters of the function name of the created function on the keyboard, which contributes to reducing the number of operations. In addition, if the function name matches the beginning of the function name of an already created created function, the full name is displayed in the code assist field 911, and if there is no match (i.e., if there is no function starting with that character string), the code assist field 911 is not displayed. Therefore, the developer can input the function name of the created function that he or she created before confirming that it is correct, and can prevent inputting a function name mistake. Note that if there are multiple created functions that match the beginning of the function name, multiple options are displayed in the code assist field 911. In addition, the function names of the created functions displayed in the code assist field 911 are functions created for the specified UI part (UI part 901 in the illustrated example) that is the target of the action board 910, and created functions created for other UI parts are not displayed. Therefore, it is possible to prevent the mistake of writing the function name of a created function created for another UI part, which does not exist as a created function for the specified UI part, in the action board 910.

As shown in FIG. 10C, the function list 920 displays the type of function (icon before the character string) and the name of each of the functions 923 to 925 of the created functions created by the developer together with the action board 910. Therefore, the developer user can check what type and name of the created function has been created while inputting (writing) the action code (character string in JavaScript) in the action board 910. This reduces the effort of checking and managing valid created functions that can be written in the action board 910 (for example, the effort of making a note of them at hand or opening another screen to check). It also contributes to preventing input errors in function names. The functions displayed in the function list 920 are functions created for the specified UI part (UI part 901 in the illustrated example) that is the target of the action board 910, and created functions created for other UI parts are not displayed. Therefore, it is possible to prevent a mistake of writing a function name of a creation function created for another UI part, which does not exist as a creation function of the specified UI part, on the action board 910. In addition, the creation function is only valid when defining the action of the specified UI part, and does not affect the definition of the action of the other UI parts. Therefore, if the function name of the creation function created for the specified UI part is the same as the creation function created for the other UI part, even if the function name is written on the action board 910, only the function setting set for the specified UI part is reflected, and the function setting set for the other UI parts is not reflected. Therefore, no error occurs even if the same function name as the function name of the creation function already created for the other UI part is used. Therefore, the user can decide the function name of the creation function and input it to the action board 910 without worrying about duplication of the function name with the creation function already created for the other UI part. That is, many original functions will be created during the entire development of an application, but these are automatically managed and organized in association with designated UI components and displayed in the code assist field 911 and function list 920, making it extremely easy for developers to manage many original functions. This reduces the effort and time required to check function names. It also reduces input errors in function names. This also reduces the amount of debugging work (debug removal work) required when an input error occurs in a function name. This reduces the load and man-hours required for software development (application development), enabling more efficient software development (application development).

Figure 10(d) is a display example when the action code has been entered in a programming language into the action board 910. In the illustrated example, the part indicated by the dotted line 960 on the third line uses the created function "rest01" (function 923 in the function list 920). In the character string of the code illustrated in the action board 910 of Figure 10(d), the details of the created function rest01 are not defined. Also, when the developer sets rest01 on the REST function setting screen 940, the details of rest01 are not defined in the programming language. When 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 a programming language including the function definition in the programming language from the uploaded definition information as a program for the execution environment, based on the function setting contents and the character string described in the action board 910 in the saving process of Figure 33(a) or Figure 35(a) described later. In this way, when the development environment 300 acquires a character string containing identification information (function name) of a created function written in a programming language, it performs control to enable execution of the function (action) indicated by the character string containing the function of the created function (action written on the action board) based on the information set on the function setting screen.

Figure 11 shows an example of source code in a programming language generated by the development environment 300 based on the character string written on the action board 910 in Figure 10 (d) and the setting contents of rest01 set on the REST function setting screen 940. In the illustrated example, the numbers 1 to 75 written on the left side are illustrated to indicate the number of lines and are not part of the source code. The example in Figure 11 is a 75-line source code including a detailed definition of rest01 in a programming language. However, the developer himself does not need to enter 75 lines. By setting on the REST function setting screen 940 and writing the amount of character string (7 lines) shown in the action board 910 in Figure 10 (d), the contents of the source code shown in Figure 11 can be defined. In other words, efficient development can be performed with low code.

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

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

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

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

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

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 the like that match the input string.

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

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

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

In S811, the developer terminal 100 displays the addition dialog 930 for adding a creation function, and accepts input 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.

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

In S813, the developer terminal 100 determines whether the type selected in the type selection field 931 of the addition dialog is a script. If it is a 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.

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, and if it is 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).

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).

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

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

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

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

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

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

In S824, the developer terminal 100 determines whether or not an operation to close the action board (an operation to end the 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 processing is repeated. If an operation to close the action board has been performed, the action board is hidden, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor processing.

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

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

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

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; otherwise, the process proceeds to S1206.

In S1205, the developer terminal 100 performs a workflow creation process. The workflow creation process will be described later with reference to FIG. 16.

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

In S1207, the developer terminal 100 displays an 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 operation on the application setting screen and updates the definition information recorded in the memory 102 based on the setting. 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 Apps). In addition, there is a setting of which UI screen among multiple UI screens belonging to the application is to be the initial UI. The initial UI is the screen that is displayed first when an already-built application deployed in the execution environment is accessed, or the screen that is displayed first after authentication is OK on the application authentication screen after accessing the already-built application.

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

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.

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

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

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

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

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; if not, the process proceeds to S1218.

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 the 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 to save 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 does not access the multi-tenant execution environment 410 without going through the development environment 300. As explained in the login process above, a developer must authenticate and log in to development environment 300. Therefore, by restricting access to various executions to those other than through development environment 300, other users who cannot log in to development environment 300 cannot illegally access the execution environment, thereby improving security.

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

In S1218, the developer terminal 100 determines whether 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; otherwise, the process proceeds to S1220.

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

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

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.

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

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

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

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

In the group information shown in FIG. 14(c2), the usernames of one or more users are associated with each of a number of group IDs, as shown in each row.

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

At S130, the developer terminal 100 sends an instruction to obtain user information for the development environment 300 (information instructing the user to obtain user information for the selected execution environment).

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 is information such as that shown in FIG. 14(c1) or FIG. 14(c2) if the selected execution environment is a single-tenant execution environment.

In S1303, the developer terminal 100 displays user information on the display 105 based on the user information received in S1302. FIG. 15 shows an example of the display of user information 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 given the same reference numerals and the description is omitted. Display item 1501 is an instruction item for instructing a display based on the user-specific 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 of the display items 1501 and 1502 can be selected by switching. In addition, 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 user-specific 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 verified columns in the user-specific 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 for adding a row to group information 1505 and registering information of a new application user. Save button 1504 is an operation icon for issuing an instruction to save group information 1505, the contents of which have been edited on the screen of FIG. 15, in the selected execution environment.

In S1304, the developer terminal 100 accepts an editing operation of the user information displayed in S1303. For example, a user account can be added by pressing the Add User button 1503, a user account can be deleted by pressing the button icon displayed in the Delete column, and the content of editable items can be edited by operating the keyboard.

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

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

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

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

In S1309, the developer terminal 100 determines whether 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 is terminated and the process proceeds to the screen switching process described above.

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

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

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 in FIG. 1, the acquired access destination information is the access destination information 421. If the selected execution environment is the single-tenant execution environment in FIG. 1, the acquired access destination information is the access destination information 456b, 466b, 476b, etc., of the selected execution environment. 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 as the selected execution environment, and stores it in the memory 304. In the selected execution environment, a file recorded in a specific path (a path that is determined when the execution environment ID is known) is accessed, and the URL of the access destination stored in the file is acquired 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, "fixed character string + execution environment ID". The predetermined file name is, for example, a common file name that is determined in advance for all execution environments. In this case, the predetermined path is "fixed character string + execution environment ID / common file name.json". That is, if 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 the file and recorded in the memory 304. The URL of the access destination information indicates an address in the execution environment, and is a URL that is a request destination for requesting acquisition and updating of user information stored in the execution environment. If a request is not made to this URL, the user information stored in the execution environment cannot be acquired and updated. In this way, if the execution environment ID is not known, the access destination information for acquiring and updating user information cannot be acquired. The execution environment ID is information that cannot be obtained unless the developer logs in after performing authentication processing to the development environment 300. In addition, a developer who can log in to the development environment 300 can only acquire the execution environment ID that he or she can access. This prevents people who cannot log in to the development environment 300, or people who can log in to the development environment 300 but have a different accessible execution environment, from illegally accessing the execution environment and leaking user information. In other words, security is improved.

In S1313, the development environment 300 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 by 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 on the email address, password, last name, first name, and accessible execution environment ID. This information is encrypted and becomes a single data string, and is acquired. Even if only this encrypted information is leaked, the email address, password, last name, first name, and accessible execution environment ID are not leaked because it is encrypted.

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

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.

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.

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.

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 change instruction is 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.

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

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

In S1321, the execution environment 400 determines whether or not a user information acquisition request sent from the development environment 300 has been received. 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.

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, improving security. The access right confirmation process will be described later with reference to FIG. 13(d).

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

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

In S1325, the execution environment 400 transmits user information held in its own execution environment to the development environment 300. In the case of a single-tenant execution environment, the environment itself is owned by a single developer, and so the user information only relates to applications owned by a single developer. Therefore, as in the processing in a multi-tenant execution environment at S1326 described below, 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 user information transmitted here is received by the development environment 300 at S1314, and transmitted to the developer terminal 100 at S1315.

In S1326, the execution environment 400 transmits to the development environment 300, a portion of the user information held in its own execution environment, whose owner ID matches the received developer information. The encrypted developer information is transmitted from the development environment 300, received in S1341 described later, decoded (decrypted) in S1343, and stored in the memory 414. This is the received developer information. Among the user information 411 of the multitenant execution environment 410 shown in FIG. 14B, information of a row having 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. Among the user information 411 of the multitenant execution environment 410, information of a row not having 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 the case of a multitenant execution environment, since user information owned by multiple developers is recorded in a mixed manner, a portion of the user information owned by the logged-in developer is transmitted. The user information sent here is received by the development environment 300 in S1314 and sent to the developer terminal 100 in S1315.

In S1327, the execution environment 400 determines whether 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.

In S1328, the execution environment 400 performs an access right confirmation process. This process is for determining whether the sender 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, improving security. The access right confirmation process will be described later with reference to FIG. 13(d).

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

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

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

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

In S1342, the execution environment 400 records (outputs) the fact that an error has occurred as a result of the access right confirmation process. In this case, an error is determined in S1323 or S1329 described above. In this way, even if a request to obtain user information or a request to update user information is received, if encrypted developer information is not received, an error is detected 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.

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

In S1344, the execution environment 400 determines whether the execution environment ID of its own execution environment (the execution environment in question) is included in the part of the developer information decoded in S1342 that indicates the accessible execution environments. If it is included, the process ends (in this case the access is deemed to be legitimate), and if it is not included, the process proceeds to S1342, where an error is recorded (output) as a result of the access rights 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 execution environment in question. Therefore, processing in response to unauthorized access can be suppressed.

The execution environment 400 does not accept access from any source other than the development environment 300, and controls so that even if a user information acquisition request or user information update request originates from a source other than the development environment 300, no processing is performed in response to the request. 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. This improves security.

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

For example, this is applicable to the processing relating to displaying and updating the database described in S1210 to S1214 in 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 in the same manner as in S1312 in response to the DB operation instruction from the developer terminal 100. The access destination information file records a DB operation request reception URL that is the request destination for receiving the DB operation request, and the execution environment 400 sends the DB operation request and developer information to this URL in the same manner as in S1313. The execution environment 400 performs processing to determine whether the sender of the DB operation request is valid, in the same manner as in the processing described in FIG. 13(c) and FIG. 13(d), and only if the sender is valid, performs processing relating to the DB set held in its own execution environment in response to the DB operation request.

Also, 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 obtains an access destination information file from the selected execution environment in the same manner as in S1312 in response to a file management instruction from the developer terminal 100. Since the access destination information file records a file management request reception URL that is the request destination for receiving a file management request, the execution environment 400 sends the file management request and developer information to the access destination information file in the same manner as in S1313. The execution environment 400 performs processing to determine whether the sender of the file management request is valid, in the same manner as in the processing described in FIG. 13(c) and FIG. 13(d), and only if the sender is valid, performs processing related to the file held in its own execution environment in response to the file management request.

<Workflow processing>
16 shows a flowchart of the workflow process. This process is a detailed flowchart of S1205 in FIG.

In S1601, the developer terminal 100 displays a workflow (WF) creation screen on the display 105. FIG. 17A shows an example of the WF creation screen. A node list 1710 is displayed in the submenu area 510. The node list 1710 includes a start 1711, which is the starting point, an end 1712, which is the end point, and a status 1713, which is the intermediate point, as node options. 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, the placement is performed by dragging and dropping. That is, any of the multiple options displayed in the node list 1710 can be dragged and dropped into the WF placement area 1700 to place it.

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

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

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

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

Figure 17 (b) shows an example of the display after nodes and arrows have been placed in the WF placement area 1700. Nodes 1701 to 1705 are placed in the WF placement area 1700. Node 1701 is the starting node. Nodes 1702, 1703, and 1704 are intermediate (status) nodes. Node 1705 is the end node. Arrow 1706 is an arrow from node 1701 to node 1702. Arrow 1707 is an arrow from node 1702 to node 1703. Arrow 1708 is an arrow from node 1703 to node 1704. Arrow 1709 is an 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.

In S1606, the developer terminal 100 determines whether an operation to set the properties of a node has been performed. Specifically, it determines whether 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.

In S1607, the developer terminal 100 displays a property box for setting properties for the node, and accepts operations for setting the node properties. FIG. 17(c) shows an example of a node property box display. 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. The UI screen ID can be set by selecting from a list of UI screen IDs displayed as options.

In S1608, the developer terminal 100 determines whether an operation to set the properties of the arrow has been performed. Specifically, it determines whether an operation to select an arrow 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 the arrow has been performed, the process proceeds to S1609; if not, the process proceeds to S1610.

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

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

In S1611, the developer terminal 100 displays the selection acceptance form (dialog box) shown in FIG. 17(e) as a wizard and accepts the selection of the status to be created. At least one of start, applying, approved, and not applied for can be selected as the status to be created.

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

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 from the displayed options.

In S1614, the developer terminal 100 creates a workflow definition based on the nodes and arrows already placed in the WF placement area 1700, their properties, and the contents set by selecting from the options in S1611 to S1614, and records the definition information in the memory 102. As a result, UI parts (UI components) based on the workflow are automatically placed on the UI screen. The automatically placed UI parts are automatically set with actions corresponding to the workflow. In this way, UI parts with automatically defined actions are generated based on the workflow generated by the operation of selecting options without the developer user writing 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). Also, an action is set (defined) in the canvas of the UI screen depending on the setting contents. The action set in the canvas is a process to be performed when the UI screen is loaded (read) in the constructed application. In other words, it is a process to be performed as an initial operation when the screen is displayed.

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 process of FIG. 16 ends, and the process proceeds to the screen switching process described above in FIG. 12. If not, the process proceeds to S1602.

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

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

Figure 18 (c) shows an example of a display when an action board is displayed with the UI part 1813, which is a button, as the specified UI part. That is, this action board is displayed in S801 described above in Figure 8 when the specified UI part is the UI part 1813. The action board 910 displays the action character string as shown in Figure 18 (c) written in a programming language as the initial value when the developer has not written the action in a programming language. In other words, the action board 910 displays the source code in the programming language that defines the action as shown in Figure 18 (c) as the initial value when the developer has not written the source code for the action in a programming language. The action displayed in the action board 910 in Figure 18 (c) has at least a database (line 3) and a UI screen to be displayed next (line 6) defined based on the group of operations received from the user in the workflow creation process in Figure 16. The user can edit the action automatically defined in this way by the processes of S802 to S808 described above. That is, a programming language can be input that uses the character string of an automatically defined action as a base, partially reuses it, and modifies or adds character strings. That is, it is possible to accept modifications to the character 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 set an action easily with fewer steps (amount of text input) than if a developer were to write the action in a programming language from scratch. Also, 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.

Figure 18(d) shows an example of a display when an action board is displayed on a canvas of a UI screen where an action is automatically set according to the generation of a workflow. This action board is displayed when a blank area of the canvas is specified and a context menu process is performed to instruct the display of the action board. It is displayed in S1903 of Figure 19, which will be described later. The action board displays a character string of the action as shown in Figure 18(d) written in a programming language as an initial value when the developer has not written the action in a programming language. In other words, the action board displays a source code in a programming language that defines the action as shown in Figure 18(d) as an initial value when the developer has not written source code for the action in a programming language. The user can edit such automatically defined actions by the process of S1904, which will be described later. That is, like the action automatically set in the UI part described in Figure 18(c), actions can be easily set with fewer operations (amount of text input), and actions that meet more detailed requests can be generated.

For example, the following customizations can be added to the UI parts and actions that are automatically generated in response to the generation of the above-mentioned workflow.
- Set up an action on the canvas action board that displays the name of the current step in the workflow.
An input field (UI part) for the reason for application is placed, and the action board of the UI part 1813 is modified so that the data entered there is sent to the next step.
Modify the action board of the part 1813 so that the data is saved in a different table. For example, customize it so that the reason for application and the case ID are also recorded in a separate DB.
On the action board of the campus, set the user who is initially input to the UI part 1812 (combo box) to be the person who applied last time by writing an action with the programming limit. Alternatively, write an action to display people who can approve as options.

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

<CRUD Generation Process>
Fig. 19 shows a flowchart of the canvas context menu process. This process is a detailed flowchart of S703 in Fig. 7 described above. This process is executed by the developer terminal 100. The canvas context menu includes an option for generating a CRUD.

In this embodiment, as an example for explaining the generation of a CRUD, a case will be described in which, before the generation of a CRUD (before the placement of a CRUD button), a canvas of a selected UI screen as shown in FIG. 20(a) is displayed, and a blank area of the canvas is right-clicked to display a context menu of the canvas. CRUD is a word formed by combining 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 parts 2001 to 2003 that were placed by a developer in the UI editor process. All of the UI parts 2001 to 2003 are UI parts of type Input. The UI part 2001 displays "ID" as a label, the UI part 2002 displays "Name" as an initial value, and the UI part 2003 displays "age" as a label. That is, the canvas in FIG. 20(a) is a canvas for a UI screen designed to be a screen for some kind of user registration. UI part 2001 is an input field for inputting the ID of the new user to be registered, UI part 2002 is an input field for inputting the name of the new user to be registered, and UI part 2003 is an input field for inputting the age of the new user to be registered. The UI part IDs of UI parts 2001 to 2003 are "number_field_ID", "text_field_Name", and "number_field_age", respectively.

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

In S1902, the developer terminal 100 determines whether or not a 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; otherwise, the process proceeds to S1906.

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) described 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 into the action board and the contents of that action are recorded in the definition information, a character string in a programming language indicating the set action is displayed on the action board.

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

In S1905, the developer terminal 100 determines whether or not an operation to close the action board (an operation to end the 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 processing is repeated. If an operation to close the action board has been performed, the action board is hidden, the processing of FIG. 19 is terminated, the display is switched to the canvas of the selected UI screen, and the process returns to the UI editor processing.

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

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

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

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

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.

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

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.

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

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

In S1915, the developer terminal 100 performs other processing, which is processing corresponding to the pressed menu item.

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 of clicking outside the area in which the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden in S1917, and the processing in FIG. 19 ends. If no operation to close has been performed, the processing returns to S1902.

Figure 20(f) shows an example of the display of a CRUD button (automatically generated component) automatically arranged by the processing of S1913. Figure 20(f) is an example of the display of a canvas of the same UI screen as Figure 20(a), and the same UI components as Figure 20(a) are given the same reference numerals. In Figure 20(f), UI components 2051-2053 have been added to Figure 20(a). These UI components 2051-2053 are CRUD buttons. Actions are automatically set for the UI components 2051-2053 that are CRUD buttons. The action of UI component 2051 that is a CRUD button is to perform a process of saving (updating or adding) 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 of UI component 2051, and then to transition to the Next UI screen. The action of UI part 2052, which is a CRUD button, is to delete data having the value entered in the UI part selected in input form 1 from the database table set in input form 3 in response to pressing of UI part 2052, and then transition to the Next UI screen. The action of UI part 2053, which is a CRUD button, is to retrieve data that matches the value entered in the UI part selected in input form 1 from the database table selected in input form 3 in response to pressing of UI part 2052, and transition to the Next UI screen to display the retrieved data.

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

The automatically generated data grid 2061 can also be edited in various ways using the grid property box and action board described later. For example, the decoration of the grid can be changed, and the label displayed as the column name can be changed from "text_field_Name" to "Name". For example, it is possible to modify the display so that some columns are not displayed. After the application is deployed and operation is started, there may be cases where you want to increase or decrease columns due to some circumstances (such as changes in regulations or operation methods). For example, there may be a case in the future where you want to change the data grid 2061 so that the "number_field_age" column is not displayed. In this case, you can delete the column you want to delete by simply deleting it from the column properties in the UI editor. Therefore, there is no need to re-enter and re-generate the CRUD input forms 1 to 3. In this way, by being able to edit the UI parts and screens that are automatically generated according to the input to the CRUD input form (fizard), future changes in the operation of the application can be easily and flexibly handled with few operations.

Figure 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, Figure 21 (a) is one of the screens related to the database displayed in S1214 of Figure 12. Of the table list (TABLES) included in the database "sample" displayed in the submenu area, table 2101 (CRUD_T01) is a table that was automatically added in response to the generation of the CRUD. Table 2102 displays the details of table 2101 (CRUD_T01), and it can be seen that in addition to the ID column, there is a column named after the UI part ID of the UI part selected in input form 2. For these columns, properties such as data type are also automatically set according to the properties of the UI part selected in input form 2.

21(b) shows an example of a display when the action board of the UI part 2051, which is a CRUD button automatically arranged in the process of S1913 in FIG. 19, is displayed in S801 described above in FIG. 8 when the specified UI part is the UI part 2051. The action board 910 displays the character string of the action as shown in FIG. 21(b) written in a programming language (JavaScript) as the initial value when the developer has not 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 initial value when the developer has not written the source code for the action in a programming language. The user can edit such an automatically defined action by the process of S802 to S808 described above. That is, the user can input a programming language to partially reuse the character string of the automatically defined action and partially modify or add a character string. That is, the user can accept a modification operation for the character string of the automatically defined action. 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 the action from scratch in a programming language. Also, 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.

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

Figure 21 (c) shows an example of a display when a function 2121 is selected from the function list 920 and a function setting screen is displayed. Function 2121 is an SQL function, and an SQL function setting screen is displayed. Since the SQL function setting screen has the same configuration as that described above in Figure 10 (a), in Figure 21 (c), the same setting/input fields as those in Figure 10 (a) are assigned the same reference numerals and their explanations are omitted. In the setting field 951, "SQL_Save" is automatically set as the function name. In addition, in the setting field 953, an SQL statement is input in advance. In this SQL statement, the character string "INSERT INTO" indicates that the processing type for the database is "INSERT" and that this is a process for adding a new row to 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 into Input Form 3. The subsequent character strings indicate the column values contained in the row to be added, and reflect the content entered into Input Form 1. The content of setting fields 951 and 953 can be edited (modified, deleted, added to, customized) by the developer using the processes in S813 to S820 in FIG. 8 described above, based on what was automatically generated.

Figure 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 an SQL function setting screen is displayed. Since the SQL function setting screen has the same configuration as that described above in Figure 10 (a), in Figure 21 (d), the same setting/input fields as those in Figure 10 (a) are assigned the same reference numerals and their explanations are omitted. In the setting field 951, "SQL_Update" is automatically set as the function name. In addition, in the setting field 953, an SQL statement is input in advance. In this SQL statement, the character string "UPDATE" indicates that the processing type for the database is "UPDATE" and that the processing is a process for updating 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 into Input Form 3. The character string that follows indicates the value of the column to be updated, and reflects the content entered into Input Form 1. The content of setting fields 951 and 953 can be edited (modified, deleted, added to, customized) by the developer using the processing of S813 to S820 in FIG. 8 described above, based on what was automatically generated.

The contents of the automatically generated actions shown in the action board 910 in Fig. 21B will be described in detail below. Each line of the JavaScript character string described in the action board 910 in Fig. 21B has the following meaning.
Line 1: defines a variable named params, with a value set including the values in lines 2 to 5.
Line 2: Defines the ID number. This will be a serial number.
Lines 3-5: Obtain the value entered in the UI part selected in input form 1. Note that "$ui.UI part ID.Target information type" is written to the right of "=" to indicate that a value is to be obtained, but this description method itself is not a standard method for JavaScript, but is unique to this system. More details on this will be provided later.
Line 6: Executes the function SQLUpdate with the params defined in lines 2 to 5 as arguments. That is, it updates the database table set in input form 3 with the values entered in the UI parts selected in input form 1.
Line 7: Obtain the row affected by the Update.
Line 8: Determine whether any rows were obtained in line 7. In other words, determine whether any rows were updated.
Line 9: If line 8 is true, display "Successfully Updated."
Line 10: Transition to a UI screen with a UI screen ID of "crud-newui-UI01" as NextUI.
Line 12: Determines whether the number of rows retrieved in line 7 is 0. If this is true, it means that there is no existing row that corresponds to the params retrieved this time, so a new row will be added and newly registered.
Line 13: If line 12 is true, executes the function SQLSave with the params defined in lines 2 to 5 as arguments. In other words, adds a row to the database table set in input form 3 with the values entered in the UI parts selected in input form 1, and saves the row as a new row.
Line 14: Obtain the lines affected by the new save in line 13 (i.e., the added lines).
Line 15: Determines whether any rows were obtained in line 14. In other words, determines whether the new registration by adding a row was successful.
Line 16: If line 15 is true, displays "Successfully Inserted."
Line 17: Transition to the UI screen with the UI screen ID "crud-newui-UI01" as NextUI.
Lines 19, 20...If lines 8 and 12 are both false, display "Insertion Failed."

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 customize it, for example, as follows:
・Since we want to change the message content (the message that is displayed when an 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 portion of NextUI on lines 10 and 17 (crud-newui-UI01).
・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 write it in. When creating a new SQL function, copy and paste the automatically created SQL statements for "SQLSave" and "SQLUpdate" into the setting field 953, and modify only the target database and table parts.

In this way, customizing an automatically generated action can greatly reduce the amount of work required, rather than creating the developer's desired CRUD button action from a state where no action description in a programming language is required. In addition, since customization can be freely performed, there is a large degree of freedom in the content of the actions that can be created. According to this embodiment, actions defined without the developer (user) having to write them in a programming language (actions defined based on the group of operations entered into input forms 1 to 3) can be modified and used more flexibly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In S2223, the development environment 300 instructs 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, although in this embodiment the external one-time password issuing system is instructed to send the one-time password, the development environment 300 itself may send the one-time password.

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 FIG. 22(a). If a one-time password has been received, the process proceeds to S2225; if not, the process waits at S2224.

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

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

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 FIG. 22(a). If a request to resend the one-time password has been received, the process proceeds to S2223; if not, the process waits in S2227.

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

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

In S2230, the development environment 300 determines whether a DB instance has been added to the multitenant execution environment 410. If a DB instance has been added, the process proceeds to S2232; if not, the process proceeds to S2231.

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

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

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

In S2234, the development environment 300 updates the DB instance name stored in the 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 of the database environment. As a result, for example, "DB instance name 1" was assigned to the account added before, but "DB instance name 2" is assigned to the account added after this. If the number of accounts connected to one DB instance (database environment) increases, the number of times the database is accessed at one time increases, and if access is concentrated, this may lead to a decrease in performance, such as a decrease in response. In contrast, if the number of accounts exceeds threshold 1 by the processing of S2233, accounts registered thereafter are set to connect to a new DB instance (database environment) different from the previous one, so that the possibility of the number of developers using one DB instance becoming excessive and access being concentrated can be reduced. Therefore, the possibility of a decrease in performance, such as a decrease in response to access to the database, can be reduced.

In S2235, the 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, if threshold 1 before the update was 10,000 developer devices and threshold 2 before the update was 9,000, threshold 1 = 20,000 and threshold 2 = 19,000. In other words, each time the number of developer device 10,000 accounts increases (each time the number of valid accounts increases by the number of threshold 1), the processes of S2231 and S2234 are performed.

In S2236, the development environment 300 assigns the DB instance name stored in memory 304 as the destination DB instance for the account information added in S2222 (the currently added account). More specifically, the DB instance name stored in memory 304 as the destination DB instance is recorded in the column indicating the destination DB instance name (the rightmost column in FIG. 14(a)) of the row of the currently added account in the developer information 301. By the process 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 developer terminal 10001's first valid account, "DB instance name 2" is recorded.

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

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

Figure 23 (a) shows details of DB set 430 in multi-tenant execution environment 410. DB set 430 initially has 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 developer information DB 2311 and DBs for each developer. Developer information DB 2311 indicates which database is prepared for each developer (each account). For example, DB information 2312 for developer A is information indicating the correspondence that DB for developer A is DB1. DBs for each developer include DB1 (2314), DB2 (2315), DB3 (2316), etc., and the number increases each time a valid account is registered in developer information 301. However, the upper limit is the same as threshold 1, and if threshold 1 is 10,000 developer devices, DBmax (2317) is the DB on the 10,000th developer device, and subsequent DBs are created in different DB instances. Each inventor's DB further includes one or more tables. For example, DB1 (2314) includes multiple tables, such as table 1, table 2, ... Each DB instance (database environment) is a writable database instance.

By processing S2231, the next DB instance 2 is created before the number of DBs in DB instance 1 reaches the upper limit (threshold 1). Then, when DBmax (2317) has been created in DB instance 1, if a further valid developer account is added to developer information 301, S2232 becomes Yes, and the newly added developer is registered in developer information 301 so as to connect 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 after that are controlled to connect to the next DB instance in a similar manner.

FIG. 23B shows details of DB set 457 of the single tenant execution environment. Since the single tenant execution environment is dedicated to one account (one developer), DB set 457 is also dedicated to one account (one developer). Therefore, the possibility of an increase in DBs or concentration of accesses to the extent that response decreases is low. Therefore, only one DB instance 1 (2350) is prepared as a DB environment in DB set 457. In addition, only information of one account statement (for example, DB information 2352 of developer A) is recorded in developer information DB 2351. There is no upper limit threshold for the number of DBs stored. In addition, as described in FIG. 22B, the control of determining the database environment of the single tenant execution environment to be connected to the account information to be registered is not performed when registering (adding) a new developer account.

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

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

In S2401, the developer terminal 100 transmits information to the development environment 300 instructing the development environment 300 to deploy the selected application. Note that before issuing the deployment instruction, a storage process may be performed to store 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.

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

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

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

In S2405, the developer terminal 100 determines whether 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.

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

In S2407, the developer terminal 100 displays a screen accessed by the URL (URL for accessing the execution environment) of the deployed app 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 the deployment instruction was received. 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 the display content and operation of the actual deployed app (built in the execution environment) can be immediately confirmed and verified by operating the new tab. This process of S2407 accesses the URL (URL for accessing the execution environment) of the deployed app to execute the app. Details of the app execution process will be described using the flowchart of FIG. 33(c) or FIG. 35(c).

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

In S2409, the developer terminal 100 displays the QR code generated in S2409. The QR code is displayed in response to the completion (success) of the deployment, so the developer can recognize the timing of the successful deployment. Figure 25 (b) shows an example of the QR code displayed in S2409. Figure 25 (b) is an example of the screen to which the transition occurs when the deploy button 506 is pressed from the state of Figure 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. The URL of the app, which is the information contained in QR code 2511, is a different URL from URL 2504 (the URL of the development system (application development platform) of this embodiment, which is the URL for accessing the developer terminal 100) displayed in the address bar of the browser displaying the UI editor screen. QR code 2511 is displayed when deployment is complete, and is an address for executing the deployed app, and is access destination information indicating the location (execution environment) where the deployment was performed.

The developer (user) can photograph and read the QR code 2511 displayed on the display 105 of the developer terminal 100 with a smartphone (mobile terminal) in hand, thereby displaying a screen on the smartphone in hand that accesses the URL (URL for accessing the execution environment) of the deployed application. Therefore, the deployed URL can be easily accessed with few operations. In this case, the smartphone in hand functions as the application user terminal 201. As a result, the authentication screen or initial UI of the deployed application is displayed on the smartphone in hand, and the display content and operation of the actual application that has been deployed (constructed in the execution environment) can be immediately confirmed and verified by operating the smartphone in hand. Since the operation of the mobile application can be confirmed and verified on the mobile terminal rather than the developer terminal 100, it is easier to confirm whether it is suitable as a mobile application than by confirming 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 URL of the application included in the success notification can be read. For example, a barcode, a Chameleon Code (registered trademark), etc. may be used. Also, the URL of the app included in the success notification may be displayed as a character string in the QR code dialog 2510.

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

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

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

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

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

In S2423, the development environment 300 stores the definition information of the selected app acquired in S2421 in the developer area (dedicated folder) of the logged-in developer in the storage 420 of the multitenant execution environment 410. More specifically, the development environment 300 transmits 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 (folder for each developer) of the logged-in developer. If this recording is completed without any problems, the deployment is successful.

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

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

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

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

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

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

Figure 26 (a) shows an example of template screen options displayed when a list of UI screens is displayed as options in submenu area 520. This display is performed by the process of S401 in Figure 4 described above. Figure 26 (a) shows an example of an expanded list of UI screen options classified into the Authentication UI group (authentication UI screen, 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 expanded Authentication UI options are 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.

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 pressing 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) by dragging and dropping from the UI component list in submenu area 520, but are template UI components whose display position (placement), color, size, and display contents are defined in advance. Template components 2631 to 2634 are UI components as follows:
Template component 2631: A UI component for displaying "Sign In" in the Output Field.
Template component 2632: A UI component of Input type TextField for receiving input of an email address that is a user name (user ID) for the application, that is, a UI component for receiving input of user-specific information.
Template component 2633: A button UI component that is set (labeled) to display "CREATE ACCOUNT?". When pressed, an action is set (predefined) to transition to a "Sign Up form" screen (a UI screen corresponding to option 2614 on the screen shown in FIG. 27(c)).
Template component 2634: A button UI component that is set (labeled) to display "NEXT." When pressed, a value (email address) input to template component 2632 is acquired, and an action is set in advance (defined in advance) to 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.

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

In an actually constructed app, in response to pressing a button corresponding to template component 2715 displayed on app user terminal 201, the app user terminal 201 sends to the execution environment an email address, which serves as the username, a password, and whether or not a check is selected. In the execution environment, the received pair of email address and password is checked to see if it is correct, and is compared with user information 411 (shown in FIG. 14(b)) of the multi-tenant execution environment or per-user information (shown in FIG. 14(c1)) of the single-tenant execution environment. If the result of the comparison is that authentication is OK, the user is logged into the app, and an initial UI is displayed on the app user terminal 201.

Similarly, the following are examples of template screens displayed on the canvas. Both are screens related to user authentication for the app.
・FIG. 27( b ): UI screen corresponding to option 2613.
・FIG. 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.
・FIG. 27( k ): UI screen corresponding to option 2622 .

Each of the above-mentioned template screens can be customized, and as described in the process after S405 in FIG. 4, the developer can edit them with a UI editor. The editable contents include adding UI parts other than template parts (template components), changing the layout position and display size of template parts, and changing the settings of the template part properties (changing the display form such as the displayed characters and color). In addition, the action of the canvas of the template screen can also be set and changed. On the other hand, it is assumed that the action of the template part cannot be changed or deleted, and the template part cannot be erased. In addition, it is assumed that the action of a normal UI part (a UI part that is not a template part) added to the template screen cannot be changed or deleted. In this way, it is possible to prevent an unintended error caused by the modification of an action required for authentication processing using a cloud service, which causes the authentication processing to not work properly. In other words, in the template screen, the actions required for authentication without errors are predefined in the template parts and cannot be modified, so that even if the developer customizes the template screen, the authentication processing using the cloud service will surely work properly. The reason why actions cannot be set for normal UI parts added to the template screen is to prevent actions that would cause authentication to not work properly being set. For example, if a new button is added to the "Sign in ID" template screen in FIG. 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 execution environment, and authentication will not work. If authentication is not successful, the UI screen to which the transition is made will not be displayed, and the app will not work properly. Problems like this can be prevented by not allowing actions to be set for normal UI parts added to the template screen.

Figure 26 (c) shows an example of a display that displays a context menu 2655 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 the options of action and deletion. This is the same as what was explained in the display example of Figure 5 (d). Therefore, as explained in S711 to S720 of Figure 7, editing such as editing properties, editing actions, and deleting parts is possible.

Figure 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 a template screen. In this way, the action and delete options are not displayed in the context menu of a template component placed on the template screen. This prevents the user from setting an action or deleting the template component. In other words, the action board is not displayed either. Therefore, as explained in S721 to S724 of Figure 7, only the properties of the template component can be edited (the display form can be changed).

Figure 26 (e) shows a display example after editing (customization) is added to the canvas of the template screen shown in Figure 26 (b). The same UI parts in Figure 26 (b) and Figure 26 (e) are given the same reference numerals. UI part 2641 is an output type UI part added by the developer, and is displayed by specifying the image file uploaded in the file management operation of S1217 in Figure 12. If this image is an icon or image representing the application, the user can easily understand which application's authentication screen this is. UI part 2642 is a type of UI part that outputs a text message added by the developer. In addition, as an action of the canvas of this screen, the developer opens the action board of the canvas and sets an action of acquiring today's date and displaying a character string "It's the closing date at the end of the month, so don't forget to apply" on UI part 2642 if it is the end of the month. In this way, it is also possible to arrange a UI part (component) whose display content changes depending on the conditions when this authentication screen is displayed. Template component 2631 is the same UI component (UI component with the same ID) as template component 2631 in FIG. 25(b), but the content (label) to be displayed can be changed by editing the properties by the developer, and "Login" is displayed. In this way, there is a high degree of freedom in screen design for actions other than those essential for authentication. Therefore, for example, it is possible to make the screen easily recognizable to the app user as to which app's authentication screen (login screen) it is, to design it according to an internal company standard design agreed upon within the company, or to design it in a more suitable way to match the nature of the app.

<Property box display example>
The property box that is displayed when a property is selected from the context menu of a UI part placed on the canvas will now be described.

28(a) shows an example of the display of the property box of a pie chart. FIG. 28 shows a screen displayed by right-clicking on the pie chart 531, which is a UI part arranged on the canvas 530, from the display state shown in FIG. 5(b) and selecting "Property" from the displayed context menu. The process of displaying this screen and the reception of the editing process for the displayed property box are performed in S706 of FIG. 7 described above. The property box 2810 is the property box of the pie chart 531. The property box 2810 is displayed together with the pie chart 531 displayed on the canvas 530. The display form of the pie chart, such as the ratio and color coding, which are the contents displayed in the pie chart 531, is displayed based on the contents set in the property box 2810. When the setting contents are changed in the property box 2801 and the apply button 2811 is pressed, the display form of the pie chart 531 is updated based on the latest setting value (changed setting value) of the property box 2801. That is, the developer can perform the setting operation for the property box 2810 while checking how the display form of the pie chart 531 changes.

When a pie chart is placed on the canvas by dragging and dropping it from the UI parts list, if no values are set, the regions of the pie chart will not be displayed according to their ratios, and it will simply be displayed as a circle. This means that a developer cannot look at the placed UI part and intuitively recognize that it is a pie chart. To solve this, a predefined initial value (a default setting value not set by the developer) is set as a property of the pie chart. By doing this, when a pie chart is placed on the canvas by dragging and dropping it from the UI parts list, a pie chart with regions divided by ratios will be displayed from the start, allowing the developer to quickly and intuitively recognize that the placed UI part is a pie chart.

Of 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 area shown by the pie chart 531. If the developer has not set anything, the initial value is displayed as shown. In the example shown, only a portion of the initial value is displayed, and it is possible to view the entire value 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.

[{″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 area 2810 is displayed in a structure used when describing it in a programming language. Of the entire text of the initial value, the part enclosed in "{" and "}" is the pie chart. A set of character strings, each of which is surrounded by "", and associated with a ":", is a pair of a key name and a key value. For example, in "id:Jan", the key name is "id" and the key value is "Jan". "," is the separator between the previous key and the next key. That is, Among the above initial values, the following multiple values are included: {"id":"Jan", "value": developer terminal 100.33, "color":"#394E79", "month":"Jan"} The part containing the grouping is one dataset (one set), and contains four key name and value pairs: id, value, color, and month. There are a total of five similar datasets. You can understand. In this way, the initial values of the pie chart are a set of settings that includes multiple data sets, each of which includes a set of default settings.

A developer can freely edit the initial value displayed in Value input area 2812 of property box 2810 by selecting Value input area 2812 and entering an input from the keyboard. However, since the initial value is displayed in such a way that the structure can be seen as above, it is easy to understand where and how to edit. Furthermore, by pressing Apply button 2811, the edited content is reflected in pie chart 531, so it is possible to confirm how pie chart 531 changes when the value of a certain structure is changed. Therefore, it is easy to understand what each part of a string displayed in a structure that can be written in a programming language means.

If it is simply necessary to set the setting values of the pie chart, it is possible to separate the setting items in the property box 2810, such as "ID of area 1", "value of area 1", "color of area 1", "display label of area 1", etc., and have the developer input or select for each of them. However, in this embodiment, instead of doing so, the initial values are displayed in a structure when written in a programming language, and when the developer edits, they are input in a description that follows the structure when written in a programming language. This is because the setting values of the pie chart can be changed by an action input in JavaScript to another UI part or the action board of the canvas. If the initial values are displayed in a structure that can be written in a programming language and as copyable text (character string), the developer can copy this character string to the clipboard by known copying and paste it into the action board (copy and paste is possible). Then, by modifying only the characters in the part to be changed on the action board, an action that changes the display content of the pie chart can be easily written. This prevents developers from being unable to write the intended action because they do not know how to write it when they want to write an action that changes the display format of a pie chart, or from spending a lot of time looking up how to write it. In other words, software development can be made more efficient. Because it is a programming language, it allows for a high degree of freedom when other edits are desired.

Figure 29 shows an example of the display of an action board when a developer inputs an action to change (specify) the display form (display content) of the pie chart 531 in the action board of a UI part (button) different from the pie chart 531 placed by the developer. The action board 2900 shown in the figure 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 the action board 2900, the second to 32nd lines are edited (changed) only for the numerical values 2901 to 2951, based on the initial value displayed in the Value input area 2812 of the property box 2810, which is copied and pasted and has line breaks added for ease of viewing. Of course, other parts may be changed, and a data set (part surrounded by "{ }") may be added or deleted. In this way, inputting an action in a programming language becomes very easy. In the constructed app, when the button corresponding to this action board is pressed, the pie chart will be displayed in a format based on the content written on this action board, rather than the default.

As with pie charts, initial values (default settings) are set for lists, which are UI components, and the initial values are displayed in the property box according to 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 values according to the structure when written in a programming language.

Like the pie chart, the LINE CHART (line chart, line graph) UI component 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 of LINE CHART 2803. As shown in the figure, the initial value is displayed in input areas 2831 to 2834 according to the structure when written in a programming language.

As with pie charts, initial values (default settings) are set for the UI components data grids (tables), combo boxes, tab components, steppers, and breadcrumbs, 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 a property box 2840 for a 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 a data grid include a data set for multiple rows, with the values of each column for each row of the data grid being one set of data set.

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

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 component arranged 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 shown 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. In the context menu 3120, at least properties 3121 and actions 3122 are displayed as options that become menu items.

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; if not, the process proceeds to S3003.

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

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

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

In S3006, the developer terminal 100 determines whether an operation to close the context menu has been performed (for example, an operation of clicking outside the area in which 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 processing returns to S3002.

In S3010, the developer terminal 100 displays a property box of the data grid, which is the specified UI component. Examples of the display of the property box of the data grid are shown in Fig. 31(b) to Fig. 31(f). In Fig. 31(b) to Fig. 31(f), the same display items are given the same reference numerals. The apply button 3131 in Fig. 31(b) is a button icon that instructs to reflect the contents (changed setting contents) inputted in the property box. When the apply button 3131 is pressed, the display form of the data grid, which is the specified UI component arranged on the canvas displayed together with the property box, is changed based on the latest setting contents of the property box. The column selection field 3132 is a selection tab for selecting the column whose settings are to be changed. In the property box of the data grid, a screen that accepts settings for each column is displayed, and the property settings for each column are accepted. The add column button 3133 is a display item that instructs to add a column to the data grid, which is the specified UI component.

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

In S3012, the developer terminal 100 switches the display content of the area below the column selection field 3132 in the property box to a setting screen (element screen) related to the selected column. FIG. 31(c) shows an example of a display when the tab 3132E (a tab marked "CompanyE") is selected in the column selection field 3132. In the area below the column selection field 3132 in the property box, the upper area 3134t of the setting screen of the tab 3132E is displayed as a screen for accepting settings of the column corresponding to the tab 3132E. This includes, for example, a type setting field 3135 for selecting the part type (component type) of the column. The setting screen of the tab 3132E continues further downward, and the lower part can be displayed by scrolling. FIG. 31(d) shows an example of a display when the lower area 3134d of the setting screen of the tab 3132E is displayed by scrolling. The lower region 3134d includes a column delete button 3136 for instructing the deletion of the column itself corresponding to tab 3132E, and an apply button 3137 for instructing the application of the contents set in the setting screen of tab 3132E to be reflected in the data grid displayed on the canvas. The 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 the 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 the column selection field 3132 is switched to a setting screen for setting the entire data grid.

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

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

Figure 31 (f) shows an example of how the property box is displayed when a column is added. Compared to Figure 31 (c), a tab 3032F (a tab labeled "Company F") 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 area 3139t of the settings screen for tab 3032F corresponding to the added column is displayed in the area below the column selection field 3132. In this way, in this embodiment, a column is added to a data grid (table) by operating the property box, which is the settings screen for the data grid.

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 the various setting fields on the setting screen displayed in the area below the column selection field 3132. If an input operation has been performed on the setting fields, the process proceeds to S3016; if not, the process proceeds to S3017.

In S3016, the developer terminal 100 accepts the setting operation and reflects it in the display. For example, it accepts the setting of the type for the type setting field 3135. In this way, the data grid allows the component (part) type to be selected for each column. TextInput, NumberInput, ComboBox, Multi-Select, CheckBox, DataPicker, Link, Button, and IconButton are displayed as options for the component type that can be set in the column, 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, the other setting items include the following: ValueType, ID, Label (character string displayed as column name), Width (column width), NumberFormat, DataFormat, Options, Footer, FooterText, Sorting, Visibility. Also, the settings that can be set on the overall settings screen for the data grid corresponding to the "DataGrid" tab include the following: ID (UI part ID of the data grid), overall size of the DataGrid (width, height), whether to make it editable in the deployed app, whether to display an add row button that instructs the user 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.

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

In S3018, the developer terminal 100 records the contents set in the property box in the definition information stored in memory 102, and changes the display form of the data grid, which is the specified UI component displayed on the canvas of the UI editor, to reflect the contents set. For example, if a column has been added, the data grid is displayed in a display form 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.

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 of FIG. 30 ends. If the End button 3140 has not been pressed, the process proceeds to S3011.

In this way, adding columns to a data grid (table) and configuring each column can be done 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 made 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. Also, after adding a column, the type is set from the options that can be set as a column component, so columns can be added and the type set without confusion.

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 items are given the same reference numerals in 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 are options 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. In this case, options corresponding to the action board of a column of a data grid other than the data grid of the specified UI component will not be displayed.

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

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

Figure 32 (b) shows an example of the display of an action board corresponding to the options (options 3211) for the action of the entire data grid. "DATA GRID" is selected in the entire or column selection area 3220, and the action board 3211a indicates that it is an area for inputting the action of the entire data grid. The trigger for executing the contents set in the action board 3211a is predetermined, and the trigger is pressing the button related to the entirety displayed outside the column of the area of the data grid, which is the specified UI part in the constructed application. In other words, this trigger is a trigger related to the data grid (table), which is the specified UI part, and is a trigger that is not related to the column of the data grid. The button related to the entirety is a button that is displayed by setting it to be displayed in the setting screen corresponding to the "DataGrid" tab of the property box described above. For example, it is the delete button of the data grid and the update button of the data grid described above. Therefore, the developer does not need to set what the trigger for executing the action is (it is not necessary to write it in JavaScript). For example, actions 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, and transitioning to another UI screen can be set on this action board 3211a by writing them in JavaScript.

Figure 32 (c) shows an example of the display of an action board corresponding to the action option (option 3212) of a specific column of a data grid. "MONTH" is selected in the selection area 3220, and the action board 3212a indicates that it is an area for inputting an action for the column (column 3111) whose label or column ID is "MONTH". The trigger for executing the content set in the action board 3212a of the column is predetermined, and the trigger is that the value of a cell in any row of the corresponding column among the designated UI parts in the constructed application is changed, or a button displayed in a cell in any row of the corresponding column is pressed. Therefore, the developer does not need to set what the trigger for executing the action is (it does not need to be written 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 the action board 3212a has been changed and the value of another first column in the same row, and displaying the sum in another second column in the same row. An example of this action is when a value in the first column of a table is changed, the sum of the changed values in the first and second columns is displayed in the third column of the same row. In other words, it is possible to accept settings for an action that affects other columns of the data grid, which is the specified UI component, other than the column corresponding to the selected option 3212.

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

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

In S3024, the developer terminal 100 determines whether or not an operation to close the action board (an operation to end the 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 processing 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.

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, so the developer can 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 component, the relationship with the data grid, which is the specified UI component, can be clearly understood. In other words, design work can be performed while understanding without confusion which column of which data grid the action set in the action board relates to.

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

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

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

In FIG. 34, the UI definition information 3401 recorded in the 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 with the file name "uiDef.json" written in JSON format. Json is an abbreviation for JavaScript Object Notification, and is 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 the information (position, size, color, etc.) of the UI components (UI parts) for each UI screen. The UI definition information 3401 also includes an action description portion 3402. This action description portion 3402 is a character string entered into the action board of each UI part or canvas, or into the function setting screen (including the creation function setting screen). The action description portion 3402 includes an action written in JavaScript, and a function definition in Json format that describes the contents set in 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.

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

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

In S3304, the development environment 300 generates an execution environment program from the action description portion 3412 extracted in S3303 and saves it in an area of the storage 320 for the logged-in developer. That is, based on the action description portion 3412 extracted from the UI definition information 3411 in 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 that adds supplementary parts necessary for execution by the execution engine of the execution environment to the character strings entered in the action board obtained from the action description portion 3412.

The UI definition information 3411 and 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. 34. 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 app has been generated.

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

Figure 33 (c) shows a flowchart of application execution processing in application user terminal 200 or 201. This processing is executed by CPU 101 of application user terminal 200 or 201, and is executed 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 Figure 33 (b) and the application execution processing in application user terminal 200 or 201 in Figure 33 (c) are executed in conjunction with each other. Below, the processing by application user terminal 200 or 201 will be described assuming that it is executed by application user terminal 200 as a representative (the description of application user terminal 201 is similar and will be omitted).

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

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

In S3313, the execution environment 400 determines whether or not an action request has been received from the application user terminal 200. An action request is a request to execute the content of the 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) described below. If an action request has been received, the process proceeds to S3314; if not, the process proceeds to S3320.

In S3314, the execution environment 400 determines whether or not a value for an input item has been received from the application user terminal 200. The value of an input item is a value input by a user on the application user terminal 200 for a UI part classified as an input item among UI parts displayed on the screen of the application. For example, it is text input into a Textfield. 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 a value for the input item has been received (if the value of the input item was included in the action request), proceed to S3315; if not, proceed to S3316.

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

In S3316, the execution environment 400 executes the execution environment program 3424 to execute the requested action. If a value for an input item has been received, the action is executed using the value for 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.

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 screen of the app displayed on the app user terminal 200, as a result of executing the action in S3316. For example, if the action is an action such as "perform arithmetic operations", the solution of the operation is obtained as the value of the output item. Also, for example, if the action is an action such as "transition to a screen" or "record in a database", there may not be a value for the output item as a result of the action. If there is a value for the output item, proceed to S3318, and if not, proceed to S3319.

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

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 a value of the output item was generated in S3318, the value of the output item will also be sent to the application user terminal 200. Then, in S3348 of FIG. 33(c) described below, the value of the output item is 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 process of S3347 of FIG. 33(c) described below.

In S3320, the execution environment 400 determines whether or not to end the process. When the execution environment 400 determines that the process is to be ended (Yes in S3320), the execution environment 400 ends the process. When the execution environment 400 determines that the process is not to be ended (No in S3320), the process returns to S3313. For example, the execution environment 400 determines that the process is to be ended when an event occurs in S3350 that ends the app, which will be described later.
33(c) , application user terminal 200 (including application user terminal 201, but the following description will be given taking application user terminal 200 as an example) uses internet browser software to access an application that has been deployed (constructed, generated) in execution environment 400. More specifically, in response to an operation of specifying the URL of a deployed application (URL for accessing the execution environment) and accessing it (for example, clicking on a link for the application's URL, or entering the application's URL in the address bar and pressing the Enter key), the application user terminal 200 accesses (connects to) the application's URL.

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

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

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

In S3335, the application user terminal 200 determines whether an action has been triggered. Specifically, it determines whether an operation has been performed on the application screen to instruct a screen transition (a trigger to activate an action on the canvas of the transition destination) or an operation has been performed on a UI part displayed on the application screen (a trigger to activate an action on a UI part by clicking, etc.). If an action has been triggered, the process proceeds to S3336; if not, the process proceeds to S3350.

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

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

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.

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

In S3340, the application user terminal 200 records information based on the element string ($ui.UI component ID.type of target information) 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 UI component ID (item code, component identifier) is obtained from the element string ($ui.UI component ID.type of target information) of a structure separated by "." (period) beginning with "$ui", and records that the UI component is an output item. For example, if a trigger related to action A occurs, "$ui" is found in the description part related to action A, it is on the left side, and the UI component ID is "UI component ID3", then it is recorded that UI component ID3 is in the output item, as in item definition list 3433 in FIG. 34. The item definition list 3433 is information that is 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 or the processing of S3349, described below, is ended) or when the app is terminated (Yes in S3350).

In S3341, the application user terminal 200 determines whether the character string "$ui" found in S3338 is found anywhere other than on the left side of a sentence containing the character. "Located anywhere other than on the left side" refers to the case where the character string is found on the right side (to the right of the "=") or in a portion not containing the "=". If the character string is found anywhere 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 found anywhere other than on the left side of a sentence containing the character, and therefore the process may proceed to S3342 without making the determination in S3341.

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

After completing the process 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 processes of S3339 to S3342 are repeated until it is determined in S3338 that "$ui" is not present. In other words, the processes of S3339 to S3342 are performed for all $ui character strings contained in the description portion extracted in S3336, and whether they are input items or output items is recorded in the item definition list 3433.

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 part ID1.value" is written in the description portion extracted in S3336, it determines whether the information of the type "value" in the UI part with UI part ID1 has a value. If the UI part with UI part ID1 is a TextField, the value is the text (character string) entered in that TextField. In other words, it determines whether the user of the application has entered text with the keyboard for UI part ID1, which is a TextField displayed on the screen of the application, and if text has been entered, it determines Yes, and if it 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, proceed to S3344; if not, proceed to S3345.

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

In S3345, the application user terminal 200 transmits to the execution 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 execution environment 400. For example, as the value of the input item, text information entered by the application user on the keyboard for UI part ID1, which is a TextField displayed on the application screen displayed on the display 105 of the application user terminal 200, is transmitted to the execution environment 400. The action request transmitted here is received by the execution environment 400 at S3313 in FIG. 33(b) described above, which is executed in the execution environment 400, and the action corresponding to the trigger detected in S3335 is executed in the execution environment 400, as described in S3314 to S3319.

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 execution 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.

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, too, the display is 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.

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.

In S3349, the application user terminal 200 displays the value of the output item included in the result of the action received in S3346 in the output item displayed on the display 105 based on the information of the output item 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 component of the output item, or if the type of information in question is "color", the color of the UI component of the output item is changed to the color indicated by the value of the output item.

In S3350, the application user terminal 200 determines whether an event that terminates the application has occurred. An event that terminates the application is, for example, disconnection of 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 another unrelated URL, etc.). If there is no event that terminates the application, the process proceeds to S3335, and if there is an event that terminates the application, the application screen is hidden and the process of FIG. 33(c) is terminated.

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

The second line states "const userid = $ui.text_field_a.value;" In this statement, because "$ui" is on the right-hand side, "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".

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 in the processing of S3340. In other words, the value indicated by the right side of "=" (the output value obtained as a result of the action) is displayed in the UI component "text_area_a". In addition to defining "text_area_a" as an output item, this statement contains processing (logic) that outputs the value indicated by 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 items and output items can also be defined in a statement that contains logic (processing that is different from the definition of at least one of the input items and output items). Similarly, the sixth line is a logic section, and because "$ui.text_area_a.value" is on the left side, it is treated as an output item.

Below is an example of an action string that has "$ui" in a statement without "=".

(The numbers at the beginning of each line are auxiliary characters that indicate the line number and are not the programming language text itself.)
1 SQLSave({
2 PREF_CODE: $ui. PREF_CODE. value,
3 PREF_NAME: $ui. PREF_NAME. value
4 });
5 // Screen transition 6 $fn. nextUI('List_ip_demo');
The character string in the above programming language is an action to register the input value ('$ui.PREF_CODE.value', $ui.PREF_NAME.value) of the application screen in the database as a parameter of the SQLSave function. In this case, $ui.{part 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 =).

In addition, in an element string of a specified structure using "$ui", the type of information to be targeted may be something other than value, such as color. For example, the color of a UI component can be changed by writing "$ui.UIComponentID.color = "#008000";".

In this embodiment, in the description of an action to be entered into the action board, depending on the position of the element string with a specific identifier "$ui" in the string (more specifically, the position in a sentence), it is possible to write (define) whether the UI part indicated by the element string is to be treated as an input item or an output item. Conventionally, whether to treat it as an input item or an output item was determined in a setting screen separate from the area where the content of the action is entered in a programming language. Or, conventionally, even if the content of the action was described in the area where the content of the action is entered in a programming language, it was necessary to declare using a variable whether to treat it as an input item or an output item in a sentence separate from the sentence of the logic part indicating the processing itself. In contrast, in this embodiment, the definition of the input item and the output item can be defined at any description point of the string describing the action logic in a programming language. Therefore, the input item and the output item to be used in the logic can be defined near the logic description part, and the input item and the output item to be used in the logic can be easily set when describing the logic. Furthermore, in this embodiment, there is no need to define variables once for the transfer of values between the function setting screen and the action logic description portion of the input and output items. This reduces the need for developers to perform cumbersome variable management, making variable management easier. This reduces the factors that can cause errors when describing 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.

In addition, the method of expressing whether an element string with the specific identifier "$ui" is an input item or an output item based on its position is not common, so when a program is executed based on the normal JavaScript programming language, it does not properly interpret whether it is an input item or an output item, and does not operate as intended. Therefore, in this embodiment, a process is performed to identify whether a string containing "$ui" as an input item or an output item, as explained in S3338 to S3342, and to classify it, thereby creating a mechanism that operates correctly.

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 a dollar character in Unicode. The half-width character "_" is an underscore character in Unicode.

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

In this embodiment, an example has been described in which the program for the 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 the execution environment 3414, and instead, the execution environment 400 may record the UI definition information 3421 in the execution environment 400 and then generate the program for the execution environment 3423 based on the UI definition information 3421.

<Modification of Action Execution Related Processing>
35(a) shows a modified flowchart of the save process (record 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.

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 and 201. FIG. 36 is a diagram that shows a schematic representation of the transition of information through the processing of the flowcharts in FIGS. 35(a) to 35(c). In FIG. 36, the same information as in FIG. 34 is given the same reference numerals.

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

In FIG. 36, unlike FIG. 34, the UI definition information is not sent to the application user terminal 200 (it is not even temporarily recorded in the application user terminal 200). This prevents detailed definitions of the developed application from being leaked via the application user terminal 200, and increases confidentiality of the configuration of the developed application. Therefore, for example, it is possible to reduce the possibility that an application that imitates at least a part of the developed application (for example, JavaScript code written in the action board) is created by a third party. In addition, the application user terminal 200 does not need to perform a process of analyzing the UI definition information and generating the 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 the application user terminal 200, and allows the application to operate with a smooth response (response speed).

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

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

In S3506, the development environment 300 extracts the action description portion 3412 from the UI definition information 3411. In this process, description portions related to all actions are extracted, not just descriptions related to specific actions.

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

In S3508, the development environment 300 determines whether or not the character string "$ui" was found as a result of the search in S3337. If "$ui" was found, the process proceeds to S3509, otherwise the process ends. S3508 returns No when all "$ui" searches have been completed or when no "$ui" was found in the action description section.

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

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

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

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

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

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

Fig. 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).

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

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

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

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

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

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; if not, the process proceeds to S3553.

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. In this modified example, the processes corresponding to S3336 to S3342 in FIG. 33(c) described above are not performed by the application user terminal 200.

Next, we will explain Figures 37(b') and (c).

Below, we will explain the differences with Figures 33(b) and (c), and unless otherwise noted, the explanation for Figure 33 will be the same.

The process in FIG. 37(b') is a more specific description of the process executed in S3316 in FIG. 33.

Before explaining the action execution of S3701, an example of action settings is shown in Fig. 38 and Fig. 42(a). By setting the action setting of button 3801 (Fig. 38) to "upload" (3802), button 3801 becomes a button for uploading a file.

That is, the button 3801 is a diagram showing an example in which the component relating to data upload is a button. Furthermore, when the selection of the action 542 for the link 4201 (FIG. 42) is accepted, an action can be set for the link 4201.

That is, link 4201 is a diagram showing an example in which a component related to data download is a link. The processing flow when the selection of action 542 is accepted is as shown in Figures 7 and 8, so a description thereof will be omitted here.

In S3701, the execution environment 400 begins executing the requested action.

In S3702, the execution environment 400 executes an action based on the action code entered into the action board.

If the action code contains "$fn.getUploadFiles", proceed to S3703, and if it contains "$fn.download", proceed to S3705. Otherwise, proceed to S3704 to execute normal code.

The "$fn" above is a function (reserved word) that is pre-prepared by this development tool.

That is, the action boards of Figures 39 (a) to (c) are diagrams showing an example of a process for controlling to accept instructions using functions or reserved words related to data uploading. That is, the action boards of Figures 42 (b) to (e) are diagrams showing an example of a process for controlling to accept instructions using functions or reserved words related to data downloading. Note that, although "$fn" is used in this embodiment, this is not limited to the description format, and other description formats such as "$function" or "<fn>" may also be used.

This allows app developers to save the trouble of having to write complex processes related to uploading and downloading. In other words, it allows them to reduce the amount of development work while still implementing detailed processes that meet the requirements of the application.

In S3703, the execution environment 400 retrieves the file from the temporary storage URL (where the file uploaded from the application user terminal 200 is temporarily stored). The temporary storage URL is described in S3713 to S3178 below.

An example of an action code related to uploading entered into the action board is shown in Figure 39 (a).

The second line retrieves the uploaded file from the temporary storage URL and assigns it to a variable.

The fifth line is the process of saving the file obtained in the second line to the cloud.

In other words, S3703 is a step that shows an example of a process for accepting and controlling the execution of an instruction using a function or reserved word related to uploading data.

The third line in Figure 39 (b) is an example of a process for converting the obtained uploaded file into a string.

The fourth line in Figure 39 (c) is an example of a process for setting the file name of the acquired uploaded file.

Line 6 in Figure 39(c) is an example of business logic that checks the file contents and determines whether or not it is a confidential document.

Line 8 of Figure 39(c) is an example of a process for saving a file in a confidential document folder if the file is a confidential document.

Line 11 of Figure 39(c) is an example of a process for saving a file in a general folder if the file is not a confidential document.

In this embodiment, the above-mentioned processes are given as examples, but are not limited to these examples, and may be processes related to control of the application screen, business logic, database processing, processes for uploading data, processes for downloading data, processes using uploaded data, processes according to uploaded data, processes for substituting uploaded data into variables, processes for processing uploaded data, processes for saving uploaded data in a specified location, processes for saving uploaded data online, processes for saving uploaded data in a database, processes for downloading uploaded data, and processes for transferring uploaded data.

In this way, source code using JavaScript can be written on the action board, and users can freely set actions as long as the process can be written in JavaScript.

That is, the action board in FIG. 39 is a diagram showing an example of control to accept instructions written in source code. Note that in this embodiment, the source code uses JavaScript, but this is not limited to this method, and source code may use other languages such as Java (registered trademark) or Python (registered trademark).

This allows app developers more flexibility in how they perform download processes, for example by downloading files stored in any location (storage, cloud, database, etc.).

Furthermore, if one has already mastered JavaScript, one can easily build an application that executes the desired process relating to downloading data, without having to learn a language unique to the development tool.
Furthermore, even complex download-related processes can be realized by inputting source code written in JavaScript into the action board, making it possible to execute the processes in a simpler manner.

In applications built with application development support tools, in order to upload binary files such as document files, spreadsheet files, and image files and perform various processes in the application, application developers were previously required to write complex processes. However, with the above, there is no longer a need to write complex processes, making it easier to build applications that perform the desired processes related to uploading data such as binary files.

In S3704, the execution environment 400 executes the code entered in the action board. The specific contents have already been explained in the processing of S3316, so they will not be explained here, but we will provide additional explanation only on the business logic of the processing related to uploading or downloading.

The third line in Figure 39(b) is an example of a process for converting the obtained uploaded file into a character string, but since this process does not contain "$fn", it is executed in S3704.

The execution result is shown in FIG. 41, 4100, where the contents of the uploaded file converted into a string are displayed in text area 4101.

In this embodiment, the uploaded file is replaced with a character string, but this is not limited to the example. It is also possible to search a database based on keywords in the uploaded file, or to draw a graph based on the data in the uploaded file and display it on the screen.

In S3705, the execution environment 400 outputs the file passed as the argument to a temporary storage area for downloading. An example of an action code related to downloading input to the action board is shown in FIG. 42(b).

Line 1 4202 is a process for retrieving a file located at a specified path from storage 420 of execution environment 400, and the argument describes the path of the file to be retrieved. In this case, "sample.txt" is the file name to be retrieved. In the file path, the storage location of the file to be downloaded to the application user terminal 200, for example, a document file, text file, audio file, image file, video file, compressed file, program file, etc., is input.

As in line 2 4203, it is also possible to change the name of the label of the component for which the action is set to be executed. For example, if the label name is set to "download", the name can be changed to "sample.txt" when the action is executed. The description in line 2 4203 is optional, and a different command may be written or it may be omitted.

In the third line 4204, the download function is called by specifying a file as an argument. When this call is executed, the file is downloaded to the application user terminal 200.

In other words, S3705 is a step showing an example of a process for accepting and controlling the execution of an instruction using a function or reserved word related to downloading data.

Note that while Figure 42(b) shows an example of downloading a file from the storage of the execution environment 400, this is not limited to this, as shown in Figures 42(c) to (e).

Figure 42 (c) is an example 4205 of downloading a file from storage on a cloud other than the execution environment 400.

Figure 42 (d) is an example 4206 of downloading data from a database. For example, user list data stored in a database is obtained and converted to CSV data. Then, the CSV data is downloaded.

Figure 42 (e) is an example 4207 of downloading an uploaded file. The file (e.g., an image file) uploaded by the process of S3711 described below is obtained, the image is reduced, and the reduced image file is downloaded to the application user terminal 200.

Here, it is assumed that the data is downloaded as a file, but it may also be downloaded as streaming data rather than as a file, or transferred as data over a communications protocol (e.g. HTTP, FTP, SMTP, etc.).

In this embodiment, the above-mentioned processes are given as examples, but are not limited to these examples, and the process may be related to control of an application screen, business logic, database processing, processing for uploading data, processing for downloading data, processing for downloading a file, processing for downloading data stored in a specified location, processing for downloading data stored online, processing for downloading data stored in a database, processing for downloading uploaded data, processing related to control of an application screen, business logic, or processing for downloading the results of database processing.

In this way, source code using JavaScript can be written on the action board, and users can freely set actions as long as the process can be written in JavaScript.

That is, the action boards in Figures 42 (b) to (e) are diagrams showing an example of control to accept instructions written in source code. Note that in this embodiment, the source code uses JavaScript, but this is not limited to this method, and source code may use other languages such as Java (registered trademark) or Python (registered trademark).

This allows app developers more flexibility in how they perform download processes, for example by downloading files stored in any location (storage, cloud, database, etc.).

In addition, if you have already learned JavaScript, you can easily build an application that performs the desired processing related to downloading data without having to learn the development tool's own language.

In addition, even complex download-related processes can be executed in a simpler way by simply entering source code written in JavaScript into the action board.

In S3706, the execution environment 400 generates a URL for a temporary storage area for downloading. Specifically, a temporary storage area is created in the storage 420 of the execution environment 400 (which is assumed to be a storage in a separate housing from the execution engine 412), and a URL for the storage location is generated.

In this way, by creating a temporary storage area for downloading within storage 420 and storing files there, the download process can be performed without using memory 414 of execution environment 400 when downloading, thereby conserving memory 414 of execution environment 400.

Note that, although an example has been shown here in which a temporary storage area for downloading is created in storage 420, it is also possible to store the area in memory 414 of execution environment 400 and download the file from there.

In S3707, the execution environment 400 ends the execution of the code entered into the action board.

This concludes the explanation of the process in Figure 37(b'), which is a more specific example of the process executed in S3316 in Figure 33.

That is, step S3316 is a step that shows an example of a process in which, when the component is a component related to data downloading and an operation on the component is received from a user of the constructed application, the processing is controlled to be executed based on the received processing content.That is, step S3316 is a step that shows an example of a process in which, when the component is a component related to data downloading and an operation on the component is received from a user of the constructed application, the processing is controlled to be executed based on the received processing content.

That is, step S3302 in FIG. 33 is a step showing an example of a process for controlling the received processing content to be stored in association with a component.

In other words, each step in FIG. 37(b') is a step showing an example of a process that includes at least one of the following: a process related to control of an application screen, business logic, database processing, a process for uploading data, a process for downloading data, a process for downloading a file, a process for downloading data stored in a specified location, a process for downloading data stored online, a process for downloading data stored in a database, a process for downloading uploaded data, and a process related to control of an application screen, business logic, or a process for downloading the results of database processing.

In other words, each step in FIG. 37(b') is a step showing an example of a process for controlling the successive execution of two or more processes among a process related to the control of an application screen, business logic, database processing, a process for uploading data, a process for downloading data, a process for downloading a file, a process for downloading data stored in a specified location, a process for downloading data stored online, a process for downloading data stored in a database, a process for downloading uploaded data, and a process related to the control of an application screen, business logic, or a process for downloading the results of database processing.

Next, we will explain Figure 37(c).

In S3711, the application user terminal 200 determines whether the action to be executed is an upload action. If it is an upload action, the process proceeds to step S3712, and if it is not an upload action, the process proceeds to step S3345.

In S3712, the app user terminal 200 displays a file selection window and accepts the user's selection of a file to upload.

Specifically, as shown in FIG. 40, when a button 4001 to which an upload action is set is pressed, the application user terminal 200 displays a file selection window 4002 and receives a selection of a file 4003 to be uploaded from the user (4004).
In S3713, the application user terminal 200 requests the execution environment 400 for the URL of the temporary storage location of the file.

In S3714, the execution environment 400 accepts a request for the URL of the temporary storage location of the file.

In S3715, the execution environment 400 creates a temporary storage location URL for the file. Specifically, a temporary storage area is created in the storage 420 of the execution environment 400 (which is assumed to be a storage in a separate housing from the execution engine 412), and a storage location URL is generated.

In S3716, the execution environment 400 returns the URL of the temporary storage location of the file.

In S3717, the application user terminal 200 obtains the URL of the temporary storage location of the file.

In S3718, the application user terminal 200 uploads the file selected by the application user in S3712 to the file temporary storage location URL.
As described above, according to this embodiment, an application that executes a desired process related to uploading data can be easily constructed.
In this way, by creating a temporary storage area for uploading within storage 420 and storing files there, the upload process can be performed without using memory 414 of execution environment 400 when downloading, thereby conserving memory 414 of execution environment 400.

In S3719, the application user terminal 200 determines whether the action execution result includes a download URL. If so, the process proceeds to S3720; if not, the process proceeds to S3350. Specifically, when the action result is received in S3347, the application user terminal 200 determines whether the action execution result includes a download URL created by the execution environment 400 in S3706.

In S3720, the application user terminal 200 downloads the file included in the download URL. Specifically, it downloads the file that was temporarily output by the execution environment 400 in S3705.

That is, step S3720 is a step showing an example of a process for controlling the execution of a process related to downloading data.

An example of a screen displayed on the application user terminal 200 is shown in FIG. 43. For example, a table stored in a database or the like is acquired, and the table contains components such as a character string 4301 and an icon 4302. An action related to downloading is set for the component, and when the character string 4301 or the icon 4302 is selected, a download process is executed.

As a result, the display format of components is not limited to text boxes (character strings) but can be a variety of formats such as icons and image images, so in this embodiment, which sets actions for components, download processing can also be set for any component.

In other words, Figure 43 shows an example in which the display format of a component includes at least one of a string, an image, and an icon.

In other words, S3720 is a step showing an example of a process in which, when the component is a component related to downloading data and an operation on the component is received from a user of the constructed application, the component is controlled to execute processing based on the received processing content.

In other words, S3720 is a step showing an example of a process in which the process contents received by the action board or the like are stored in association with a component, and a process is executed based on the process contents stored in association with the component that received the operation from the user.

As described above, according to this embodiment, it is possible to easily build an application that executes the desired processing related to downloading data.

If you were to try to execute a download process by developing from scratch, the file you are trying to download would already be saved in a fixed location, and the download would be executed from that location. Also, a fixed string of characters or a fixed link format would be generated, and the download process would be executed by selecting it. Also, even for complex processes, it would be necessary to write the code from scratch, which is time-consuming.

In contrast, according to this embodiment, it is possible to set an action for any component, and it is possible to download a file from any location by specifying the save location. Furthermore, even if the processing is complicated, it can be realized by setting an action for the component, so there is no need to write code from scratch, and it can be realized in a simpler way.

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.
In addition, although the present invention has been described in detail based on the 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-mentioned embodiments merely shows one embodiment of the present invention, and each embodiment can be appropriately combined.

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 medium on which the program is stored constitute the present invention.

Recording media for supplying the program may include, for example, a flexible disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a DVD-ROM, a magnetic tape, a non-volatile memory card, a ROM, an EEPROM, a silicon disk, etc.

Furthermore, it goes without saying that not only are the functions of the above-mentioned embodiments realized by the computer executing a program it has read, but also that the above-mentioned functions of the embodiments are realized by an operating system (OS) or the like running on the computer carrying out some or all of the actual processing based on the instructions of the program.

Furthermore, it goes without saying that this also includes cases where a program read from a recording medium is written into a memory provided on a function expansion board inserted into a computer or a function expansion unit connected to a computer, and then a CPU or the like provided on the function expansion board or function expansion unit performs some or all of the actual processing based on the instructions of the program code, thereby realizing the functions of the above-mentioned embodiments.

The present invention may be applied to a system made up of multiple devices, or to a device made up of a single device. Needless to say, the present invention can also be applied to cases where the effects of the present invention are achieved by supplying a program to a system or device. In this case, the effects of the present invention can be enjoyed by reading a recording medium that stores a program for achieving the present invention into the system or device.

The program may be in the form of object code, program code executed by an interpreter, script data supplied to an OS (operating system), etc.

Furthermore, by downloading and reading a program for achieving the present invention from a server, database, etc. on a network using a communication program, the system or device can enjoy the effects of the present invention. Note that the present invention also includes configurations that combine the above-mentioned embodiments and their modified examples.

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

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

[Configuration 1-2]
a setting means for setting information about the creation function based on an input operation from the user on a setting screen for creating the creation 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 creative function when a character string that partially matches the identification information of the creative function is input into a description area of a programming language;
An information processing system comprising:

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

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

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

[Configuration 4]
An information processing system including a first type of environment (development environment) and a second type of environment (execution environment),
an acquisition means for acquiring access destination information in the second type environment from a specific area of a specific environment among environments 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 of transmitting user information) to an access destination indicated by the access destination information acquired by the acquisition means.

[Configuration 5]
An information processing system including a first type of environment (development environment) and a second type of environment (execution environment),
an authentication means for performing user authentication to determine whether 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 an environment identified by the environment specifying information without acquiring authentication information related to the second type of environment from a user, based on the environment specifying information acquired by the acquisition means;
An information processing system comprising:

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

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

[Configuration 8]
A receiving means for receiving a selection of a table;
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 input screen for an action;
and a control means for controlling, in response to a selection of any one of the plurality of options, to display an input screen for an action in a column corresponding to the selected option and to accept an input operation of the action from a user.

[Configuration 9]
An acquisition means for acquiring a character string input into an input area of a programming language;
a specification means for specifying, based on an element string to which a specific identifier is assigned, among the character strings acquired by the acquisition means, that the element string is information of either an input item which is information to be acquired as an 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 while reflecting the content identified by the identification means;
An information processing system comprising:

[Configuration 10]
A control means for controlling to define an action for a screen of application software to be constructed based on a group of operations including an operation of selecting from options, not including an operation of writing source code in a programming language, or to place an automatically generated component having an action defined thereon as a component to be displayed on the screen of the application software to be constructed (for example, placement of a button having an action defined thereon by workflow generation, a UI screen having an action defined on a canvas, placement of a button by CRUD button placement, generation of a UI screen, etc.);
a display control means for controlling, when the control means selects either the screen on which an action is defined or the automatically generated component and an instruction is given to display the action, the action defined for the selected object is displayed as a character string in a programming language;
a reception means for receiving a correction operation of the character string in a programming language expressing an action displayed by the display control means;
An information processing system comprising:

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

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

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

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

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

Claims (12)

A reception control means for controlling reception of instructions regarding the processing contents of components to be arranged on an application screen;
A construction control means for controlling construction of an application including a screen displaying the component;
and an execution control means for controlling, when the component is a component related to data downloading and an operation on the component is received from a user of an application constructed by the construction control means, to execute processing based on the processing content received by the reception control means. The processing content is:
Processing related to control of application screens;
Business logic,
Database processing,
The process of uploading data,
The process of downloading data,
The process of downloading files
A process to download data stored in a given location;
The process of downloading data stored online;
A process to download data stored in a database;
The process of downloading uploaded data;
2. The information processing system according to claim 1, wherein the process includes at least one of a process related to control of an application screen, a business logic, and a process for downloading a result of a database process. The execution control means
Processing related to control of application screens;
Business logic,
Database processing,
The process of uploading data,
The process of downloading data,
The process of downloading files
A process to download data stored in a given location;
The process of downloading data stored online;
A process to download data stored in a database;
The process of downloading uploaded data;
and controlling the execution of two or more processes in succession among a process related to control of an application screen, a business logic, or a process for downloading a processing result of a database processing. the construction control means controls so as to store the process content received by the reception control means in association with the component;
2. The information processing system according to claim 1, wherein the execution control means controls the execution of the process based on processing content stored in association with the component that has received an operation from the user. The execution control means
2. The information processing system according to claim 1, further comprising control means for executing a process relating to downloading of data. The reception control means
2. The information processing system according to claim 1, further comprising control for accepting an instruction using a function or a reserved word relating to downloading of data. The reception control means
2. The information processing system according to claim 1, further comprising control for accepting instructions written in source code. 2. The information processing system according to claim 1, wherein the component is a link. The display format of the component is:
2. The information processing system according to claim 1, wherein the information includes at least one of a character string, an image, and an icon. 2. The information processing system according to claim 1, further comprising a display control means for controlling so as to display an input area for receiving an instruction regarding the processing content. an acceptance control step of controlling to accept instructions regarding the processing contents of components to be arranged on the application screen;
A construction control step of controlling construction of an application including a screen displaying the component;
and an execution control step of controlling, when the component is a component related to data downloading and an operation on the component is received from a user of the application constructed by the construction control step, the component being executed based on the processing content received by the reception control step. A program for causing at least one computer to function as each of the means of the information processing system described in any one of claims 1 to 10.

Images