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

Abstract

To provide a mechanism of being able to perform an input operation of an action with higher operability on each column included in a table.SOLUTION: An information processing system has: receiving means that receives selection of a table; display control means that controls to display a plurality of options corresponding to respective input regions of actions of a plurality of columns included in the selected table; and control means that controls to display the input region of the action of the column corresponding to the selected option in accordance with the selection of any of the options, and receive an input operation of the action from a user.SELECTED DRAWING: Figure 32

Description

[Technical field]

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

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

[0003] Patent Document 1 proposes a method for placing a table (data grid) in an application to be constructed. Specifically, the following is disclosed. Data grid components are placed on a screen editor by drag-and-drop or other operations. When the data grid components are placed, a simple lattice grid is displayed, and it is then set which items of which data model are to be displayed in this table. The setting of these items is also set by dragging and dropping the data model. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2018-010616 A Summary of the Invention [Problem to be solved by the invention]

[0005] Actions can be set for each column of a table. For example, when a value in the first column of a table is changed, the display is updated to show the sum of the changed values ​​in the first and second columns in the third column of the same row. If such actions for each column are set by opening a detailed setting screen for each column, it is difficult for users to recognize that actions can be set for columns, and there is a possibility that an action for a column may not be set. Patent Document 1 does not take into consideration how actions should be set for table columns.

[0006] In view of at least one of the above problems, the present invention has an object to provide a mechanism that enables easier input of actions for each column included in a table. [Means for solving the problem]

[0007] The information processing system of the present invention comprises: 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 respective action input areas for each of a plurality of columns included in the selected table; a control means for controlling, in response to a selection of any one of the plurality of options, to display an action input area for a column corresponding to the selected option and to receive an input operation of the action from a user; The present invention is characterized by having the following. Effect of the Invention

[0008] According to the present invention, it is possible to input actions with greater ease for each column included in a table. [Brief description of the drawings]

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

[0010] Hereinafter, the embodiments will be described in detail with reference to the accompanying 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 essential to the invention. Two or more features among the multiple features described in the embodiments may be arbitrarily combined. In addition, the same reference numbers are used for the same or similar configurations, and duplicated descriptions are omitted.

[0011] Various features shown in the following embodiments can be combined with each other. In the following, "application" and "app" both mean application software.

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

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

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

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

[0016] The execution engine 302 is at least one hardware resource for executing a process 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 one processor on a cloud, or may be a processor group combining a plurality of 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 realized by the processor 303 expanding it into an area of ​​the development environment 300 that serves as a work memory and executing it.

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

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

[0019] The developer accesses the development environment 300 by accessing a URL for accessing the development environment 300 from the browser software of the developer terminal 100, and logs in to the development environment. 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. Then, the developer performs an operation to design a new application or an operation to update and design an existing (in-progress) application, and transmits the resultant 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.

[0020] The execution environment 400 is an environment using at least one hardware resource built 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 built 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 built in the execution environment 400 on the network is a so-called WEB application.

[0021] The multitenant execution environment 410 is an execution environment of a multitenant environment shared by multiple developers, and applications developed by multiple developers are deployed in the multitenant execution environment 410. In other words, the multitenant execution environment 410 is an environment shared by multiple developers, and is an environment in which multiple applications by multiple developers can be built. The multitenant execution environment 410 includes user information 411, an execution engine 412, a delivery engine 415, a storage 420, and a DB set 433.

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

[0023] The execution engine 412 is at least one hardware resource for executing a process 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 one processor on a cloud, or may be a processor group combining a plurality of processors. The memory 414 is at least one recording medium in which a program to be executed by the processor 413 is recorded. Among various flowcharts described later, those described as being executed by the multitenant execution environment 410 are executed by the execution engine 412. That is, the processor 413 expands and executes the program recorded in the memory 414 in an area serving as a work memory in the multitenant execution environment 410. The program executed here includes a program that executes an action of an application.

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

[0025] The storage 420 is a storage area of ​​at least one recording medium, and stores at least a client program 422 that is common to a plurality of applications. In addition, in a predetermined area (a predetermined folder, a predetermined bucket, a predetermined level) of the 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 a developer A area 423 which is an area for developer A, a developer B area 424 which is an area for developer B, and a developer C area 425 which is an area for developer C. In each developer area, definition information of an application developed by each developer and deployed from the development environment 300 is stored. For example, an application definition 423a is recorded in the developer A area 423.

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

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

[0028] Using the system of FIG. 1, for example, an operator may provide the multi-tenant execution environment 410 to a developer free of charge, and provide 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, the developers do not need to bear the costs for trial use of this system, making it easy for many developers to use and promoting the spread of this system. The operator recovers costs by charging developers for the single-tenant execution environments.

[0029] There is an upper limit to the number of processing requests that can be processed per unit time in one execution environment, and when many applications are built in a multi-tenant execution environment and many app users access the environment simultaneously, the requests cannot be processed, which may result in the applications running slowly. In addition, there are some limitations on the number of applications developed by many developers that can be deployed and executed in a multi-tenant execution environment, and these limitations may prevent the applications from performing satisfactorily. If a developer pays to own a dedicated single-tenant execution environment, the problems caused by the limitations of such a multi-tenant execution environment can be avoided (or reduced). In other words, by building an application in a single-tenant execution environment, it is possible to build an application that performs satisfactorily.

[0030] Considering the characteristics of both the multi-tenant single environment and the single-tenant execution environment, the developer can use the system as follows. For example, when using the system for the first time, the developer can build an application developed using the system in the multi-tenant execution environment 410 and test it, and then, if the developer determines that the system is useful for the developer's software development, introduce the single-tenant execution environment for a fee. When developing a specific application X, the developer builds an alpha version of the application X in the multi-tenant execution environment 410 for a limited number of test users to test before releasing it to general users. The developer tests the application X, modifies the application X, and further develops it. After the development is completed to a level where it can be released to general users, the developer builds a production version of the application X in the single-tenant execution environment and releases it to general users. By using the system in this way, the developer can reduce development costs during the development period and operate an application without problems even when used by a large number of general users.

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

[0032] The memory 102 is, for example, a RAM (a volatile memory using a semiconductor element, etc.). 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, etc. The non-volatile memory 103 is, for example, a hard disk (HD), a ROM, etc.

[0033] 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., under the control of the CPU 101. 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 a specific image processing. Depending on the type of image processing, the CPU 101 can also perform image processing according to a program without using the image processing unit 104.

[0034] Display 105 displays images, GUI screens constituting a GUI (Graphical User Interface), and the like under the control of CPU 101. CPU 101 generates 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 processes executed by developer terminal 100, application user terminal 200, and application user terminal 201 is assumed to be display 105 of each operator.

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

[0036] The recording medium I / F 107 is capable of receiving a recording medium 108 such as a memory card, CD, or DVD, and reads data from the received recording medium 108 and writes data to the recording medium 108 under the control of the CPU 101. The external I / F 109 is an interface for connecting to an external device via a wired cable or wirelessly, and inputting and outputting video and audio signals. The communication I / F 110 is an interface for communicating with an external device, the Internet 111, and the like, and transmitting and receiving various data such as files and commands. The developer terminal 100 is capable of communicating with a development environment 300 on the Internet 111 (capable of transmitting and receiving information) using the communication I / F 110. The application user terminals 200 and 201 are capable of communicating with an execution environment 400 on the Internet 111 (capable of transmitting and receiving information) using the communication I / F 110.

[0037] <Login process> 3(a) and (b) show a flowchart 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 specify the URL of the development system (application development platform) of this embodiment and access it, the process of FIG. 3(a) is started. The process of FIG. 3(a) 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.

[0038] 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 a client program 322 to the developer terminal 100 that originated the access.

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

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

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

[0042] In S304, the developer terminal 100 accepts input operations into the input fields of the login screen for the developer ID and password. The user's input operations are performed using the operation unit 106. The developer ID is user identification information for identifying (specifying) the developer user. In this embodiment, the developer ID (user name) is an email address. Furthermore, 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).

[0043] 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 or display item such as a button or icon) by clicking with the mouse included in the operation unit 106 or by touching the touch panel will be referred to simply as "pressing." If the New Registration button has been pressed, the process proceeds to S306, and if not, the process proceeds to S307.

[0044] In S306, the developer terminal 100 performs a developer account registration process. The details of the developer account registration process will be described later with reference to FIG.

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

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

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

[0048] In S310, the developer terminal 100 determines whether or not it has received an execution environment list from the development environment 300. Since the development environment 300 transmits the execution environment list to the developer terminal 100 if the login authentication is successful, receiving the execution environment list means that the login authentication was successful (login was successful). If the execution environment list has been received, the process proceeds to S311, and if not, the process returns to S309.

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

[0050] FIG. 5(a) shows an example of the display of execution environment options in S311. In the display example of FIG. 5(a), two options are displayed as execution environments 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 can 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. The execution environment selected here can be changed by the operation described later.

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

[0052] In S313, the developer terminal 100 records information (such as an execution environment ID) that identifies the execution environment selected in S312 in memory 102 as the "selected execution environment" and transmits 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 application information, information (such as application IDs and application names) that identifies all applications owned by the logged-in developer (applications that have been generated in the past and recorded in storage 320).

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

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

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

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

[0057] In S318, the developer terminal 100 judges whether or not it has received definition information (UI definition information) of the selected application from the development environment 300. If it has received the definition information of the selected application, it records the received definition information of the selected application in the memory 102 and proceeds to S319, otherwise, it waits for the reception of the definition information in S318. In this embodiment, it is assumed that 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, the display is performed based on the definition information recorded in the memory 102. When an operation for updating the selected application (for example, changing the arrangement of UI parts) is performed in the UI editor process described later, the definition information in the memory 102 is updated to define the updated content. Then, when a save instruction is given, the latest definition information recorded in the memory 102 is transmitted to the development environment 300 and saved in the area of ​​the login developer in 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, thereby making it possible to perform a comfortable update operation.

