JP7316240B2 - Program update management system, program update management method, and program update management program - Google Patents

Description

The present invention relates to technology for managing program updates.

In recent years, application (program) development utilizing a Web API (Application Programming Interface) of a service provided by a third party has become common. Application developers can easily add new functions to their own applications by utilizing the functions of services provided by third parties via Web API, that is, the functions of programs that implement services.

Since there are many third parties that provide web APIs for services and programs for those services, marketplaces that collect and register them and present them to application developers like catalogs have become popular. ing.

By selecting and starting to use a plurality of services registered in the marketplace, an application developer can use a plurality of functions required for the application to be developed via the Web API provided by the services.

Programs that implement services registered in the marketplace are updated independently of each other, so application developers can update service programs that they themselves use and Web APIs for using those programs. Therefore, it may be necessary to check whether the quality of the application is affected.

For example, Patent Literatures 1 and 2 disclose techniques for automating change detection and compatibility verification by periodically monitoring input/output data and performance of Web APIs.

JP 2011-257994 A JP 2019-117465 A

By the way, in recent years, there has been a vigorous movement toward automating the test process during application development, and for example, CI/CD (Continuous Integration/Continuous Deployment) tools are being adopted. Normally, the application development process is standardized and specified so that it can be applied to various applications, thereby making the development process more efficient, and the test process is no exception.

For this reason, as in Patent Documents 1 and 2, if update detection and verification are performed independently of the existing development process for program updates in services, the application quality will change without the application developer noticing. there is concern that

SUMMARY OF THE INVENTION The present invention has been made in view of the above circumstances, and its object is to enable developers to easily and appropriately grasp program updates that may affect programs developed by developers. is to provide

To achieve the above object, a program update management system according to one aspect is a program update management system for managing program updates, the program update management system having a processor unit, the processor unit comprising the Acquiring notification document content information specifying the content of a notification document when the program is updated from a user of the program, determining whether or not the program has been updated, and determining whether the program has been updated. Sometimes, based on the notification document content information, a notification document for notifying the update of the program is created and sent to the user of the program.

According to the present invention, it is possible for a developer to easily and appropriately grasp update of a program that may affect the program developed by the developer.

FIG. 1 is an overall configuration diagram of a computer system according to one embodiment. FIG. 2 is a hardware configuration diagram of a computer according to one embodiment. FIG. 3 is a configuration diagram of user information according to one embodiment. FIG. 4 is a configuration diagram of service list information according to one embodiment. FIG. 5 is a configuration diagram of service information according to one embodiment. FIG. 6 is a configuration diagram of instance information according to one embodiment. FIG. 7 is a configuration diagram of notification management information according to one embodiment. FIG. 8 is a configuration diagram of notification document content information according to one embodiment. FIG. 9 is a flowchart of service deployment processing according to one embodiment. FIG. 10 is a flowchart of service update processing according to one embodiment. FIG. 11 is a flowchart of service update analysis processing according to one embodiment. FIG. 12 is a flowchart of service update notification processing according to one embodiment.

Embodiments will be described with reference to the drawings. It should be noted that the embodiments described below do not limit the invention according to the scope of claims, and that all of the elements described in the embodiments and their combinations are essential to the solution of the invention. is not limited.

In the following description, various types of information may be described as, for example, a table format data structure, but the information may be expressed in any data structure.

Also, in the following description, a "processor unit" includes one or more processors. The at least one processor is typically a microprocessor such as a CPU (Central Processing Unit). Each of the one or more processors may be single-core or multi-core. A processor may include hardware circuitry that performs some or all of the processing.

In the following explanation, the processing may be explained with the "program" as the main body of operation, but the program is executed by the processor unit (CPU etc.), and the determined processing is appropriately performed by the storage resource ( memory, storage device, etc.) and an interface unit, the subject of processing may be the processor unit (or a computer or computer system having a processor unit).

FIG. 1 is an overall configuration diagram of a computer system according to one embodiment.

The computer system includes a marketplace system 100 as an example of a program update management system, a computer 200 used by a service developer 20 for service development, etc., a computer 300 used by an application (program) developer 30 for development, etc. and an execution server 400 . Marketplace system 100 , computer 200 , computer 300 and execution server 400 are connected via network 10 .

