JP7808488B2 - Scenario management device, scenario management program, recording medium, and scenario management method - Google Patents

Description

This invention relates to RPA (Robotic Process Automation) technology, which aims to reduce the workload of users by automating tasks that users previously performed using computers.

RPA uses a scenario (sometimes called a "flow") that indicates the order in which processes are to be executed by a computer. Furthermore, the computer that executes processes according to the scenario appropriately references various variables, such as files that manage data in tabular format and the data managed by those files. For example, in Patent Document 1, a scenario file that indicates the order in which processes are to be executed and a customization file that indicates the setting values of variables required to execute the scenario file are prepared, and the computer that executes processes according to the scenario file references the setting values indicated in the customization file.

Japanese Patent Application Laid-Open No. 2020-113034

Work that can be automated using RPA technology includes the task of a user referencing arbitrary data and inputting that data in a format that can be processed by a computer. Patent Document 1 discloses that a user edits a customization file that is referenced as a variable included in a scenario file. Therefore, while the above work can be replaced by editing the customization file, it is not automated. To automate this, it is necessary to manage the variables included in the scenario so that arbitrary data can be referenced in the same way that a user references arbitrary data when performing the above work.

However, one advantage of RPA technology is that it creates scenarios based on the user's actual operations, i.e., the entity values processed during the user's operations. In other words, users can create scenarios by accessing entity values through their actual operations. However, variables included in a scenario do not reference entity values except when the scenario is actually executed, which poses a problem: when a user manages variables included in a scenario, they cannot access the entity values referenced by those variables.

This invention was developed in consideration of the above-mentioned problems, and aims to provide a configuration in which the actual values of variables referenced in a scenario are accessed when managing the scenario.

The scenario management device of the present invention manages scenarios for automating operations on other application programs and includes: a management unit that manages scenarios including a first activity and a second activity selected from multiple types of activities, including activities corresponding to operations for obtaining values from other application programs, activities corresponding to operations for inputting values into other application programs, and activities corresponding to operations for processing obtained values; an execution unit that executes the first activity included in the scenario based on a scenario execution instruction; a first storage area that is accessed by the execution unit when executing the first activity included in the scenario and that holds the entity values of variables referenced in the first activity so that they can be referenced as entity values of variables included in a second activity included in the scenario; a second storage area that is accessible by the management unit and that holds the entity values of variables held in the first storage area in association with the variables; and a storage unit that stores the entity values of variables held in the first storage area in the second storage area.

The scenario management program of the present invention causes a computer to function as the above-mentioned scenario management device.

The recording medium of the present invention records the above-mentioned scenario management program in a computer-readable manner.

The scenario management method of the present invention manages a scenario including a first activity and a second activity selected from multiple types of activities, including activities corresponding to operations for obtaining values from other application programs, activities corresponding to operations for inputting values into other application programs, and activities corresponding to operations for processing obtained values, as a scenario for automating operations on other application programs. The scenario management method includes the steps of: executing the first activity based on a scenario execution instruction; and storing in a first storage area the entity values of variables referenced in the first activity so that they can be referenced as the entity values of variables included in the second activity; and storing in a second storage area accessible by a management unit that manages the scenario the entity values of the variables stored in the first storage area in association with the variables.

In this configuration of the present invention (scenario management device, scenario management program, recording medium, and scenario management method), when a first activity included in a scenario is executed and the entity value of the variable is stored in a first storage area so that it can be referenced as the entity value of a variable included in a second activity, the storage unit associates the entity value with the variable and stores it in a second storage area accessible by the management unit. Therefore, the user can access the referenced entity value not only when the scenario is executed, but also when managing the scenario. As a result, for example, the user can check the entity values of variables referenced in a scenario when editing it.

As described above, according to the present invention, when managing a scenario, it is possible to access the actual values of variables referenced in the scenario.

1 is a block diagram showing an example of a scenario management system including a scenario management device according to the present invention; FIG. 2 is a block diagram showing an example of each functional unit configured in the calculation unit for scenario management. FIG. 4 is a diagram schematically showing an example of a scenario management screen displayed on a display. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in a scenario creation mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in a scenario creation mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in a scenario creation mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in a scenario creation mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in a scenario creation mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in a scenario creation mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in a scenario creation mode. FIG. 4 is a block diagram showing the operation of each functional unit of the calculation unit when variable management is executed. 10 is a flowchart showing an example of control executed by an execution unit for variable management. 10 is a flowchart showing an example of control executed by a monitoring unit for variable management. FIG. 8 is a diagram schematically showing the operation of variable management executed based on the flowcharts of FIGS. 6 and 7; FIG. 4 is a diagram schematically illustrating an example of entity values stored in a memory unit. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in the scenario editing mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in the scenario editing mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in the scenario editing mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in the scenario editing mode. FIG. 10 is a diagram schematically showing an example of operations that can be performed on the scenario management screen in the scenario editing mode. FIG. 10 is a block diagram showing the operation of each functional unit of the calculation unit when a scenario edit mode is executed. 10 is a flowchart showing an example of variable display executed by the editing operation unit in a scenario editing mode. FIG. 10 is a diagram schematically showing the contents of variable name management. 10 is a flowchart showing an example of variable name management executed in association with acquisition of the entity value of a variable. 10 is a flowchart showing an example of control for displaying substance values in a scenario editing mode. FIG. 16 is a diagram schematically illustrating an example of the result of the control shown in FIG. 15 . 10 is a flowchart showing an example of control for partial execution in a scenario edit mode.

Figure 1 is a block diagram showing an example of a scenario management system equipped with a scenario management device according to the present invention. This scenario management system 1 comprises a server 11 and a terminal device 2 that functions as a client of the server 11. The server 11 is a computer, and has a storage unit 111 composed of a hard disk drive (HDD) or solid state drive (SSD), etc., in which a scenario management program 12 is stored.

The terminal device 2 is a computer for managing scenarios used in RPA. This terminal device 2 includes a calculation unit 21, a memory unit 22, a storage unit 23, a UI (User Interface) 24, a communication unit 25, and a bus 26, and signals are sent and received between the calculation unit 21, memory unit 22, storage unit 23, UI 24, and communication unit 25 via the bus 26.

The calculation unit 21 is a processor such as a CPU (Central Processing Unit) and controls the memory unit 22, storage unit 23, UI 24, and communication unit 25. The memory unit 22 has a main memory, cache memory, etc., and volatilely stores data based on instructions from the calculation unit 21, which then performs calculations using data read from the memory unit 22.

The storage unit 23 includes an HDD, SSD, etc., and stores data in a non-volatile manner. The UI 24 includes input devices such as a keyboard 241 and a mouse 242, and an output device such as a display 243. Therefore, a user can perform input operations on the terminal device 2 by operating the keyboard 241 and mouse 242, and can check various data stored in the memory unit 22 and storage unit 23 by checking the display 243. The input and output devices do not need to be configured separately; they may be configured as an integrated touch panel display. The communication unit 25 also communicates with the server 11. The communication unit 25 downloads the scenario management program 12 from the server 11, and the storage unit 23 stores the scenario management program 12. When the calculation unit 21 executes the scenario management program 12, the functional units shown in FIG. 2 for executing scenario management are configured in the calculation unit 21.

Note that the scenario management program 12 may be provided to the terminal device 2 in a manner other than by download from the server 11. It may instead be provided via an optical disc such as a DVD (Digital Versatile Disc) or other recording medium such as a USB (Universal Serial Bus) memory. The terminal device 2 can read the scenario management program 12 from these recording media and store it in the storage unit 23.

