WO2022190409A1

WO2022190409A1 - Node management system and node management method

Info

Publication number: WO2022190409A1
Application number: PCT/JP2021/031618
Authority: WO
Inventors: 謙太山崎
Original assignee: 株式会社日立製作所
Priority date: 2021-03-11
Filing date: 2021-08-27
Publication date: 2022-09-15
Also published as: JP2022139187A

Abstract

This node management system is capable of managing a node to be used for defining a digital service. The node management system comprises a processor. The processor of the node management system (1) executes an update acquisition program to acquire service update information. Then, the processor of the node management system (2) executes an update execution program to acquire a node update parameter for updating a node to be used for updated service execution required by the service update information, and update the node.

Description

Node management system and node management method

The present invention relates to a node management system and a node management method.

In recent years, in the development of new digital services, instead of developing everything from scratch, a service linkage system that can reduce development man-hours and improve development speed by combining and linking multiple existing digital services has attracted attention. ing. Such a system is also called iPaaS (Integration Platform as a Service), and by connecting multiple nodes representing the execution processing of each digital service on the GUI (Graphical User Interface), the cooperative processing between multiple digital services can be performed as a workflow. can be defined and executed as

A digital service generally implements a Web API (hereinafter sometimes referred to as a Web API), and the above nodes execute processing based on the specifications of the Web API. Here, the prior art document discloses a technique for generating a node based on a web API specification document.

JP 2019-144848 A

By the way, development methods such as agile development and DevOps that improve services in a shorter period than before are widely used these days, and changes in web APIs and internal processing may occur more frequently than before even for digital services. Here, as the digital service is updated, the web API of the service is changed, the authentication information is recreated, and the like, and it may be necessary to recreate the node that executes the service. However, Patent Literature 1 proposes a node creation method, but does not propose a node update method corresponding to digital service updates.

The present invention is an invention that solves such problems, and a node management system and a node management method capable of efficiently updating a node that executes a digital service when an update occurs in the digital service. intended to provide Non-Patent Literature 1 discloses a technique for defining cooperative processing between multiple digital services as a workflow by connecting multiple nodes that represent the execution processing of each digital service on the GUI as described above. is doing.

According to the first aspect of the present invention, the following node management system is provided. That is, the node management system is a node management system that manages nodes used for defining digital services. A node management system comprises a processor. The processor (1) executes an update acquisition program to obtain service update information, and (2) executes an update execution program to execute the updated service requested using the service update information. Get the node update parameters for updating the node to be used and update the node.

According to the second aspect of the present invention, the following node management method is provided. That is, the node management method is a node management method for managing nodes used for defining digital services. The node management method includes (1) acquiring service update information, (2) acquiring node update parameters for updating a node used for executing the updated service obtained from the service update information, and updating the node. Update.

According to the present invention, there is provided a node management system and a node management method capable of efficiently updating a node executing a digital service when an update occurs in the digital service. Therefore, when a digital service used by the digital service developer is updated, the iPaaS node executing the digital service can be updated efficiently.

It is the figure which showed the system configuration example of this invention. It is the figure which showed the structural example of a computer. It is the figure which showed the structural example of user information. It is the figure which showed the structural example of service information. FIG. 4 is a diagram showing a configuration example of node information; It is the figure which showed the structural example of notification information. It is the figure which showed the structural example of service cooperation program information. FIG. 4 is a diagram showing a configuration example of node update policy information; It is the figure which showed the structural example of authentication information. 10 is a flowchart showing an example of node update; 6 is a flowchart showing an example of node update execution; It is the flowchart which showed an example of service information update. FIG. 11 is a flow chart showing an example of collective node update of different service cooperation programs; FIG. FIG. 10 is a diagram showing an example of a node update notification display;

Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings. It should be noted that the content described below is one of the forms for carrying out the present invention, and does not limit application to other configurations and forms in which similar processing is possible.

The configuration of the system (node management system) of the embodiment will be described with reference to FIG. The system of the embodiment is an environment for executing a node update management system 100, a service developer computer 200 used by the service developer 20 for service development, a node generation computer 300, a service monitoring computer 400, and a service instance 510. It has an execution environment 500 and each component is connected by a network 10 .