[0058] In S319, the developer terminal 100 displays a UI editor screen on the display 105 and performs display based on the received definition information. For example, a canvas (editing area of ​​a 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. A list of UI screens that the selected application has (belongs to the selected application) is displayed in the submenu area (described later) (strictly speaking, this process is performed in S401 in FIG. 4 described later). In addition, the canvas displays components (UI parts to be placed on a UI screen) that are to be placed on a UI screen selected by default (initial UI or 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.

[0059] Meanwhile, in S320, the developer terminal 100 determines whether an icon (a + mark, not shown) for creating a new application displayed on the screen displaying the list of applications has been pressed and an instruction to create a new application has been issued. If it is determined that an instruction to create a new application has been issued, the process proceeds to S321, and if not, the process returns to S316.

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

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

[0062] In S323, the developer terminal 100 displays a UI editor screen as an editing screen for the newly created application. In this case, the canvas is displayed in a shape according to whether it is for desktop or mobile, selected in S321. Also, the canvas is displayed as blank information with no components placed on it. The login process ends in the process of S323, and then the process proceeds to S401 in FIG. 4.

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

[0064] In S331, the development environment 300 determines whether or not the login information transmitted in S308 from the developer terminal 100 has been received. If the login information has been received, the process proceeds to S332, and if not, the process waits for reception of the login information.

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

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

[0067] In S335, the development environment 300 transmits to the developer terminal 100 a list of execution environments of developers (login developers) whose login has been approved and is included in the developer information 301. In addition to an email address (username, developer ID) and password, the developer information 301 records an 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 execution environment that each developer can access (the execution environment that each developer can use) is recorded in the developer information 301 recorded in the development environment 300. This runtime environment that can be logged in can only be obtained by the developer who has been granted permission to log in. Furthermore, only the runtime 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 runtime environment that can be accessed by the developer separately from information for logging in to the development environment 300. Furthermore, unauthorized access to the runtime environment by other users can be prevented.

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

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

[0070] In S338, the development environment 300 obtains application information indicating all applications owned by 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 application information transmitted here is only the application definition information necessary to display the application list described above in S315, and does not include detailed definition information regarding each application (such as component placement and information indicating actions described below).

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

[0072] In S340, the development environment 300 creates and records definition information of a new application in the area of ​​the login developer in 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, 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 multitenant 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 is terminated. After that, 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, excluding the developer code, is displayed.

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

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

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

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

[0077] In the header menu area 500, a selected execution environment box 501, a selected app box 502, a selected UI screen box 503, a save button 504, a preview button 505, and a deploy button 506 are displayed.

[0078] The selected execution environment box 501 displays the selected execution environment ID as information 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 acquired 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 is not changed, and the contents displayed in the main menu area 510, the submenu area 520, and the canvas 530 are not changed. 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 multiple execution environments.

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

[0080] In selected UI screen box 503, the name of the UI screen being edited is displayed as information representing the UI screen being edited in canvas 530. By pressing the arrow icon in selected UI screen box 504, a list of UI screens belonging to the selected application based on the definition information of the selected application acquired in S318 is displayed as a pull-down menu, and by selecting an arbitrary UI screen from the list, it is possible to change the UI screen to be edited and displayed in canvas 530.

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

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

[0083] The canvas 530 is a layout editing area for the selected UI screen of the selected application (the UI screen of the UI screen name displayed in the selected UI screen box 503). The canvas 530 in FIG. 5(b) is an example of a canvas display for a desktop application, and is displayed in a shape for a desktop. The user can select any UI widget (UI component) from the UI widget 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 widget can be adjusted by selecting the UI widget placed in the canvas area 530. In addition, by selecting a UI widget placed in the canvas area 530 and right-clicking to display a right-click menu (context menu), more detailed settings such as color scheme can be performed. 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 widget is operated can be set. The canvas context menu can be displayed by right-clicking with the cursor in a blank area of ​​the canvas 530, and an action to be executed (executed when the UI screen is displayed) when the UI screen of the canvas is loaded in the constructed application can be set by selecting an action included in the context menu.

[0084] 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 zooming instructions, and indicates that pie chart 531 is selected.

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

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

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

[0088] In S403, it is determined 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 is terminated, and the process proceeds to screen switching process 112, which will be described later. If not, the process returns to S402.

[0089] In S404, the developer terminal 100 displays the UI screen selected in S402 on the canvas 530 based on the definition information of the selected application recorded in the memory 102. If the UI screen has UI widgets previously arranged, the UI widgets previously arranged according to the definition information are displayed on the canvas 530. In other words, if a UI screen was created partway through in the past, it can be developed from the beginning. If the UI screen selected in S402 is a newly created UI screen, the canvas 530 is displayed blank with no UI widgets arranged. If the UI screen selected in S402 is a UI screen (template screen) prepared in advance as a template, a template component with a predetermined action defined is displayed at a predetermined position on the canvas 530 even if the user has not previously arranged UI widgets on the UI screen.

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

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

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

[0093] In S408, the developer terminal 100 determines whether or not 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 one of the tabs is selected, the display content displayed by the tab part is switched to the element screen corresponding to the selected tab.

[0094] The tab part will be described with reference to Figs. 6(a) and (b). Fig. 6(a) is a display example on the display 105 when a tab part 601 is arranged on a canvas 530 displaying a UI screen different from that shown in Fig. 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, namely, tabs 610, 620, and 630. Labels that can be set by a 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 settings are performed by an operation to open a tab property box from the tab context menu in S706 of the context menu processing 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, 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 widgets can be arranged in 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 widget 611 and the UI widget 612 are arranged in 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, the UI widget 621 is arranged in the element screen corresponding to the tab 620. In the examples of Figures 6(a) and 6(b), the definition information records at least the UI component ID (identification information of the UI component) of the tab component 601 and the position of the tab component 601 in the UI screen, in association with the ID (identification information of the UI screen) of the UI screen being edited on the canvas 530.Also, the IDs of UI widget 611 and UI widget 612 and the respective positions of UI widget 611 and UI widget 612 in the component screen of tab 610 are recorded in association with the ID of tab 610 of tab component 601 (identification information of the component screen). Also, the ID of UI widget 621 and the position of UI widget 621 in the component screen of tab 620 are recorded in association with the ID of tab 620 of tab component 601. Returning to the description of FIG. 4.

[0095] In S409, developer terminal 100 places the UI widget selected in S406 from submenu area 520 at a specified position on 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 widget placed in S410, UI widget ID, placement coordinates, placement size, etc. are recorded in association with the ID of the UI screen of the placement destination (the UI screen being edited).

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

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

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

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

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

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

[0102] On the other hand, in the case of other UI widgets that are not of a predetermined type, such as a tab widget, the display content of the UI widget is not changed in response to the selection of the UI widget on the canvas 530. The only processing performed in response to the selection of a UI widget is processing related to the display of an operation path, and no other actions are performed. For example, when button 532 is selected on the canvas 530 in FIG. 5(b), only an operation path is displayed, and the action of button 532 (processing executed when button 532 is pressed in the constructed application) is not executed. Also, when text field 533 is selected on the canvas 530, only an operation path is displayed, and processing such as displaying a character input cursor in text field 533 is not performed.

[0103] An example of an AppBar will be described with reference to Figs. 6(c), 6(d), and 6(e) as an example of a type of UI widget to which the processes of S409, S410, S413, and S414 can be applied in the same way as with the tab widget. Fig. 6(c) shows an example in which an AppBar650, a TextField661, and a Button662, which are UI widgets, are arranged on a canvas 530. The AppBar650 is one UI widget, and an element icon 651 and an element icon 652 are included in the AppBar650. In the constructed application, the element icon 651 is a display item that receives an instruction to display a drawer menu. In the constructed application, the element icon 652 is a display item that receives an instruction to display a pop-up menu. In the canvas 530, when the positions of the element icon 651 and the element icon 652 in the arranged AppBar650 are clicked, they are controlled in the same way as the tab part of the tab widget. More specifically, they are controlled as follows.

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

[0105] When the position of the element icon 652 in the arranged AppBar 650 is clicked (Yes in S411), an 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), an 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). In a state where the pop-up menu 652a is displayed, other UI components can be arranged in the pop-up menu 652a by dragging another UI component 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 component as an example. Return to the description of FIG. 4.

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

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

[0108] In S419, the developer terminal 100 judges whether or not an instruction operation (in this embodiment, right-clicking of the mouse) for displaying 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. In the context menu 540, property 541, action 542, and delete 543 are displayed as menu items to be selected. When property 541 is selected, a property box (detailed setting 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 by specifying a numerical value can be performed. When action 542 is selected, an action board related to the button 532 is displayed, and an action can be input to the action board in JavaScript, which is a programming language. The action entered here is the process to be executed when the button 532 (designated UI widget) is pressed in the constructed application. When Delete 543 is selected, the button 532 is deleted (deleted) from the canvas 530. Details of the context menu process will be described later with reference to FIG. 7.

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

[0110] In S423, the developer terminal 100 judges whether the preview button 505 has been pressed. If it is judged 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 widget is not displayed. In addition, some operations that are not executed on the UI editor screen (not executed by operations on the canvas 530) are executed in the preview. For example, when a UI widget for screen transition or a link portion is operated, a screen transition or transition to a link destination is executed. In addition, an operation such as moving a selection frame for an item by operating the tab key on the keyboard is also executed. Note that operations such as actions entered by the developer in the action board and database references are not executed. As a result, the preview process can be displayed faster than if you were to actually deploy and check the results.

[0111] In S425, the developer terminal 100 judges whether the deploy button 506 has been pressed. If the deploy button 506 has been pressed, the process proceeds to S426, and 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). Note that 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, the developer works to update the contents to be deployed to one specific execution environment 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 user is to be deployed from the developer user.

[0112] In S427, the developer terminal 100 determines whether or not an operation to change the selected execution environment has been performed. Specifically, it determines whether or not 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, and if not, the process proceeds to S429. In S428, the developer terminal 100 records information (such as an execution environment ID) that identifies the selected execution environment in the memory 102 as the "selected execution environment" and transmits the information to the development environment 300. In addition, the display content of the selected execution environment box 501 is updated to indicate the changed selected execution environment. When the development environment 300 receives the information that identifies the selected execution environment, the development environment 300 records the selected execution environment in a file for setting management that is saved in an area for the logged-in developer in the storage 320, based on the information.

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

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

[0115] In S431, the developer terminal 100 determines whether or not an operation has been performed to select 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 proceeds to the screen switching process described later with reference to Fig. 12. If not, the process returns to S406.

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

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

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

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

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

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

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

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

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

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

[0126] In S713, the developer terminal 100 displays a property box for the button superimposed on the canvas 530 as a property box (detailed setting dialog) for the specified UI widget. Then, various setting operations for the property box are accepted. Here, for example, detailed settings can be made such as the button name (label) to be displayed for the button that is the specified UI widget, the button color, and a size specified by a numerical value. When the settings are made and an operation is performed to reflect them, the specified UI widget is displayed on the canvas 530 in a display form that reflects the settings.

[0127] In S714, the developer terminal 100 determines whether or not an action (property 542 in FIG. 5(d)) is selected from among the options included in the context menu. If an action is selected, the process proceeds to S715, and if not, the process proceeds to S716.

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

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

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

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