In this embodiment, the scenarios used in RPA and managed by the terminal device 2 are scenarios for automating operations performed by the user of the terminal device 2 or other humans on application programs other than the scenario management program 12. These operations include operations to obtain values from application programs other than the scenario management program 12, operations to process values, and operations to input values into application programs other than the scenario management program 12. Operations to obtain values from application programs other than the scenario management program 12 include humans operating application programs other than the scenario management program 12 to output referenced information from an output device such as the display 243. Operations to input values into application programs other than the scenario management program 12 include humans operating input devices such as the keyboard 241 and mouse 242 to input values into application programs other than the scenario management program 12. For example, these include directly inputting values using the keyboard 241 and selecting a value to be input from options displayed by the application program using an input device.

Figure 2 is a block diagram showing an example of the functional units configured in the calculation unit for scenario management. As shown in Figure 2, execution of the scenario management program 12 by the calculation unit 21 configures an editor 31, a scenario creation unit 33, an execution unit 35, and a debugger 37 in the calculation unit 21.

The editor 31 manages scenarios. In this embodiment, the scenarios managed by the editor 31 include multiple activities Act (not shown), which are computer operations corresponding to various human operations on applications other than the scenario management program 12, and the editor 31 manages multiple activities Act. The editor 31 accepts user operations on the UI 24 for scenario management. The editor 31 has an editing operation unit 311 and a scenario execution operation unit 312. The editing operation unit 311 displays a scenario management screen 4 (see Figure 3, etc.) on the display 243 of the UI 24, which shows the contents of the operations to be automated in the scenario, for the user's scenario management, and accepts user operations on the scenario management screen 4. The scenario execution operation unit 312 accepts operations from the user to instruct the execution of a scenario. The user selects some or all of the activities Act included in the scenario to instruct the execution of the scenario. The scenario execution operation unit 312 accepts the selection of an activity Act and sends a scenario execution instruction Ce to the execution unit 35, indicating the execution of a scenario corresponding to the selected activity Act.

The scenario creation unit 33 creates a scenario in response to user operations on the scenario management screen 4. More specifically, the scenario creation unit 33 accepts settings for the activity Act, via user operations, related to the content of various human operations to be automated by the activity Act, and generates the activity Act based on these settings. The scenario creation unit 33 also sends a scenario execution instruction Cg to the execution unit 35 based on the generated activity Act. In this embodiment, each time an activity Act is generated, the scenario creation unit 33 sends a scenario execution instruction Cg to the execution unit 35 indicating the execution of the generated activity Act. Note that the scenario execution instruction Cg may be sent to the execution unit 35 each time a predetermined number of activity Acts are generated, or may be sent to the execution unit 35 in response to an operation being performed on the scenario management screen 4 requesting the execution of the generated activity Act. Furthermore, the scenario creation unit 33 may also send a scenario execution instruction Cg to the execution unit 35 that does not include the activity Act in question, depending on the type of activity Act.

The execution unit 35 executes part or all of a scenario based on a scenario execution instruction Ce from the editor 31 or a scenario execution instruction Cg from the scenario creation unit 33. The debugger 37 manages the variables used by the execution unit 35 to execute a scenario when the execution unit 35 executes the scenario. This debugger 37 has a monitoring unit 371 and a holding unit 372. The monitoring unit 371 monitors the acquisition of the actual values of variables by the execution unit 35. The holding unit 372 holds the actual values acquired by the execution unit 35 based on instructions from the monitoring unit 371.

Figure 3 is a diagram that schematically illustrates an example of a scenario management screen that is displayed on the display. Note that the scenario management screen 4 shown in Figure 3 is merely an example, and various modifications are possible. The scenario management screens 4 shown in the following figures can also be modified in a similar manner. As shown in Figure 3, the scenario management screen 4 has a utility operation column 41, a mode selection column 43, and a scenario display column 45. The utility operation column 41 has a button 411 for naming and saving a newly created scenario, a button 412 for overwriting and saving an edited scenario, and a button 413 for executing part or all of the scenario.

The mode selection column 43 accepts an operation to select either the scenario creation mode or the scenario editing mode. In other words, the user can select the scenario creation mode by operating (clicking) the expand/collapse button provided in the scenario creation column 431 of the mode selection column 43 to expand the scenario creation column 431. The user can also select the scenario editing mode by operating (clicking) the expand/collapse button provided in the scenario editing column 432 of the mode selection column 43 to expand the scenario editing column 432.

4A to 4G are diagrams showing an example of operations that can be performed on the scenario management screen in the scenario creation mode. In these diagrams, the scenario creation field 431 is expanded, while the scenario editing field 432 is contracted. In the scenario creation mode, icons indicating various activities Act that can be used to create a scenario are displayed in the scenario creation field 431. The activities Act include:
Specific examples include an activity that retrieves a table written in CSV (Comma-Separated Values) format or the like, an activity that narrows down the values in the table using specified conditions, an activity that extracts values from the table, an activity that outputs the values to an output destination (a table, a web page, an email address, etc.), an activity that accesses a specified web page, and an activity that retrieves images or text from a web page. The user can select the activity Acts that make up the scenario by placing the activity Acts in the scenario creation field 431 in the scenario display field 45. In this way, a scenario can be created that includes the activity Acts placed in the scenario display field 45. The user can place the activity Acts in the scenario creation field 431 in the scenario display field by various operations, such as dragging the activity Act in the scenario creation field 431 to the scenario display field 45 or double-clicking the activity Act in the scenario creation field.

In addition, in scenario creation mode, activities Act are organized into units U according to the work purpose, such as table editing or web scraping. Therefore, the user can create a scenario including the activities Act that make up the units U by placing (dragging) the units U according to the work purpose into the scenario display field 45. This reduces the burden on the user required to create a scenario. However, it is not necessary for activities Act to be organized into units in scenario creation mode.

In scenario creation mode, the user's operations of placing an activity Act in the scenario display field 45 and determining the content of the activity Act (for example, the variable V to be used) are input to the scenario creation unit 33 (Figure 2). The scenario creation unit 33 then accepts these operations and creates a scenario. This creates a scenario in which each activity Act is executed in accordance with the arrangement order of the activity Act in the scenario display field 45.

The scenario creation unit 33 also sends a scenario execution instruction Cg to the execution unit 35, indicating the execution of an activity Act placed in the scenario display field 45, and the execution unit 35 executes the activity Act. In other words, in scenario creation mode, the activity Act included in the scenario is executed in parallel with the creation of the scenario. Therefore, the user can determine the activity Act that constitutes the scenario while checking the operation of the activity Act placed in the scenario display field 45. In particular, the entity value E of the variable V used in the activity Act is acquired as the activity Act is executed. In this embodiment, acquiring the entity value as the activity Act is executed means that the entity value is stored in a specified storage area so that it can be referenced when executing activities other than the activity in question. This allows the user to create a scenario while checking the entity value E of the variable V. The acquisition of this entity value E will be specifically explained using the examples of Figures 4A to 4G. Note that the execution of an activity Act in scenario creation mode may be configured to accept an instruction from the user regarding whether or not to execute the activity Act. For example, for activities that may have an impact on business operations if performed during the scenario creation stage, such as writing data to another file or sending an email, the user may be allowed to choose whether or not to perform the activities.

In Figure 4A, activity Act(1), which extracts a table, and activity Act(2), which extracts a value from the table, are selected as activities Act that constitute a scenario (i.e., they are arranged in the scenario display field 45). In activity Act(1), a variable V_t is declared. The user can enter the path of the table (data) to be obtained as the entity value E_t of variable V_t in input field 51. When the path is entered in input field 51, activity Act(1) is set, which obtains the table of the path as the entity value E_t of variable V_t. When activity Act(1) is set in this way, the scenario creation unit 33 sends a scenario execution instruction Cg to the execution unit 35, which instructs the execution of activity Act(1). Then, the execution unit 35 executes activity Act(1), thereby obtaining the entity value E_t of variable V_t. At this time, variable management is performed by storing the actual values of the variables acquired by the execution unit 35 in the memory unit 22; details of this variable management will be described later.