Each component (100, 200, 300, 400, 500) can be operated by a computer equipped with a CPU, memory, hard disk, etc. The form of operation may be an operation on each physically different computer, or may be an operation in a computer unit, which is a logical division of a physical computer called a virtual server. Alternatively, the operation of each component (100, 200, 300, 400, 500) may be in units of tasks (also called processes or containers) executed on one computer or a plurality of computer clusters. Also, the network 10 may be a virtual network represented by the Internet, a local area network (LAN), a dedicated communication network, or a VLAN.

The node update management system 100 includes an update acquisition program 110, an update notification program 120, an update execution program 130, an information update program 140, a registry 150 storing node files 151, user information T110, and service information T210. , node information T310, notification information T410, service linkage program information T510 (shown as linkage tool information T510 in FIG. 1), node update policy information T610, and authentication information T710.

By executing the update acquisition program 110, the node update management system 100 can acquire update information of the service used by the service developer 20 through processing of the update notification program 420 executed by the service monitoring computer 400. can. Here, the node update management system 100 may execute an API provided by the update notification program 420 to acquire update information. Alternatively, the node update management system 100 may provide an API, and the service monitoring computer 400 may execute the API to transmit update information.

Further, the node update management system 100 determines whether updating of the node executing the service is necessary based on the service update information acquired by executing the update acquisition program 110 . When it is determined that a node needs to be updated, the node update management system 100 executes the update notification program 120 to notify the user of the service of the update content. Also, the update notification program 120 is used to implement an interface function for receiving confirmation results of update contents from the user. Note that the service developer computer 200 used by the service developer 20 (that is, the service cooperation program 210) may be the notification destination of the update content, and the e-mail address or chat room used by the service developer 20 may be Notifications of updates may be sent. Any notification means that can be confirmed by the service developer 20 may be used, and the notification destination and notification mode are not particularly limited.

By executing the update execution program 130, the node update management system 100 causes the node generation program 310 to be executed to update the nodes that need to be updated. Note that the node generation program 310 may be a single program, or may be a program for each type of the service cooperation program 210 .

By executing the information update program 140, the node update management system 100 periodically checks the update information of the services managed using the update management program 410, and updates the user information T110, the service information T210, and the node information. and T310.

A node file 151 is held in the registry 150 . For the sake of convenience, one registry 150 is provided, but a plurality may be provided for each service developer 20 . For example, if the node file 151 is JavaScript, the registry 150 may be an npm registry, or if the node file 151 is configured in another program language, it may be a registry for each program language. Furthermore, a storage that can be used via a network such as an FTP server or object storage may be used. It should be noted that there may be physical devices and wires connecting devices that are not described in this specification and drawings.

Next, with reference to FIG. 2, the configuration of elements common to each computer included in the system in this embodiment will be described. In this embodiment, the computer 1910 comprises a memory 1920, a CPU 1930, an input/output IF 1940, a storage device 1950, a NW IF 1960 (sometimes referred to as a network interface 1960), and a GPU 1970. These are internal bus Connected at 1980. In this embodiment, the program is stored in storage device 1950 , loaded into memory 1920 and executed by CPU 1930 . An operating system (OS) is loaded into the memory of all computers 1910 of the system in this embodiment and executed by the CPU 1930 . The OS is shown as OS (P1000) in FIG.

All computers 1910 may be physical computers or virtual computers operating on physical computers. Also, the storage device 1950 of each computer 1910 is not an essential element, and instead may be, for example, an external storage device or a storage service that logically provides the functions of the storage device. In the system of this embodiment, the storage unit is configured to store such programs and data. An example of the network interface 1960 included in each computer 1910 is a Network Interface Card (NIC), but other than this may be used.

The computer 1910 may be provided with a keyboard and mouse as the input/output IF 1940, or may be provided with an output device such as a display. However, the input IF 1940 is not an essential element when the computer is remotely managed via a network by means such as Secure Shell (SSH). Note that the GPU 1970 is not an essential element.

The programs and tables included in each computer may be included in the storage device 1950 provided in each computer 1910. In addition, all programs are executed by a CPU 1930 (processor) provided in each computer. However, all programs may be executed by other semiconductor devices (processors) having arithmetic functions.