The network 10 may be a virtual network represented by the Internet, a local area network (LAN), a dedicated communication network, or a VLAN (Virtual LAN).

The marketplace system 100, the computer 200, the computer 300, and the execution server 400 may each be composed of one or more computers equipped with a processor (CPU), memory, hard disk, etc., and logically one or more physical computers. It may be composed of divided virtual computers, or may be composed of tasks (also called processes or containers) configured on a cluster of one or more physical computers.

The marketplace system 100 includes a screen program 110, a deploy program 120, an update analysis program 130, an update notification program 140, a template engine 160, a registry 150, user information T110, service list information T210, service It comprises information T310, instance information T410, notification management information T510, and notification document content information T610. User information T110, service list information T210, service information T310, instance information T410, notification management information T510, and notification document content information T610 will be described later.

The registry 150 holds service images 151 . The service image 151 includes a VM (Virtual Machine) image and a program that implements the service. In FIG. 1, for the sake of convenience, the marketplace system 100 has one registry 150, but there may be multiple as long as they are associated with the service information T310. The registry 150 is, for example, a container registry represented by Docker Registry when all images are container images, and various registries having a function of distributing binaries when the images are binary. Note that if different types of images (for example, binaries and containers) coexist, a plurality of different types of registries 150 may be used. The registry 150 may be storage that can be used via the network 10, such as object storage.