In activity Act(2), variable V_v1 is declared and the entity value E_v1 of variable V_v1 is obtained. The user can set the entity value E_v1 of variable V_v1 by entering it in input field 52. In this embodiment, when the user selects (clicks) input field 52, the user can choose to enter the value directly into input field 52 or select it from options and enter it into input field 52. In this embodiment, the user selects one of two options: "Direct Input" or "Table: Value of V_t." By selecting "Direct Input," the user can enter the value directly into input field 52. Furthermore, by selecting "Table: Value of V_t," the user can specify whether to obtain entity value E_v1 using any variable as an argument, or to use variable V_t as an argument. In particular, in this embodiment, candidate variables F that can be used as arguments in activity Act(2) are displayed. The variables displayed as candidate F are, for example, variables whose entity values are acquired at the time the activity is executed when a scenario is executed. In this embodiment, activity Act(1) is already being executed when activity Act(2) is executed, so the variable V_t whose entity value E_t is acquired by executing activity Act(1) is displayed as candidate F. Note that the variables displayed as candidate F may be displayed according to the type of input field 52.

Figure 4B shows the case where the option "Table: Value of V_t" is selected, i.e., the entity value E_v1 is obtained using an argument, and the variable V_t (Table) is selected from the candidate variables F that can be used as the argument. In this example, a table is obtained as the entity value E_t in activity Act(1), so the value contained in variable V_t (Table) is selected as the entity value E_v1. That is, the scenario management screen 4 in Figure 4B displays the entity value E_t (Table) of variable V_t selected from multiple candidates F. This allows the user to confirm the type of entity value E_t that candidate F, selected as the argument for activity Act(2), obtains. In this example, variable V_t is a table. Therefore, by specifying one of the cells contained in the displayed entity value E_t (Table), the user can specify in input field 52 that the entity value E_v1 of variable V_v1 is to be obtained from a cell contained in variable V_t (Table). FIG. 4C illustrates a case in which the user designates a cell containing "3" in the first row and c column of the entity value E_t of the variable V_t. When the OK button is clicked in this state, activity Act(2) is set, which acquires the value in the first row and c column of the data (entity data) acquired as the entity value E_t of the variable V_t as the entity value E_v1 of the variable V_v1 ( FIG. 4D ). Once activity Act(2) is set in this manner, the scenario creation unit 33 sends a scenario execution instruction Cg to the execution unit 35, which instructs the execution unit 35 to execute the activity Act(2). The execution unit 35 then executes activity Act(2), thereby acquiring the entity value E_v1 of the variable V_v1. While the present embodiment displays the entity value E_t of the variable V_t, the entity value E_t may be displayed in accordance with the type accepted by the input field 52. For example, in this embodiment, activity Act(2) is an activity that extracts a value, and input field 52 accepts input that extracts the value contained in variable V_t, so the entity value E_t is displayed to make it easier for the user to specify the source of extraction within variable V_t. If activity Act(2) is an activity that outputs the data obtained as the entity value E_t of variable V_t to an arbitrary file without any special processing, input in input field 52 only needs to correctly specify the data to be output, and it is not necessarily necessary to check the entity value E_t. In this way, the configuration may be such that whether or not the entity value E_t is displayed, and if it is displayed, the display format changes depending on what is accepted by input field 52.

In Figure 4E, in addition to activities Act(1) and Act(2), activity Act(3), which sends an email, is selected as an activity Act that constitutes the scenario. In the example shown in Figure 4E, an email address and a reference destination for attached data are specified as variables, and the user sets activity Act(3) to declare each variable and send an email using the variable as an argument. In activity Act(3), variable V_v2 is declared as an email address, and the user can set the entity value E_v2 of variable V_v2 by entering it in input field 53. Furthermore, variable V_v3 is declared as the file path of the attached data, and the entity value E_v3 of variable V_v3 can be set by entering it in input field 54. In particular, as shown in Figure 4F, when the user selects (clicks) input field 54, candidate F that can be obtained as the entity value E_v3 of variable V_v3 is displayed. Specifically, the values contained in the variable V_t (table) and the variable V_v1 are displayed as candidates F. Then, when input is made into input fields 53 and 54, and the entity value E_v2 of variable V_v2 and the entity value E_v3 of variable V_v3 are set, the entity values E_v2 and E_v3 are acquired, and activity Act(3) is set, which sends an email with the attached data indicated in the entity value E_v3 to the email address E_v2 indicated in the entity value E_v2 ( FIG. 4G ). In response to this, the scenario creation unit 33 sends a scenario execution instruction Cg to the execution unit 35, which instructs the execution of activity Act(3). Then, the execution unit 35 executes activity Act(3), thereby acquiring the entity values E_v2 and E_v3 of variables V_v2 and V_v3. Note that when executing activity Act(3) in scenario creation mode, email does not need to be sent. This prevents unnecessary emails from being sent.

As mentioned above, variable management, which manages the actual value E of the acquired variable V, is executed in parallel with the execution of the scenario creation mode. Next, this variable management will be explained using Figures 5, 6, and 7. Here, Figure 5 is a block diagram showing the operation of each functional unit of the calculation unit when variable management is executed, Figure 6 is a flowchart showing an example of control executed by the execution unit for variable management, and Figure 7 is a flowchart showing an example of control executed by the monitoring unit for variable management.

As shown in Figure 5, in scenario creation mode, a first storage area R1 and a second storage area R2 are allocated in the memory unit 22.

The first storage area R1 is an area accessible by the execution unit 35. By executing an activity Act, the execution unit 35 stores the entity value E of the variable V in the first storage area R1. At this time, the entity value E stored in the first storage area R1 is referenced when the execution unit 35 executes an activity including the variable V. In other words, the entity value E stored in the first storage area R1 by executing one activity Act (e.g., activity Act(1)) is stored so that it can be referenced when another activity Act (e.g., activity Act(2)) is executed. The first storage area R1 is secured in the memory unit 22 as an area accessible by the execution unit 35 when executing a scenario, and is secured for a period corresponding to the timing when the execution unit 35 executes the scenario and is released when the period ends. In the scenario creation mode, a scenario execution instruction Cg is sent from the scenario creation unit 33 to the execution unit 35 at any time, and therefore the first storage area R1 may be secured in the memory unit 22 during the scenario creation mode. Furthermore, when the execution unit 35 executes a scenario based on a scenario execution instruction Ce sent from the scenario execution operation unit 312, a first storage area R1 may be secured in the memory unit 22 from the time the execution unit 35 starts executing the activities indicated in the scenario execution instruction Ce until the time the execution of all activities indicated in the scenario execution instruction Ce is completed.

The debugger 37 can also access the first storage area R1. As described above, the debugger 37 has a monitoring unit 371 and a holding unit 372. The monitoring unit 371 monitors whether the execution unit 35 acquires the actual value E of the variable V, i.e., whether the actual value E of the variable V is being held in the first storage area R1. The holding unit 372 then accesses the first storage area R1 and the second storage area R2 based on instructions generated by the monitoring unit 371 in response to the monitoring results, and causes the actual value E held in the first storage area R1 to be held in the second storage area R2.

The second storage area R2 is an area reserved in a predetermined area of the memory unit 22, i.e., a volatile memory element, and is an area accessible by the retention unit 372 of the debugger 37. The entity value E retained in the second storage area R2 is associated with the variable V that references the entity value E. More specifically, the second storage area R2 retains the entity value E referenced as a variable V included in an activity Act when the activity Act is executed by the execution unit 35, in association with the variable V. The second storage area R2 is reserved in the memory unit 22 as an accessible storage area by the retention unit 372, which retains the entity value E in response to the entity value E of the variable V being retained in the first storage area R1, and is therefore reserved in the memory unit 22 at least for the period during which the first storage area R1 is reserved in the memory unit 22. In addition, as described below, the second storage area R2 is also an area accessible by the editor 31, and is therefore reserved in the memory unit 22 even during periods other than those in which the first storage area R1 is reserved in the memory unit 22.