It should be noted that all the programs included in the system in this embodiment may be executed by a plurality of different computers as described above, or may be executed by a single computer. Further, each program may be executed by one computer for all steps, or may be executed by a different computer for each step. In addition, the computer 1910 may include components not described in this specification and drawings, wiring connecting the components, and the like.

Next, the structure of data used by the system in this embodiment will be described with reference to FIGS. 3 to 9. FIG. First, user information will be described with reference to FIG. FIG. 3 shows a configuration example of user information.

The user information T110 includes a user ID (T101) that identifies the service developer 20 who is the user of the node update management system 100, a service ID (T102) that identifies the service used by the user, Contains a node ID (T103) that identifies a node used by the user, notification information (T104) to the user, and a service linkage program ID (T105) used by the user. .

The user ID (T101) is information for uniquely identifying the service developer 20. For example, a serial number, a user account name, or an employee ID may be used. Anything other than that is acceptable.

The service ID (T102) is information for uniquely identifying the service information being used by the user. Anything else is acceptable. A plurality of service IDs (T102) may exist for each user ID (T101).

The node ID (T103) is information for uniquely identifying the node being used by the user. For example, serial numbers or arbitrary character strings may be used. It's okay. A plurality of node IDs (T103) may exist for each user ID (T101).

The notification information ID (T104) is information for uniquely identifying notification information for each user. For example, a serial number or an arbitrary character string may be used. Anything other than A plurality of notification information IDs (T104) may exist for each user ID (T101).

The service linkage program ID (T105) is information for uniquely identifying the service linkage program 210 being used by the user. Other values may be used as long as they can be identified. A plurality of service linkage program IDs (T105) may exist for each user ID (T101).

Next, the service information will be explained with reference to FIG. FIG. 4 shows a configuration example of service information.

The service information T210 includes a service ID (T201) that identifies the service, a service name (T202) that indicates the service, a service description (T203) that describes the content of the service, and a current service version (T203) that indicates the current service version. T204), current service API (T205), previous service version (T206), and previous service API (T207).

The service ID (T201) is a value that matches the service ID (T102) of the user information T110.

The service name (T202) is set when the service developer 20 registers a service in the node update management system 100, or registers a service in the node update management system 100 via another system, and when the information update program 140 is executed. It is a value that is set when the service information is updated by , and any character string that indicates the service may be used.

The service description (T203) is provided when the service developer 20 registers a service in the node update management system 100, or registers a service in the node update management system 100 via another system, and when the information update program 140 is executed. It is a value that is set when the service information is updated by , and any character string that indicates the service description may be used.

The current service version (T204) is set when the service developer 20 registers a service in the node update management system 100, or when the service is registered in the node update management system 100 via another system. It is a value that is set when service information is updated by execution, and any number or character string indicating the current service version may be used.

The current service API (T205) is used when the service developer 20 registers a service in the node update management system 100 or registers a service in the node update management system 100 via another system. A value that is set when the service information is updated by execution. The current service API (T205) indicates endpoint information, request information, and response information for using the corresponding service. All the information may be registered as a character string as long as the information can be distinguished, or a path to a file written in a format conforming to standard specifications such as OpenAPI may be registered. .

The previous service version (T206) is set when the service developer 20 registers a service in the node update management system 100, or when the service is registered in the node update management system 100 via another system, and when the information update program 140 is This value is set when updating service information. The previous service version (T206) is a value for setting the already registered corresponding service version as the previous service version.

The previous service API (T207) is used when the service developer 20 registers a service in the node update management system 100 or registers a service in the node update management system 100 via another system. This value is set when updating service information. The previous service API (T207) is a value for setting the corresponding service API that has already been registered as the previous service API. Only one previous service version (T206) and previous service API (T207) are shown for convenience (that is, in FIG. 4, information about one service version 1.0 for one service ID (T201) is shown), multiple service versions and service APIs may be retained as historical information.

Next, node information will be described with reference to FIG. FIG. 5 shows a configuration example of node information.

The node information T310 includes a node ID (T301) for identifying a node, a service ID (T302) for identifying a service used by the node, and a user ID (T303) for identifying a user using the node. , a node version (T304) indicating the version of the corresponding node, and a service cooperation program ID (T305) identifying the service cooperation program using the corresponding node.

