Synchronization control device, synchronization control method, and synchronization control program

Abstract

To provide a synchronization control device that can easily manage versions of multiple subsystems that exist below a main system.SOLUTION: In this embodiment, application means refers to a subsystem version master to determine whether a current version of the major version of each subsystem is the same as an available version, executes a major version update job of the available version for different subsystems, updates the major version of the subsystem version master to the available version, deletes, for actual master, data in which the major version in a major version-specific master is different from the major version of the subsystem version master, and adds, for the major version-specific master, data whose major version is the same as the major version of the subsystem major version master.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a synchronization control device, a synchronization control method, and a synchronization control program.

Background Art

[0002] For example, there are several types of introduction forms of ERP (Enterprise Resources Planning), and one of them is component-type ERP. As an advantage of component-type ERP, since management is divided for each system, it is possible to add and update the necessary version at the necessary timing. Conventionally, for example, as a device for performing a system version upgrade, there is, for example, Patent Document 1.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] On the other hand, in such component-type EPR, when managing different major versions for each of a plurality of subsystems (for example, a salary system or a personnel system) existing under the main system (for example, a business system), if the major versions of the subsystems are different, the system structure changes, so there is a problem that the update management becomes complicated accordingly.

[0005] The present invention has been made in view of the above, and an object thereof is to provide a synchronization control device, a synchronization control method, and a synchronization control program capable of easily performing version management of a plurality of subsystems existing under a main system.

Means for Solving the Problems

[0006] To solve the above-mentioned problems and achieve the objective, the present invention provides a synchronization control device for upgrading the version of a target system, which is composed of a main system that is an installation and management unit for multiple subsystems installed in a component type and includes a control unit, and multiple subsystems that are installation and management units for application groups including job modules, which are further subdivided from the main system, wherein the control unit is a master for managing the current major version and updatable major versions of subsystems, a subsystem version master that registers subsystems, the current major version and available versions in association, a master for managing jobs available for each major version of each subsystem, a major version-specific master that registers subsystems, jobs and major versions in association, an actual master that registers jobs available for the current subsystem from among the jobs in the major version-specific master, and a master for managing the association between each job and module in the major version-specific master, and jobs, binaries, modules The system is configured to access a job module master registered with associated paths, a DB that stores patches including major version upgrade patches and minor version upgrade patches for the main system, which are created for each major version and minor version of the main system, and which are used to upgrade the major versions of multiple subsystems and are updated by applying the major version upgrade patch or the minor version upgrade patch for subsystems, and an application means for performing a version upgrade by applying the patches from the DB to the target system, the application means referring to the subsystem version master to determine whether the current version of the major version of each subsystem is the same as an available version, and if they are different, it executes a major version update job for the different subsystem using the major version upgrade data of the subsystem in the patch, for the available version.This method involves updating the major version of the subsystem version master to the available version, deleting data from the actual master where the major version in the major version-specific master differs from the major version of the subsystem version master, and adding data from the major version-specific master where the major version is the same as the major version of the subsystem major version master.

[0007] Furthermore, according to one aspect of the present invention, the application means may also execute a major version update job for a subsystem selected by the operator on the display screen, where the current version of the major version is different from the available version.

[0008] Furthermore, according to one aspect of the present invention, the application means may determine whether a version upgrade is possible for the selected subsystem, taking into account its dependencies, and if it is determined that a version upgrade is possible, execute a major version update job.

[0009] Furthermore, according to one aspect of the present invention, the application means may determine that a version upgrade is possible and execute a major version update job if the major version of the main system is greater than or equal to the available major version of the selected subsystem.

[0010] Furthermore, according to one aspect of the present invention, the control unit is configured to be able to access a main system version master, which is used to manage the current major version of the main system and is registered in association with the main system and the current major version, and a patch application history master, which is used to manage the patch versions applied to the main system and is registered in association with the main system, major version and minor version. The application means may refer to the main system version master to determine whether the current major version of the main system is the same as the version to be updated, and if they are different, apply the major version upgrade patch among the patches to be applied to the main system, and further update the current major version of the main system in the major version master to the updated version, and add the major version of the main system applied to the patch application history master.

[0011] Furthermore, according to one aspect of the present invention, the application means may refer to the patch application history master to determine whether the current version of the minor version of the main system is the same as the version scheduled for update. If they are different, the application means may apply a minor version upgrade patch from the patches to be applied to the main system. In addition, the application means may reflect the data for the major version upgrade of multiple subsystems included in the applied patch in the major version master and the job module master. Only the data corresponding to the current major version of the reflected major version master will be reflected in the actual master. Based on the data for the major version upgrade of multiple subsystems, the available major versions of the subsystem version master will be updated, and the updated minor version of the main system will be added to the patch application history master.

[0012] Furthermore, according to one aspect of the present invention, the main system may include a business system.

[0013] Furthermore, in order to solve the above-mentioned problems and achieve the objective, the present invention provides a synchronization control method for upgrading the version of a target system, which is composed of a main system, which is the unit for introducing and managing multiple subsystems introduced in a component-type manner, and multiple subsystems, which are the units for introducing and managing application groups including job modules, which are further subdivided from the main system, wherein the control unit is a master for managing the current major version and updatable major versions of subsystems, a subsystem version master that registers subsystems, the current major version and available versions in association, a master for managing jobs available for each major version of each subsystem, a major version-specific master that registers subsystems, jobs and major versions in association, an actual master that registers jobs available in the current subsystem from among the jobs in the major version-specific master, and a master for managing the association between each job and module in the major version-specific master, jobs, binaries, modules The system is configured to access a database that stores patches, which include a job module master registered with associated paths, major version and minor version patches for the main system, and version upgrade data for the major versions of subsystems, which are created for upgrading the major versions of multiple subsystems and are updated by applying the major version upgrade patch or the minor version upgrade patch. The system includes an application step performed by the control unit to upgrade the target system by applying the patches from the database, in which the application step refers to the subsystem version master to determine whether the current version of the major version of each subsystem is the same as an available version, and if they are different, it executes a major version update job for the different subsystem using the version upgrade data for the subsystem's major version in the patch, for the available version.This method involves updating the major version of the subsystem version master to the available version, deleting data from the actual master where the major version in the major version-specific master differs from the major version of the subsystem version master, and adding data from the major version-specific master where the major version is the same as the major version of the subsystem major version master.

[0014] Furthermore, in order to solve the above-mentioned problems and achieve the objective, the present invention is intended to be executed by an information processing device equipped with a control unit, and is a synchronization control program for upgrading the version of a target system which is composed of a main system which is the unit for the introduction and management of multiple subsystems introduced in a component type, and multiple subsystems which are the units for the introduction and management of application groups including job modules, which are further subdivided from the main system, wherein the control unit is a master for managing the current major version and updatable major versions of subsystems, a subsystem version master which registers subsystems, current major versions and available versions in association, a master for managing jobs available for each major version of each subsystem, a major version-specific master which registers subsystems, jobs and major versions in association, an actual master which registers jobs available for the current subsystem from among the jobs in the major version-specific master, and a master for managing the association between each job and module in the major version-specific master. The system is configured to access a database containing patches, which includes a job module master that registers jobs, binaries, modules, and paths in association with each other, a major version and minor version of the main system, major version upgrade patches and minor version upgrade patches for the main system, and version upgrade data for the major versions of subsystems that are updated by applying the major version upgrade patch or the minor version upgrade patch to upgrade the major versions of multiple subsystems, and the control unit is configured to execute an application process to perform an upgrade by applying the patches from the database to the target system, and in the application process, the system refers to the subsystem version master to determine whether the current version of the major version of each subsystem is the same as the available version, and if they are different, it uses the version upgrade data for the major version of the subsystem in the patch to apply the patch to the different subsystems.The process involves executing a major version update job for the available version, updating the major version of the subsystem version master to the available version, deleting data from the actual master where the major version in the major version-specific master differs from the major version of the subsystem version master, and adding data from the major version-specific master where the major version is the same as the major version of the subsystem major version master. [Effects of the Invention]