When the scenario creation mode is initiated, as shown in FIG. 6, the execution unit 35 checks whether a variable has been declared in the activity Act (step S101). If the declaration of variable V is confirmed ("YES" in step S101), the execution unit 35 allocates a first storage area R1 in the memory unit 22 for the declared variable V (step S102). Next, the execution unit 35 acquires the entity value E of the variable V in the first storage area R1 (step S103). That is, the entity value E of the variable V is stored in the first storage area R1 so that it can be referenced by the execution unit 35. The entity value E is stored in the first storage area R1 until the variable V is no longer needed. On the other hand, when the variable V is no longer needed ("YES" in step S104), the execution unit 35 releases the first storage area R1, and the entity value E is erased from the memory unit 22. A typical example of when the variable V declared in the scenario creation mode becomes unnecessary is when the user performs an operation to end the scenario creation mode and the execution unit 35 exits the scenario creation mode.

Furthermore, when the scenario creation mode is initiated, as shown in FIG. 7, the monitoring unit 371 monitors the acquisition of the entity value E of the variable V by the execution unit 35 (step S201). When it is confirmed that the execution unit 35 has acquired the entity value E of the variable V ("YES" in step S201), the monitoring unit 371 causes the holding unit 372 to execute steps S202 and S203. That is, the holding unit 372 allocates a second storage area R2 in the memory unit 22 (step S202) and copies the entity value E of the first storage area R1 to the second storage area R2 (step S203). As a result, the entity value E is associated with the variable V and held in the second storage area R2.

Figure 8 is a diagram that schematically illustrates the variable management operations performed based on the flowcharts of Figures 6 and 7. Figure 8 summarizes the above operations in chronological order. When a variable V is declared in an activity Act included in a scenario being created, the execution unit 35 allocates a first storage area R1 corresponding to the variable V in the memory unit 22 (step S102) and acquires the entity value E of the variable V in the first storage area R1 (step S103). Furthermore, upon confirming the acquisition of the entity value E, the monitoring unit 371 causes the retention unit 372 to allocate a second storage area R2 in the memory unit 22 (step S202) and copy the entity value E from the first storage area R1 to the second storage area R2 (step S203). As a result, the entity value E is associated with the variable V and stored in the second storage area R2. In step S105, the first storage area R1 is released as the variable V is no longer needed. Even after the first storage area R1 is released, the actual value E is still held in the second storage area R2.

When multiple variables V are declared in scenario creation mode, the flowcharts of FIGS. 6 and 7 are executed for each of the multiple variables V. That is, in the example shown in FIGS. 4A to 4E, the flowcharts of FIGS. 6 and 7 are executed for each of the variables V_t, V_v1, V_v2, and V_v3. As a result, the entity value E shown in FIG. 9 is stored in the memory unit 22. Here, FIG. 9 is a diagram schematically illustrating an example of an entity value stored in the memory unit. When the flowcharts of FIGS. 6 and 7 are executed for the example shown in FIGS. 4A to 4E, as shown in FIG. 9, the entity values E_t, E_v1, E_v2, and E_v3 are associated with the variables V_t, V_v1, V_v2, and V_v3 and stored in the second storage areas R2(1), R2(2), R(3), and R(4).

As explained using Figure 3, in addition to scenario creation mode, the mode selection field 43 on the scenario management screen 4 allows you to select scenario editing mode. By selecting scenario editing mode, you can edit the scenario created in scenario creation mode using the procedure described above.

Figures 10A to 10E are diagrams showing examples of operations that can be performed on the scenario management screen in scenario editing mode. In these figures, the scenario editing field 432 is expanded, while the scenario creation field 431 is contracted. Figure 11 is a block diagram showing the operation of each functional part of the calculation unit when the scenario editing mode is running.

As shown in Figure 11, in scenario editing mode, a second storage area R2 is secured in the memory unit. Figure 11 shows the operation of each functional unit of the calculation unit when transitioning to scenario editing mode after ending scenario creation mode. Compared to Figure 5, which shows the operation of each functional unit of the calculation unit in scenario creation mode, the first storage area R1 is released and disappears from the memory unit 22, while the second storage area R2 is continuously secured in the memory unit 22. The second storage area R2 is continuously secured in the memory unit 22 by the retention unit 372. As a result, the entity value E stored in association with the variable V when the execution unit 35 executes the activity Act is continuously held in the second storage area R2.

The second storage area R2 is an area accessible by the editor 31 in addition to the above-mentioned retention unit 372. The editor 31 accesses the second storage area R2 to reference the entity value E stored in association with the variable V. As shown in FIG. 11 , the editor 31 accesses the second storage area R2 without going through the execution unit 35. Therefore, the editor 31 can reference the entity value E stored in association with the variable V in parallel with the execution unit 35 executing the scenario. The editor 31 can also reference the entity value E stored in association with the variable V even outside the time when the execution unit 35 is executing the scenario. Because the second storage area R2 is accessed by the editor 31 for managing the scenario, the second storage area R2 is reserved in the memory unit 22 at least from the time the execution unit 35 starts executing the activity Act until the end of the period during which the editor 31 accepts operations for managing the scenario. In this embodiment, the second storage area R2 is allocated in the memory unit 22 when the calculation unit 21 starts executing the scenario management program 12, and is released when the calculation unit 21 finishes executing the scenario management program 12.

In scenario creation mode, operations by the user to place an activity Act in the scenario display field 45 and to edit the content of the activity Act are input to the editing operation unit 311 (Figure 11). The editing operation unit 311 then accepts operations on the scenario display field 45 and edits the scenario in accordance with those operations.

In Figure 10A, a scenario created using the scenario creation mode illustrated in Figures 4A to 4E is selected as the target for editing and is displayed in the scenario display field 45. In addition, the scenario editing field 432 displays icons indicating various activities (Act) that can be added to the scenario.

Figure 10B shows an editing operation for activity Act(2), one of the multiple activities Act(1) to Act(3) included in the scenario. Specifically, data related to obtaining the entity value E_v1 of variable V_v1 declared in activity Act(2) is being edited. In particular, when the user selects (clicks) input field 52, a candidate F that can be used as an argument in activity Act(2) is displayed.

Figure 10C shows the case where an entity value E_v1 is obtained using an argument, and a variable V_t is selected as the argument from among candidates F. That is, the scenario management screen 4 in Figure 10C displays the entity value E_t of the variable V_t selected from candidate F. That is, by selecting variable V_t from candidate F, variable V_t is designated as the display target. Because variable V_t references entity value E_t, which is a table consisting of multiple values, the display of entity value E_t displays the multiple values contained in the table. At this time, the editing operation unit 311 (Figure 11) reads out the entity value E_t stored in the second storage area R2 and displays the entity value E_t on the scenario management screen 4. This allows the execution of activity Act(1) to obtain the entity value E_t to be omitted, while the entity value E_t can be confirmed by editing activity Act(2).

On the scenario management screen 4 shown in Figure 10C, the user performs an operation to specify one of the cells in the table displayed as the entity value E_t as a value included in this entity value E_t. When the editing operation unit 311 accepts the operation to specify a cell in the table, it changes the reference of the entity value E_v1 of the variable V_v1 based on the operation. That is, instead of directly entering information indicating the reference in the input field 52, an activity is set that references a desired value from among the multiple values included in the data referenced by the variable V_t by accepting an operation on the display of the entity value E_t, which is composed of multiple values. Specifically, Figure 10D shows the case where "5" in the second row, column b is selected from among the entity values E_t of the variable V_t. In this state, when the OK button is operated (clicked), the content of activity Act(2) is changed so that the value in the second row, column b from among the multiple values constituting the entity value E_t acquired as the variable V_t is acquired as the entity value E_v1 of the variable V_v1 (Figure 10E). In this way, the data obtained as the entity value E_v1 of variable V_v1 can be changed when activity Act(2) is executed.