The node ID (T301) is a value that matches the node ID (T103) of the user information T110.

The service ID (T302) is a value that matches the service ID (T201) of the service information T210.

The user ID (T303) is a value that matches the user ID (T101) of the user information T110.

The node version (T304) is information recording the current version of the node, given when the node file 151 is generated by executing the node generation program 310.

The service linkage program ID (T305) is a value that matches the service linkage program ID (T501) of the service linkage program information T510.

Next, the notification information will be described with reference to FIG. FIG. 6 shows a configuration example of notification information.

The notification information T410 includes a notification information ID (T401) that identifies notification information, notification destination information (T402), and notification means (T403).

The notification information ID (T401) is a value that matches the notification information ID (T104) of the user information T110.

The notification destination information (T402) indicates the information of the access destination to which the information is notified when the service currently used by the user is updated and the node using the service can be updated. The access destination information may specify, for example, a Webhook URL address, an API of the notification destination system, or a telephone number or e-mail address.

The notification means (T403) is information for uniquely identifying the notification means used when notifying service updates. The notification means (T403) can specify, for example, "HTTP" as a value indicating notification to a URL, further can specify "SMS" as a value indicating notification to short mail, and can specify "SMS" as a value indicating notification to e-mail. Although "EMAIL" can be specified as a value indicating the notification, it is not limited to this, and other values may be used as long as they can uniquely identify means for notification.

Next, the service linkage program information will be described with reference to FIG. FIG. 7 shows a configuration example of service cooperation program information.

The service linkage program information T510 includes a service linkage program ID (T501) that identifies the service linkage program, a service linkage program name (T502), a service linkage program version (T503), a node update means (T504), and a node storage location (T505);

The service linkage program ID (T501) is a value that matches the service linkage program ID (T105) of the user information T110.

The service linkage program name (T502) is entered when the service developer 20 registers the service linkage program 210 in the node update management system 100, or registers the service linkage program 210 in the node update management system 100 via another system. , and any character string indicating the service cooperation program 210 may be used.

The service linkage program version (T503) is set when the service developer 20 registers the service linkage program 210 in the node update management system 100, or when the service linkage program 210 is registered in the node update management system 100 via another system. , and any character string indicating the current version of the service cooperation program 210 may be used. Even with the same service cooperation program 210, different versions of the service cooperation program 210 may be used by different users. Therefore, as shown in service linkage program IDs "i001" and "i003" in FIG. 7, different service linkage program versions may be set for the same service linkage program name.

When the service developer 20 registers the service cooperation program 210 in the node update management system 100 or registers the service cooperation program 210 in the node update management system 100 via another system, the node update means (T504) , is a value to be set, and any character string indicating means for updating or generating a node of the corresponding service cooperation program 210 may be used. In this specification, the node update means may be called a node update parameter. For example, path information indicating the position of the node generation program 310 arranged in the node generation computer 300 may be set in the node update means, or a node generation web site that the node generation computer 300 opens to the public. API information may be set.

The node storage location (T505) is set when the service developer 20 registers the service linkage program 210 in the node update management system 100, or when the service linkage program 210 is registered in the node update management system 100 via another system. , is the value to be set, and any character string indicating the node storage location can be used. As the node storage location, the registry 150 of the node update management system 100 may be set, a registry independently prepared by the service developer 20, or a registry shared among a plurality of service developers. Alternatively, a registry owned by the service developer's computer 200 or the service cooperation program 210 may be set.

Next, the node update policy information will be described with reference to FIG. FIG. 8 shows a configuration example of node update policy information.

The node update policy information T610 includes a user ID (T601) that identifies a service developer who is a user of the node update management system, a service cooperation program ID (T602) that identifies a service cooperation program, and a policy (T603). ,including.

The user ID (T601) is a value that matches the user ID (T101) of the user information T110.

The service linkage program ID (T602) is a value that matches the service linkage program ID (T105) of the user information T110.

The policy (T603) is information indicating the policy for the node file 151 updated or generated based on the node update means (T504). The policy (T603) is set when the service developer 20 registers the service cooperation program 210 in the node update management system 100 or registers the service cooperation program 210 in the node update management system 100 via another system. It is information that is In the policy (T603), for example, information on permission/non-permission to share the updated or generated node file 151 with other service developers 20 may be set.