[0015] The present invention has the effect of making it possible to easily manage the versions of multiple subsystems that exist below the main system. [Brief explanation of the drawing]

[0016] [Figure 1] Figure 1 is a block diagram showing an example of the configuration of a synchronous control device according to this embodiment. [Figure 2] Figure 2 is a diagram used to explain the problem. [Figure 3] Figure 3 is a diagram used to explain the problem. [Figure 4] Figure 4 is a diagram illustrating the solution. [Figure 5] Figure 5 shows an example of the configuration of the business system version master. [Figure 6] Figure 6 shows an example of the subsystem Ver master configuration. [Figure 7] Figure 7 shows an example of the configuration of the patch application history master. [Figure 8] Figure 8 shows an example of the configuration of the job master menu display by major version. [Figure 9] Figure 9 shows an example of the configuration of a menu display job master. [Figure 10] Figure 10 shows an example of the configuration of a job module master. [Figure 11]FIG. 11 is a diagram showing a configuration example of a major version update check master. [Figure 12] FIG. 12 is a diagram showing a configuration example of a major version update execution stored master. [Figure 13] FIG. 13 is a diagram showing a work determination flow. [Figure 14] FIG. 14 is a diagram showing examples of the major Ver and minor Ver of the main system and the subsystem before and after update. [Figure 15A] FIG. 15A is a diagram for explaining solution (1). [Figure 15B] FIG. 15B is a diagram for explaining solution (1). [Figure 15C] FIG. 15C is a diagram for explaining solution (1). [Figure 16A] FIG. 16A is a diagram for explaining solution (2). [Figure 16B] FIG. 16B is a diagram for explaining solution (2). [Figure 16C] FIG. 16C is a diagram for explaining solution (2). [Figure 17] FIG. 17 is a diagram showing another configuration example of a job module master. [Figure 18A] FIG. 18A is a diagram for explaining solution (3). [Figure 18B] FIG. 18B is a diagram for explaining solution (3). [Figure 18C] FIG. 18C is a diagram for explaining solution (3). [Figure 19A] FIG. 19A is a diagram for explaining solution (4). [Figure 19B] FIG. 19B is a diagram for explaining solution (4). [Figure 19C] FIG. 19C is a diagram for explaining solution (4). [Figure 20A] FIG. 20A is a diagram for explaining a supplement. [Figure 20B] FIG. 20B is a diagram for explaining a supplement. [Modes for carrying out the invention]

[0017] Embodiments of the synchronous control device, synchronous control method, and synchronous control program according to the present invention will be described in detail below with reference to the drawings. However, the present invention is not limited to these embodiments.

[0018] [1. Overview] (1) Regarding terminology The meanings of terms used in this specification and drawings are as follows: • Main system (e.g., business system)... This is the unit for the implementation and management of each subsystem group implemented in a component-based manner. • Subsystem: A unit for the implementation and management of application groups (job modules) that further subdivide business systems. A subsystem also refers to a product that can be contracted (e.g., core accounting system, asset management system). • Major version upgrade (hereinafter, "version" may be abbreviated as "Ver")... This refers to a large-scale change to the system. Generally, this means an incompatible change (such as a change in the framework used) where the same usage method as before is not guaranteed, but in this invention, we are not necessarily bound by this general meaning. Each system may freely decide whether it is a major version upgrade or a minor version upgrade. • Minor version upgrade: This refers to a small change to the system. Generally, it means a change (such as functional enhancement or improvement) that is expected to maintain compatibility and allow for the same usage as before. However, in this invention, we are not necessarily bound by this general meaning. We are free to set our own criteria for whether a system is a major version upgrade or a minor version upgrade. Modules are files necessary to run an application. Examples include exe, dll, js, config, and xml files. A job is a unit of processing performed by a system user. While modules are used when using jobs, they are not necessarily linked on a one-to-one basis. Even the same module may be displayed as separate jobs in the menu if they are triggered under different conditions.

[0019] (2) Conventional technology and its problems There are several types of ERP implementations, one of which is component-based ERP. One advantage of component-based ERP is that, because management is separated for each system, it is possible to add and update the necessary versions when needed.

[0020] On the other hand, when managing different major versions for multiple subsystems under a single main system, the system structure changes if the major versions of the subsystems differ, which complicates update management.

[0021] (3) Outline and effects of the present invention Therefore, in this embodiment, in order to facilitate version management of multiple subsystems existing below the main system, different major versions can coexist for multiple subsystems, and major version updates can be performed at any time.

[0022] This allows for the creation of finely divided versions tailored to each customer, enabling new installations and version upgrades. Furthermore, it becomes possible to release the system without having to completely build the entire system during version upgrade development, allowing for faster delivery of value to customers. The synchronous control device of the present invention is: Applicable to all industries and sectors.

[0023] [2. Structure] An example of the configuration of the synchronous control device 100 according to this embodiment will be described with reference to Figure 1. Figure 1 is a block diagram showing an example of the configuration of the synchronous control device 100.

[0024] The synchronization control device 100 is a commercially available desktop personal computer. However, the synchronization control device 100 is not limited to stationary information processing devices such as desktop personal computers, but may also be portable information processing devices such as commercially available notebook personal computers, PDAs (Personal Digital Assistants), smartphones, and tablet personal computers.

[0025] The synchronous control device 100 comprises a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. Each part of the synchronous control device 100 is connected to communicate via any communication path.

[0026] The communication interface unit 104 connects the synchronization control device 100 to the network 300 via communication devices such as routers and wired or wireless communication lines such as dedicated lines. The communication interface unit 104 has the function of communicating data with other devices via communication lines. Here, the network 300 has the function of connecting the synchronization control device 100 with the server 200 and the system 400 that is the target of the version upgrade, enabling them to communicate with each other, and is, for example, the internet or a LAN (Local Area Network). Data such as various masters and databases, which will be described later, may be stored in the server 200, for example.

[0027] System 400 is, for example, a component-type ERP system, consisting of a main system (for example, a business system (HR system as an example of a business system)) and multiple subsystems located at lower levels of the main system (for example, a payroll system, a human resources system, etc.). The synchronization control device 100 performs major and minor updates to the main system and multiple subsystems of System 400.

[0028] The input / output interface unit 108 is connected to an input device 112 and an output device 114. The output device 114 can be a monitor (including a home television), a speaker, or a printer. The input device 112 can be a keyboard, mouse, microphone, or a monitor that works in conjunction with a mouse to provide pointing device functionality. In the following, the output device 114 may be referred to as the monitor 114, and the input device 112 may be referred to as the keyboard 112 or mouse 112.

[0029] The memory unit 106 stores various databases, tables, and files. The memory unit 106 also stores computer programs that work in cooperation with the OS (Operating System) to give instructions to the CPU (Central Processing Unit) to perform various processes. As the memory unit 106, for example, memory devices such as RAM (Random Access Memory) and ROM (Read Only Memory), fixed disk devices such as hard disks, flexible disks, and optical disks can be used.

[0030] The memory unit 106 includes, for example, a business system version master 106a, a subsystem version master 106b, a patch application history master 106c, a major version menu display job master 106d, a menu display job master 106e, a job module master 106f, a main system module master, a major version upgrade check master 106g, a major version upgrade execution stored master 106h, a patch DB 106i, and the like.

[0031] The functions and contents of each master are explained in detail in [4. Overview of Processing, etc.], [4-2. Master Configuration] below.

[0032] Patch DB106i stores patches for upgrading System 400. Patches are created for each major and minor version of the main system (for example, a patch for major version 1 and minor version 1 of the main system, a patch for major version 1 and minor version 2 of the main system, etc.). Each patch includes major and minor version upgrade patches for the main system, and version upgrade data (including job modules) for the major versions of multiple subsystems, which are updated when the major or minor version upgrade patch is applied. The latest patch contains the latest major version upgrade data for each of the multiple subsystems. By unifying the patches in this way, the management of major versions of multiple subsystems is made easier.