Figure 12 is a flowchart showing an example of variable display performed by the editing operation unit in scenario editing mode. The display of the entity value E of variable V shown in Figures 10B, 10C, and 10D above is performed according to the flowchart in Figure 12. In step S301, the editing operation unit 311 checks whether the user has specified a variable V for which display is requested. For example, when the user performs the specification operation shown in Figure 10B (operation of selecting a variable from candidates F) ("YES" in step S301), the editing operation unit 311 checks whether the entity value E of the specified variable V is stored in the second storage area R2 (step S302). If an entity value is stored ("YES" in step S302), the editing operation unit 311 displays the entity value E of the specified variable V on the display 243 (step S303), as shown in Figures 10C and 10D. Although not shown in the examples of Figures 10A to 10E, it is also possible that the entity value E of variable V is not stored in the second storage area R2 in the memory unit 22. In such a case, the editing operation unit 311 determines "NO" in step S302 and displays on the display 243 a message indicating that the entity value E of variable V does not exist (step S304). Note that in this flowchart, when a variable V is specified, it is confirmed whether the entity value E of variable V is stored in the second storage area R2. However, before the variable V is specified, it may be determined whether the entity value E associated with each variable V included in the displayed scenario is held in the second storage area R2, and a display indicating whether the entity value E is stored in the second storage area R2 is displayed.

In the embodiment described above, as an activity Act included in a scenario is executed, the execution unit 35 acquires the entity value E of the variable V referenced by the activity Act in the first storage area R1 (step S103). That is, the execution unit 35 stores the entity value E of the variable V referenced by the activity Act in the second storage area R1 so that it can be referenced when another activity Act is executed. The storage unit 372 also associates the entity value E with the variable V and stores it in the second storage area R2 accessible by the editor 31 for managing scenarios (step S203). Therefore, when managing a scenario, the user can access the entity value E of the variable V using the editor 31 without going through the execution unit 35.

Furthermore, the second storage area R2 retains the entity value E even after the first storage area R1 is released (step S105 in Figure 8). With this configuration, even after scenario creation is completed (i.e., scenario creation mode is completed) and the first storage area R1, from which the entity value E was acquired, is released, the entity value E of the variable V referenced by the activity Act included in the scenario can be read from the second storage area R2. Therefore, even after the first storage area R1 is released, the user can access the entity value E of the variable V referenced by the activity Act when managing a scenario.

An editing operation unit 311 is also provided. This editing operation unit 311 displays on the display 243 the entity value E associated with a variable V included in the scenario and stored in the second storage area R2, as a display showing the content of the operation automated by the scenario (Figures 10C and 10D). With this configuration, the user can check the entity value E of the variable V included in the scenario being managed and confirm the content of the operation automated by the scenario.

Furthermore, if there is no entity value E associated with the variable V and stored in the second storage area R2 ("NO" in step S302), the editing operation unit 311 displays this on the display 243. With this configuration, the user can easily determine whether or not there is an entity value E for the variable V included in the scenario to be managed.

The scenario creation unit 33 also includes a scenario creation unit that accepts settings for activity Acts included in the scenario and creates the activity Acts. The scenario creation unit 33 sends a scenario execution instruction Cg to the execution unit 35 based on the created activity Act. With this configuration, as an activity Act set in the scenario being created is executed, the actual value E of the variable V used in the activity Act can be acquired (step S103) and stored in the second storage area R2 (step S203). Setting an activity Act includes, for example, determining the content of the activity Act. The scenario creation unit can accept operations related to scenario creation, such as placing activity Acts in the scenario display field (setting the processing order of the created activity Acts). In this case, the scenario execution instruction Cg is not limited to being based on the created activity Act; a scenario execution instruction Cg that corresponds to the scenario creation status can also be sent.

Furthermore, when the editing operation unit 311 receives a variable designation operation (step S301) that designates a variable V to be displayed, it reads the entity value E associated with the variable V from the second storage area R2 and displays it on the display 243. In this configuration, the user can check the entity value E of the variable V by simply performing a variable designation operation on the editing operation unit 311 via the display 243.

The system also includes a monitoring unit 371 that monitors the execution unit 35's acquisition of the entity value E of the variable V in the first storage area R1, i.e., the storage of the entity value E in the first storage area R1. When the monitoring unit 371 confirms that the execution unit 35 has stored the entity value E of the variable V in the first storage area R1 (step S201), the storage unit 372 stores the entity value E in the first storage area R1 in the second storage area R2 (step S203). With this configuration, the function of the monitoring unit 371 can reliably store the entity value E of the variable V acquired by the execution unit 35 in the second storage area R2.

As shown in FIG. 5, each of the functional units 311, 312, 33, 35, 371, and 372 configured in the calculation unit 21 is realized by a separate process. Specifically, the execution unit 35 executes the activity Act as an execution unit process (first process), and the retention unit 372, as a retention process (second process) different from the execution process, associates the entity value E acquired in the first storage area R1 with the variable V and stores it in the second storage area R2. In this configuration, the execution of the activity Act and the storage of the entity value E are performed by separate processes (the execution process and the storage process). This allows the retention unit 372 to store the entity value E in the second storage area R2 in parallel with the execution of the activity Act by the execution unit 35, thereby reducing the impact on the execution of the activity Act by the execution unit 35. Therefore, the entity value E can be retained in the second storage area R2 by the retention process even after the execution process ends upon completion of the execution of the activity Act, while minimizing the impact on the execution of the activity Act by the execution unit 35. As a result, when managing a scenario, the editor 31 can access the entity value E of the variable V referenced in the scenario.

In a scenario, it is conceivable that multiple variables V may have the same name. By implementing variable name management, multiple variables V with the same name can be managed separately.

Figure 13 is a diagram illustrating the contents of variable name management. In the example of Figure 13, variables Var_a, Var_b, and Var_a are declared in order, with the first declaration being identical to the third declaration. Therefore, when associating the entity value E of each of these variables Var_a with the variable and storing it in the second storage area R2, associating the variable name itself with the entity value E would result in a name conflict. Therefore, in the variable name management described here, the monitoring unit 371 (and the storage unit 372) assigns a different identifier ID1, ID2, or ID3 to the variable V each time it is declared, associates the identifier ID1, ID2, or ID3 with the entity value E, and stores the entity value E in the second storage area R2. Identifying variable V using identifiers ID1, ID2, and ID3 in this way corresponds to identifying variable V based on its scope. The scope of variable V is the range in which variable V is valid within a scenario. Identifying variable V based on its scope distinguishes between variables with the same variable name that are valid in different scopes. Furthermore, storing the entity value E in the second storage area R2 in association with identifiers ID1, ID2, and ID3 corresponds to storing the entity value E of variable V in the second storage area R2 in association with the scope of variable V.

Figure 14 is a flowchart showing an example of variable name management performed in conjunction with the acquisition of a variable's entity value. When the execution unit 35 executes a line of an activity Act that constitutes a scenario (i.e., a line of a program that defines the activity Act) (step S401), the monitoring unit 371 checks whether the line was executed successfully (step S402). If the line fails to execute ("NO" in step S402), the flowchart in Figure 14 ends. However, if the line is executed successfully ("YES" in step S402), the monitoring unit 371 identifies the variable declaration section that declares variable V in the line executed in step S401. This corresponds to identifying the node (node in syntax analysis) that declares variable V.