Next, the authentication information will be explained with reference to FIG. FIG. 9 shows a configuration example of authentication information.

The authentication information T710 includes a user ID (T701) that identifies the service developer 20 who is the user of the node update management system 100, a service ID (T702) that identifies the service used by the user, and an authentication information (T703);

The user ID (T701) is a value that matches the user ID (T101) of the user information T110.

The service ID (T702) is a value that matches the service ID (T102) of the user information T110.

The authentication information (T703) is authentication information for using the service of the service ID (T702). The authentication information (T703) is used when the service developer 20 registers a service in the node update management system 100 or registers a service in the node update management system 100 via another system, and when the information update program 140 is executed. This value is set when the service information is updated by The authentication information (T703) may be, for example, data obtained by encrypting a pair of user name and password, data obtained by encrypting access token information, or path information to a file storing authentication information. When the authentication information is not set, for example, a character string such as "-" or a blank character may be set, or a character string indicating that the authentication information has not been set may be set.

Next, an example of the processing flow when updating a node will be described with reference to FIG. FIG. 10 is a flow chart showing an example of the steps in which the node update management system 100 updates the node using the service when the service used by the service developer 20 is updated. Note that, as described above, the subject of program processing is the processor.

The node update management system 100 is on standby to process each program (S100).

After that, service update information is acquired by executing the update acquisition program 110 (S101). Service update information may be acquired by executing the update acquisition program 110 when the service information T210 is updated by executing the information update program 140, or the service developer 20 may acquire the update acquisition program 110 at any timing. The service information T210 may be obtained by executing Note that the processing of the information update program 140 will be described later in detail. Further, by executing the update acquisition program 110, the acquired service information T210 is recorded in the memory or output to a file. done.

Then, by executing the update acquisition program 110, the information acquired last time and the information acquired this time in step S101 are collated, and the updated service is determined (S102). This determination may be, for example, a determination based on comparison of the current service version (T204) or a determination based on comparison of the current service API (T205). Then, by executing the update acquisition program 110, after the service in which the update has occurred is determined, the service ID (T201) of the corresponding service is acquired, and the user information T110 is referenced to include the service ID of the corresponding service. A user ID (T101) is acquired.

Next, by executing the update notification program 120, the corresponding user indicated by each user ID (T101) acquired in step S102 is notified that the service has been updated and that the node using the service can be updated. It is notified that there is (S103, S104). To explain the details of this notification process, first, by executing the update notification program 120, the notification information ID (T104) of the user information T110 of the corresponding user is acquired. Next, by executing the update notification program 120, the corresponding notification information ID (T401) of the notification information (T410) is referenced, the notification destination information (T402) and notification means (T403) are acquired, and the above is sent (notified).

When the notification destination is the user's service cooperation program 210 (that is, when the notification destination is the service developer's computer 200), as a form of notification, for example, as shown in FIG. A method of displaying the content 220 is conceivable. Also, a method of displaying a sign 230 indicating that there is an update for a node that uses the service to be updated is conceivable. Here, data used for display is generated by executing an appropriate program. Moreover, the display method is not limited to these, and other display modes may be realized by utilizing the display function of the service cooperation program 210 .

After notifying the relevant user, the update notification program 120 is executed so that the node update management system 100 waits to receive a response from the relevant user. Then, when a response to reject the update of the node is received from the corresponding user, the process of step S105 is skipped and the process of step S106 is performed.

On the other hand, if a reply that the node can be updated is received from the corresponding user, the update acquisition program 110 is executed to call the update execution program 130, and the node is updated (S105). Note that the node update processing will be described later in detail using other flowcharts.

Then, if the applicable user still remains, the next applicable user is acquired and the process continues (S103, S106). After step S106 (that is, when there are no more applicable users left), the process proceeds to step S107 and the node update flowchart ends.

Next, the node update processing will be described in detail with reference to FIG. FIG. 11 is a flow chart showing an example of a process of updating a node by executing the update execution program 130. As shown in FIG. Note that, as described above, the subject of program processing is the processor.