The screen program 110 (strictly speaking, the processor (for example, the CPU 1930 (see FIG. 2)) that executes the screen program 110 sends the service information registered in the marketplace system 100 to the computer 300 of the application developer 30. T310 is displayed, and a service usage start request from the application developer 30 is received from the computer 300 . The screen program 110 also extracts service information currently used by the application developer 30 from the user information T110 and displays it on the computer 300. FIG. The screen program 110 also displays service information T310 registered by the service developer 20 in the marketplace system 100 on the computer 200 of the service developer 20, and information for registering service update information. to display.

The screen program 110 may have an API, and provides the computer 300 of the application developer 30 with the service information T310 registered in the marketplace system 100 via the API, or requests to start using the service via the API. You may receive it via Further, the screen program 110 may extract service information being used by the application developer 30 from the user information T110 and provide it to the computer 300 via API. Further, the screen program 110 provides service information T310 registered in the marketplace system 100 by the service developer 20 via the API to the computer 200 of the service developer 20, and updates service update information via the API. You can register with

The deploy program 120 (strictly speaking, the processor (for example, the CPU 1930 (see FIG. 2) that executes the deploy program 120) analyzes the use start request passed from the computer 300 of the application developer 30, and responds to the use start request. The service image 151 of the corresponding service is searched from the registry 150 and the obtained service image 151 is deployed to the execution server 400 . The process (deployment process) in which the deploy program 120 deploys the service image 151 may use existing technology. For example, when using a container image, Docker (registered trademark) or Kubernetes (registered trademark) may be used. Alternatively, when using a virtual machine image, OpenStack (registered trademark) or the like may be used. According to the deployment processing by the deployment program 120, for example, when the service image 151 includes a VM image and a program that implements the service, the service instance 410 is formed on the execution server 400, the VM is configured, and the VM The service becomes executable by executing the program.

The update analysis program 130 (strictly speaking, the processor (for example, the CPU 1930 (see FIG. 2)) that executes the update analysis program 130 analyzes the service update information registered by the service developer 20 via the computer 200 .

The update notification program 140 (strictly speaking, the processor (for example, the CPU 1930 (see FIG. 2)) that executes the update notification program 140, based on the analysis result of the update analysis program 130, the user information T110, The service information T310, the notification management information T510, and the notification document content information T610 are used to generate a notification document (also referred to as an update notification document) for notifying service updates (including program updates). An update notification document is sent to the developer 30 .

Note that the destination of the update notification document, that is, the destination of the service update, is registered in advance by the application developer 30 in the notification management information T510. As a means for notifying the application developer 30 of the update notification document, for example, means for transmitting to the development management program 310 used by the application developer 30, which operates on the computer 300 of the application developer 30, may be used. It may be a means of transmitting to the test program 320 to be used, or a means of using e-mail.

Here, at least one of the screen program 110, the deploy program 120, the update analysis program 130, and the update notification program 140 is stored in a computer-readable recording medium such as a CD or DVD. , and installed in the marketplace system 100.

The template engine 160 generates a notification document according to the template of the notification document content information T610. As the template engine 160, an existing template engine such as Jinja can be used.

Computer 300 is used by application developer 30 and includes development management program 310 , test program 320 , and application program (application program) 330 .

The application program 330 is a program developed or being developed by an application developer (also referred to as an application program, application, or app). In this embodiment, the application program 330 is a program that uses the functions of the service program provided by the marketplace system 100 to execute various processes. A test program 320 is a program for testing the application program 330 . The development management program 310 is a program that manages development of the application program 330 .

Next, the configurations of the computers constituting the marketplace system 100, computer 200, computer 300, and execution server 400 will be described.

FIG. 2 is a hardware configuration diagram of a computer according to one embodiment.

The computer 1910 includes a memory 1920 , a CPU 1930 , an input/output IF (interface) 1940 , a storage device 1950 , a NW IF (network interface) 1960 and a GPU (Graphics Processing Unit) 1970 . Memory 1920 , CPU 1930 , input/output IF 1940 , storage device 1950 , NW IF 1960 and GPU 1970 are connected via internal bus 1980 . Note that the storage device 1950 is not an essential element, and instead of the storage device 1950, for example, an external storage device may be used, or a storage service that logically provides the functions of the storage device may be used. In addition, the computer 1910 may include components other than those shown in FIG. 2, wires connecting the components, and the like.

The NW IF 1960 is, for example, a NIC (Network Interface Card) such as a wired LAN card or wireless LAN card, and communicates with other devices via the network 10 .

CPU 1930 executes various processes according to programs stored in memory 1920 and/or storage device 1950 .

The memory 1920 is, for example, a RAM, and stores programs executed by the CPU 1930 and necessary information. In this embodiment, an OS (Operating System) P1000 stored in a storage device 1950 is loaded into the memory 1920 and executed by the CPU 1930 .

The storage device 1950 is, for example, a hard disk or a flash memory, and stores programs (OS P1000, etc.) executed by the CPU 1930 and data used by the CPU 1930 . The storage device 1950 of the computer 1910 constituting each of the marketplace system 100, the computer 200, the computer 300, and the execution server 400 stores programs, information, etc. of each configuration shown in FIG. All steps of each program may be executed by one computer 1910, or may be executed by different computers depending on the steps.

The input/output IF 1940 is, for example, an output device such as a display, and an input device such as a keyboard and a mouse, and receives various inputs from the user of the computer 1910 and displays and outputs various information for the user. In addition, when the computer 1910 is remotely managed via the network 10 by a means such as Secure Shell (SSH), the input IF 1940 may not be provided.

The GPU 1970 executes various image processing. Image processing may be performed by the CPU 1930 without the GPU 1970 .

Next, various information stored in the marketplace system 100 will be described.

First, the user information T110 will be explained.

FIG. 3 is a configuration diagram of user information according to one embodiment.

The user information T110 is a user who uses the service of the marketplace system 100, that is, an application developer who develops an application (program) using the function of the program that provides the service (hereinafter simply referred to as a user). ).

The user information T110 is configured in, for example, a table format and includes an entry for each user. The entry of the user information T110 includes fields (columns) of a user ID T101, a service list ID T102, and a notification management ID T103.

The user ID T101 stores an ID (user ID) for identifying the user. The user ID may be any information that uniquely identifies the user, and may be, for example, a number, the user's account name, or an employee ID.

The service list ID T102 stores an ID (service list ID) for identifying a list of services used by the user corresponding to the entry. A plurality of service list IDs may exist for one user ID.

The notification management ID T103 stores an ID (notification management ID) that identifies the content of notification management for the user corresponding to the entry. The notification management ID may be information for uniquely identifying the content of notification management for the user, and may be, for example, numbers or arbitrary character strings. A plurality of notification management IDs may exist for one user ID.

Next, the service list information T210 will be explained.

FIG. 4 is a configuration diagram of service list information according to one embodiment.

The service list information T210 is information relating to a list of services used by users of the marketplace system 100. FIG.

The service list information T210 is configured in, for example, a table format, and includes entries for each service list. The entry of the service list information T210 includes fields of service list ID T201, service ID T202, and instance ID T203.

The service list ID T201 stores an ID (service list ID) for identifying a service list. The service list ID corresponds to the value of the service list ID T102. The service ID T202 stores an ID (service ID) for uniquely identifying a service belonging to the service list corresponding to the entry. The service ID may be information for uniquely identifying the service, and may be, for example, numbers or arbitrary character strings. The instance ID T203 stores information (instance ID) for uniquely identifying the instance in the execution server 400 of the service corresponding to the entry. The instance ID may be any value that can identify the instance, and may be a number or any character string, for example.

In the service list information T210, when there are multiple services belonging to the same user's service list, there are multiple entries corresponding to the same service list ID.

Next, the service information T310 will be explained.

FIG. 5 is a configuration diagram of service information according to one embodiment.

The service information T<b>310 is information for managing various information about services in the marketplace system 100 . The service information includes a program that implements the service and information about the program such as API information for the program.

The service information T310 is configured in, for example, a table format and includes an entry for each service. The entry of service information T310 includes fields of service ID T301, service name T302, service description T303, service charge T304, service image ID T305, current service version T306, and service API T307.

A service ID for identifying a service is stored in the service ID T301. The service ID corresponds to the service ID of the service list information T210. The service name T302 stores the name of the service (service name) corresponding to the entry. The service name is set by the service developer 20, for example, when registering a new service in the marketplace system 100 or when changing the name of the service. A service name is, for example, a character string indicating a service. The service description T303 stores a description of the service corresponding to the entry. The service description is set by the service developer 20, for example, when a new service is registered in the marketplace system 100 or when the service description needs to be changed. The service description is, for example, a character string describing the content of the service.

The service usage fee T304 stores the fee required when using the service corresponding to the entry (service usage fee). The service usage fee is set by the service developer 20 when a new service is registered in the marketplace system 100 or when the service fee needs to be changed. The service image ID T305 stores information (service image ID) for uniquely identifying the service image 151 used when creating an instance of the service corresponding to the entry. The service image ID is, for example, tag information such as a path and version on the registry 150 storing the service image, or a hash value for specifying the service image 151 .

The current service version T306 stores the current version (current service version) of the program that provides the service corresponding to the entry. The current service version is set when a new service is registered in the marketplace system 100 or when a service program is updated. The current service version may be a number or a string. The service API T307 stores information of an API (for example, Web API) corresponding to a program that provides a service corresponding to the entry. The API information is set by the service developer 20, for example, when a new service is registered in the marketplace system 100 or when the API of the service program needs to be changed. API information includes, for example, endpoint information (endpoint) indicating an access destination (e.g., URL) in the API, request information (request) defining the format of requests in the API, response information defining the format of responses in the API ( response). The API information stored in the service API T307 is not limited to this, and may be, for example, a path to a file written in a format conforming to standard specifications such as OpenAPI.

It should be noted that the entry of the service information T310 may be provided with fields for storing service logos, sample codes, and the like.

Next, the instance information T410 will be explained.

FIG. 6 is a configuration diagram of instance information according to one embodiment.

The instance information T 410 is information for managing information on the service instance (also referred to as instance) 410 deployed on the execution server 400 .

The instance information T410 is configured in, for example, a table format and includes an entry for each instance. The entry of instance information T410 includes fields of instance ID T401, service ID T402, user ID T403, operating service version T404, usage start time T405, and execution environment ID T406.

The instance ID T401 stores the instance ID of the instance 410 corresponding to the entry. The instance ID corresponds to the instance ID of the instance ID T203 of the service list information T210. The service ID T402 stores the service ID of the service corresponding to the instance 410 corresponding to the entry. The service ID corresponds to the service ID of service ID T301 of service information T310.

The user ID T403 stores the user ID of the user who uses the instance 410 corresponding to the entry. The user ID corresponds to the user ID of user ID T101 of user information T110. The running service version T404 stores the program version of the service when the instance corresponding to the entry was deployed (running service version).

The use start time T405 stores the time (use start time) when the use of the instance 410 corresponding to the entry was started. The usage start time may include information such as date, day of the week, and time. The execution environment ID T406 stores information (execution environment ID) for uniquely identifying the execution environment (execution server 400) in which the instance 410 corresponding to the entry is executed. The execution environment ID may be any information that can identify the execution environment, and may be the IP address, host name, or URL of the execution server 400 that executes the instance 410, or link information to text data containing these.

Next, the notification management information T510 will be explained.

FIG. 7 is a configuration diagram of notification management information according to one embodiment.

The notification management information T510 is information for managing information regarding update notifications when updates regarding services occur.

The notification management information T510 is configured in, for example, a table format, and includes an entry for each notification management content. The entry of notification management information T510 includes fields of notification management ID T501, notification destination information T502, notification document content ID T503, and notification means T504.

The notification management ID T501 stores a notification management ID that identifies the content of notification management corresponding to the entry. The notification management ID corresponds to the notification management ID of the notification management ID T103 of the user information T110. The notification destination information T502 stores information of an access destination (notification destination information) to which a notification document is notified when an update occurs. The notification destination information may be, for example, a Webhook URL address, an API of the notification destination system, a telephone number, or an e-mail address.

The notification document content ID T503 stores information (notification document content ID) for uniquely identifying the content of the notification document. Any value that can identify the content of the notification document may be used as the notification document content ID. For example, a number or an arbitrary character string may be used. The notification means T504 stores information for uniquely specifying the notification means when sending the notification document. The information for specifying the notification means may be any value that can uniquely identify the notification means. For example, "HTTP" indicating notification to URL, "SMS" indicating notification by short mail, and It may be "EMAIL" or the like indicating the notification of.

Next, the notification document content information T610 will be described.

FIG. 8 is a configuration diagram of notification document content information according to one embodiment.

The notification document content information T610 is information about the content of the notification document, for example, the description of the notification document, the description method of the notification document, and the like. The notification document content information T610 stores an entry (template) corresponding to each notification document content. The entry of the notification document content information T610 is, for example, text information in a format that can be received and recognized by the notification recipient. The entry of the notification document content information T610 is set in advance by the user. In the example of FIG. 8, as the notification text content information T610, an entry T601 of the notification text content corresponding to the notification text content ID "ntfy-text001" and an entry T601 of the notification text content corresponding to the notification text content ID "ntfy-text004" T602 is displayed.

Entry T601 contains text information in JSON (Javascript (registered trademark) Object Notation) format. The item "message" describes "the service currently in use has been updated." The "body" item describes text information of a template that can be processed by the template engine 160 for describing a list of updated service names (corresponding to program names) in HTML list format. In the illustrated example, "service.name" is a variable item to be replaced with each updated service name. According to the entry T601, it is possible to create a notification document in a format that allows the computer 30, the development management program 310, and the test program 320 to easily recognize the content. Therefore, the notification document can be imported into the development management program 310 and the test program 320 to perform various processes, thereby improving the efficiency of the process related to the development of programs for updating services. can be done.

Entry T602 contains text information in JSON format. The item "message" describes "the service currently in use has been updated." The "body" item describes text information of a template that can be processed by the template engine 160 for sequentially listing updated service names (corresponding to program names). In the illustrated example, "service.name" is a variable item to be replaced with each updated service name. According to entry T602, it is possible to create a notification document in a format suitable for e-mail that can be easily recognized by the user.

Note that the notification document information T610 is not limited to the JSON format, and may be described in accordance with existing markup languages such as HTML and XML. Information to be included in the notification document information T610 is not limited to displaying the service name, and may be various information that can be obtained from service update information and a service update item list, which will be described later. It may be the version of the program to be implemented, API information, or the contents of other services. By doing so, it is possible to easily grasp the updated contents and/or the contents before the update from the notification document.

Next, processing operations of the marketplace system 100 according to one embodiment will be described.

First, the service deployment process will be explained.

FIG. 9 is a flowchart of service deployment processing according to one embodiment.

The service deployment process is executed when the marketplace system 100 receives a service usage start request from the application developer 30 via the computer 300 .

The screen program 110 (strictly speaking, the CPU 1930 that executes the screen program 110) receives a login request from the user (application developer 30) to the marketplace system 100 from the computer 300 (S101). It is assumed that an account (user ID, password, etc.) required for logging into the marketplace system 100 is set, for example, at the time of first use.

The screen program 100 authenticates the user, and if the authentication succeeds, causes the computer 300 to display a screen for displaying the service to be used by the user so that the user can start using the service. A selection of a service to be started is accepted (S102). Note that the screen program 110 may be provided with an API, and the screen program 110 may acquire a usage start request from the user via the API.

Next, when the screen program 110 receives a service selection from the user, it acquires an entry for the selected service from the service information T310, and extracts the service ID of this service from the service ID T301 of the acquired entry. It acquires and notifies the deployment program 120 (S103).

The notified deploy program 120 (more precisely, the CPU 1930 executing the deploy program 120) acquires the service image ID from the service image ID T305 of the entry corresponding to the service ID of the service information T310, and corresponds to the service image ID. The service image 151 to be executed is acquired from the repository 150, and this service image 151 is deployed to the execution server 400 (step S104). Here, the deployment process may use existing technology, such as Docker or Kubernetes when using a container image, or OpenStack when using a virtual machine image. . The execution server 400 to which the service image 151 is to be deployed may be arbitrarily selected by the deployment program 120 using existing resource management technology, or the user may be allowed to select the execution server 400 when selecting the service. The execution server 400 may be an execution server 400 that has

Next, the deployment program 120 determines the deployment execution result (S105). As a result, when it is determined that execution of deployment has succeeded (S105: Yes), the deployment program 120 creates an instance ID that can uniquely identify the service instance 410 of the deployed service image 151, and sets the instance information T410. to add an entry corresponding to the service instance 410, further refer to the user information T110 to acquire the service list ID of this user, and store the acquired service list ID and the service ID in the service list information T210. , and the instance ID of the generated service instance 410 (S106), and the process proceeds to step S107. On the other hand, when it is determined that execution of deploy has failed (S105: No), the deploy program 120 advances the process to step S107.

In step S107, the deployment program 120 notifies the screen program 110 of the deployment execution result, and terminates the service deployment process. The screen program 110 may display the execution result on the screen for the marketplace 100 of the computer 300, or may display it on a separate pop-up screen.

Next, service update processing will be described.

FIG. 10 is a flowchart of service update processing according to one embodiment.

The service update process is a process of updating services (including program updates) registered in the marketplace system 100 , and is performed based on an operation from the computer 200 by the service developer 20 .

First, the screen program 110 receives a login request to the marketplace system 100 by the service developer 20 from the computer 200 (S201). It is assumed that the account (service developer ID, password, etc.) of the service developer 20 required for logging into the marketplace system 100 is set, for example, at the time of first use. Further, it is assumed that the service information created by the service developer 20 is registered in the service information T310.

Next, the screen program 110 authenticates the service developer 20, and if the authentication is successful, a screen for inputting update information (service update information) about the service for which the service developer 20 registers updates. is displayed on the computer 200, and the computer 200 receives input of service update information about the service by the service developer 20 (S202). Note that the service update information may be information (values, etc.) about all of the items in the entry of the service information T310, or may be only information about items that have been updated among the items. The screen program 110 may be provided with an API, and the screen program 110 may receive service update information from the service developer 20 via the API.

Next, the screen program 110 acquires the service update information received from the service developer 20 from the computer 200 (S203). Next, the screen program 110 notifies the update analysis program 130 of the acquired service update information (S204). The update analysis program 130 that has received notification of the service update information executes service update analysis processing (see FIG. 11), which will be described later. After the service update analysis process is completed, the screen program 110 may reflect (register) the service update information in the entry of the corresponding service in the service information T310.

Next, the screen program 110 notifies the service developer 20 by displaying the completion of service update registration on the screen for the marketplace system 100 of the computer 200 (S205), and terminates the process. When the service developer 20 notifies the service update information via the API of the screen program 110, the service update registration completion is included in the response information of the API.

Next, service update analysis processing will be described.

FIG. 11 is a flowchart of service update analysis processing according to one embodiment.

The service update analysis process is executed when the update analysis program 130 receives notification of service update information from the screen program 110 (step S204).

First, the update analysis program 130 acquires the notified service update information (S301). Next, the update analysis program 130 acquires the entry for the service targeted by the service update information from the service information T310 (S302).

Next, the update analysis program 130 compares the value of each item (item value) of the service update information with the value of each item (item value) of the entry for the service acquired in step S302 (S303).

Next, the update analysis program 130 executes the processing of loop 1 (steps S304 and S305) for each item of the service update information. Here, in the explanation of the processing of loop 1, the item to be processed is called the target item.

In the processing of loop 1, the update analysis program 130 determines whether the item value of the target item of the service update information has been updated from the item value of the corresponding item of the entry acquired in step S302 (S304). . As a result, for example, if the item value (version information) of the current service version is different between the service update information and the entry of the service information T310, it can be determined that the program has been updated. If the item values of the service API are different between the update information and the entry of the service information T310, it can be determined that the API has been updated.

As a result, if the item value of the target item has been updated (S304: Yes), the update analysis program 130 adds the target item to the service update item list (S305). Here, the service update item list may be an array on the memory 1920, or may be a text file or database temporarily created in the storage device 1950. can be in the form On the other hand, if the item value of the target item has not been updated (S304: No), the update analysis program 130 advances the process to the end of loop 1. FIG.

The update analysis program 130 executes the processing of loop 1 for each item of the service update information. to step S306.

In step S306, the update analysis program 130 notifies the update notification program 140 of the service update information and the service update item list. Note that the update notification program 140 that has received notification of the service update information and the service update item list executes service update notification processing (see FIG. 12), which will be described later.

The update analysis program 130 terminates the service update analysis process after executing the process of step S306.

Next, service update notification processing will be described.

FIG. 12 is a flowchart of service update notification processing according to one embodiment.

The service update notification process is executed when the update notification program 140 receives notification of service update information and a service update item list from the update analysis program 130 (step S306).

First, the update notification program 140 acquires the notified service update information and service update item list (S401).

Next, the update notification program 140 acquires the service ID of the service targeted by the service update information from the service update information, refers to the service list information T210 and the user information T110, and uses this service. (S402).

Next, the update notification program 140 executes loop 2 processing (steps S403 to S406) for each user in the user list. Here, in the processing of loop 2, the user to be processed is called the target user.

In the process of loop 2, the update notification program 140 refers to the user information T110 and acquires the notification management ID of the target user (S403). Here, the update notification program 140 acquires multiple notification management IDs when there are multiple notification management IDs for the target user. Note that when a plurality of notification management IDs are obtained, the same processing is performed for each notification management ID in the following steps (S404 to S406).

Next, the update notification program 140 acquires the notification destination information, the notification document content ID, and the notification means from the entry corresponding to the notification management ID in the notification management information T510 (S404).

Next, the update notification program 140 acquires the entry (template) corresponding to the acquired notification document content ID from the notification document information T610, and the template engine 160 calculates the values of the variable items of the entry (template) of the notification document information T610. is set using the information of the service update information and the service update item list, thereby creating a notification document (S405). Note that the notification document may be created without using the template engine 160. In that case, the information of the service update information and the service update item list may be included in the notification document as they are.

Next, the update notification program 140 transmits a notification document to the notification destination of the notification destination information acquired in step S404 using the acquired notification means (S406). Here, as described above, when a plurality of notification management IDs are acquired in step S403, a plurality of notification documents are transmitted by corresponding notification destinations and notification means. Note that if the transmission fails, the update notification program 140 may perform retry processing.

The update notification program 140 executes loop 2 processing for each user in the user list. End the service update notification process.

As described above, according to the marketplace system 100 according to one embodiment, when the service developer 20 updates the service, the application developer 30 uses one or more notification means specified by the application developer 30. , can receive notification documents written in a specified format. As a result, the application developer 30 can improve development efficiency in service update correspondence for applications.

It should be noted that the present invention is not limited to the above-described embodiments, and can be modified appropriately without departing from the scope of the present invention.

For example, in the above-described embodiment, an update is determined for the program executed by the execution server 400 and the API to be used, and a notification document is sent, but the present invention is not limited to this. etc., and the program (including applications, programs, APIs, etc.) to be executed on the computer 300 side may be determined to be updated, and the notification document may be transmitted.

Further, in the above embodiment, not only the programs and APIs that provide services in the marketing place system 100, but also items other than programs and APIs related to services are determined to be updated, and if it is determined that they have been updated, a notification document is sent. However, the present invention is not limited to this, and the update determination target may be a part of them, for example, limited to only a program or API.

Moreover, in the above embodiments, part or all of the processing performed by the CPU may be performed by a hardware circuit. Also, the programs in the above embodiments may be installed from program sources. The program source may be a program distribution server or storage media (eg, portable storage media).

100... Marketplace system, 110... Screen program, 120... Deployment program, 130... Update analysis program, 140... Update notification program, 150... Registry, 160... Template engine, 200, 300... Computer, 400... Execution server, T110... User information, T210... Service list information, T310... Service information, T410... Instance information, T510... Notification management information, T610... Notification document content information

Claims (11)

A program update management system for managing program updates,
The program update management system has a processor unit,
The processor unit
Acquiring notification document content information that defines the content of a notification document when the program is updated from the user of the program;
determining whether an update of the program has occurred;
when an update of the program occurs, creating a notification document notifying the update of the program based on the content information of the notification document, and transmitting the notification document to the user of the program;
The notification document content information is a template including variable items indicating that it is written according to the update content of the program,
The processor unit
executing a process of creating the notification document by determining the variable items in the template according to the update contents of the program;
Program update management system. The program includes a processing program for executing a predetermined process and an API (Application Programming Interface) for the processing program,
The processor unit
2. The program update management system according to claim 1, wherein when the processing program or the API for the processing program is updated, it is determined that the program has been updated. The processor unit
2. The program update management system according to claim 1, wherein whether or not said program has been updated is determined based on at least version information of said program . The notification document content information includes the content of the notification document when the service provided by the program is updated,
The processor unit
determining whether an update to the service provided by the program has occurred;
2. A program update management system according to claim 1, wherein, when said service is updated, said notification document contains the updated contents of said service. The processor unit
Acquiring notification document management information in which the notification document content information, notification destination information indicating a notification destination of the notification document of the notification document content information, and notification means of the notification document are associated with each other;
2. The program update management system according to claim 1, wherein a notification document based on said notification document content information is notified to a notification destination of said notification destination information by said notification means. The processor unit
A plurality of pieces of notification document management information can be acquired from the user of the program in association with one program,
When an update occurs in a program associated with a plurality of pieces of notification document management information, a notification document is created based on a plurality of pieces of notification document content information, and each notification document is sent to a notification destination of the corresponding notification destination information, 6. The program update management system according to claim 5 , wherein notification is made by the corresponding notification means. The plurality of pieces of notification document management information include notification document content information for notifying the update content in a format for causing the program to notify, and notification content information for notifying the update content in a format for causing a human to notify. 7. The program update management system according to claim 6 , wherein the setting is possible. A program update management method by a program update management system for managing program updates,
Acquiring notification document content information that defines the content of a notification document when the program is updated from the user of the program;
determining whether an update of the program has occurred;
when an update of the program occurs, creating a notification document notifying the update of the program based on the content information of the notification document, and transmitting the notification document to the user of the program;
The notification document content information is a template including variable items indicating that it is written according to the update content of the program,
executing a process of creating the notification document by determining the variable items in the template according to the update contents of the program;
Program update management method. The program includes a processing program for executing a predetermined process and an API for the processing program,
9. The program update management method according to claim 8 , wherein it is determined that said program has been updated when said processing program or an API for said processing program has been updated. A program update management program for causing a computer to execute processing for managing program updates,
to the computer;
Acquiring notification document content information that defines the content of a notification document when the program is updated from a user of the program;
determining whether or not an update of the program has occurred;
creating a notification document notifying the update of the program based on the notification document content information when the update of the program occurs, and causing the notification document to be transmitted to the user of the program ;
The notification document content information is a template including variable items indicating that it is written according to the update content of the program,
to the computer;
executing processing for creating the notification document by determining the variable items in the template according to the update contents of the program;
Program update manager. The program includes a processing program for executing a predetermined process and an API for the processing program,
to the computer;
11. The program update management program according to claim 10 , which determines that the program has been updated when the processing program or the API for the processing program has been updated.