[0033] The control unit 102 is a CPU or the like that comprehensively controls the synchronization control device 100. The control unit 102 has internal memory for storing control programs such as the OS, programs that define various processing procedures, and required data, and executes various information processing based on these stored programs.

[0034] Functionally, the control unit 102 comprises a creation unit 102a, an application unit 102b, a master maintenance unit 102c, and a screen display control unit 102d.

[0035] The creation unit 102a creates the aforementioned patches in units of major and minor versions of the main system, according to the developer's operations, and stores them in the patch DB 106i.

[0036] The application unit 102b performs a version upgrade by applying the target patch stored in the patch DB 106i to the system 400. Specifically, the application unit 102b performs the following processes (1) to (3).

[0037] (1) Determine whether the current major version of the main system in Business System Ver Master 106a is the same as the version after processing (scheduled update). If they are different, apply the major version upgrade patch from the patches to be applied to the main system. Furthermore, update the current major version of the main system in Business System Ver Master 106a to the version after processing, and add the major version of the main system applied to Patch Application History Master 106c.

[0038] (2) Referencing the patch application history master 106c, determine whether the current version of the main system's minor version and the version scheduled for update (after processing) are the same (the latest minor version in the patch application history master 106c becomes the current version). If they are different, apply the minor version upgrade patch among the patches to be applied to the subsystem. Furthermore, reflect the version upgrade data for the major versions of multiple subsystems included in the applied patch in the major version menu display job master 106d and the job module master 106f. Reflect only the data corresponding to the current major version of the reflected major version menu display job master 106d in the menu display job master 106e. Based on the version upgrade data for the major versions of multiple subsystems, update the available major versions in the subsystem Ver master 106b and add the minor version of the main system applied to the patch application history master 106c.

[0039] (3) Refer to subsystem Ver master 106b to determine whether the current version of the major version of each subsystem is the same as the available version. If they are different, execute a major version update job for the different subsystem using the subsystem's major version upgrade data to update the major version of subsystem Ver master 106b to the available version. For menu display job master 106e, delete data in major version-specific menu display job master 106d where the major version is different from the major version of subsystem version master, and add data in major version-specific menu display job master 106d where the major version is the same as the major version of subsystem Ver master 106b.

[0040] In this case, for subsystems where the current major version differs from the available version, the operator can select the subsystem on the display screen and run a major version update job for the available version.

[0041] Furthermore, for the selected subsystem, it may be determined whether an upgrade is possible considering its dependencies, and if an upgrade is possible, a major version update job may be executed. For example, if the major version of the main system is greater than or equal to the available (scheduled) major version of the selected subsystem, a major version update job may be executed, and otherwise, an error message (for example, "The subsystem's major version upgrade is not possible") may be output.

[0042] The master maintenance unit 102c performs various master settings, etc., in response to operator operations on the master maintenance screen displayed on the monitor 114, for example.

[0043] The screen display control unit 102d controls the display and input of various screens to be displayed on the monitor 114.

[0044] [3. Challenges, Solutions, and Effects] This section describes the background, challenges and requirements, solutions, and effects.

[0045] [3-1. Background of the Invention] (Characteristics of component-based ERP) There are several types of ERP implementation models, one of which is component-based ERP. Component-based ERP has the advantage of allowing flexible addition of business systems as needed, depending on the timing and content. However, because each business system in the ERP is componentized and can be implemented in stages, the implementation timing differs for each business system, and it's not always possible to keep them up-to-date.

[0046] (Regarding system subdivision and version upgrades) While it's necessary to consider the coexistence of different versions of business systems, maintaining version compatibility within each business system is possible if there's a one-to-one correspondence between the business system and the database. However, when the overall scale of the business system is large, the business systems may be further subdivided and managed as subsystems within a single database. For example, within a main system like the HR (Human Resources) system, there are subsystems such as the personnel system and the payroll system. Furthermore, there are subsystems that depend on those subsystems (for example, the HR-specific My Number system used by the HR system).

[0047] To keep pace with the rapid pace of change, it is necessary to develop and release version upgrades for each subsystem. Releasing a new version of all subsystems at once would result in delays. Therefore, there is a growing need for a configuration that allows for the coexistence of different subsystem versions within a business system, even if the latest versions differ for each subsystem. For example, within an HR system, an existing HR system might need to be used for a while because it cannot be immediately upgraded, while a newly introduced payroll system needs to be the latest version.

[0048] From now on, the entire business system may be referred to as the "main system," the subdivided business systems as "subsystems," and the unit of implementation without distinguishing between main and subsystems as the "product."

[0049] Therefore, there is a need to implement major version control for multiple subsystems within a single business system (database), but this presents the following challenges.

[0050] (Previous version upgrade) Previously, major version upgrades could be performed on a per-business system (DB) basis, making the relationship between the current major version and the latest applicable patch version clear and relatively easy to control.