[0132] In S720, the developer terminal 100 determines whether or not an operation to close the context menu has been performed (for example, an operation of clicking outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden and the process of Fig. 7 ends. If no operation to close the context menu has been performed, the process returns to S712.

[0133] On the other hand, in S721, the developer terminal 100 displays a context menu for a 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 widget. The context menu for the template screen (template component 2634 in Fig. 26(d)) differs from the context menu for a normal UI screen (context menu 540 shown in Fig. 5(d)) in that it does not display options such as Action or Delete, but only Properties. In other words, for UI widgets placed on the template screen among UI screens, the developer is not allowed to set the action to be taken when the UI widget is operated. The reason for this will be explained later.

[0134] In S722, the developer terminal 100 determines whether or not the property has been selected from among the options included in the context menu. If the property has been selected, the process proceeds to S723, and if not, the process proceeds to S724. The process of S723 is the same as that of S713.

[0135] In S724, the developer terminal 100 determines whether or not an operation to close the context menu has been performed (for example, an operation of clicking outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden and the processing of Fig. 7 ends. If no operation to close the context menu has been performed, the process returns to S722.

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

[0137] FIG. 9B is an example of the display of an action board related to a UI widget 901. The action board 910 is displayed in place of the canvas in the area where the canvas 900 was displayed. If the designated UI widget is not a template widget (template component) arranged in advance on the template screen, and if the developer has not set an action for the designated UI widget in the past, 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 designated UI widget. 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 designated UI widget is a button, the trigger is the pressing of the button in the constructed application, and the action set on the action board of the button is executed in response to the occurrence of the trigger.

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

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

[0140] FIG. 9(d) is a display 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 for receiving various settings required to create a function (REST function) using REST (REpresentational State Transfer) is displayed. In addition, in the function list 920, a function 923 with the function name "rest01" input in the function name input field 932 is displayed as a function option. Note that the icon displayed in front of "rest01" indicates that the type of the function 923 is a REST function. If all the required setting items are not set on the function setting screen (if information to be set is insufficient), an incomplete mark 929 indicating that the function is incomplete is displayed, and the corresponding function 923 is displayed in an identifiable incomplete state.

[0141] The REST function setting screen 940 in FIG. 9(d) displays setting fields 941 to 944. The setting field 941 is a setting screen for setting the function name, and in the initial state, the function name entered in the function name input field 932 is displayed, but can be changed according to an input operation by the developer. The setting field 942 is a setting field for setting a 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 a character string of the source code in a programming language.

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

[0143] FIG. 10(a) is a display example of an SQL function setting screen that is displayed when SQL is selected in the type selection field 931. Instead of the action board 910, an SQL function setting screen 950 is displayed for accepting various settings required to create a function (SQL function) using SQL (Structured Query Language). In addition, in the function list 920, a function 924 with a function name "sql01" input in the function name input field 932 is displayed together with an incomplete mark 929 as a function option. Note that an 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 setting the function name, and in the initial state, the function name input in the function name input field 932 is displayed, but it can be changed according to an input operation by the developer. The setting field 952 is a setting field for setting a variable name for setting arguments. In this embodiment, param is set by default and cannot be changed. It is displayed in gray to indicate that it cannot be changed. The setting field 953 is an input field for inputting a character string (SQL sentence, SQL statement) for issuing an instruction to a database in SQL (a database language, not a programming language), which is a type of computer language. A developer can input any SQL STATEMENT into the setting field 953 using a keyboard or the like included in the operation unit 106. In this way, when creating an SQL function on the SQL function setting screen 950, the developer does not need to write a character string of source code in a programming language.

[0144] FIG. 10B shows an example of a display at the stage where the developer has created functions 923 to 925, input (describe) a certain amount of 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 function name that matches the character string as an input candidate option. In the illustrated example, the input "sq" matches the function name "sql01" of the 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 "l01". This code assist function allows a developer (user) to input the function name (identification information) of a 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. If the function name matches the beginning of the function name of a created function that has already been created, 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 has already created after confirming that it is correct, and can prevent inputting a mistake in the function name. 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. Furthermore, the function names of the created functions displayed in the code assist field 911 are functions created for the specified UI widget (UI widget 901 in the illustrated example) that is the target of the action board 910, and created functions created for other UI widgets are not displayed. Therefore, it is possible to prevent a mistake of writing a function name of a created function created for another UI widget, which does not exist as a created function for the specified UI widget, in the action board 910.

[0145] As shown in FIG. 10C, the function list 920 displays the type of function (icon before the character string) and the name of the function for 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 can reduce the effort of checking and managing valid created functions that can be written in the action board 910 (e.g., the effort of making a note of it at hand, opening another screen to check, etc.). This also contributes to preventing input errors in function names. The functions displayed in the function list 920 are functions created for the specified UI widget (UI widget 901 in the illustrated example) that is the target of the action board 910, and created functions created for other UI widgets are not displayed. Therefore, it can prevent the mistake of writing in the action board 910 the function name of a created function created for another UI widget but not existing as a created function for the specified UI widget. In addition, the creation function is effective only when the action of the specified UI widget is defined, and does not affect the definition of the action of other UI widgets. Therefore, if the function name of the creation function created for the specified UI widget is the same as the creation function created for other UI widgets, even if the function name is described in the action board 910, only the function setting set for the specified UI widget is reflected, and the function setting set for the other UI widget is not reflected. Therefore, even if the same function name as the function name of the creation function already created for the other UI widget is used, an error does not occur. Therefore, the user can decide the function name of the creation function and input it to the action board 910 without worrying about the duplication of the function name with the creation function already created for the other UI widget. That is, although a large number of creation functions are created in the entire development of an application, they are automatically managed and organized in association with the specified UI widget and displayed in the code assist field 911 and the function list 920, so that it is very easy for the developer to manage a large number of creation functions. Therefore, the effort and time required for checking the function name can be reduced.It also reduces input errors in function names. This reduces the amount of debugging work (debug removal work) required when a function name is input incorrectly. This reduces the workload and man-hours required for software (application) development, allowing for more efficient software (application) development.

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

[0147] FIG. 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 FIG. 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 FIG. 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 character string of the amount (7 lines) shown in the action board 910 in FIG. 10(d), the contents of the source code shown in FIG. 11 can be defined. In other words, efficient development can be performed with low code.

[0148] Fig. 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 Fig. 7, and is a process for controlling the operation to be performed as explained using the display examples in Figs. 9(b)-(d) and 10(a)-(d).

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

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

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

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

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

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

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

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

[0157] In S811, the developer terminal 100 displays the addition dialog 930 for adding a created function, and accepts input to the addition dialog 930. The contents of the input accepted in the addition dialog are as described above with reference to Fig. 9(c). When the input is made to the addition dialog and the SAVE button 933 is pressed, the process proceeds to S812.

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

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

[0160] In S815, the developer terminal 100 determines whether or not 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., the type selected in the type selection field 931 of the addition dialog is REST), the process proceeds to S817. In S816, the developer terminal 100 displays an SQL function setting screen and accepts setting operations from the developer user. The setting contents accepted on the SQL function setting screen are as described above with reference to FIG. 10(a).

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

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

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

[0164] In S820, the developer terminal 100 determines whether or not any of the created functions displayed in the function list 920 has been selected (pressed). If a created function has been selected in the function list 920, the process proceeds to S813, and in S814, S816, or S817, a setting screen according to the type of the selected created function 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 created function).

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

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

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

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

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

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

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

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

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

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

[0175] In S1207, the developer terminal 100 displays an application setting screen. The application setting screen is a screen that accepts a setting operation related to a selected application. In S1208, the developer terminal 100 accepts a 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 a screen that is displayed first when an already-built application deployed in the execution environment is accessed, or a screen that is displayed first after authentication is OK on the authentication screen of the application after accessing the already-built application.

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

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

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

[0179] In S1212, the developer terminal 100 acquires database information acquired by the development environment 300 from the 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. Then, the development environment 300 transmits the database information acquired from the selected execution environment to the developer terminal 100. The developer terminal 100 does not access the single-tenant execution environment without going through the development environment 300.

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

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

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

[0183] In S1216, the developer terminal 100 displays a file management screen for managing files to be saved in the selected execution environment, and in S1217, accepts an operation for managing 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 be authenticated before logging in to the development environment 300. Therefore, by restricting access to various execution environments except via the development environment 300, other users who cannot log in to the development environment 300 cannot illegally access the execution environment, thereby improving security.

[0184] Furthermore, 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 makes it possible to prevent an increase in the number of operations.

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

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

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

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

[0189] <User information display process> FIG. 14(a) shows a specific example of developer information 301 held in the development environment 300. In the developer information 301, the following information is recorded in association with each developer as account information for each developer, as shown in each row in the figure. An email address (username) 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 or not the account is valid. Note that information recorded in association with one account may be other than the information shown in FIG. 14(a).

[0190] FIG. 14(b) shows a specific example of user information 411 held in the multi-tenant execution environment 410. In the user information 411, the following information is recorded in association with each application user as account information for each application user, as shown in each row in the figure. The account information for each application user includes an email address (user name) that serves as the application 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 in a mixed manner. Therefore, in order to identify which developer (owner) each user of an application is a user of the application created by, a developer ID is also recorded as an owner ID. Note that information recorded in association with one account may be other than the information shown in FIG. 14(b). For example, a creation date and time, an update date and time, etc. may be recorded.

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

[0192] In the user-specific information shown in FIG. 14(c1), the following information is recorded in association with each application user as account information for each application user, as shown in each row in the figure. The account information for each application user includes an email address (user name) that serves as the application user's account ID, a password, a last name, a first name, and information on whether the email 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.

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

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

[0195] At S130, the developer terminal 100 transmits an instruction to obtain user information for the development environment 300 (information giving an instruction to obtain user information for the selected execution environment).

[0196] In S1302, the developer terminal 100 determines whether or not it has received user information sent from the development environment 300 in response to the user information acquisition instruction sent in S1301. If user information has not been received, it waits for reception of user information in S1302, and if user information has been received, it proceeds to S1303. The user information acquired 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.

[0197] In S1303, the developer terminal 100 displays the 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, when the selected execution environment is a multi-tenant execution environment, the display items 1501 and 1502 are not displayed, and it is not possible to switch to displaying the group information. Group information 1505 is an example of user information displayed based on the user information received in S1302 (in the illustrated example, the per-user information shown in FIG. 14(c1). In group information 1505, the Username and Email Verified columns correspond to the information in the email address (username) and email verified columns in the per-user information shown in FIG. 14(c1), respectively. In the Delete column, a button icon is displayed in each row to receive an instruction to delete the user account of that row. Add user button 1503 is an operation icon 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.

[0198] 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 contents of editable items can be edited by operating the keyboard.

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

[0200] In S1306, the developer terminal 100 transmits to the development environment 300 an instruction to update the user information to reflect the editing operation accepted in S1304.

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

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

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

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

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

[0206] In S1312, the development environment 300 acquires access destination information (connection destination information) from the selected execution environment. The access destination information acquired here is the access destination information 421 if the selected execution environment is the multi-tenant execution environment 410 in FIG. 1, and is the access destination information of the selected execution environment among the access destination information 456b, 466b, 476b, etc. if the selected execution environment is the single-tenant execution environment in FIG. 1. 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 or 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 in 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. Therefore, it is possible to prevent a person who cannot log in to the development environment 300 or a person who can log in to the development environment 300 but has a different accessible execution environment from illegally accessing the execution environment and leaking user information.That is, security is improved.

[0207] In S1313, the development environment 300 transmits a user information acquisition request (a request to execute a process to send user information to the development environment 300) and developer information to the access destination indicated 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 the 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 converted into a single data string. Even if only this encrypted information is leaked, the email address, password, last name, first name, and accessible execution environment ID will not be leaked because it is encrypted.

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

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

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

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

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

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

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

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

[0216] In S1322, the execution environment 400 performs an access right confirmation process. This process is for determining whether the source of the user information acquisition request is a developer with legitimate access rights, and this process reduces the possibility of user information leaking 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).

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

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

[0219] 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 owner of the environment itself is a single developer, so the user information is only for applications owned by a single developer. Therefore, unlike the processing in a multi-tenant execution environment in S1326 described later, the entire user information is transmitted, rather than transmitting 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 in S1314, and transmitted to the developer terminal 100 in S1315.

[0220] 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 in the multitenant execution environment 410 shown in FIG. 14(b), information on 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 in the multitenant execution environment 410, information on 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, user information owned by multiple developers is recorded in a mixed manner, so 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 is sent to the developer terminal 100 in S1315.

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

[0222] In S1328, the execution environment 400 performs an access right confirmation process. This process is for determining whether the source of the user information update request is a developer with valid 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 valid access rights, improving security. The access right confirmation process will be described later with reference to FIG. 13(d).

[0223] In S1329, the execution environment 400 judges whether the result of the access right confirmation process is an error or not. If there is an error, the process proceeds to S1321 without updating according to the user information update request. If there is no error, the process proceeds to S1330.

[0224] In S1330, execution environment 400 updates the user information stored in its own environment in response to 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.

[0225] Fig. 13D shows a flowchart of the access right confirmation process, which is a detailed flowchart of S1322 and S1328 in Fig. 13C described above.

[0226] In S1341, the execution environment 400 determines whether or not encrypted developer information has been received from the development environment 300. The developer information received here is 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, and if not, the process proceeds to S1342.

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

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