In step S105 of the node update flowchart of FIG. 10, when the update execution program 130 is called by executing the update acquisition program 110, the process proceeds from step S105 to step S200, and step S201 is performed. In this step, the user information T110 is referred to by executing the update execution program 130, and the service cooperation program ID (T105) of the user is obtained (S201).

Next, by executing the update execution program 130, the service cooperation program information T510 is referenced, and the node update means (T504) of the corresponding service cooperation program ID (T501) is acquired (S202).

Also, by executing the update execution program 130, the authentication information T710 is referred to, and the authentication information (T703) of the corresponding service used by the corresponding user is acquired (S203). If the authentication information (T703) cannot be found, or if the content is a character string such as a blank character or "-" indicating that information does not exist, the authentication information is not acquired by executing the update execution program 130. .

Then, by executing the update execution program 130, the node generation program 310 is executed, and node generation is executed using the node update means (T504) acquired in S202 (S204). If the authentication information (T703) has been acquired in step S203, the authentication information may be included when the node is generated.

Next, by executing the update execution program 130, the node update policy information T610 is referred to, and the policy (T603) matching the corresponding user ID (T601) and service cooperation program ID (T602) is obtained (S205). .

Then, by executing the update execution program 130, the service cooperation program information T510 is referred to, and the node storage location (T505) of the corresponding service cooperation program ID (T501) is acquired (S206). Here, if multiple node storage locations (T505) are set, the node storage location (T505) may be selected based on the previously acquired policy (T603). For example, when the user ID "user001" uses the service linkage program ID "i001", the policy is "sharable", so "shared registry 1" can be selected as the node storage location.

Next, by executing the update execution program 130, the node generated in step S204 is stored in the node storage location selected in step S206 (S207). Then, the update notification program 120 is used to notify the user that the update of the user's node has been completed through node generation. Here, notification information (T410) is used for notification to the user (S208).

After that, the node update execution flowchart ends by proceeding to step S209 after step S208 and proceeding to S106 of the node update flowchart.

Next, an example of processing for updating service information by executing the information update program 140 will be described. FIG. 12 is a flow chart showing an example of processing for updating service information by the information update program 140 . Note that, as described above, the subject of program processing is the processor.

The node update management system 100 is on standby to process the information update program 140 (S300). That is, step S300 is a state of waiting for receiving information and executing processing.

By executing the information update program 140, the service update information received from the service monitoring computer 400 is obtained (S301). Here, the service update information is transmitted by executing the update notification program 420 . By executing the information update program 140, the service update information is analyzed, and the service name (T202), the service description (T203), the current service version (T204), and the current service API (T205) in the service information T210 are analyzed. is obtained.

Further, by executing the information update program 140, the service monitoring computer 400 is inquired about the service update information, and the service update information managed by the service monitoring computer 400 by executing the update management program 410 is acquired (S302). . Acquisition of service update information may be via an API by publishing the update management program 410 . Alternatively, a file output by executing the update management program 410 may be acquired, and service update information may be acquired. The acquisition method of the service update information is not particularly limited as long as the service update information can be acquired appropriately, and other acquisition methods may be used.

Then, by executing the information update program 140, the service information T210 is referred to, information matching the service name (T202) is obtained, and the current service version (T204) and current service API (T205) are updated in step S301 and step S302. It is checked whether there is any difference from the service update information acquired in (S303). Here, if there is a difference, the current service version (T204) and current service API (T205) of the current service information T210 are copied to the previous service version (T206) and previous service API (T207), and the service update information By setting values in the current service version (T204) and current service API (T205), the information in the service information T210 is updated.

After step S303, the process proceeds to step S304, and the service information update flowchart ends.

Next, a method for updating nodes with a processing flow different from the processing flow shown in FIG. 10 will be described. FIG. 13 is a flow chart showing an example of the steps in which the node update management system 100 updates the node using the service when the service used by the service developer 20 is updated. In the flowchart of FIG. 10, the node update process is executed starting from the user information, but in FIG. is the difference. Note that, as described above, the subject of program processing is the processor.

First, each program of the node update management system 100 waits for processing execution (S400).

Next, service update information is acquired by executing the update acquisition program 110 (S401). Since this process is the same as S101, the description is omitted.