[0051] When introducing a new business system (where operational data does not exist in the business system's database), you should follow the procedure for adding the database to the major version at the time of initial installation for each business system, and then applying the update patches to the desired major / minor version.

[0052] Furthermore, if you want to upgrade the version in an existing deployment environment (where operational data exists in the business system's database), you should create an update patch that takes the existing operational data into consideration and apply the update patch to the desired major / minor version for each business system.

[0053] When implementing a new system or upgrading an existing environment, it is relatively easy to unify the generational management system of multiple minor version patches corresponding to the major version, resulting in high maintainability.

[0054] (Challenges of version upgrades for each subsystem) On the other hand, consider a scenario where minor version upgrade patches are applied to subsystems within a single business system (database) where different major versions exist for each subsystem.

[0055] If existing subsystems maintain their current major versions while only newly introduced subsystems are given the latest major version, it becomes necessary to manage separate minor version upgrade patches for each subsystem's major version within a single business system (DB). This increases the number of patch families by the number of subsystem major version combinations, thus reducing maintainability.

[0056] Furthermore, errors in patch selection by update personnel can lead to problems such as major or minor version upgrades being performed on existing systems that should not be updated.

[0057] Therefore, while simplifying the application of update patches to a single business system (DB) unit, as before, and unifying the major / minor version upgrade process to improve maintainability, a new mechanism is needed to ensure that only the necessary minor version upgrades are performed safely, depending on the major version of the subsystem.

[0058] Generally, managing updates for hierarchical product structures like this, where subsystems are located under a single business system (DB), becomes extremely complex.

[0059] [3-2. Challenges and Requirements] (assignment) When creating patches that are strictly subdivided into subsystems or similar units, the number of patches and combinations increases, leading to the following challenges (1) and (2) which reduce maintainability and safety.

[0060] (1) Maintainability: The maintenance burden increases when managing multiple generations of systems. (2) Safety: For each combination of installed subsystems and major versions, it becomes difficult to determine, collect, and apply the corresponding update patches in the correct order, leading to errors in operator judgment.

[0061] Figures 2 and 3 illustrate these challenges. Figures 2 and 3 show a scenario where the main system is an HR system, and the subsystems are payroll and personnel management.

[0062] The main contents of each patch are as follows: A script to update DB objects such as tables (hereinafter, "table" has the same meaning as "master," and may be written as "master"). • Table data update files, scripts • Binary information of the program module

[0063] The processes performed in a major version patch are as follows: Select the appropriate major version upgrade patch for the subsystem. The subsystem's major version upgrade patch includes the following: • Table data update files, scripts • Binary information of the program module

[0064] These are units that may apply to different subsystems depending on their major / minor versions, and they need to be updated while maintaining consistency.

[0065] In the example shown in Figure 2, in addition to the major version upgrade patches for salary (version 1 to 2) and HR (version 1 to 2), it is necessary to manage separate minor version upgrade patches 1, 2, ... for salary (version 1), minor version upgrade patches 1, 2, ... for salary (version 2), minor version upgrade patches 1, 2, ... for HR (version 1), and minor version upgrade patches 1, 2, ... for HR (version 2). As a result, the number of patch systems increases by the number of major version combinations of subsystems, which reduces maintainability.

[0066] If, for the sake of improving maintainability, patches are simply integrated and applied at the business system level rather than at the subsystem level, as shown in Figure 3, a problem arises where updates cannot be performed on combinations that retain older versions of subsystems. In Figure 3, only completely identical combinations are acceptable, and inconsistencies arise due to differences in the major versions of subsystems, making application impossible.

[0067] (request) (1) Regardless of the major version combination of subsystems, the minor version can be upgraded with a single patch on a business system basis. This solves the "maintainability (issue (1))" problem because there is only one patch, and also solves the "safety (issue (2))" problem because it eliminates the need for operator judgment.

[0068] (2) To address complex cases where dependencies exist between subsystems, etc., it is necessary to enable control over major version dependencies between subsystems, etc. This will help prevent operator errors and contribute to solving "safety (issue (2))".

[0069] [3-3. Solution] (1) Separate the major version table (master) and the actual table (master) to manage the data. Specifically, a single patch will include data for major versions of multiple subsystems. Data spanning multiple major versions will be stored in separate tables for each major version. Only data corresponding to currently installed and running subsystem versions will be reflected in the actual tables.

[0070] (2) Provide a major version update function. Specifically, when updating a major version, dependency checks are performed. Then, the data in the actual tables is updated based on the major version-specific tables.

[0071] Figure 4 is a diagram illustrating the solution method according to this embodiment. In Figure 4, the The processes performed by the major version update job are: "checking dependencies based on the major version upgrade check master" and "updating the actual tables based on the major version-specific tables." In the same diagram, 500 is a diagram showing an example of the major version update job screen. The major version update job screen has an execute button to instruct the execution of the major version update and a major version update selection area to select the product (subsystem) to be updated. The major version update selection area displays checkboxes for selecting rows, the product (HR, payroll), the current major version, and the available (updatable) major version. When a checkbox is selected and the execute button is pressed, the product in the selected row is updated to the available major version.

[0072] In this way, the major version update job screen allows users to select the subsystem to be major updated, enabling control over major version dependencies between subsystems, etc., in complex cases where dependencies exist between subsystems, etc. (as per requirement (2) above).

[0073] This example explains the case where the checkboxes in the first and second rows are checked, and the major version of HR and payroll is updated from 1 to 2.

[0074] As shown in the figure, patches are created for each major and minor version of the main system (HR system), and include major version upgrade patches and minor version upgrade patches for the main system, as well as data for upgrading the major versions of multiple subsystems. Therefore, regardless of the combination of major versions of subsystems, a single patch can be used to upgrade the minor version of each business system (HR system) (requirement (1) above).

[0075] The example shown in the figure illustrates patches for major version 2, minor version upgrades 1 and 2, etc., of the HR system. These patches include, for example, the following:

[0076] • Binary information for the program module (including the following versions) Salary Measure Ver1 Salary Measure Ver2 HR Major Ver1 HR Measures Ver2

[0077] • Data update files for tables by major version (including the following versions) Salary Measure Ver1 Salary Measure Ver2 HR Major Ver1 HR Measures Ver2

[0078] • A script to update the actual table based on the major version table. • A script to update DB objects such as tables.

[0079] (3-4) Effects (1) Safety introduction The following issues described in the problem will be resolved, preventing errors in patch application by workers. • Maintainability: By enabling parallel management of multiple generations of multiple subsystems with a single patch system, the maintenance burden does not increase. • Safety: Since there is only one patch system, there is no need for a human to determine the major version differences of the subsystem. Furthermore, if there are dependencies between subsystems, these will be controlled within the major version update job.

[0080] (2) Early adoption • Because versions can be provided on a subsystem-by-subsystem basis, rather than on a per-business-system basis, subsystem version upgrades can be delivered quickly and in small increments without having to wait for version upgrades of other subsystem systems. As a result, it is possible to respond quickly to changes such as regulatory compliance. • For customers whose systems are currently running, we can provide data for a major version upgrade in advance, without changing the major version of the currently installed and running subsystems.

[0081] As a result, when you want to upgrade the major version of a subsystem, you can switch at any time by running a major version update job instead of applying a patch.

[0082] Although this embodiment uses a "business system" as an example, its application is not limited to this and can be applied to other systems consisting of a main system and multiple subsystems. For example, it can be applied to any system to which a similar version upgrade concept can be applied (e.g., multiple web services used by general consumers, or equipment control systems).

[0083] [4. Overview of the process, etc.] This section describes the overview of the processing of the synchronous control device 100 according to this embodiment.

[0084] [4-1. Overview] This embodiment will be outlined below.

[0085] (Patch format) The patch format in this embodiment will now be described. The patch format shall include the following: • Binary information of the program module • Updating the table

[0086] Tables are primarily divided into the following four types.

[0087] (1) Version control tables: These tables control the versions of business systems and subsystems.

[0088] (2) Major Version Table: This is a master table that manages major version data for subsystems, etc., and is referenced when applying patches and when executing major version update jobs to update the actual tables.

[0089] (3) Actual tables: These are tables that are actually used by the business system and subsystems.

[0090] (4) Job Module Control Table: This table is used to manage modules and to manage the association between jobs and modules.

[0091] (Solution strategy) The solutions (1) to (4) in this embodiment will be explained below.

[0092] Solution (1): When applying a major version upgrade patch to the business system, perform a major version upgrade of the business system.

[0093] Solution (2): When applying a minor version patch to the business system, update as follows: • Major Version Table: Updates data including past major versions that may be mixed together. • Actual tables: Only data updates corresponding to the current major version will be performed. • Job module control table (binary information of program modules): Updates including modules of past major versions that may be mixed together (assuming that each major version is separated into a different folder or file name).

[0094] Solution (3): Information on major version upgrades of subsystems will be included in the minor version patches of the business systems. Major version upgrades of subsystems will not be performed at the time of patch application (system operation will conform to the major version before application). Version control tables and other related tables will be updated.

[0095] Solution (4): Major version upgrades of subsystems, etc., are performed by executing a major version update job. Based on the major version-specific table, data is switched from the old major version data in the actual table to the new major version data, thereby performing a data update equivalent to that of the conventional patch application.

[0096] [4-2. Master Configuration] The master configuration of this embodiment will be described with reference to Figures 5 to 12.

[0097] (1) Version control system table Version control tables are tables that control the versions of business systems and subsystems, such as business system version master 106a, subsystem version master 106b, patch application history master 106c, etc.

[0098] Figure 5 shows an example of the configuration of the business system version master 106a. The business system version master 106a is a master for managing the major version of the business system, and as shown in Figure 5, it can be composed of tables that register the relationship between the main system and the current major version. In the example shown in the figure, the main system is "HR System" and the current major version is "3".

[0099] Figure 6 shows an example configuration of subsystem Ver Master 106b. Subsystem Ver Master 106b is a master for managing the current major version and updatable major versions of a subsystem, and as shown in Figure 6, it can be composed of tables that associate and register the product (subsystem), major version, and available version. In the example shown in the figure, the first row is product "Personnel", major version "1", and available version "1", and the second row is product "Payroll", major version "2", and available version "2".

[0100] Figure 7 shows an example of the configuration of the patch application history master 106c. The patch application history master 106c is a master for managing the patch versions applied to the main system so far, and can be composed of tables that register the main system, major version, and minor version in association with each other. In the example shown in the figure, the first row is "HR system" for the main system, "2" for the major version, and "0" for the minor version, and the second row is "HR system" for the main system, "2" for the major version, and "1" for the minor version. The last row is the current major version and minor version.

[0101] (2) Table by major version The major version-specific table is a master table that manages major version-specific data for subsystems, etc., and includes the major version-specific menu display job master 106d, but may also include other tables. It is referenced when applying patches and when executing major version update jobs, and when updating the actual tables.

[0102] Figure 8 shows an example configuration of the Major Version Menu Display Job Master 106d. The Major Version Menu Display Job Master 106d is a master for managing the jobs available for each major version of each subsystem, and as shown in Figure 8, it can be composed of tables that associate and register products (subsystems), jobs, and major versions. In the example shown in the figure, the first row is Product "Personnel", Job "Personnel Job A_Ver1", Major Version "1", and the second row is Product "Personnel", Job "Personnel Job B_Ver1", Major Version "1".

[0103] (3) Actual Table The actual tables are those actually used by the main system and subsystems, including the menu display job master 106e, but other tables may also be used.

[0104] Figure 9 shows an example configuration of the menu display job master 106e. The menu display job master 106e is used to manage the jobs available in the current subsystem combination and registers the available jobs.

[0105] (4) Job module control table The job module control table is a table used to manage modules and the association between jobs and modules, and includes the job module master 106f, the main system module master, etc.

[0106] Figure 10 shows an example of the configuration of the job module master 106f. The job module master 106f is a master for managing the binary data of each job, and can be composed of tables that register the job, binary, module name, and path in association. In the example shown in the figure, the first row is the job "HR Job A_Ver1", binary "binary data", module name "HR Job A_Ver1.exe", and path "HR Folder\1.0Bin", and the second row is the job "HR Job B_Ver1", binary "binary data", module name "HR Job B_Ver1.exe", and path "HR Folder\1.0Bin".

[0107] The main system module master can consist of tables that register and associate module names, binaries, paths, and major versions (see, for example, Figure 15A).

[0108] (5) Others Figure 11 shows an example configuration of the Major Version Upgrade Check Master 106g. The Major Version Upgrade Check Master 106g is a master for managing stored procedures that check dependencies during a major version upgrade, and as shown in Figure 11, it can be composed of tables that register products and check stored procedures in association. In the example shown in the figure, the first row is the product "HR" and the check stored procedure "HR Check Stored Procedure", and the second row is the product "Payroll" and the check stored procedure "Payroll Check Stored Procedure".

[0109] Figure 12 shows an example configuration of the major version upgrade execution stored master 106h. As shown in Figure 12, the major version upgrade execution stored master 106h can be composed of tables and the like that register products and execution stored procedures in association.

[0110] [4-3. Work Decision Flow] Figure 13 illustrates the process performed by the application unit 102b of this embodiment.

[0111] Figure 13 shows the decision-making flow for upgrading from the "version before processing" to the "version after processing (planned update)." Versions are defined as follows:

[0112] • "Pre-processing version": The version at the start of processing. • "Processed Version": The version that is scheduled (expected) to be updated. The version at the time of processing completion. • "Current Version": The version at that point in the process. • "Available Versions": This indicates the version to which the system can be updated. It is stored in the version control system table.

[0113] In Figure 13, the major versions of the business system are determined by referring to the business system version master 106a, and whether the "version before processing" and the "version after processing" are the same (Step S1).

[0114] If the major version of the business system is the same for both the "version before processing" and the "version after processing" (Yes in step S1), proceed to step S2.

[0115] If the major versions of the business system in the "version before processing" and the "version after processing" are not the same ("No" in step S1), apply the major version upgrade patch to the business system (step S4: explained in detail in the solution policy (1) described later), and proceed to step S2.

[0116] In step S2, the patch application history master 106c is referenced to determine whether the minor versions of the business system in the "pre-processing version" and the "post-processing version" are the same. If the minor versions of the business system in the "pre-processing version" and the "post-processing version" are the same ("Yes" in step S2), the process proceeds to step S3.

[0117] If the minor versions of the business system in the "version before processing" and the "version after processing" are not the same ("No" in step S2), apply the minor version upgrade patch to the business system (step S5: explained in detail in the resolution strategies (2) and (3) described later), and proceed to step S3.

[0118] In step S3, the subsystem Ver master 106b is referenced to determine whether the major versions of the "current version" and "available versions" for each subsystem are the same. If the major versions of the "current version" and "available versions" for each subsystem are the same ("Yes" in step S3), the flow is terminated.

[0119] If the major versions of the "current version" and "available version" of each subsystem are not the same (No in step S3), a major version update job is executed (step S6: explained in detail in the solution strategy (4) below).

[0120] Furthermore, assuming that the major version upgrade information for the subsystem has already been applied when applying the business system minor version patch, the order in which subsequent business system minor version upgrade patches are applied and the execution of the subsystem major version update jobs can be reversed. Alternatively, the order can be such that the business system minor version upgrade patch is applied → the subsystem major version update job is executed → the business system minor version upgrade patch is applied again, with the latter being an intermediate step.

[0121] Here, we will explain the difference between "Apply Patches" in S4 and S5 and "Run Version Update Jobs" in S6. "Apply Patches" includes the following: (a) The above major version upgrade will be a direct update of the actual data of the main system. (b) For subsystems, scheduled data updates of the "Major Version-Specific XX Table" which will be required later when the "Version Update Job" is executed. (c) Of the above (b), the "Major Version Table" corresponding to the major version of the product in the subsystem version master shall be updated to the actual table immediately.

[0122] The "version update job" reflects the changes in the subsystem version as described in (b) above (this means that the process equivalent to "applying a patch" in previous tasks is executed with a delay). In other words, • "Apply Patch" does not update actual data that does not correspond to the major version of the product in the subsystem version master (it does not arbitrarily change the major version of installed products, but instead reschedules the updates of data necessary for the "version update job"). The scope and timing of actual data updates differ. • The "Version Update Job" updates the actual data for the major version of the subsystem version master product that has been changed (the major version of the installed product can be changed at any time at the operator's discretion using the reserved updated major version data mentioned above). The advantage of delaying the execution of a process equivalent to "applying a patch" is that it allows customers to switch major versions at any time they wish, which is part of their major version upgrade operations.

[0123] [4-3. Mechanism Details] The details of the mechanism of this embodiment will be explained with reference to Figures 14 to 19C. Below, an example will be described in which the processing of the work decision flow in Figure 13 is carried out according to solution policies (1) to (4).

[0124] The following explanation uses the data movement during a version upgrade as shown in Figure 14 as an example. Figure 14 shows an example of the main system (HR system) and subsystems (HR, payroll) major and minor versions before and after the update. As shown in the figure, the following explanation describes the case where, before the update, the HR system's major version was "2", minor version was "1", HR's major version was "1", and payroll's major version was "2", and after the update, the HR system's major version was "3", minor version was "2", HR's major version was "1", and payroll's major version was "3".

[0125] (Solution strategy (1)) Solution (1) will be explained with reference to Figures 15A to 15C.

[0126] In the work decision flow shown in Figure 13 above, step S1 determines whether the major versions of the business system in the "version before processing" and the "version after processing" are the same. Since they are not the same, the result is "No," and the business system major version upgrade patch is applied (step S4).

[0127] Refer to Figures 15A to 15C to explain the control when applying a major version upgrade patch to a business system. Here, we will explain the case of applying a patch to raise the major version of the business system from "2" to "3" (for example, a patch for major version 3 and minor version 0 of the business system), as described above.

[0128] Figure 15A shows an example of a version control system table before patch application. In the example shown in the figure, the business system Ver master 106a is "HR System" for the main system and "2" for the current major version. The subsystem Ver master 106b has the product "HR" as the first row, major version "1" and available version "1" for the second row, and the product "Payroll" as the major version "2" and available version "2" for the second row. The patch application history master 106c has the system "HR System" as the first row, major version "2" and minor version "0" for the second row, and the system "HR System" as the major version "2" and minor version "1" for the second row. The main system module master has the module name "menu.exe", binary "binary data", path "HR System\2.0Bin", and major version "2". An example of enhancing the functionality of the menu itself is shown as an example of a major version upgrade of a business system. The jobs available on the menu are HR Job A_Ver1, HR Job B_Ver2, Payroll Job A_Ver2, and Payroll Job B_Ver1.

[0129] Apply the patch shown in Figure 15B. This patch is a major version upgrade patch for the business system to upgrade the HR system (Major Ver2 → 3), and it performs an actual table update (the explanation of the actual table update is omitted as there is nothing particularly unusual about it). The patch information is as follows: Business System: HR System, Business System Major Ver: 3, Business System Minor Ver: 0. The Major Ver of the module name "Menu.exe" in the Main System Module Master is "3".

[0130] Figure 15C shows the version control system table after the patch has been applied. When the patch is applied, the version control system table is updated as shown in Figure 15(C). Specifically, the major version of the main system "HR System" in the business system Ver master 106a is updated from "2" to "3". In addition, the third row of the patch application history master 106c is updated (added) with the history of the main system "HR System", major version "3", and minor version "0".

[0131] (Solution strategy (2)) Solution (2) will be explained with reference to Figures 16A to 17.

[0132] In the work decision flow shown in Figure 13 above, step S1 determines whether the major version of the business system in the "version before processing" and the "version after processing" are the same, and if they are the same, the answer is "Yes". Step S2 determines whether the minor version of the business system in the "version before processing" and the "version after processing" are the same, and if they are not the same, the answer is "No". The business system minor version upgrade patch is then applied (step S5).

[0133] Refer to Figures 16A to 16C to explain the control when applying minor version upgrade patches to the business systems. Here, when the major version upgrade for HR is Ver:1 and for payroll is Ver:2, the system is controlled to allow only jobs that are available in those versions to be used.

[0134] Figure 16A shows the (1) version control system table, (2) major version table, (3) actual table, and (4) job module control table before patch application. Table (2) major version table has a corresponding (3) actual table. As an example, the "Menu Display Job Master 106e" controls the content of jobs that users can use on the menu. Table (1) version control system table is the same as in Figure 15(C).

[0135] In the major version-specific menu display job master 106d, the first row shows product "HR", job "HR Job A_Ver1", major version "1", the second row shows product "HR", job "HR Job B_Ver1", major version "1", and so on.

[0136] The menu display job master 106e has "Personnel Job A_Ver1" on the first line, "Personnel Job B_Ver1" on the second line, and so on.

[0137] The job module master 106f has the following on the first line: Job "HR Job A_Ver1", Binary "Binary Data", Module Name "HR Job A_Ver1.exe", Path "HR Folder\1.0Bin", Job "HR Job B_Ver1", Binary "Binary Data", Module Name "HR Job B_Ver1.exe", Path "HR Folder\1.0Bin", ...

[0138] 600 indicates the menu screen, where job data from the menu display job master 106e is displayed as available jobs on the menu. When a user selects a job, the system refers to the job module master 106f and executes the module (binary) at the corresponding path.

[0139] Apply the patch shown in Figure 16B. This patch is a minor version upgrade patch for the business system to upgrade the HR system (minor Ver0→1). The patch information is as follows: Business System: HR System, Business System Major Ver: 3, Business System Minor Ver: 1. This patch adds data as part of the minor version upgrade of the business system, including the job module for "HR Job C_Ver1" from "Major Ver1" and the job module for "HR Job C_Ver2" from "Major Ver2" for the HR subsystem, and the job module for "Payroll Job C_Ver1" from "Major Ver1" and the job module for "Payroll Job C_Ver2" from "Major Ver2" for the payroll subsystem. The patch updates all data, including any mixed data from previous major versions, to the latest version.

[0140] Figure 16C shows the (1) version control system table, (2) major version table, (3) actual table, and (4) job module control table after patch application.

[0141] Process 1: The data included in the patch to be applied is reflected in the major version menu display job master 106d and job module master 106f.

[0142] Process 2: For each "product" in subsystem Ver Master 106b, data matching the "Major Ver" of that "product" is extracted from Major Version Menu Display Job Master 106d, and the Menu Display Job Master 106e is updated. In other words, only the data corresponding to the current major version is updated in Menu Display Job Master 106e. In this example, of the four details newly added to Major Version Menu Display Job Master 106d, the two details that match the extraction condition based on the "Major Ver" of the "product" are updated in Menu Display Job Master 106e.

[0143] Process 3: Update the patch application history master 106c based on the patch information. In this example, the major version of the HR system does not change, so the business system version master 106a is not updated. Similarly, the available versions of the subsystems do not change, so the subsystem version master 106b is not updated.

[0144] This section explains the correspondence between jobs and modules. For simplicity of explanation, the above description assumes a one-to-one correspondence between jobs and modules. In reality, multiple jobs may use a single common module (this is done by changing the startup arguments). Figure 17 shows an example of job module master 106f when multiple jobs use a single common module.

[0145] (Solution strategy (3)) Solution (3) will be explained with reference to Figures 18A to 18C.

[0146] In the work decision flow shown in Figure 13 above, step S1 determines whether the major version of the business system in the "version before processing" and the "version after processing" are the same, and if they are the same, the answer is "Yes". Step S2 determines whether the minor version of the business system in the "version before processing" and the "version after processing" are the same, and if they are not the same, the answer is "No". The business system minor version upgrade patch is then applied (step S5).

[0147] Refer to Figures 18A to 18C to explain the control process when applying a minor version upgrade patch to a business system (which also serves as a major version upgrade for subsystems). Here, we will explain the case of applying a patch that upgrades the minor version of the HR system from 1 to 2 and the major version of the payroll system from 2 to 3.

[0148] Figure 18A shows (1) the version control system table, (2) the major version table, (3) the actual table, and (4) the job module control table before patch application, and is the same as Figure 16(C).

[0149] Apply the patch shown in Figure 18B. The patch to be applied is the major version 3 and minor version 2 patch for the HR system (which also serves as the major version upgrade patch from major version 2 to 3 for payroll).

[0150] The patch information is for the business system: HR system, business system major version: 3, and business system minor version: 2. This patch adds data for the major update of subsystems, specifically for payroll, including data for the "Payroll Jobs A, B, C_Ver3" job modules under "Major Version 3". This patch updates the usable payroll version in subsystem Ver Master 106b from 2 to 3.

[0151] Figure 18C shows the (1) version control system table, (2) major version table, (3) actual table, and (4) job module control table after patch application.

[0152] Process 1: The data included in the patch to be applied is reflected in the major version menu display job master 106d and job module master 106f.

[0153] Process 2: For each "product" in subsystem Ver Master 106b, data matching the "Major Ver" of that "product" is extracted from major version menu display job master 106d, and menu display job master 106e is updated. In this example, three new details have been added to major version menu display job master 106d, but there are no details that match the extraction criteria by "Major Ver" of the "product," so menu display job master 106e is not updated. At this point, the results of the subsystem's major version upgrade are not reflected in menu display job master 106e. Therefore, the jobs available on the menu do not change.

[0154] Process 3: Apply the scripts included in the patch to subsystem Ver Master 106b. In this example, the available payroll version in subsystem Ver Master 106b will be updated to "3".

[0155] Process 4: Based on the patch information, update the patch application history master 106c to add the main system "HR system", major version "3", and minor version "2". In this case, since the major version of the HR system does not change, the business system version master 106a is not updated. The available versions of payroll in the subsystem version master are updated in process 3.

[0156] (Solution strategy (4)) Solution (4) will be explained with reference to Figures 19A to 19C.

[0157] In the work decision flow shown in Figure 13 above, step S1 determines whether the major version of the business system in the "version before processing" and the "version after processing" are the same, and since they are the same, the answer is "Yes". Step S2 determines whether the minor version of the business system in the "version before processing" and the "version after processing" are the same, and since they are the same, step S3 determines whether the major version of the "current version" and the "available version" of each subsystem are the same, and since they are not the same, the major version update job is executed (step S6).

[0158] Refer to Figures 19A to 19C to explain the control during execution of a major version update job. Here, we will explain the case of updating the major version of payroll to version 3.

[0159] Figure 19A shows (1) the version control system table, (2) the major version-specific table, (3) the actual table, and (4) the job module control table before the execution of a major version update job, and is the same as in Figure 18C.

[0160] Figure 19B is a diagram illustrating a major version update job. On the major version update job screen 500, select the product you want to update with the major version update job and press the execute button. This example explains the case where the second row is selected and the major version of the product "Payroll" is updated from "2" to "3".

[0161] This document describes the steps involved in the process performed by a major version update job.

[0162] 1. Determine if an upgrade is possible for the selected product, taking dependencies into consideration. Assuming complex cases with dependencies between subsystems, etc., control the major version dependencies between subsystems, etc. (as per requirement (2) above).

[0163] The Major Version Upgrade Check Master 106g registers products and check entries in association. In this example, the Payroll Check Stored entry determines that the Major Version of the HR system is greater than or equal to the Major Version of the Payroll system scheduled for update. Since Major Version 3 of the HR system equals Major Version 3 of the Payroll system scheduled for update, it determines that the "Payroll" product can be upgraded.

[0164] 2. For the selected product, update the major version of subsystem Ver Master 106b to a usable version.

[0165] 3. Recreate the menu display job master 106e based on the information from the major version menu display job master 106d and subsystem version master 106b.

[0166] For each selected product, data from the menu display job master 106e that shows a major version in the major version-specific menu display job master 106d that differs from the major version in the subsystem version master 106b is deleted. Additionally, for each selected product, data from the menu display job master 106e that shows a major version in the major version-specific menu display job master 106d that is identical to the major version in the subsystem version master 106b is added.

[0167] In this example, we will delete the data for jobs in the menu display job master 106e where the major version of payroll in the major version-specific menu display job master 106d is not 3. We will add the data for jobs in the menu display job master 106e where the major version of payroll in the major version-specific menu display job master 106d is 3.

[0168] The major version upgrade execution stored procedure master 106h registers products and execution stored procedures in association. In this example, the payroll execution stored procedure updates the information of the new major version in the menu display job master 106e, based on the major version-specific menu display job master 106d.

[0169] Figure 19C shows the (1) version control system table, (2) major version table, (3) actual table, and (4) job module control table after the execution of a major version update job. Based on (2) the major version table, the data in (3) the actual table is switched from the old major version data to the new major version data, thereby performing a data update equivalent to that of a conventional patch application. As a result, the jobs available in the menu are also switched to the new version.

[0170] (supplement) Refer to Figures 20A and 20B to explain the cases in which the check for "1. Determine whether an upgrade is possible for the selected product, taking dependencies into consideration" in the above resolution policy (4) fails when executing a major version update job.

[0171] Consider the situation described above, where further patches have been applied, a HR-focused My Number system (Major Ver1) has been added, and the usable versions of both the HR system and the HR-focused My Number system are now 2. Furthermore, it is assumed that the "HR-focused My Number system" depends on the "HR system," and that in order to upgrade the version of the "HR-focused My Number system," the higher-level system it depends on must first be updated to the new version. As an example of a check that fails, consider the case where only the HR-focused My Number system is upgraded.

[0172] Figure 20A shows the (1) version control system table before the execution of the major version update job. The third row of subsystem Ver Master 106b shows product "My Number for HR", major Ver "1", and available Ver "2".

[0173] Figure 20B is a diagram illustrating the major version update job. On the major version update job screen 500, select the product you want to update with the major version update job and press the execute button. This example explains the case where the third row is selected, and the major version update of the product "My Number for HR" is selected from "1" to "2".

[0174] This document describes the steps involved in the process performed by a major version update job.

[0175] 1. Determine if an upgrade is possible for the selected product, taking dependencies into consideration.

[0176] In Major Version Upgrade Check Master 106g, the HR-focused My Number Check Stored for the product "HR Minor Version" determines that an upgrade is possible if the planned major version of the HR system update is greater than or equal to the planned major version of the HR-focused My Number system update. Otherwise, it determines that an upgrade is not possible. In this example, the HR system's major version is not scheduled for an update, so it remains at "1," while the HR-focused My Number system's major version is scheduled to be updated to "2." Therefore, the conditions for the HR-focused My Number Check Stored are not met. If an upgrade is determined to be impossible, the process is terminated.

[0177] As described above, according to this embodiment, there is a master for managing the current major version and updatable major versions of a subsystem, a subsystem version master that registers subsystems, the current major version and available versions in association, a master for managing jobs available for each major version of each subsystem, a major version master that registers subsystems, jobs and major versions in association, an actual master that registers jobs available in the current subsystem from among the jobs in the major version master, a master for managing the association between each job and module in the major version master, a job module master that registers jobs, binaries, modules and paths in association, created for each major version and minor version of the main system, major version upgrade patches and minor version upgrade patches for the main system, and for upgrading the major versions of multiple subsystems, the major version upgrade patches or The system includes a DB that stores a patch containing version upgrade data for the major version of a subsystem, which is updated by applying the aforementioned minor version upgrade patch, and an application unit 102b that applies the DB patch to the target system 400 to perform the version upgrade. The application unit 102b refers to the subsystem version master to determine whether the current version of the major version of each subsystem is the same as the available version. If they are different, it executes a major version update job for the different subsystem using the version upgrade data for the major version of the subsystem in the patch, updates the major version of the subsystem version master to the available version, deletes data in the major version-specific master where the major version is different from the major version of the subsystem version master, and adds data in the major version-specific master where the major version is the same as the major version of the subsystem major version master.This makes it easy to manage the versions of multiple subsystems that exist beneath the main system.

[0178] [5. Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This embodiment can contribute to improving operational efficiency and promoting appropriate management decisions by companies, thereby contributing to SDGs Goals 8 and 9.

[0179] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and digital processes, thereby contributing to SDGs Goals 12, 13, and 15.

[0180] Furthermore, this embodiment can contribute to strengthening control and governance, thereby enabling contributions to SDG Goal 16.

[0181] [6. Other Embodiments] In addition to the embodiments described above, the present invention may be implemented in various different embodiments within the scope of the technical idea described in the claims.

[0182] For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods.

[0183] Furthermore, the processing procedures, control procedures, specific names, information including parameters such as registration data and search conditions for each process, screen examples, and database configuration shown in this specification and in the drawings may be changed at will unless otherwise specified.

[0184] Furthermore, with respect to the synchronous control device 100, each component shown in the illustration is a functional concept and does not necessarily have to be physically configured as shown.

[0185] For example, the processing functions of the synchronous control device 100, particularly those performed in the control unit, may be implemented in whole or in part by a CPU and a program interpreted and executed by the CPU, or they may be implemented as wired logic hardware. The program is recorded on a non-temporary computer-readable recording medium containing programmed instructions for the information processing device to execute the processing described in this embodiment, and is mechanically read by the synchronous control device 100 as needed. That is, a storage unit such as ROM or HDD (Hard Disk Drive) stores a computer program that works in cooperation with the OS to give instructions to the CPU and perform various processing tasks. This computer program is executed by being loaded into RAM and works in cooperation with the CPU to constitute the control unit.

[0186] Furthermore, this computer program may be stored on an application program server connected to the synchronization control device 100 via any network, and it is possible to download all or part of it as needed.

[0187] Furthermore, the program for executing the processing described in this embodiment may be stored on a non-temporary computer-readable recording medium, or it may be configured as a program product. Here, "recording medium" includes any "portable physical medium" such as memory cards, USB (Universal Serial Bus) memory, SD (Secure Digital) cards, flexible disks, magneto-optical disks, ROMs, EPROMs (Erasable Programmable Read Only Memory), EEPROMs (Registered Trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROMs (Compact Disk Read Only Memory), MOs (Magneto-Optical disks), DVDs (Digital Versatile Disks), and Blu-ray (Registered Trademark) Discs.

[0188] Furthermore, "program" refers to a data processing method described in any language or writing method, regardless of its format, such as source code or binary code. Note that "program" is not necessarily limited to a single, monolithic structure; it also includes distributed structures consisting of multiple modules or libraries, and those that work in cooperation with other programs, such as an operating system, to achieve their functions. Regarding the specific configuration and reading procedures for reading the recording medium in each device shown in the embodiments, as well as the installation procedures after reading, well-known configurations and procedures can be used.

[0189] The various databases stored in the memory unit are memory devices such as RAM and ROM, fixed disk devices such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and website provision.

[0190] Furthermore, the synchronization control device 100 may be configured as an information processing device such as a known personal computer or workstation, or as an information processing device to which any peripheral device is connected. Alternatively, the synchronization control device 100 may be implemented by implementing software (including programs or data, etc.) that realizes the processing described in this embodiment on the device.

[0191] Furthermore, the specific forms of distribution and integration of the devices are not limited to those shown in the figures, and all or part of them can be configured by functionally or physically distributing and integrating them in any unit according to various additions or functional loads. In other words, the embodiments described above may be implemented in any combination, or the embodiments may be implemented selectively. [Industrial applicability]

[0192] This invention is useful in all industries and sectors. [Explanation of Symbols]

[0193] 100 Synchronous control device 102 Control Unit 102a Creation Department 102b Applicable part 102c Master Maintenance Department 102d Screen display control unit 104 Communication Interface Section 106 Storage section 106a Business System Version Master 106b Subsystem Ver Master 106c Patch Application History Master 106d Major Version-Specific Menu Display Job Master 106e Menu Display Job Master 106f Job Module Master 106g Major Version Upgrade Check Master 106h Major version upgrade execution stored master 106i Patch DB 108 Input / Output Interface Section 112 Input device 114 Output device 200 servers 300 Networks 400 System

Claims

1. A synchronous control device for upgrading the version of a target system, which consists of a main system that is the unit for the introduction and management of multiple subsystems installed in a component-type manner and includes a control unit, and multiple subsystems that are further subdivided from the main system and are units for the introduction and management of application groups including job modules, The control unit, This is a master for managing the current major version and updatable major versions of subsystems, and it is a subsystem version master that registers subsystems, their current major version, and available versions in association with each other. This is a master for managing the jobs available for each major version of each subsystem, and it is a major version-specific master that associates subsystems, jobs, and major versions. Of the jobs in the aforementioned major version master, the actual master registers the jobs that are currently available in the subsystem, This is a master for managing the association between each job and module in the aforementioned major version master, and includes a job module master in which jobs, binaries, modules, and paths are registered in association, A database for storing patches, created on a major and minor version basis for the main system, containing major version upgrade patches and minor version upgrade patches for the main system, and for upgrading the major versions of multiple subsystems, which are updated by applying the major version upgrade patch or the minor version upgrade patch for the subsystems. It is configured to be accessible, The system is provided with an application means for performing a version upgrade by applying the DB patch to the target system. The aforementioned application means is A synchronization control device characterized by referring to the subsystem version master to determine whether the current version of the major version of each subsystem is the same as the available version, and if they are different, executing a major version update job for the different subsystem using the patch's major version upgrade data for the subsystem, updating the major version of the subsystem version master to the available version, deleting data in the major version-specific master where the major version is different from the major version of the subsystem version master, and adding data in the major version-specific master where the major version is the same as the major version of the subsystem version master.

2. The synchronization control device according to claim 1, wherein the application means executes a major version update job for an available version for a subsystem selected by an operator on a display screen, among subsystems where the current version of the major version is different from the available version.

3. The synchronization control device according to claim 2, characterized in that the application means determines whether a version upgrade is possible for a selected subsystem, taking into account its dependencies, and executes a major version update job if it is determined that a version upgrade is possible.

4. The synchronization control device according to claim 3, wherein the application means determines that a version upgrade is possible and executes a major version update job when the major version of the main system is greater than or equal to the available major version of the selected subsystem.

5. The control unit further, This is for managing the current major version of the main system, and it registers the main system version master, which associates the main system with the current major version, This is a master for managing patch versions applied to the main system, and it is a patch application history master that registers the main system, major version, and minor version in association with each other. It is configured to be accessible, The aforementioned application means is The synchronization control device according to claim 1, characterized in that it refers to the main system version master to determine whether the current major version of the main system is the same as the version to be updated, and if they are different, applies the major version upgrade patch among the patches to be applied to the main system, further updates the current major version of the main system in the main system version master to the updated version, and adds the major version of the main system to which the patch application history master was applied.

6. The aforementioned application means is The synchronization control device according to claim 5, characterized in that it refers to the patch application history master to determine whether the current version of the main system's minor version is the same as the version to be updated, and if they are different, it applies the minor version upgrade patch among the patches to be applied to the main system, and further reflects the data for the major version upgrade of multiple subsystems included in the applied patch to the major version master and the job module master, reflects only the data corresponding to the current major version of the reflected major version master to the actual master, updates the available major versions of the subsystem version master based on the data for the major version upgrade of multiple subsystems, and adds the updated minor version of the main system to the patch application history master.

7. The synchronous control device according to claim 1, characterized in that the main system includes a business system.

8. A synchronization control method for upgrading the version of a target system, which consists of a main system, which is the unit for the introduction and management of multiple subsystems introduced in a component-type manner, and multiple subsystems, which are further subdivided from the main system and are units for the introduction and management of application groups including job modules, the main system being executed by an information processing device equipped with a control unit, The control unit, This is a master for managing the current major version and updatable major versions of subsystems, and it is a subsystem version master that registers subsystems, their current major version, and available versions in association with each other. This is a master for managing the jobs available for each major version of each subsystem, and it is a major version-specific master that associates subsystems, jobs, and major versions. Of the jobs in the aforementioned major version master, the actual master registers the jobs that are currently available in the subsystem, This is a master for managing the association between each job and module in the aforementioned major version master, and includes a job module master in which jobs, binaries, modules, and paths are registered in association, A database for storing patches, which are created on a major version and minor version basis for the main system, and which include major version upgrade patches and minor version upgrade patches for the main system, and which are used to upgrade the major versions of multiple subsystems, and which are updated by applying the major version upgrade patch or the minor version upgrade patch for the subsystems. It is configured to be accessible, The control unit is executed as follows: This includes an application process to upgrade the target system by applying the DB patch, In the aforementioned application process, A synchronization control method characterized by referring to the subsystem version master to determine whether the current version of the major version of each subsystem is the same as the available version, and if they are different, executing a major version update job for the different subsystem using the patch's subsystem major version upgrade data to update the major version of the subsystem version master to the available version, deleting data in the major version-specific master where the major version is different from the major version of the subsystem version master, and adding data in the major version-specific master where the major version is the same as the major version of the subsystem version master.

9. This is a synchronization control program for performing a version upgrade on an information processing device equipped with a control unit, which consists of a main system that is the unit for the introduction and management of multiple subsystems introduced in a component-type manner, and multiple subsystems that are further subdivided from the main system and are units for the introduction and management of application groups including job modules. The control unit, This is a master for managing the current major version and updatable major versions of subsystems, and it is a subsystem version master that registers subsystems, their current major version, and available versions in association with each other. This is a master for managing the jobs available for each major version of each subsystem, and it is a major version-specific master that associates subsystems, jobs, and major versions. Of the jobs in the aforementioned major version master, the actual master registers the jobs that are currently available in the subsystem, This is a master for managing the association between each job and module in the aforementioned major version master, and includes a job module master in which jobs, binaries, modules, and paths are registered in association, A database for storing patches, which are created on a major version and minor version basis for the main system, and which include major version upgrade patches and minor version upgrade patches for the main system, and which are used to upgrade the major versions of multiple subsystems, and which are updated by applying the major version upgrade patch or the minor version upgrade patch for the subsystems. It is configured to be accessible, In the control unit, This is a synchronization control program for executing an application process to upgrade the target system by applying the DB patch, In the aforementioned application process, A synchronization control program characterized by referring to the subsystem version master to determine whether the current version of the major version of each subsystem is the same as the available version, and if they are different, executing a major version update job for the different subsystem using the patch's subsystem major version upgrade data to update the subsystem version master to the available version, deleting data in the major version-specific master where the major version is different from the subsystem version master's major version, and adding data in the major version-specific master where the major version is the same as the subsystem version master's major version.

Images