[0229] In S1344, the execution environment 400 determines whether or not the execution environment ID of its own execution environment (the execution environment in question) is included in the portion of the developer information decoded in S1342 that indicates the accessible execution environment. If it is included, the process ends (in this case the access is deemed to be valid), and if it is not included, the process proceeds to S1342, where an error is recorded (output) as a result of the access right confirmation process. This prevents the execution environment from performing a process 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, it is possible to suppress processing in response to unauthorized access.

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

[0231] According to the user information display process described above, unauthorized processing due to unauthorized access to the execution environment 400 can be prevented, the risk of information leakage can be reduced, and security can be improved. Note that, in the above-mentioned user information display process, processing related to user information held in the execution environment has been described, but the same can be applied to other processing related to the execution environment other than processing related to user information. For example, security can be improved by applying a similar process when processing databases and files held in the execution environment 400.

[0232] For example, this is applicable to the processing relating to displaying and updating a database described in S1210 to S1214 of Fig. 12. In this case, in response to a DB operation instruction from the developer terminal 100, the development environment 300 acquires an access destination information file from the selected execution environment in the same manner as in S1312 in response to a DB operation instruction from the developer terminal 100. Since the access destination information file records a DB operation request reception URL that is the request destination for receiving a DB operation request, the execution environment 400 transmits the DB operation 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 DB operation request is legitimate, in the same manner as in the processing described in Figs. 13(c) and 13(d), and only if the sender is legitimate, performs processing relating to the DB set held in its own execution environment in response to the DB operation request.

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

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

[0235] In S1601, the developer terminal 100 displays a workflow (WF) creation screen on the display 105. FIG. 17(a) shows an example of the display 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 a starting point, an end 1712, which is an end point, and a status 1713, which is an 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.

[0236] In S1602, the developer terminal 100 determines whether or not an operation to place a node has been performed. Specifically, it determines whether or not 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, and if not, the process proceeds to S1604.

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

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

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

[0240] FIG. 17(b) shows an example of a display after nodes and arrows are placed in the WF placement area 1700. Nodes 1701 to 1705 are placed in the WF placement area 1700. Node 1701 is a start node. Nodes 1702, 1703, and 1704 are intermediate (status) nodes. Node 1705 is an 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 procedures, respectively.

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

[0242] In S1607, the developer terminal 100 displays a property box for setting properties for the node, and accepts a setting operation for the node properties. Fig. 17(c) shows an example of the display of a node property box. The node property box accepts settings for the node ID (an initial value that does not overlap with other nodes is set, and this 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.

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

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

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

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

[0247] In S1612, the developer terminal 100 displays the selection reception form (dialog box) shown in Fig. 17(f) as a wizard, and receives the selection of whether to add a 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 the IDs of the UI screens is displayed as options, and the user can select from the options.

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

[0249] In S1614, the developer terminal 100 creates a workflow definition based on the nodes and arrows already placed in the WF placement area 1700, their properties, and the contents set by selecting from the options in S1611 to S1614, and records the workflow definition in the definition information of the memory 102. As a result, a UI widget (UI component) based on the workflow is automatically placed on the UI screen. The automatically placed UI widget is one in which an action corresponding to the workflow is automatically set. In this way, a UI widget with an action automatically defined based on the workflow generated by the operation of selecting options is generated 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.

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

[0251] Fig. 18(a) shows an example of a display when database button 516 in the main menu area is pressed to display the database tables added in S1614 in Fig. 16. That is, Fig. 18(a) is one of the screens related to the database displayed in S1214 in Fig. 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 a workflow. They have been added (generated) as tables included (subordinate, in a lower hierarchical hierarchy) in the database whose designation was accepted in S1613.

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

[0253] FIG. 18(c) shows a display example in the case where an action board is displayed with a UI widget 1813, which is a button, as the designated UI widget. That is, this action board is displayed in S801 described above in FIG. 8 when the designated UI widget is the UI widget 1813. In the action board 910, a character string of an action as shown in FIG. 18(c) is displayed in a state in which the developer has not written an action in a programming language as an initial value. In other words, in the action board 910, a source code in a programming language that defines an action as shown in FIG. 18(c) is displayed as an initial value in a state in which the developer has not written a source code in a programming language for the action. In the action displayed in the action board 910 in FIG. 18(c), at least a database (line 3) and a UI screen to be displayed next (line 6) are defined based on the group of operations received from the user in the workflow creation process in FIG. 16. The user can edit the action that is automatically defined in this way by the processes in S802 to S808 described above. That is, a programming language can be input so that the character string of an automatically defined action is used as a base, and some of it can be reused and some modifications or additional character strings can be made. That is, modifications to the character string of an automatically defined action can be accepted. In this way, by using the programming language of an automatically generated and displayed action as a base, an action can be easily set with fewer steps (amount of text input) than if a developer were to write an action in a programming language from scratch. Also, because an automatically generated action can be customized by making modifications rather than using it as is, it is possible to generate actions that meet more detailed requests.

[0254] FIG. 18(d) shows a display example of an action board 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 FIG. 19, which will be described later. The action board displays a character string of an action as shown in FIG. 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 FIG. 18(d) as an 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 S1904, which will be described later. That is, similar to the action automatically set in the UI widget described in FIG. 18(c), it is possible to easily set an action with a small number of operations (amount of text input), and it is possible to generate an action that meets more detailed requests.

[0255] For example, the following customizations can be added to the UI widgets 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. Place an input field (UI widget) for the reason for application, and modify the action board of UI widget 1813 so that the data entered there is sent to the next step. Modify the action board of part 1813 to save data in a different table. For example, customize it so that the reason for application and case ID are also recorded in a separate database. · On the campus action board, set the user who initially inputs to the UI component 1812 (combobox) to the person who applied last time by writing an action up to the programming limit. Alternatively, write an action to display selectable approvable persons as options.

[0256] Thus, according to this embodiment, the basic part of the workflow can be quickly created with simple operations according to the operations on the workflow creation screen and the input content to the wizard (that is, based on a group of operations including operations of selecting from options and not including operations of writing source code in a programming language). In addition, by presenting the actions set on the automatically created UI components and the canvas of the UI screen so that they can be modified in a programming language, a more flexible design becomes possible.

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

[0258] In this embodiment, as an example for explaining the generation of CRUD, a case will be described in which a canvas of a selected UI screen as shown in FIG. 20(a) is displayed before the generation of CRUD (before the placement of a CRUD button), 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 of FIG. 20(a) displays UI widgets 2001 to 2003 arranged by a developer in UI editor processing. All of the UI widgets 2001 to 2003 are UI widgets of type Input. The UI widget 2001 displays "ID" as a label, the UI widget 2002 displays "Name" as an initial value, and the UI widget 2003 displays "age" as a label. That is, the canvas of FIG. 20(a) is a canvas of a UI screen designed assuming a screen for some kind of user registration. UI widget 2001 is an input field for inputting the ID of the user to be newly registered, UI widget 2002 is an input field for inputting the name of the user to be newly registered, and UI widget 2003 is an input field for inputting the age of the user to be newly registered. The UI widget IDs of UI widgets 2001 to 2003 are "number_field_ID", "text_field_Name", and "number_field_age", respectively.

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

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

[0261] In S1903, the developer terminal 100 displays the canvas action board based on the definition information stored in the memory 102. An example of the display of the canvas action board is shown in FIG. 18(d) 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.

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

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

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

[0265] In S1907, the developer terminal 100 displays CRUD input form 1 (a dialog box) as a wizard and accepts an operation to select a UI widget for which data is to be acquired in CRUD. FIG. 20(c) shows an example of the display of CRUD input form 1. In area 2021, the UI widget IDs of all UI widgets 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.

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

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

[0268] In S1910, the developer terminal 100 determines whether a selection operation has been performed in the 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, and if not, the process waits in S1910 for the NEXT icon 2033 to be pressed.

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

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

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

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

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

[0274] In S1916, the developer terminal 100 determines whether or not an operation to close the context menu of the canvas has been performed (for example, an operation of clicking outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden in S1917, and the processing of Fig. 19 ends. If no operation to close has been performed, the process returns to S1902.

[0275] FIG. 20(f) shows a display example of a CRUD button (automatically generated component) automatically arranged by the processing of S1913. FIG. 20(f) is a display example of a canvas of the same UI screen as FIG. 20(a), and the same UI components as FIG. 20(a) are given the same reference numerals. In FIG. 20(f), UI components 2051 to 2053 are added to FIG. 20(a). These UI components 2051 to 2053 are CRUD buttons. Actions are automatically set to the UI components 2051 to 2053 that are CRUD buttons. The action of the UI component 2051 that is a CRUD button is to perform a process of saving (updating or adding) a value input to the UI component selected in input form 1 in a database table set in input form 3 in response to pressing of the UI component 2051, and then to perform a process of transitioning to the Next UI screen. The action of UI widget 2052, which is a CRUD button, is to delete data having the value entered in the UI widget selected in input form 1 from the table of the database set in input form 3 in response to pressing of UI widget 2052, and then to transition the screen to NextUI. The action of UI widget 2053, which is a CRUD button, is to retrieve data that matches the value entered in the UI widget selected in input form 1 from the table of the database selected in input form 3 in response to pressing of UI widget 2052, and to transition the screen to NextUI and display the retrieved data.

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

[0277] In addition, the automatically generated data grid 2061 can 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". In addition, for example, it is possible to modify so that some columns are not displayed. After the application is deployed and operation is started, there may be cases where it is desired to increase or decrease columns due to some circumstances (such as changes in laws and regulations or operation methods). For example, there may be a case in the future where it is desired to change the data grid 2061 so that the "number_field_age" column is not displayed. In this case, the column can be deleted simply by deleting it from the column properties in the UI editor. Therefore, it is not necessary 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 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.

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

[0279] FIG. 21(b) shows a display example when an action board of UI widget 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 designated UI widget is UI widget 2051. In the action board 910, a character string of an action as shown in FIG. 21(b) is displayed in a programming language (JavaScript) as an initial value when the developer has not written the action in a programming language. In other words, in the action board 910, a source code in a programming language that defines the action as shown in FIG. 21(b) is displayed as an initial value when the developer has not written source code in a programming language for the action. The user can edit such an automatically defined action by the processes of S802 to S808 described above. That is, the user can input a programming language so as to partially reuse the character string of the automatically defined action as a base, and partially modify or add a character string. That is, a modification operation to the character string of the automatically defined action can be accepted. In this way, by using the programming language of the automatically generated and displayed action as a base, it is possible to set up actions easily with fewer steps (amount of text input) than if a developer were to write the action in a programming language from scratch.In addition, because the automatically generated actions can be customized by adding modifications rather than using them as is, it is possible to generate actions that meet more detailed requests.

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

[0281] FIG. 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. The function 2121 is an SQL function, and an SQL function setting screen is displayed. The SQL function setting screen has the same configuration as that described above in FIG. 10(a), so in FIG. 21(c), the same setting / input fields as those in FIG. 10(a) are given 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 contents entered in input form 3. In addition, the subsequent character strings indicate the values ​​of columns included in the row to be added, and reflect the contents entered in input form 1. The contents of the setting fields 951, 953 can be edited (modified, deleted, added, customized) by the developer through the processes of S813 to S820 in FIG. 8 described above, based on what has been automatically generated.

[0282] FIG. 21(d) shows an example of a display when a function 2122 is selected from the function list 920 and a function setting screen is displayed. The function 2122 is an SQL function, and an SQL function setting screen is displayed. The SQL function setting screen has the same configuration as that described above in FIG. 10(a), so in FIG. 21(d), the same setting / input fields as those in FIG. 10(a) are given 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 this 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 contents entered in input form 3. In addition, the subsequent character strings indicate the values ​​of the columns to be updated, and reflect the contents entered in input form 1. The contents of the setting fields 951, 953 can be edited (modified, deleted, added, customized) by the developer through the processes of S813 to S820 in FIG. 8 described above, based on what has been automatically generated.

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

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

[0285] In this way, customizing an automatically generated action can greatly reduce the number of steps required by a developer, rather than creating the desired CRUD button action from a state where no action description is made in a programming language. In addition, since it can be freely customized, there is a high degree of freedom in the content of the actions that can be created. According to this embodiment, the developer (user) can more flexibly modify and use the defined actions (actions defined based on the group of operations to be input into input forms 1 to 3) without having to write the action in a programming language.

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

[0287] In S2201, the developer terminal 100 displays on the display 105 input fields for accepting 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.

[0288] In S2202, the developer terminal 100 transmits to the development environment 300 the account information input in S2201 and a registration request that is a request to newly register the account information.

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

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

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

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

[0293] In S2207, the developer terminal 100 determines whether or not there has been a resend instruction operation from the developer (user). If there has been a resend instruction operation, the process proceeds to S2208. If there has been no resend instruction operation, the developer terminal 100 waits until there is a resend instruction operation.

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

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

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

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

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

[0299] In S2222, the development environment 300 adds a row to 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 developer information 301 are as shown in FIG. 14(a). One row of developer information 301 is the account information for one person, and information in each column recorded in the same row is recorded in association with each other as account information for the same developer.

[0300] In S2223, the development environment 300 instructs an external one-time password issuing system (not shown) to issue and send a one-time password to the email address included in the account information received in S2221. As a result, the one-time password is sent from the external one-time password issuing system to the developer's email address. Note that, 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.

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

[0302] In S2225, the development environment 300 transmits the one-time password received in S2225 to the external one-time password issuing system, and transmits an instruction to check whether it matches the issued one-time password, i.e., to instruct the system to verify the one-time password.

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

[0304] In S2227, the development environment 300 determines whether or not a resend request for 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 resend request for the one-time password has been received, the process proceeds to S2223, and if not, the process waits at S2227.

[0305] In S2228, the development environment 300 activates the account added to the developer information 301 in S2222. Specifically, among the account information added to the developer information 301 in S2222, the value of the column "Verify" is changed to "confirmed." Account information with the value of the column "Verify" 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 regarded as a registered valid account. Note that, although authentication is performed using an email address in this embodiment, if other contact information for the developer, such as a phone number or an SNS account, is registered as account information, authentication may be performed using the other contact information.

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

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

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

[0309] In S2232, the development environment 300 determines whether the number of valid accounts registered in the developer information 301 (the number of accounts 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.

[0310] In S2233, the development environment 300 determines whether 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 has been updated to the DB instance name of the new DB instance added in S2231. If it has been updated, proceed to S2236, and if not, proceed to S2234.

[0311] 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. On the other hand, if the number of accounts exceeds the threshold 1 by the process of S2233, accounts registered thereafter are set to connect to a new DB instance (database environment) different from the previous one, so that it is possible to reduce the possibility that the number of developers using one DB instance becomes excessive and access is concentrated. Therefore, it is possible to reduce the possibility that performance is decreased, such as a decrease in response regarding access to the database.

[0312] 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 becomes 20,000 and threshold 2 becomes 19,000. That is, each time the number of developer devices increases by 10,000 (each time the number of valid accounts increases by the number of threshold 1), the processing of S2231 and the processing of S2234 are performed.

[0313] In S2236, the development environment 300 assigns the DB instance name held in memory 304 as the connection destination DB instance of the account information added in S2222 (the currently added account). More specifically, the DB instance name held in memory 304 as the connection destination DB instance is recorded in the column indicating the connection 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 the threshold 1 is the developer terminal 10000 and the currently added account is the 9999th valid account, "DB instance name 1" is recorded. If the currently added account is the first valid account in the developer terminal 1000, "DB instance name 2" is recorded.

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

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

[0316] FIG. 23(a) shows details of the DB set 430 in the multitenant execution environment 410. In the DB set 430, a fixed number of DB environments (DB instances), which may be one or more, are initially prepared. In this embodiment, the fixed number is 1, that is, only DB instance 1 (2310) is initially prepared. The DB instance 1 includes a developer information DB 2311 and DBs for each developer. The developer information DB 2311 indicates which database is prepared for each developer (each account). For example, the DB information 2312 of developer A is information indicating the correspondence that the DB for developer A is DB1. The DBs for each developer include DB1 (2314), DB2 (2315), DB3 (2316), etc., and the number increases every time a valid account is registered in the developer information 301. However, the upper limit is the same as threshold 1, and if threshold 1 is 10,000 developer devices, then DBmax (2317) is the DB for the 10,000th developer device, and subsequent DBs are created in different DB instances. The DB for each inventor 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.

[0317] The process of S2231 generates the next DB instance 2 before the number of DBs in DB instance 1 reaches the upper limit (threshold 1). Then, when DBmax (2317) has been generated in DB instance 1, if a valid developer account is further registered in developer information 301, the result in S2232 becomes Yes, and the newly registered developer is registered in developer information 301 so as to connect to DB instance 2 (2320). Then, DBs for accounts (developers) added thereafter are generated 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.

[0318] FIG. 23(b) 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), the DB set 457 is also dedicated to one account (one developer). Therefore, the possibility of an increase in DBs to the extent that response is reduced or concentration of accesses occurring is low. Therefore, only one DB instance 1 (2350) is prepared as a DB environment in the DB set 457. Also, in the developer information DB 2351, only information of one account statement (for example, DB information 2352 of developer A) is recorded. No upper limit threshold is prepared for the number of DBs to be stored. Also, as described in FIG. 22(b), 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.

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

[0320] Fig. 25(a) shows an example of the UI editor screen when the selected application is a mobile application. A canvas 2501 is a canvas for a mobile device, and is shaped like a smartphone. When the deploy button 506 is pressed, the process in Fig. 24(a) starts.

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

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

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

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

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

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

[0327] In S2407, the developer terminal 100 displays a screen accessed by the URL (URL for accessing the execution environment) of the deployed application included in the success notification in a new tab of the browser software different from the screen (for example, 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, an authentication screen or initial UI of the deployed application is displayed in the new tab, and the display contents and operations of the actual application that has been deployed (built in the execution environment) can be immediately confirmed and verified by operating the new tab. The process of S2407 performs the execution process of the application by accessing the URL (URL for accessing the execution environment) of the deployed application. Details of the execution process of the application will be described with reference to the flowchart of FIG. 33(c) or FIG. 35(c).

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

[0329] In S2409, the developer terminal 100 displays the QR code generated in S2409. Since the QR code is displayed in response to the completion (success) of the deployment, the developer can recognize the timing when the deployment is successful. FIG. 25(b) shows an example of the display of the QR code in S2409. FIG. 25(b) shows an example of the display of the screen to which the transition is made when the deploy button 506 is pressed from the state of FIG. 25(a) to issue a deployment instruction and the deployment is successful. A QR code dialog 2510 is displayed superimposed on the mobile canvas. The QR code dialog 2510 displays the QR code 2511 generated in S2408, a close button 2512, and an open in new tab button 2513. Note that the URL of the application, which is information contained in the QR code 2511, is a different URL from the 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 the deployment is completed, and is an address for executing the deployed application, and is access destination information indicating the location (execution environment) where the application has been deployed.

[0330] The developer (user) can display a screen for accessing the URL (URL for accessing the execution environment) of the deployed application on the handheld smartphone by photographing and reading the QR code 2511 displayed on the display 105 of the developer terminal 100 with a handheld smartphone (mobile terminal). Therefore, the deployed URL can be easily accessed with few operations. In this case, the handheld smartphone functions as the application user terminal 201. As a result, the authentication screen or initial UI of the deployed application is displayed on the handheld smartphone, 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 handheld smartphone. Since the operation of the mobile application can be confirmed and verified on the mobile terminal instead of the developer terminal 100, it is easier to confirm whether it is suitable as a mobile application than by confirming and verifying 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), or the like may be used. Also, the URL of the application included in the success notification may be displayed as a character string in the QR code dialog 2510.

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

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

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

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

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

[0336] In S2423, the development environment 300 stores the definition information of the selected application 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 application 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.

[0337] In S2424, the development environment 300 stores the definition information of the selected application 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 transmits the definition information of the selected application acquired in S2421 to the single-tenant execution environment, which is the currently selected execution environment, and instructs the multi-tenant execution environment 410 to record the definition information in a folder directly under the bucket. If this recording is completed without any problems, the deployment is successful.

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

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

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

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

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

[0343] FIG. 26(a) shows an example of a display of template screen options when a list of UI screens is displayed as options in submenu area 520. This display is performed by the process of S401 in FIG. 4 described above. FIG. 26(a) shows an example of an expanded display of a list of options of UI screens classified into a group of AuthenticationUI (UI screen for authentication, screen for authentication) among UI screens classified into a plurality of types. Group name 2610 indicates that the group being expanded and displayed is AuthenticationUI. When group name 2610 is pressed, the expansion of the AuthenticationUI option is collapsed, and the group names of the other groups are displayed in submenu area 520. Options 2611 to 2622 are each an option of one UI screen, and all of them are prepared in advance as template screens.

[0344] 26(b) shows a display example when option 2611 is selected and "Sign in ID", which is the template screen (UI screen) corresponding to option 2611, is displayed on canvas 2630. The screen of FIG. 26(b) is displayed in S404 of FIG. 4 described above in response to selection of option 2611 being pressed. 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 widget list in submenu area 520, but are template UI widgets whose display positions (placement), colors, sizes, and display contents are defined in advance. Template components 2631 to 2634 are UI widgets as follows: Template part 2631: UI part for displaying "Sign In" in the Output Field. Template part 2632: A TextField of the Input type, which is a UI part for receiving input of an email address that is the user name (user ID) of the application. In other words, this is a UI part for receiving input of user-specific information. Template component 2633: A button UI component, which is set (labeled) to display "CREATE ACCOUNT?" When pressed, an action is set in advance (predefined) to transition to a "Sign Up form" screen (a UI screen corresponding to option 2614 on the screen shown in FIG. 27(c)), which is a type of template screen. Template 2634: A button UI component that is set (labeled) to display "NEXT." When pressed, a value (email address) entered in template 2632 is acquired, and a transition to a "Sign in Password" screen (a UI screen corresponding to option 2612 on the screen shown in FIG. 27(a)) is performed, which is a type of template screen. This action is predefined.

[0345] Fig. 27(a) shows an example of how the "Sign in Password" screen is displayed on the canvas. Note that Fig. 27(a) to Fig. 27(k) are each partial display examples that show only a portion of the canvas when a template screen is displayed on the canvas. Template components 2711 to 2715 placed on the "Sign in Password" screen are UI components such as the following: Template component 2711: A TextField of type Input, this is a UI component for accepting input of the app's user password. Template component 2712: A button UI component that is set to display "Forget Password?" When pressed, an action is set in advance (defined in advance) 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 2713: A checkbox displays "Trust this device for 14 days." Template part 2714: A button that displays "CHANGE EMAIL," and when pressed, has a predefined action of returning to the "Sign in ID" screen. Template 2715: A button that displays "SIGN IN." When pressed, a predefined action is performed to send the value entered in template 2632 (email address), the value entered in template 2711 (password), and whether the check box of template 2713 is checked, to the execution environment in which the application is built.

[0346] In an actually constructed application, in response to pressing a button corresponding to template component 2715 displayed on application user terminal 201, an email address serving as a username, a password, and whether or not a check is selected are sent from application user terminal 201 to the execution environment. 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 of the multi-tenant execution environment (shown in FIG. 14(b)) or per-user information of the single-tenant execution environment (shown in FIG. 14(c1)). If the result of the comparison is that authentication is OK, the user is logged into the application, and an initial UI is displayed on application user terminal 201.

[0347] Similarly, the following are examples of template screens displayed on the canvas. Both are screens related to user authentication for the app. 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. FIG. 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.

[0348] Each of the above-mentioned template screens can be customized, and as described in the process from S405 onward in FIG. 4, developers can edit them with a UI editor. 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 template part properties (changing the display form such as the displayed text 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 not possible to change or delete the action of a template part, and it is not possible to erase the template part. In addition, it is not possible to change or delete the action of a normal UI part (UI part that is not a template part) added to the template screen. In this way, it is possible to prevent an unintended error caused by a 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 mistakes are predefined in the template parts and cannot be modified, so that even if a developer customizes the template screen, the authentication processing using a cloud service will work properly without fail. The reason why actions cannot be set for normal UI widgets added to template screens 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 Figure 26(b) and an action that transitions to a UI screen unrelated to authentication is set for that button, the email address and password required for authentication cannot be sent to the runtime environment, and authentication will not work. If authentication is not successful, the UI screen to transition to 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 widgets added to template screens.

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

[0350] Fig. 26(d) shows an example of a display in which a context menu 2635 of a button 2634 arranged on the canvas of the template screen is displayed. In this way, the options of action and deletion are not displayed in the context menu of a template component arranged on the template screen. This controls the template component so that it cannot be set as an action or deleted. In other words, the action board is not displayed either. Therefore, as explained in S721 to S724 of Fig. 7, only the properties of the template component can be edited (the display form can be changed).

[0351] FIG. 26(e) shows a display example after editing (customization) is added to the canvas of the template screen shown in FIG. 26(b). The same UI widgets in FIG. 26(b) and FIG. 26(e) are given the same reference numerals. UI widget 2641 is an output type UI widget added by the developer, and is displayed by specifying an image file uploaded by the file management operation in S1217 of FIG. 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 widget 2642 is a text message type UI widget added by the developer. In addition, the developer opens the action board of the canvas and sets an action for obtaining today's date and displaying a character string "This is the closing date at the end of the month, so don't forget to apply" on UI widget 2642 as the action of the canvas of this screen. In this way, it is also possible to arrange a UI widget (component) whose display content changes depending on the conditions when this authentication screen is displayed. Template part 2631 is the same UI part (UI part with the same ID) as template part 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 the screen in a more suitable way to match the nature of the app.

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

[0353] FIG. 28(a) shows an example of the display of the property box of a pie chart. FIG. 28 shows a screen displayed by right-clicking on pie chart 531, which is a UI widget arranged on canvas 530, in the display state shown in FIG. 5(b) and selecting "Property" from the context menu displayed. 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. A property box 2810 is the property box of pie chart 531. The property box 2810 is displayed together with pie chart 531 displayed on canvas 530. The display form of the pie chart, such as the ratio and color coding of the contents displayed in pie chart 531, is displayed based on the contents set in the property box 2810. When the setting contents are changed in property box 2801 and apply button 2811 is pressed, the display form of pie chart 531 is updated based on the latest setting value (changed setting value) of property box 2801. That is, the developer can perform the setting operation for property box 2810 while checking how the display form of pie chart 531 changes.

[0354] When a pie chart is placed on the canvas by dragging and dropping it from the UI widget list, if no values ​​are set, the regions for each ratio of the pie chart are not displayed, and it appears as just a circle. This means that developers cannot intuitively recognize that the placed UI widget is a pie chart when they look at it. To solve this, a predefined initial value (a default setting value that is 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 widget list, a pie chart with regions divided by ratio is displayed from the start, allowing developers to quickly and intuitively recognize that the placed UI widget is a pie chart.

[0355] Within the property box 2810, the Value input area 2812 is an area for inputting the ID, numerical value, color, and label (display string) of each section shown by the pie chart 531. If the developer has not set anything, the initial value 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 from start to finish by scrolling. The full text of the initial value displayed in the Value input area 2812 is as follows. Note that "" is assumed to be a double quotation mark.

[0356] [{″id″:″Jan″,″value″:Developer terminal 100.33,″color″:″#394E79″,″month″:″Jan″},{″id″:″Feb″,″value″:22.12,″color″:″#5E83BA″,″month″:″Feb″},{″id″:″Mar″,″value″:53.21 ,″color″:″#C2D2E9″,″month″:″Mar″},{″id″:″Apr″,″value″:34.25,″color″:″#9A8BA5″,″month″:″Apr″},{″id″:″May″,″value″:24.65,″color″:″#E3C5D5″,″month″:″May}] The initial value displayed in the value input area 2810 is displayed in a structure when written in a programming language. In the entire text of the initial value above, the part enclosed in "{" and "}" is one data set corresponding to one section in the pie chart. A pair of character strings, in which a character string enclosed in "" is 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 a separator between the previous key and the next key. That is, in the entire text of the initial value above, the part including multiple pairs of {"id":"Jan", "value": Developer's terminal 100.33, "color":"#394E79", "month":"Jan"} is one data set (one set), and includes four sets of key names and values: id, value, color, and month. It can be seen that there are a total of five similar data sets. In this way, the initial value of the pie chart is a set of setting values ​​including multiple data sets each including a default setting value group.

[0357] 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 a value from the keyboard. However, since the initial value is displayed in such a way that the structure can be seen as described 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 the character string displayed in a structure that can be written in a programming language means.

[0358] If the setting value of the pie chart is simply to be set, it is possible to divide the setting items into "ID of area 1", "value of area 1", "color of area 1", "display label of area 1", etc. in the property box 2810, and have the developer input or select for each item. However, in this embodiment, instead of doing so, the initial values ​​are displayed in a structure when described in a programming language, and when the developer edits, the developer inputs the description according to the structure when described in a programming language. This is because the setting value of the pie chart can be changed by an action input by JavaScript to another UI widget or the action board of the canvas. If the initial values ​​are displayed in a structure that can be described in a programming language and as copyable text (character string), the developer can copy this character string to the clipboard by a known copy method and paste it on the action board (copy and paste is possible). Then, by modifying only the characters of the part to be changed on the action board, the developer can easily write an action that changes the display content of the pie chart. In this way, when the developer wants to write an action that changes the display form of the pie chart, it is possible to prevent the developer from not knowing how to write the action as intended, or from spending a lot of time looking up how to write it. In other words, software development can be carried out more efficiently. Because it is a programming language, it can be freely edited when other edits are required.

[0359] FIG. 29 shows an example of the display of an action board when a developer inputs an action to change (specify) the display form (display contents) of the pie chart 531 into the action board of a UI part (button) different from the pie chart 531 arranged by the developer. The action board 2900 shown in the figure is a description area (input area) in which an action to be executed when a 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 obtained by editing (changing) only 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 line breaks are added for ease of viewing. Of course, other parts may be changed, and a data set (part enclosed in "{}") may be added or deleted. In this way, inputting an action in a programming language becomes very easy. In the constructed application, when a button corresponding to this action board is pressed, the pie chart is displayed in a display form based on the contents described in this action board, rather than in the initial value.

[0360] As with pie charts, initial values ​​(default settings) are set for lists among UI widgets, 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 the display of a property box 2820 for a list 2802. As shown in the figure, the initial values ​​are displayed in a value input area 2821 according to the structure when written in a programming language.

[0361] As with the pie chart, the LINE CHART (a line chart, a line graph), one of the UI widgets, 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 how the property box 2830 of the LINE CHART 2803 is displayed. As shown in the figure, the initial values ​​are displayed in the input areas 2831 to 2834 according to the structure when written in a programming language.

[0362] As with the pie chart, initial values ​​(default settings) are set for the data grid (table), combo box, tab, stepper, and breadcrumbs among the UI widgets, and the initial values ​​are displayed in the property box according to the structure when written in a programming language. Fig. 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 an input area 2841 according to the structure when written in a programming language. The initial values ​​of the 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.

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

[0364] In S3001, the developer terminal 100 displays a context menu for the data grid. FIG. 31(a) shows an example of the display of the context menu for the data grid. The data grid 3110, which is a UI widget arranged on the canvas 530, has six columns, 3111 to 3116. Note that the dotted lines surrounding the data grid 3110 are auxiliary lines on the drawing shown to show the entire data grid 3110, and are not displayed. The context menu 3120 for the data grid is displayed near the mouse cursor. At least a property 3121 and an action 3122 are displayed in the context menu 3120 as options to be menu items.

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

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

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

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

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

[0370] In S3010, the developer terminal 100 displays a property box of a data grid, which is a specified UI widget. FIG. 31(b) to FIG. 31(f) show examples of display of the property box of a data grid. 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 instructing 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 a specified UI widget 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 a column whose settings are to be changed. In the property box of the data grid, a screen for accepting settings for each column is displayed, and the property settings for each column are accepted. The add column button 3133 is a display item instructing to add a column to the data grid, which is a specified UI widget.

[0371] In S3011, the developer terminal 100 determines whether or not 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 or not any column has been selected as a 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, among the tabs (options) displayed in the column selection field 3132, the tab (not shown) located on the far left is a tab labeled "DataGrid," and is a tab for displaying a setting screen for making settings related to the entire data grid, which is the specified UI widget. Only this "DataGrid" tab does not relate to a specific column (it is not for selecting a specific column).

[0372] In S3012, the developer terminal 100 switches the display content of the area below the column selection field 3132 in the property box to a setting screen (element screen) related to the selected column. FIG. 31(c) shows a display example 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, an 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 (type of component) of the column. The setting screen of the tab 3132E continues further downward, and the further lower part can be displayed by scrolling. FIG. 31(d) shows a display example 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 to delete the column itself corresponding to the tab 3132E, and an apply button 3137 for instructing to apply the contents set in the setting screen of the tab 3132E and reflect them in the data grid displayed on the canvas. The column selection field 3132 moves upward as the user scrolls and is no longer visible in the property box, but it will reappear if the user scrolls back so that the upper region 3134t is visible. When the "DataGrid" tab is selected in S3011, the display content of the region below the column selection field 3132 in the property box is switched to a setting screen for setting the entire data grid.

[0373] In S3013, the developer terminal 100 determines whether or not the add column button 3133 in the property box has been pressed. If the add column button 3133 has been pressed, the process proceeds to S3014, and if not, the process proceeds to S3015.

[0374] In S3014, the developer terminal 100 performs a column addition process. In the column addition process, first, a column addition form 3138 shown in Fig. 31(e) is displayed, and settings of the ID and label (name of the column to be displayed) of the column (column of the table) to be added are accepted from the developer (user). Then, when the ADD TO Value button is pressed, a new column is added, and a tab corresponding to the new column is added to the column selection field 3132.

[0375] Fig. 31(f) shows an example of the display of the property box when a column is added. Compared to Fig. 31(c), a tab 3032F (a tab marked "CompanyF") corresponding to the new column has been added to the column selection field 3132. Immediately after the addition, the added column is selected, and the upper region 3139t of the setting screen for the tab 3032F corresponding to the added column is displayed in the region below the column selection field 3132. Thus, in this embodiment, a column is added to a data grid (table) by operating the property box, which is the setting screen for the data grid.

[0376] In S3015, the developer terminal 100 determines whether or not a setting operation has been performed on the selected column. Specifically, it determines whether or not an input operation has been performed on 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 a setting field, the process proceeds to S3016, and if not, the process proceeds to S3017.

[0377] In S3016, the developer terminal 100 accepts the setting operation and reflects it in the display. For example, the type setting for the type setting field 3135 is accepted. In this way, the data grid allows the selection of the type as a component (part) for each column. As options of the component type that can be set for a column, TextInput, NumberInput, ComboBox, Multi-Select, CheckBox, DataPicker, Link, Button, and IconButton are displayed, and the developer can select and set one of them. In addition, at least a part of the other configurable items (setting items) changes depending on the type of the selected component. For example, when TextInput is selected as the type, the other setting items include the following: ValueType, ID, Label (character string displayed as the column name), Width (column width), NumberFormat, DataFormat, Options, Footer, FooterText, Sorting, and Visibility. In addition, the setting items that can be set on the setting screen for the entire data grid corresponding to the "DataGrid" tab include the following. ID (data grid UI part ID), overall size of the DataGrid (width, height), whether it will be 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.

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

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

[0380] In S3019, the developer terminal 100 determines whether or not the End button 3140 has been pressed. If the End button 3140 has been pressed, the property box is hidden and the processing of Fig. 30 ends. If the End button 3140 has not been pressed, the process proceeds to S3011.

[0381] In this way, columns can be added to a data grid (table) and settings can be made for each column with greater operability. In particular, the operation of adding a column to a data grid can be performed by operating the data grid's property box, and 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 setting the settings for the added column can be performed smoothly with the same feel as operating the property box. In addition, after adding a column, the type is set from options that can be set as a column component, so columns can be added and the type set without confusion.

[0382] In S3020, the developer terminal 100 displays options of actions 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 the action 3122 is pressed from the state of FIG. 31(a). The same display objects in FIG. 31(a) and FIG. 32(a) are given the same reference numerals. The submenu 3210 is displayed as a submenu of the action 3122 of the context menu 3120. The submenu 3210 includes options 3211 to 3217. The option 3211 is an option for opening an action board of actions to be executed in response to an operation on the entire data grid 3110. The options 3212 to 3217 are options for opening an action board of actions for each column to be executed when each column of the data grid 3110 is operated. The options 3212 to 3217 correspond to the columns 3111 to 3116, respectively. At this time, options corresponding to the action board of a column of a data grid different from the data grid of the specified UI widget are not displayed.

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

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

[0385] FIG. 32(b) shows a display example of an action board corresponding to the options (options 3211) of the action of the entire data grid. "DATA GRID" is selected in the whole 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 whole that is displayed outside the column of the area of ​​the data grid, which is the specified UI widget in the constructed application. In other words, this trigger is a trigger related to the data grid (table), which is the specified UI widget, and is a trigger that is not related to the column of the data grid. The button related to the whole 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 described above, the update button of the data grid, etc. 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). This action board 3211a can be configured by writing actions in JavaScript, such as calculating the sum of all rows in a specific column and displaying it in another UI widget, saving the contents displayed in the data grid to a database, and transitioning to another UI screen.

[0386] FIG. 32(c) shows an example of the display of an action board corresponding to an 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 widgets is changed, or a button displayed in a cell in any row of the corresponding column is pressed in the constructed application. 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, 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 an action in which, 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 widget, other than the column corresponding to the selected option 3212.

[0387] It should be noted that even after an action board is opened, it is possible to switch to and display an action board in another column by selecting another column in the selection area 3220.

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

[0389] 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 process is repeated. If an operation to close the action board has been performed, the action board is hidden, the display is switched to the canvas of the selected UI screen, and the process returns to the UI editor processing.

[0390] In this way, actions can be set for each column included in the data grid (table) with greater operability. 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 that the developer can recognize that actions can be set for each column, and the possibility of missing an action setting for a column can be reduced. In addition, since it is displayed as a submenu of the context menu of the data grid, which is the specified UI widget, the relationship with the data grid, which is the specified UI widget, can be clearly understood. In other words, the design work can be performed while understanding without confusion which column of which data grid the action set in the action board relates to.

[0391] <Action execution related processing> 33(a) shows a flowchart of the save process (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 transmitted from the developer terminal 100 in S422 of the above-mentioned FIG. 4.

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

[0393] In S3301 of Fig. 33(a), the development environment 300 determines whether or not definition information (UI definition information) of the selected application has been received from the developer terminal 100. The definition information received here is the information transmitted from the developer terminal 100 in S422 of Fig. 4 described above. If a UI definition has been received, the process proceeds to S3302, and if not, the process waits in S3301.

[0394] In FIG. 34, UI definition information 3401 recorded in memory 102 of 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 information (position, size, color, etc.) of UI components (UI widgets) for each UI screen. The UI definition information 3401 also includes an action description part 3402. This action description part 3402 is a character string inputted to the action board of each UI widget or canvas or the function setting screen (including the creation function setting screen). The action description part 3402 includes an action described in JavaScript and a function definition in JSON format describing the contents set in the function setting screen without inputting JavaScript. This UI definition information 3401 is transmitted (uploaded) from the developer terminal 100 to the development environment 300, and is received by the development environment 300 in S3301.

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

[0396] In S3303, the development environment 300 extracts action information from the UI definition information saved in S3302. That is, the development environment 300 extracts the action description part 3412 from the UI definition information 3411 in FIG.

[0397] In S3304, the development environment 300 generates an execution environment program from the action description portion 3412 extracted in S3303, and saves it in an area for the login developer in the storage 320. That is, based on the action description portion 3412 extracted from the UI definition information 3411 in Fig. 34, the execution environment program 3413 is generated and saved in the development environment. The execution environment program 3413 is text data written in JavaScript. The execution environment program 3413 is a program in which, in addition to the character strings inputted in the action board obtained from the action description portion 3412, supplementary portions necessary for execution by the execution engine of the execution environment are added.

[0398] The UI definition information 3411 and the program for execution environment 3413 saved in the development environment 300 by the save process described in Fig. 33(a) are deployed (placed, saved, recorded, constructed) to the execution environment 400 by the deploy process. This process is performed at S2423 or S2424 in Fig. 24 described above. As a result, the UI definition information 3421 and the program for execution environment 3423 are recorded in the execution environment 400 as shown in Fig. 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 application has been generated.

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

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

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

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

[0403] In S3313, the execution environment 400 determines whether or not an action request has been received from the application user terminal 200. An action request is a request to execute the content of an action input to the action board. The action request received here is the one sent from the application user terminal 200 in S3345 in Fig. 33(c) described below. If an action request has been received, the process proceeds to S3314, and if not, the process proceeds to S3320.

[0404] In S3314, the execution environment 400 determines whether or not a value of 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 at the application user terminal 200 for a UI widget classified as an input item among UI widgets displayed on the screen of the application. For example, it is text input into a text field. In this embodiment, the determination in S3314 is a determination of whether or not the value of the input item was included in the action request received in S3313. If the value of the input item has been received (if the value of the input item was included in the action request), the process proceeds to S3315; otherwise, the process proceeds to S3316.

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

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

[0407] In S3317, the execution environment 400 determines whether or not there is a value for an output item, which is a value to be displayed on the screen of the application displayed on the application user terminal 200, as a result of executing the action in S3316. For example, if the action is an action such as "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.

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

[0409] At S3319, the execution environment 400 transmits result information of the action executed at S3316 to the application user terminal 200. If action result information including a value of the output item has been generated at S3318, the value of the output item will also be transmitted to the application user terminal 200. Then, at S3348 in 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 in FIG. 33(c) described below.

[0410] In S3320, the execution environment 400 determines whether or not to end the process. If the execution environment 400 determines to end the process (Yes in S3320), the execution environment 400 ends the process. If the execution environment 400 determines not to end the process (No in S3320), the process returns to S3313. For example, the execution environment 400 determines to end the process when an event occurs in S3350 that ends the app, which will be described later. 33(c), in S3331, application user terminal 200 (including application user terminal 201, but the following description will take 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's URL is accessed (connected).

[0411] In S3332, application user terminal 200 determines whether or not a client program has been received. When execution environment 400 detects access from 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 storage (client program 422, 456c, 466c, 476c, etc., that of the accessed execution environment) to application user terminal 200. In S3332, it is determined 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.

[0412] In S3333, the application user terminal 200 transmits a request to acquire UI definition information to the runtime environment 400. The client program received in S3332 defines that when the runtime environment is accessed, a request to acquire UI definition information is first issued. S3333 is a process that follows this definition. The UI definition information acquisition request transmitted here is received by the runtime environment 400 in S3311 in the above-mentioned Fig. 33(b).

[0413] 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 transmitted 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 the 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 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). Furthermore, the application user terminal 200 displays the screen of the application on the display 105 based on the UI definition information recorded in the memory 102.

[0414] In S3335, the application user terminal 200 determines whether an action trigger has occurred. Specifically, it determines whether an operation to instruct a screen transition (a trigger to activate an action on the canvas of the transition destination) or an operation on a UI widget displayed on the application screen (a trigger to activate an action on a UI widget by clicking, etc.) has occurred. If an action trigger has occurred, the process proceeds to S3336, and if not, the process proceeds to S3350.

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

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

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

[0418] In S3339, the application user terminal 200 determines whether the character string "$ui" found in S3338 is on the left side of a sentence that contains that character. A "sentence" (one sentence) 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 sentences are separated by a line terminator or a closing bracket ('}'). If "$ui" found by 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, the process proceeds to S3340, and if not, the process proceeds to S3341.

[0419] In S3340, the application user terminal 200 records information based on the element character string ($ui.UI widget 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 the memory 102. Specifically, a UI widget ID (item code, component identifier) ​​is obtained from the element character string ($ui.UI widget ID.type of target information) of a structure separated by "." (period) beginning with "$ui", and records that the UI widget is an output item. For example, if a trigger related to action A occurs, and "$ui" is found in the description portion related to action A, and it is on the left side, and the UI widget ID is "UI widget ID3", then it is recorded that UI widget ID3 is present in the output item, as in item definition list 3433 in FIG. 34. The item definition list 3433 is information temporarily stored in the memory 102, which is the working memory, and is automatically deleted depending on whether the result of the action is received and reflected in the output items (No in S3348, described below, or the processing of S3349 is ended) or the app is terminated (Yes in S3350).

[0420] In S3341, the application user terminal 200 determines whether the character string "$ui" found in S3338 is located anywhere other than on the left side of a sentence containing the character. When it is located anywhere other than on the left side, it means that it is on the right side (to the right of "=") or in a portion not containing "=". When it is located anywhere other than on the left side, the process proceeds to S3342, and when it is not, the process proceeds to S3337. Note that if the determination in S3339 is No, this is equivalent to the character string "$ui" being located 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.

[0421] In S3342, the application user terminal 200 records information based on the element character string ($ui.UI widget 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 the memory 102. Specifically, a UI widget ID (item code, component identifier) ​​is obtained from the element character string ($ui.UI widget ID.type of target information) of a predetermined structure beginning with "$ui", and records that the UI widget is an input item. For example, if a trigger related to action A occurs, and "$ui" is found in the description portion related to action A, and it is on the right and the UI widget ID is "UI widget ID1", then it is recorded that UI widget ID1 exists in the input item, as in item definition list 3433 in FIG. 34. Also, for example, if a trigger for action A occurs, and "$ui" is found in the description section for action A, and it is in a sentence without "=", and the UI widget ID is "UI widget ID2", then it will be recorded that UI widget ID2 is in the input item, as shown in item definition list 3433 in Figure 34.

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

[0423] In S3343, when it is determined in S3335 that an action has been triggered, the application user terminal 200 determines whether or not the information targeted by the input item recorded in the item definition list 3433 has a value. For example, if "$ui.UI widget ID1.value" is written in the description portion extracted in S3336, it determines whether or not the information of the type "value" in the UI widget with UI widget ID1 has a value. If the UI widget with UI widget ID1 is a TextField, the value is the text (character string) input in the TextField. That is, it determines whether or not the user of the application has input text with the keyboard for the UI widget ID1 that is a TextField displayed on the screen of the application, and if text has been input, it determines Yes, and if it is blank, it determines No. This determination is performed for all input items recorded in the item definition list 3433. If the information targeted by the input item has a value, the process proceeds to S3344, and if not, the process proceeds to S3345.

[0424] 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, the action request is generated including, as the value of the input item, information about text entered by the application user on the keyboard for UI widget ID1, which is a TextField displayed on the screen of the application displayed on display 105 of the application user terminal 200.

[0425] 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 has been 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 input by the application user via a keyboard for UI widget ID1, which is a TextField displayed on the screen of the application displayed on the display 105 of the application user terminal 200, is transmitted to the 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.

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

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

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

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

[0430] In S3350, the application user terminal 200 determines whether or not an event that will cause the application to be terminated has occurred. Events that cause the application to be terminated include, for example, disconnection of a connection to an access destination indicated by the application's URL (closing the Internet browser, turning off the power of the application user terminal 200, changing the connection to another unrelated URL, etc.). If there is no event that will cause the application to be terminated, the process proceeds to S3335, and if there is an event that will cause the application to be terminated, the process of FIG. 33(c) ends with the application screen not being displayed.

[0431] Taking as an example a character string in a programming language input to action board 910 shown in FIG. 10(d), 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 will be described in more detail.

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

[0433] In the statement on the fourth line, since the character string "$ui.text_area_a.value" including "$ui" is on the left side, "text_area_a" is recorded as an output item in the item definition list in the process of S3340. That is, the value indicated by the right side of "=" (the output value obtained as a result of the action) is displayed in the UI widget "text_area_a". In addition to the definition that "text_area_a" is an output item, this statement includes a process (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 characteristic features of this embodiment is that input items and output items can also be defined in a statement that includes logic (a process that is different from the definition of at least one of the input item and the output item). Similarly, the sixth line is a logic portion, and since "$ui.text_area_a.value" is on the left side, it is treated as an output item.

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

[0435] (The numbers at the beginning of each line are auxiliary characters that indicate the line number and are not the programming language text.) 1 SQLSave({ 2 PREF_CODE: $ui.PREF_CODE.value, 3 PREF_NAME: $ui.PREF_NAME.value 4}); 5 / / Screen transition 6 $fn.nextUI(′List_ip_demo′); The above programming language strings are actions that register the input values ​​(`$ui.PREF_CODE.value`, $ui.PREF_NAME.value) of the app screen as parameters to the SQLSave function in the database. In this case, $ui.{part ID}.{target information type} used as a parameter to the SQLSave function is identified as an input item (because it is not on the left side of =).

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

[0437] In this embodiment, in the description of an action to be input to the action board, depending on the position of an element string with a specific identifier "$ui" in the string (more specifically, the position in one sentence), it is possible to write (define) whether the UI widget 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 in which the content of the action is input in a programming language. Or, conventionally, even if the content of the action is described in the area in which the content of the action is input 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 process 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 in which the action logic is described in the 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 description part of the action logic for 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 items and / or output items used in logic entered in a programming language.

[0438] In addition, since the method of expressing whether an element string is an input item or an output item depending on the position of the element string with the specific identifier "$ui" is not common, when a program is executed based on the normal JavaScript programming language, it does not properly interpret whether the item is an input item or an output item, and does not operate as intended. Therefore, in this embodiment, a process is performed to identify whether a string containing "$ui" as described in S3338 to S3342 is an input item or an output item, and the system operates correctly.

[0439] In this embodiment, an example has been described in which the specific identifier is the half-width character "$ui", but this is not limiting. 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.

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

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

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

[0443] Moreover, Fig. 36 illustrates a modified example of the transition of information recorded in the developer terminal 100, development environment 300, execution environment 400, and application user terminals 200, 201. Fig. 36 is a diagram that diagrammatically illustrates the transition of information due to the processing of the flowcharts in Fig. 35(a) to Fig. 35(c). In Fig. 36, the same information as in Fig. 34 is given the same reference numerals.

[0444] 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 a process based on client UI definition information 3635.

[0445] In FIG. 36, unlike FIG. 34, the UI definition information is not sent to the application user terminal 200 (it is not even temporarily stored in the application user terminal 200). This prevents detailed definitions of the developed application from being leaked via the application user terminal 200, and improves 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. Also, in the application user terminal 200, it is not necessary 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 in the application user terminal 200, and allows the application to operate with a smooth response (response speed).

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

[0447] In S3505, the development environment 300 generates the UI definition information for the client 3615. The UI definition information for the client 3615 is assumed to be a JSON format file with a file name of "uiDef2.json", for example. The UI definition information for the client 3615 includes, as information acquired from the UI definition information 3411, various setting information related to the application such as the initial UI, information on the UI widget (component) for each UI screen (contents set by the UI widget ID and properties, the layout position and size of the UI widget, etc.), an action identifier of the canvas, an action identifier of the UI widget, etc. In addition, the UI definition information for the client 3615 also records an input / output item definition for each action (definition of which components are present 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 3512 described later). In addition, the character string (source code of the action) itself described in JavaScript (programming language) written on the action board is not recorded. That is, the generated UI definition information for client 3615 includes the action identifier and information on the input / output item definition for each action, but does not include information indicating the operation content of the action.

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

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

[0450] 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. If the result in S3508 is No, it means that all "$ui" searches have been completed or there is no "$ui" at all in the action description portion.

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

[0452] In S3510, the development environment 300 records information based on the element character string of a predetermined structure beginning with "$ui" found in S3338 ($ui.UI widget ID.Target information type) as an output item in the UI definition information for client 3615 generated in S3505. More specifically, in the UI definition information for client 3615, a UI widget ID is obtained from the element character string of a predetermined structure beginning with "$ui" found in S3338 ($ui.UI widget ID.Target information type) 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, when "$ui", which indicates that the UI widget ID is "RESULT", is found on the left side, it is recorded as shown in FIG.

[0453] In S3511, similar to S3341 in Fig. 33(c), the development environment 300 judges whether or not the character string "$ui" found in S3508 is present in a sentence containing the character in question anywhere other than the left side. If it is present in a sentence containing the character in question, the process proceeds to S3512, and if not, the process proceeds to S3507. Note that if the judgment in S3509 is No, this is equivalent to the character string "$ui" being present in a sentence containing the character in question anywhere other than the left side, so the process may proceed to S3512 without making the judgment in S3511.

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

[0455] When the process of S3512 is completed, the process proceeds to S3507, where the character string "$ui" is further searched for in the continuation of the description 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 character strings of $ui included in the description portion extracted in S3506, and whether they are input items or output items is recorded in the UI definition information for client 3615.

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

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

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

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

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

[0461] Since S3541 to S3543 in Fig. 35(c) are similar to S3331 to S3333 in Fig. 33(c) respectively, a description thereof will be omitted, except that in S3543, a request to obtain UI definition information for a client is transmitted.

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

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

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

[0465] The various controls described in each of the above flowcharts may be performed by a single piece of hardware, or the entire device may be controlled by multiple pieces of hardware (e.g., multiple processors or circuits) sharing the processing. 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.

[0466] (Other embodiments) The present invention can also be realized by executing the following process. That is, software (programs) that realize the functions of the above-mentioned 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 storing the program constitute the present invention.

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

[0468] [Configuration 1-1] a receiving means for receiving an input operation from a user on a setting screen for creating a creation function, the input operation being different from an input written by the user in a programming language; a setting means for setting information 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:

[0469] [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 created function when a character string that partially matches the identification information of the created function is input into a description area of ​​a programming language; An information processing system comprising:

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

[0471] [Configuration 2] a display control means for controlling, in response to an operation on a designated area (tab) of a first type component arranged on a development screen of an application, to switch display of at least a part of an area of ​​the first type component to an element screen corresponding to the operated designated area; a control means for controlling, when an operation for placing another component in an area of ​​the first type component placed on the development screen is performed, to place the other component on a currently displayed element screen among a plurality of element screens of the first type component; An information processing system comprising:

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

[0473] [Configuration 4] An information processing system including a first type of environment (development environment) and a second type of environment (execution environment), an acquisition means for acquiring access destination information in the 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 for execution of a predetermined process (e.g., a process for transmitting user information) to the access destination indicated by the access destination information acquired by the acquisition means; An information processing system comprising:

[0474] [Configuration 5] An information processing system including a first type of environment (development environment) and a second type of environment (execution environment), an authentication means for performing user authentication to determine whether or not a user is permitted to access the first type of 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:

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

[0476] [Configuration 7] A means for accepting a selection of a table (data grid); A display control means for controlling to display a setting ...

Claims

1. Receiving means for receiving a selection of a table, Display control means for controlling to display, as options, objects whose functions can be set, included in the selected table, Control means for displaying an input area for receiving an input of a function related to the object corresponding to the selected option in response to selection of any one of the options, and controlling to receive an input operation of the function An information processing system, characterized by comprising the above.

2. The input area for receiving the input of the function is an area for setting a process to be executed triggered by a change in the value of a cell in the corresponding column of the table or an operation on a button displayed in the cell The information processing system according to claim 1, characterized by the above.

3. In the input area for receiving the input of the function, the setting of the trigger from the user is not received The information processing system according to claim 2, characterized by the above.

4. The input area for receiving the input of the function can receive a setting of a function that affects other objects in the table different from the object corresponding to the selected option The information processing system according to claim 1, characterized by the above.

5. The control means controls to receive an input of a character string in a programming language as the input operation on the input area for receiving the input of the function The information processing system according to claim 1, characterized by the above.

6. The programming language is JavaScript The information processing system according to claim 5, characterized by the above.

7. When displaying the options, the display control means controls not to display options related to a table different from the selected table The information processing system according to claim 1, characterized by the above.

8. The display control means controls to display, together with the options, an option for setting a function to be executed in response to a trigger related to the selected table, which is a trigger not related to the columns of the table The information processing system according to claim 1, characterized by the above.

9. The objects whose functions can be set include columns and tables The information processing system according to claim 1, characterized by the above.

10. The table is a table arranged as a component to be displayed on the screen of the constructed application on the development screen of the application The information processing system according to claim 1, characterized by the above.

11. The function is a process to be executed in the constructed application. The information processing system according to claim 10, characterized in that.

12. The information processing system further includes construction means for constructing the application by deploying definition information of the application including information indicating a function based on the input operation from a development environment to an execution environment. The information processing system according to claim 11, characterized in that.

13. The display control means further controls to display a setting screen of the selected table, The control means controls to add a column to the selected table in response to a first operation on the setting screen, and controls to set information displayed in the added column in response to a second operation on the setting screen. The information processing system according to claim 1, characterized in that.

14. The display control means displays a first option and a second option regarding the selected table, and controls to display the setting screen of the selected table when the first option is selected, and controls to display, as an option, an object for which a function included in the selected table can be set when the second option is selected. The information processing system according to claim 13, characterized in that.

15. A reception step of receiving a selection of a table, A display control step of controlling to display, as an option, an object for which a function included in the selected table can be set, A control step of, in response to any one of the options being selected, displaying an input area for receiving an input of a function related to the object corresponding to the selected option and controlling to receive an input operation of the function. A control method of an information processing system, characterized by comprising the above.

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

Images