In step S404, the monitoring unit 371 checks whether an identifier ID has already been assigned to the variable declaration section identified in step S403. If an identifier ID has already been assigned (if "YES" in step S404), the retention unit 372 updates the entity value E stored in the second storage area R2 in association with the identifier ID to the most recently acquired entity value E (step S405). On the other hand, if an identifier ID has not been assigned (if "NO" in step S404), the monitoring unit 371 assigns an identifier ID to the variable declaration section (step S406), and the retention unit 372 stores the entity value E of the variable V declared in the variable declaration section in association with the identifier ID in the second storage area R2.

In this way, in the example shown in Figures 13 and 14, the storage unit 372 stores the entity value E in the second storage area R2 in association with the scope of the variable V (steps S405, S406, S407). With this configuration, even if multiple variables V have the same name, the entity value E of the variable V can be identified based on the scope associated with the variable V.

In other words, the storage unit 372 associates the scope of variable V with the entity value E by associating the node that declares variable V (i.e., the variable declaration section) with the entity value E (steps S403 and S406). By using the variable declaration node in this way, the scope of variable V can be accurately associated with the entity value E.

The second storage area R2 also holds the latest entity value E obtained for the variable V (step S405). With this configuration, the entity value E in the second storage area R2 is updated each time a new entity value E is obtained, allowing the user to always check the latest entity value E.

In the above embodiment, in a scenario editing mode, which is an example in which the user manages a scenario, the entity value E of variable V is displayed on the display 243 to assist the user in their editing work. In particular, in the example of Figure 10B, when the user edits activity Act (2) related to variable V_v1, candidate arguments F are displayed on the display 243. At this time, the variable V (variable V_t in the example of Figure 10B) whose scope includes the activity Act to be edited is displayed as candidate F, and the entity value E of variable V selected from candidate F is displayed. Next, an example of control that enables such entity value display will be described.

Figure 15 is a flowchart showing an example of control for displaying entity values in scenario editing mode. In step S501, the editing operation unit 311 analyzes the syntax of the activity Act selected by the user as the activity to be edited (edit target activity Act). Then, the editing operation unit 311 obtains a scope that includes the edit target activity Act (step S502), and obtains a list of variables V that include the edit target activity Act in that scope (step S503). This corresponds to obtaining a list of variables V that can be used in the edit target activity Act.

In parallel with steps S502 and S503, the editing operation unit 311 also acquires the type of variable V at the selected location in the activity Act to be edited (step S504). Specifically, in the example of FIG. 10B, input field 52 (selected location) is selected from activity Act(2) to be edited, so the type accepted by input field 52 is acquired. Here, the type accepted by input field 52 refers to the format of data, such as numbers, characters, dates, or tables, that is handled in activity Act(2) depending on the content entered in input field 52.

In step S505, the editing operation unit 311 creates a list of variables V that have the type obtained in step S504 from among the variables obtained in step S503, and displays the list on the display 243. In this way, a candidate F such as the one shown in Figure 10B is displayed.

In step S506, the editing operation unit 311 accepts a user selection operation to select one variable V from among the candidates F. The editing operation unit 311 then acquires the identifier ID of the selected variable V and checks the entity value E associated with the identifier ID and stored in the second storage area R2 (step S507). If the entity value E exists (YES in step S508), the editing operation unit 311 displays the entity value E on the display 243 (step S509). On the other hand, if the entity value E does not exist (NO in step S508), the editing operation unit 311 displays a message on the display 243 indicating that the entity value E does not exist (step S510).

Figure 16 is a schematic diagram showing an example of the results of the control shown in Figure 15. The example in Figure 16 shows a scenario being edited (scenario editing mode) in which six activities Act(11) to Act(16), each of which declares a variable V, are executed in sequence. Of the activities Act(11) to Act(16), the type of variable V declared in five activities Act(11) and Act(13) to Act(16) is character, while the type of variable V declared in one activity Act(12) is numeric. The variable V (string3) declared in activity Act(14) is selected as the part to be edited. The variable V whose scope includes activity Act(14) is the variables string1, num1, and string2 of activities Act(11), Act(12), and Act(13). However, since the type of variable V (string3) handled by activity Act(14) is character, variables string1 and string2 that match this type are displayed as candidates F.

Now, focusing on the activity Act that declares the character variable V, in the example of Figure 16, the edit operation unit 311 displays on the display 243 the first activities Act(11), Act(13), Act(15), and Act(16) that are not to be edited and that declare the variables string1, string2, string4, and string5 (first variables), as well as the second activity Act(14) that is to be edited. In this case, of the activities Act(11), Act(13), Act(15), and Act(16) that are not to be edited, the variables string1 and string2 declared in activities Act(11) and Act(13) include the activity Act(14) that is to be edited in their scope, while the variables string4 and string5 declared in activities Act(15) and Act(16) do not include the activity Act(14) that is to be edited in their scope. In response to this, the editing operation unit 311 displays variables string1 and string2 whose scope includes the activity Act(14) as candidates F for variable V(string3) used in the activity Act(14) to be edited, but does not display variables string4 and string5 whose scope does not include the activity Act(14). With this configuration, when the user sets variable V(string3) to be referenced in the activity Act(14) to be edited, only variables V(string1, string2) that can be referenced in the activity Act(14) are displayed as candidates F. This allows the user to easily set variable V.

In scenario editing mode, it is possible to selectively execute some of the activities Act out of the multiple activities Act that make up a scenario (partial execution). In particular, in the above embodiment, the entity value E of variable V is stored in the second storage area R2. Therefore, if an activity Act that is the target of partial execution uses a variable V declared in an earlier preceding activity Act, the entity value E of that variable V can be read from the second storage area R2 and used to execute only the activity Act that is the target of partial execution, without executing the earlier activity Act. Next, an example of control that enables such partial execution will be described.

Figure 17 is a flowchart showing an example of control for partial execution in scenario editing mode. In step S601, the scenario execution operation unit 312 accepts a user operation specifying an activity Act to be partially executed. In step S602, the scenario execution operation unit 312 performs syntax analysis on the first line of the activity Act to be partially executed. Then, the scenario execution operation unit 312 obtains a list of identifier IDs (ID list) of the variable declaration sections of variable V whose scope includes the first line (step S603).

The scenario execution operation unit 312 resets the count value N for counting the identifiers ID in the ID list to zero (step S604) and increments the count value N (step S605). The scenario execution operation unit 312 then checks whether an entity value E exists in the second storage area R2 associated with the Nth identifier ID in the list (step S606). If an entity value E exists for the Nth identifier ID (YES in step S606), the scenario execution operation unit 312 generates a variable declaration activity Act that declares a variable V corresponding to the entity value E (step S607) and proceeds to step S608. On the other hand, if an entity value E does not exist for the Nth identifier ID (NO in step S606), the process skips step S607 and proceeds to step S608. In this case, the display 243 may display a message indicating that the entity value E for the identifier ID does not exist.

In step S608, the scenario execution operation unit 312 checks whether the count value N has reached the number (Nmax) of identifiers ID included in the ID list. If the count value N is less than the number Nmax ("NO" in step S608), steps S605 to S608 are repeated. On the other hand, if the count value N is the number Nmax ("YES" in step S608), the scenario execution operation unit 312 generates a partial scenario by attaching the variable declaration activity Act generated in step S607 before the activity Act to be partially executed (step S609). Furthermore, the scenario execution operation unit 312 sends a scenario execution instruction Ce to the execution unit 35 requesting execution of the generated partial scenario, and the execution unit 35 executes the partial scenario in accordance with the scenario execution instruction Ce (step S610).

In step S610, the execution unit 35 executes the activity Act to be partially executed, using the entity value E of the variable V stored in the second storage area R2. Specifically, the execution unit 35 stores the entity value E read from the second storage area R2 in the first storage area R1, and uses this entity value E to execute the activity Act to be partially executed.