Then, by executing the update acquisition program 110, the information acquired last time and the information acquired this time in step S101 are collated, and the updated service is determined (S403). Since this process is the same as S102, the description is omitted.

After determining which service has been updated, the update acquisition program 110 is executed to acquire the service ID (T201) of the corresponding service. Then, the user information T110 is referenced, and the user ID (T101) including the corresponding service ID is obtained (S404).

Next, by executing the update acquisition program 110, the corresponding user indicated by each user ID (T101) is notified that the service has been updated and that the node using the service can be updated. (S405). This process is a process performed using the update notification program 120 and is the same as step S104, so a description thereof will be omitted.

When a response is received from the user that the node can be updated, the update acquisition program 110 is executed, the update execution program 130 is called, and the node is updated (S406). Since this process is the same as step S105, description thereof is omitted.

Then, if the corresponding service still remains, the next service information is acquired and the process continues (S402, S407). After step S407 (that is, if there are no more services remaining), the process proceeds to step S408 and the node update flowchart ends.

As shown in FIG. 13, by performing the process of specifying the relevant user for each service, it is possible to collectively notify the user for each service. Therefore, it is possible to flexibly cope with a situation in which there are many updated services, and it is possible to perform efficient notification.

As described above, with the configuration and means of the embodiment, the service developer 20 who is the user of the node update management system 100 can update the node used by the service cooperation program 210 when the service is updated. This is expected to improve the efficiency of service development when the person 220 responds to service updates.

100 node update management system 110 update acquisition program 120 update notification program 130 update execution program 140 information update program 200 service developer computer 210 service cooperation program 300 node generation computer 400 service monitoring computer 500 execution environment

Claims

A node management system for managing nodes used to define digital services,
with a processor
The processor
(1) Execute an update acquisition program to acquire service update information,
(2) executing an update execution program to obtain a node update parameter for updating a node used to execute the updated service obtained from the service update information, and update the node;
A node management system characterized by:
A node management system according to claim 1,
The processor
Before updating the node, an update notification program is executed to notify the user to select permission/non-permission of the update of the node;
A node management system characterized by:
A node management system according to claim 2,
The processor
Execute the update notification program to perform notification to display a screen for selecting permission/non-permission of update of the node;
A node management system characterized by:
A node management system according to claim 3,
The processor
Execute the update notification program to notify by displaying information indicating the updated service.
A node management system characterized by:
A node management system according to claim 1,
Equipped with a storage unit,
The storage unit
storing information that associates information identifying a user with information identifying a service used by the user;
The processor
identifying a user of a service executed by a node to be updated using the information by executing the update acquisition program;
Before updating the node, an update notification program is executed to notify the user to select permission/non-permission of update of the node.
A node management system characterized by:
A node management system according to claim 5,
The processor
In executing the update acquisition program, identifying a user of the updated service for each service,
In the execution of the update notification program, notifying the user collectively for each service;
A node management system characterized by:
A node management system according to claim 1,
The processor
In executing the update acquisition program, update information of the service is acquired based on information acquired from a service monitoring computer that monitors the service;
A node management system characterized by:
A node management method for managing nodes used to define a digital service,
(1) to obtain service update information;
(2) obtaining a node update parameter for updating the node used for executing the updated service obtained from the service update information, and updating the node;
A node management method characterized by:
A node management method according to claim 8,
before updating the node, notifying the user to select permission/non-permission to update the node;
A node management method characterized by:
A node management method according to claim 9,
Notifying to display a screen for selecting permission/non-permission of update of the node;
A node management method characterized by:
A node management method according to claim 10,
Notifying by display with information indicating the updated service;
A node management method characterized by:
A node management method according to claim 8,
identifying a user of a service executed by a node to be updated using information that associates information identifying a user with information identifying a service used by the user;
before updating the node, notifying the user to select permission/non-permission of updating the node;
A node management method characterized by:
A node management method according to claim 12,
When identifying the users of the services executed by the node to be updated, identify the users on a service-by-service basis,
When notifying the user to select permission/non-permission of update of the node, collectively notifying the user for each service;
A node management method characterized by:
A node management method according to claim 8,
obtaining update information of the service based on information obtained from a service monitoring computer that monitors the service;
A node management method characterized by:
A program for causing a computer to execute the node management method according to claim 8.