In this embodiment, the variable declaration activity Act generated in step S607 is executed by the execution unit 35 to declare a variable V and obtain the entity value E of the variable V. Declaring the variable V indicates that the variable V is valid at least after the activity in which the variable V is declared, i.e., that the scope of the variable V exists after the activity. Furthermore, obtaining the entity value E of the variable V causes the entity value E to be stored in the first storage area R1 so that it can be referenced as the entity value of the variable V within the valid range of the variable V. In this embodiment, the variable declaration activity Act generated in step S607 is executed to obtain the entity value E of the declared variable V, and therefore the entity value E is stored in the first storage area R1 so that it can be referenced within the valid range of the variable V, which is at least the range after the variable declaration activity Act.

This section explains how partial execution is controlled when a user operation is received specifying activity Act(2) shown in Figure 10E as the activity Act to be partially executed.

First, in the scenario shown in FIG. 10E, activity Act(1) corresponds to an operation to obtain a value from an application other than the scenario management program 12. Activity Act(1) obtains the value obtained in this operation as the entity value E_t of variable V_t, and the entity value E_t is stored in the first storage area R1. Also, in the scenario shown in FIG. 10E, activity Act(2) corresponds to an operation to process a value and is activity Act(2) that uses variable V_t included in activity Act(1). In other words, when executed by the execution unit 35, activity Act(2) is an activity that references the entity value E_t stored in the first storage area R1 as a result of the execution of activity Act(1) as the entity value E_t of variable V_t. Note that activity Act(1) shown in FIG. 10E declares variable V_t, and therefore indicates that the scope of variable V_t is in activities subsequent to this activity, i.e., activity Act(2) and subsequent activities.

When the scenario execution operation unit 312 receives a user operation specifying activity Act(2) as the partial execution target, it generates a variable declaration activity Act that declares the variable V_t included in activity (2). The scenario execution operation unit 312 then generates a partial scenario consisting of the variable declaration activity Act that declares the generated variable V_t and activity Act(2) specified as the partial execution target, and sends a scenario execution instruction Ce to the execution unit 35 instructing the execution of the partial scenario. Therefore, when the scenario execution operation unit 312 receives a user operation that specifies activity Act(2) as the partial execution target, it sends a scenario execution instruction Ce to the execution unit 35 that selects the variable declaration activity Act of variable V_t and activity Act(2) as a scenario execution instruction Ce that specifies the activity Act corresponding to activity Act(2) as the execution target. At this time, the variable declaration activity Act that declares the variable V_t is an activity Act that acquires the entity value E_t stored in the second storage area R2, unlike activity Act(1) that acquires the entity value E_t by referencing the path entered in the input field 51. In other words, the variable declaration activity Act is an activity Act that references the entity value E_t stored in the second storage area R2 and stores the entity value E_t of the variable V_t in the first storage area R1. After storing the entity value E_t read from the second storage area R2 in the first storage area R1, the execution unit 35 references the entity value E_t stored in the first storage area R1 when executing the activity Act(2) that is the target of partial execution.

In this way, the scenario execution operation unit 312 accepts the scenario displayed in the scenario display field 45 as the scenario selected by the user, and accepts the selection of an activity Act included in the selected scenario (step S601). Furthermore, the scenario execution operation unit 312 sends a scenario execution instruction Ce to the execution unit 35, instructing the execution of an activity Act corresponding to the selected activity Act (i.e., the variable declaration activity Act and the selected activity Act). With this configuration, it is possible to partially execute an activity Act selected from multiple activities Acts included in the scenario, and check the operation of that activity Act.

In a scenario that corresponds to an operation of obtaining a value from an application other than the scenario management program 12 and includes an activity Act that obtains the entity value E of a variable V as the value, and an activity Act that uses the variable V, the activity Act that uses the variable V is an activity Act that references the entity value E stored in the first storage area R1. When an activity Act designated as a partial execution target includes an activity Act that references the entity value E stored in the first storage area R1, the scenario execution operation unit 312 generates an activity Act that references the second storage area R2 and stores the entity value E in the first storage area R1. In this configuration, the execution unit 35 can execute the activity Act designated as a partial execution target without reference to the entity value E stored in the first storage area R1. For example, if there is a difference between the entity value E held in the first storage area R1 and the entity value E held in the second storage area R2, such as the entity value E held in the first storage area R1 not being immediately reflected in the entity value E held in the second storage area R1, an activity Act can be executed that references the entity value E in the second storage area R2.

Furthermore, there may be cases where there is no entity value E stored in the first storage area R1, such as after the scenario creation mode ends and the first storage area R1 is released, and the activities Act specified as targets for partial execution include an activity Act that references the entity value E stored in the first storage area R1, but no activity Act that causes the entity value E to be stored in the first storage area R1. In this case, the execution unit 35 associates the entity value E stored in the second storage area R2 with the variable V used in the activity that references the entity value E stored in the first storage area R1 and stores it in the first storage area R1, and then executes the activity Act that references the entity value E stored in the first storage area R1. In this way, by utilizing the entity value E of the variable V stored in the second storage area R2, even when the entity value E is not stored in the first storage area R1, the activity Act that references the entity value E stored in the first storage area R1 can be partially executed without executing the activity Act that causes the entity value E to be stored in the first storage area R1, which is included in the scenario.

In this embodiment, an activity Act generated by the scenario execution operation unit 312 that references the second storage area R2 and stores the entity value E in the first storage area R1 is executed in addition to an activity Act designated as a partial execution target. However, if the activity Act designated as a partial execution target includes an activity Act that stores an entity value E in the first storage area R1, an activity Act generated by the scenario execution operation unit 312 that references the entity value E stored in the second storage area R2 and stores it in the first storage area R1 may be executed instead of the activity Act. In this configuration, an activity Act designated as a partial execution target can be executed without executing an activity Act in the scenario that stores an entity value E in the first storage area R1. If an activity Act in the scenario that stores an entity value E in the first storage area R1 is an activity that depends on the execution environment, an activity Act designated independent of the execution environment can be executed. Furthermore, if an activity Act in a scenario that causes an entity value E to be stored in the first storage area R1 is an activity that takes a long time to execute, the time required to execute the specified activity Act can be reduced. Furthermore, if an activity Act in a scenario that causes an entity value E to be stored in the first storage area R1 is an activity that has an external impact, the specified activity Act can be executed without affecting the external impact.

As explained above, in this embodiment, the storage unit 111 of the server 11 corresponds to an example of a "recording medium" of the present invention, the scenario management program 12 corresponds to an example of a "scenario management program" of the present invention, the terminal device 2 corresponds to an example of a "scenario management device" and "computer" of the present invention, the display 243 corresponds to an example of a "display" of the present invention, the editor 31 corresponds to an example of a "management unit" of the present invention, the scenario creation unit 33 corresponds to an example of a "scenario creation unit" of the present invention, the execution unit 35 corresponds to an example of an "execution unit" of the present invention, the monitoring unit 371 corresponds to an example of a "monitoring unit" of the present invention, the storage unit 372 corresponds to an example of a "storage unit" of the present invention, the activity Act corresponds to an example of an "activity" of the present invention, the scenario execution instruction Cg corresponds to an example of a "scenario execution instruction" of the present invention, the first storage area R1 corresponds to an example of a "first storage area" of the present invention, and the second storage area R2 corresponds to an example of a "second storage area" of the present invention.

The present invention is not limited to the above embodiment, and various modifications can be made to the above without departing from the spirit of the invention. For example, the timing at which the entity value E of variable V is stored in the second storage area R2 is not limited to when the scenario creation mode is executed, and may be changed. That is, in the above embodiment, the entity value E acquired in the first storage area R1 when the execution unit 35 executes an activity Act in the scenario creation mode is stored in the second storage area R2. However, the entity value E of variable V may be changed so that it is stored in the second storage area R2 after the scenario creation mode ends and before the scenario editing mode begins. In this modified example, a scenario execution instruction Ce instructing execution of a created scenario is sent from the scenario execution operation unit 312 to the execution unit 35, and the entity value E acquired in the first storage area R1 by executing the activity Act of the scenario is stored in the second storage area R2 by the storage unit 372.

In other words, the scenario execution operation unit 312 accepts a scenario execution operation from the user indicating execution of a created scenario, and sends a scenario execution instruction Ce to the execution unit 35 based on the accepted scenario execution operation. In this configuration, by executing a created scenario, the user can obtain the entity value E of the variable V used in the activity Act included in the scenario and store it in the second storage area R2. Then, in scenario editing mode, the entity value E read from the second storage area R2 can be confirmed on the display 243.

The specific configuration of the second storage area R2 that stores the actual value E of the variable V can be changed as appropriate. Therefore, the second storage area R2 may be allocated in the storage unit 23 instead of the memory unit 22, and the actual value E of the variable V may be stored in the second storage area R2 in a non-volatile manner. In other words, the second storage area R2 may be a non-volatile memory element.

Furthermore, it is not necessary for the execution of activity Act and the storage of entity value E to be performed in separate processes (execution process and storage process). Therefore, the storage unit 372 may associate the entity value E acquired in the first storage area R1 with the variable V and store it in the second storage area R2 in the same process as the execution process in which the execution unit 35 executes activity Act. In such a configuration, for example, in FIG. 5, the execution unit 35 and storage unit 372 are realized by a single functional block, which releases the first storage area R1 when variable V is no longer needed and also secures the second storage area R2 even after the first storage area R1 is released.

Similarly, each functional block (Figure 5) configured in the calculation unit 21 does not need to be executed in a separate process. Therefore, the editor 31 and the execution unit 35 may be executed in the same process rather than in separate processes. Alternatively, conversely, one functional block may be divided into multiple blocks. For example, the editor 31 does not need to have the function of accepting user operations on the UI 24, and this function may be separated from the editor 31 and carried out by another module.

Furthermore, it is not necessary to configure all of the functional blocks 31, 33, 35, and 37 in Figure 5 in the calculation unit 21 of the terminal device 2; some of the functional blocks (e.g., execution unit 35, etc.) may be configured in the processor of the server 11. In this case, the terminal device 2 and the server 11 work together to function as the "scenario management device" of the present invention.

This invention can be applied to RPA technology in general, which aims to reduce the workload of users by automating tasks that users previously performed using computers.

11... Server 111... Storage unit (recording medium)
12...Scenario management program 2...Terminal device (scenario management device, computer)
243: Display 311: Editing operation section 33: Scenario creation section 35: Execution section 371: Monitoring section 372: Storage section Act: Activity Cg: Scenario execution instruction R1: First storage area R2: Second storage area

Claims (17)

A scenario management device that manages scenarios for automating operations on other application programs,
a management unit that manages the scenario, which includes a first activity and a second activity selected from a plurality of types of activities including an activity corresponding to the operation of acquiring a value from another application program, an activity corresponding to the operation of inputting a value into another application program, and an activity corresponding to an operation of processing the acquired value;
an execution unit that executes the first activity included in the scenario based on a scenario execution instruction;
a first storage area that is accessed by the execution unit when executing the first activity included in the scenario, and that holds entity values of variables referenced in the first activity so that the entity values of variables included in the second activity included in the scenario can be referenced;
a second storage area accessible by the management unit, which stores the actual values of the variables stored in the first storage area in association with the variables;
a storage unit that stores the actual values of the variables stored in the first storage area in the second storage area;
A scenario management device comprising: the execution unit executes the first activity as a first process;
The scenario management device of claim 1, wherein the storage unit stores the actual value acquired in the first storage area in association with the variable in the second storage area as a second process different from the first process. A scenario management device as described in claim 1 or 2, wherein the second storage area retains the actual value even after the first storage area is released. The scenario management device described in any one of claims 1 to 3, wherein the management unit displays on a display, as a display indicating the content of the operation automated by the scenario, a display corresponding to the actual value associated with the variable included in the scenario and stored in the second storage area. The scenario management device of claim 4, wherein the management unit displays the entity value stored in the second storage area on the display as an indication of the variable corresponding to the entity value. The scenario management device of claim 4 or 5, wherein the management unit displays on the display, as the display of the variable corresponding to the entity value, a display indicating whether or not the entity value is associated with the variable and stored in the second storage area. a scenario creation unit that receives settings related to the content of the operation to be automated by the activity as the creation of the scenario, and generates the activity based on the settings;
The scenario management device according to claim 1 , wherein the scenario creation unit sends the scenario execution instruction to the execution unit based on the generated activity. A scenario management device according to any one of claims 1 to 7, comprising a scenario execution operation unit that receives, from a user, a selection of an activity included in the scenario as an operation instructing execution of a scenario, and sends to the execution unit the scenario execution instruction to execute an activity corresponding to the selected activity. A scenario management device according to any one of claims 1 to 8, wherein the storage unit stores the actual value of the variable in the second storage area in association with information indicating the scope, which is the range within which the variable is valid in the scenario. the first activity corresponds to an operation of acquiring a value from the other application program, and is an activity that references the acquired value as an entity value of the variable;
the second activity is an activity that uses the variable included in the first activity,
When the execution unit receives an instruction to execute the scenario including the second activity,
A scenario management device described in any one of claims 1 to 9, wherein the execution unit retrieves the entity value stored in the second storage area associated with the variable used in the second activity into the first storage area, and then executes the second activity. The management unit
When a variable designation operation that designates the variable to be displayed is received, the entity value associated with the variable is read from the second storage area and displayed on the display;
When the variable is a variable that refers to the entity value that is composed of multiple values,
expressing the plurality of values as the entity values;
A scenario management device as described in any one of claims 4 to 6, wherein when an operation specifying an arbitrary value from the plurality of values is received, the activity corresponding to an operation of obtaining a value contained in the data referenced as the variable is set based on the operation. the management unit displays the scenario on the display, the scenario including the first activity that declares a first variable and the second activity;
A scenario management device as described in any one of claims 4 to 6, wherein the management unit displays the first variable declared in the first activity on the display as a candidate variable to be used in the second activity when the scope, which is the valid range of the first variable declared in the first activity, includes the second activity, and does not display the first variable declared in the first activity on the display as a candidate variable to be used in the second activity when the scope of the variable declared in the first activity does not include the second activity. a monitoring unit that monitors the execution unit storing the actual value of the variable in the first storage area,
A scenario management device as described in any one of claims 1 to 12, wherein when the monitoring unit confirms that the execution unit has stored the actual value of the variable in the first storage area, the storage unit stores the actual value stored in the first storage area in the second storage area. A scenario management device according to any one of claims 1 to 13, wherein when the execution unit executes the first activity and the first storage area stores, as the entity value of the variable referenced in the first activity, an entity value that differs from the entity value stored in the second storage area in association with the variable, the second storage area stores, in association with the variable, the most recent entity value stored in the first storage area as the entity value of the variable. A scenario management program that causes a computer to function as the scenario management device described in any one of claims 1 to 14. A recording medium on which the scenario management program described in claim 15 is recorded in a computer-readable manner. A computer-executable scenario management method for managing, as a scenario for automating an operation on another application program, a scenario including a first activity and a second activity selected from a plurality of types of activities including an activity corresponding to the operation of acquiring a value from another application program, an activity corresponding to the operation of inputting a value into another application program , and an activity corresponding to an operation of processing the acquired value,
a step of executing the first activity based on a scenario execution instruction, and storing the entity values of variables referenced in the first activity in a first storage area so that the entity values can be referenced as entity values of variables included in the second activity;
a step of storing the actual values of the variables stored in the first storage area in association with the variables in a second storage area accessible by a management unit that manages scenarios;
A scenario management method comprising: