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-based ERP. The advantages of component-based ERP include that since management is divided for each system, it is possible to add and update the necessary version at the necessary timing. Conventionally, for example, Patent Document 1 exists as an apparatus for performing a system version upgrade.

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-based EPR, when managing different major versions for each of a plurality of subsystems (for example, a salary system and a personnel system) existing under a main system (for example, a business system), if the major versions of the subsystems are different, the system structure changes, and thus 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] In order to solve the above-described problems and achieve the object, the present invention provides a synchronization control device for upgrading the version of a target system including a main system that is an introduction and management unit of a plurality of subsystems to be introduced in a component type and including a control unit, and a plurality of subsystems that are introduction and management units of an application group including job modules obtained by further subdividing the main system. The control unit includes a master for managing the current major version and the updatable major version of the subsystem, a subsystem version master in which the subsystem, the current major version, and the available version are registered in association with each other, a master for managing available jobs for each major version of each subsystem, a master-by-major-version master in which the subsystem, the job, and the major version are registered in association with each other, an actual master in which jobs available in the current subsystem among the jobs of the master-by-major-version master are registered, a master for managing the association between each job and module of the master-by-major-version master, a job module master in which the job, the binary, the module, and the path are registered in association with each other, a database storing patches including data for upgrading the major version of the subsystem, which is created in units of the major version and the minor version of the main system, a patch for upgrading the major version of the main system, a patch for upgrading the minor version, and a patch for upgrading the major version of a plurality of subsystems, and being updated by applying the patch for upgrading the major version or the patch for upgrading the minor version, and an application means for applying the patch of the database to the target system to perform version upgrading. The application means 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, for different subsystems, it uses the data for upgrading the major version of the subsystem of the patch to execute a major version update job of the available version.Update the major version of the subsystem version master to the available version, delete data in the actual master where the major version in the major version-specific master is different from the major version of the subsystem version master, and add data in the major version-specific master where the major version is the same as the major version of the subsystem major version master.

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

[0008] Also, according to one aspect of the present invention, the application means may determine whether the selected subsystem can be upgraded in consideration of the dependency relationship, and execute a major version update job when it is determined that the upgrade is possible.

[0009] Also, according to one aspect of the present invention, the application means may determine that the upgrade is possible and execute 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.

[0010] Also, according to one aspect of the present invention, the record control unit is further for managing the current major version of the main system, and is accessible to the main system version master that registers the main system in association with the current major version, and the master for managing the patch version applied to the main system, the patch application history master that registers the main system, major version, and minor version in association with each other. The application means 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. If they are different, a patch for major version upgrade among the patches to be applied to the main system is applied. Further, the current major version of the main system in the major version master is updated to the updated version, and the major version of the main system applied to the patch application history master may be added.

[0011] Also, according to one aspect of the present invention, the application means refers 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 to be updated. If they are different, a patch for minor version upgrade among the patches to be applied to the main system is applied. Further, data for upgrading the major versions of a plurality of subsystems included in the patch to be applied is reflected in the major version-specific master and the job module master, and only the data corresponding to the current major version of the reflected major version-specific master is reflected in the actual master. Based on the data for upgrading the major versions of the plurality of subsystems, the available major versions of the subsystem version master are updated, and the minor version of the main system updated in the patch application history master may be added.

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

[0013] In order to solve the above-described problems and achieve the object, the present invention provides a synchronization control method for upgrading a target system composed of a main system, which is an introduction and management unit of a plurality of subsystems introduced in a component type and executed by an information processing apparatus including a control unit, and a plurality of subsystems, which are introduction and management units of an application group including job modules obtained by further subdividing the main system. The control unit is a master for managing the current major version and the updatable major version of the subsystem, a subsystem version master in which the subsystem, the current major version, and the usable version are registered in association with each other, a master for managing usable jobs for each major version of each subsystem, a master-by-major-version master in which the subsystem, the job, and the major version are registered in association with each other, an actual master in which the jobs usable in the current subsystem among the jobs of the master-by-major-version master are registered, a master for managing the association between each job and module of the master-by-major-version master, a job module master in which the job, the binary, the module, and the path are registered in association with each other, patches for upgrading the major version and the minor version of the main system, and data for upgrading the major version of the subsystem, which is updated by applying the patch for upgrading the major version or the patch for upgrading the minor version, and is configured to be accessible to a DB that stores the patches. The method includes an application step of applying the patch of the DB to the target system in the control unit to perform an upgrade. In the application step, by referring to the subsystem version master, it is determined whether the current version of the major version of each subsystem is the same as the usable version. If they are different, for different subsystems, using the data for upgrading the major version of the subsystem of the patch, a major version update job of the usable version is executed.Update the major version of the subsystem version master to the available version, delete data from the actual master where the major version in the major version-specific master is different from the major version of the subsystem version master, and add data in the major version-specific master where the major version is the same as the major version of the subsystem major version master.

[0014] In addition, in order to solve the above-described problems and achieve the object, the present invention is for causing an information processing apparatus including a control unit to execute, and is a main system which is an introduction and management unit of a plurality of subsystems introduced in a component type, and a plurality of subsystems which are introduction and management units of an application group including job modules obtained by further subdividing the main system. A synchronization control program for performing a version upgrade of a target system configured by: the control unit is a master for managing the current major version and the updatable major version of the subsystem, a subsystem, and a subsystem version master in which the current major version and the available version are registered in association with each other; a master for managing available jobs for each major version of each subsystem, a major version master in which a subsystem, a job, and a major version are registered in association with each other; an actual master in which jobs available in the current subsystem are registered among the jobs of the major version master; a master for managing the association between each job and a module of the major version master, a job module master in which a job, a binary, a module, and a path are registered in association with each other; a patch including data for upgrading the major version of the subsystem, which is created in units of the major version and the minor version of the main system, and is updated by applying the patch for upgrading the major version or the patch for upgrading the minor version of the main system, and a database for storing the patch; and is configured to be accessible to the database. A synchronization control program for causing the control unit to execute an application process for applying the patch of the database to the target system to perform a version upgrade. In the application process, by referring to the subsystem version master, it is determined whether the current version of the major version of each subsystem is the same as the available version. If they are different, for different subsystems, using the data for upgrading the major version of the subsystem of the patch,Execute the major version update job of the available version, update the major version of the subsystem version master to the available version, delete data in the actual master where the major version in the master by major version is different from the major version of the subsystem version master, and add data in the master by major version where the major version is the same as the major version of the subsystem master version.

Effect of the Invention

[0015] According to the present invention, there is an effect that it becomes possible to easily manage the version of a plurality of subsystems existing below the main system.

Brief Description of the Drawings

[0016]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15A

Figure 15B

Figure 15C

Figure 16A

Figure 16B

Figure 16C

Figure 17

Figure 18A

Figure 18B

Figure 18C

Figure 19A

Figure 19B

Figure 19C

Figure 20A

Figure 20B

[0017] Hereinafter, embodiments of a synchronization control device, a synchronization control method, and a synchronization control program according to the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited by this embodiment.

[0018] [1. Overview] (1) Regarding Terms The meanings of the terms used in the specification and drawings of this application are as follows. · Main system (for example, business system) ··· It is an introduction / management unit for each group of subsystems introduced in a component type. · Subsystem ··· It is an introduction / management unit for an application group (job / module) obtained by further subdividing a business system. Also, a subsystem refers to a product that can be contracted (for example, core accounting system, asset management system). · Major version upgrade (hereinafter, "version" may be abbreviated as "Ver") ··· It is a large-scale change to the system. Generally, it means an incompatible change (such as a change in the framework used) for which the same usage method as before is not guaranteed, but in the present invention, it is not necessarily restricted to this general meaning. The criteria for whether a system undergoes a major version upgrade or a minor version upgrade can be freely determined for each system. · Minor version upgrade ··· It is a small-scale change to the system. Generally, it means a change (such as function enhancement / improvement) for which the same usage method as before can be expected and which is compatible, but in the present invention, it is not necessarily restricted to this general meaning. The criteria for whether a system undergoes a major version upgrade or a minor version upgrade can be freely determined for each system. · Module ··· It is a file required when running an application. For example, files in exe, dll, js, config, xml formats, etc. ·Job... It is a unit of processing executed by a user of the system. Modules are used when using a job, but they are not necessarily associated in a 1:1 manner. Even for the same module, depending on different activation conditions, it may be displayed as a different job on the menu.

[0019] (2) Prior Art and Its Problems There are several types of ERP implementation forms, and one of them is component-based ERP. As an advantage of component-based ERP, since management is separated for each system, it is possible to add and update the necessary version at the necessary timing.

[0020] On the other hand, when managing different major versions for each of a plurality of subsystems existing under one main 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.

[0021] (3) Outline and Effects of the Present Invention Therefore, in the present embodiment, in order to facilitate the version management of a plurality of subsystems existing under the main system, different major versions are made to coexist for the plurality of subsystems, and the major version can be updated at an arbitrary timing.

[0022] As a result, it becomes possible to finely divide the versions according to the customer and perform new introduction and version upgrade. Also, it becomes possible to release without completing the entire system in version upgrade development, and it becomes possible to deliver value to the customer earlier. The synchronization control device of the present invention is Applicable to all industries and sectors.

[0023] [2. Configuration] An example of the configuration of the synchronization control device 100 according to the present embodiment will be described with reference to FIG. 1. FIG. 1 is a block diagram showing an example of the configuration of the synchronization control device 100.

[0024] The synchronization control device 100 is a commercially available desktop personal computer. Note that the synchronization control device 100 is not limited to a stationary information processing device such as a desktop personal computer, and may be a portable information processing device such as a commercially available notebook personal computer, PDA (Personal Digital Assistants), smartphone, or tablet personal computer.

[0025] The synchronization control device 100 includes a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. Each unit included in the synchronization control device 100 is communicably connected via an arbitrary communication path.

[0026] The communication interface unit 104 communicably connects the synchronization control device 100 to the network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function of communicating data with other devices via a communication line. Here, the network 300 has a function of communicably connecting the synchronization control device 100 with the server 200 and the system 400 to be updated, and is, for example, the Internet or a LAN (Local Area Network). Note that data such as various masters and DBs described later may be stored in the server 200, for example.

[0027] The system 400 is, for example, a component type ERP system, and is composed of a main system (for example, a business system (an HR system as an example of a business system)) and a plurality of subsystems (for example, a salary system, a personnel system, etc.) existing in a lower layer of the main system. The synchronization control device 100 performs major updates and minor updates on the main system and the plurality of subsystems of the system 400.

[0028] An input / output interface unit 108 is connected to an input device 112 and an output device 114. As the output device 114, in addition to a monitor (including a home television), a speaker or a printer can be used. As the input device 112, in addition to a keyboard, a mouse, and a microphone, a monitor that collaborates with the mouse to realize a pointing device function can be used. In the following, the output device 114 may be described as the monitor 114, and the input device 112 may be described as the keyboard 112 or the mouse 112.

[0029] The storage unit 106 stores various databases, tables, files, etc. The storage unit 106 records a computer program for giving commands to the CPU (Central Processing Unit) in cooperation with the OS (Operating System) to perform various processes. As the storage unit 106, for example, a memory device such as a RAM (Random Access Memory) or a ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, and an optical disk can be used.

[0030] The storage unit 106 includes, for example, a business system Ver master 106a, a subsystem Ver master 106b, a patch application history master 106c, a menu display job master 106d for each major version, 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 procedure master 106h, a patch DB 106i, etc.

[0031] Note that the functions and contents of each master will be described in detail in [4-2. Master Configuration] of [4. Outline of Processing, etc.] below.

[0032] The patch DB 106i stores patches for upgrading the system 400. The patches are created in units of the major version and the minor version of the main system (for example, patches for major version 1 and minor version 1 of the main system, patches for major version 1 and minor version 2 of the main system, ···). Each patch includes a patch for upgrading the major version of the main system and a patch for upgrading the minor version, and data (including job modules) for upgrading the major versions of a plurality of subsystems, which is updated by applying the patch for upgrading the major version or the patch for upgrading the minor version. The latest patch includes data for upgrading the latest major versions of a plurality of subsystems. In this way, by standardizing the patches, it is easy to manage the major versions of a plurality of subsystems.

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

[0034] Functionally conceptually, the control unit 102 includes 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 above-mentioned patches in units of the major version and the minor version of the main system according to the operation of the developer, and stores them in the patch DB 106i.

[0036] The application unit 102b applies the target patch stored in the patch DB 106i to the system 400 to perform an upgrade. 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 the business system Ver master 106a is the same as the version after processing (scheduled for update). If they are different, apply the patch for major version upgrade among the patches to be applied to the main system. Further, update the current major version of the main system in the business system Ver master 106a to the version after processing, and add the major version of the main system applied to the patch application history master 106c.

[0038] (2) Refer to the patch application history master 106c to determine whether the current version of the minor version of the main system is the same as the version scheduled for update (after processing) (the latest minor version in the patch application history master 106c is the current version). If they are different, apply the patch for minor version upgrade among the patches to be applied to the subsystem. Further, reflect the data for version upgrade of the major versions of the multiple subsystems included in the patch to be applied in the major version - specific menu display job master 106d and job module master 106f, and reflect it only in the menu display job master 106e for the data corresponding to the current major version of the major version - specific menu display job master 106d. Based on the data for version upgrade of the major versions of the 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 the 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, for different subsystems, use the data for major version upgrade of the subsystem to execute the major version update job of the available version, update the major version of the subsystem Ver master 106b to the available version, for the menu display job master 106e, delete the data in the major version - specific menu display job master 106d where the major version is different from the major version of the subsystem version master, and add the data in the major version - specific menu display job master 106d where the major version is the same as the major version of the subsystem Ver master 106b.

[0040] In this case, for the subsystem selected by the operator on the display screen among the subsystems where the current version of the major version is different from the available version, it may be decided to execute the major version update job of the available version.

[0041] Also, for the selected subsystem, determine whether it can be upgraded considering the dependency relationship. If it is determined that it can be upgraded, the major version update job may be executed. For example, when the major version of the main system ≥ the available (scheduled for update) major version of the selected subsystem, execute the major version update job; otherwise, an error message (e.g., "The major version of the subsystem cannot be upgraded") may be output.

[0042] The master maintenance section 102c performs settings of various masters, etc., according to the operations of the operator on the master maintenance screen displayed on the monitor 114, for example.

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

[0044] [3. Problems, Solutions, and Effects] In this section, the background, problems and requirements, solutions, and effects will be described.

[0045] [3-1. Background of the Present Invention] (Features of Component-Type ERP) There are several types of ERP implementation forms, and one of them is component-type ERP. Component-type ERP has the advantage that business systems can be added flexibly according to the required timing and content. However, since each business system of ERP can be componentized and introduced step by step, which is one of the advantages, the introduction timing varies for each business system and it is not always possible to be up-to-date.

[0046] (Regarding System Subdivision and Version Updating) It is necessary to consider the coexistence of business systems with different versions. If the business system and the DB are in a one-to-one relationship, it is possible to maintain version compatibility within each business system. However, when the scale of the entire business system is large, within one DB, the business system may be further subdivided and managed in subsystems. For example, within the main system called the HR (Human Resource) system, there are subsystems such as the personnel system and the salary system. Furthermore, there are subsystems that depend on those subsystems (for example, there is a personnel-specific My Number system used in the personnel system).

[0047] In order to cope with the speed of the times' transformation, it is required to conduct version upgrade development and release for each subsystem. If we create and then release new versions of all subsystems, there will be a situation where the response is delayed. Therefore, assuming that the latest versions of subsystems within the business system are different, a configuration that allows the introducing company to consider the coexistence of versions for each necessary subsystem and perform introduction and version upgrade has come to be required. For example, within the HR system, since the already introduced personnel system cannot be immediately upgraded, it is desired to continue using the old version for a while, while for the newly introduced salary system, it is desired to introduce the latest version, and so on.

[0048] Hereafter, the entire business system may be called the "main system", the subdivided business systems may be called "subsystems", and without distinguishing between the main / subsystems, the introduction unit may be called a "product".

[0049] Therefore, within one business system (DB), there is a requirement to realize the major version control of multiple subsystems, but there are the following issues with this.

[0050] (Conventional version upgrade) Conventionally, since it was only necessary to perform a major version upgrade for one business system (DB) unit, the correspondence between the current major version and the applicable latest patch version was clear, and the control was relatively easy.

[0051] When introducing a new business system (when there is no operation data in the business system's DB), for each business system, when initially introducing, just perform the addition of the DB of the major version at the initial introduction time and apply the update patch to the major / minor version to be used according to the procedure.

[0052] Also, when you want to upgrade the version in an existing introduction environment (when there is production data in the business system's database), create an update patch that performs the version upgrade considering the existing production data, and apply the update patch to the major / minor version you want to use for each business system.

[0053] When standardizing the generation management system of multiple minor version patches according to the major version for the update patches of new introduction / existing environment version upgrades, it is relatively easy and has high maintainability.

[0054] (Issues with version upgrades for each subsystem) On the other hand, assume a scenario where an update patch for a minor version upgrade is applied under the condition that the major versions are different for each subsystem, etc. within one business system (DB).

[0055] When only the newly introduced subsystems, etc. apply the latest major version while maintaining the current major version for the already introduced subsystems, etc., it is necessary to separately manage the update patches for different minor version upgrades according to the major version of the subsystems within one business system (DB). Since the patch lineage increases only with the major version combinations of the subsystems, the maintainability decreases.

[0056] Also, problems such as accidentally major / minor version upgrading an existing system that should not be upgraded due to incorrect patch selection by the update personnel may occur.

[0057] Therefore, while simplifying the update patch to be applied in a unified manner for major / minor version upgrades for each business system (DB) unit as before to enhance maintainability, a new mechanism is required that can safely perform a minor version upgrade only for the necessary components without fail according to the major version of the subsystem.

[0058] Generally, the update management of a hierarchical product system with subsystems under one business system (DB) like this becomes very complicated.

[0059] [3-2. Problems and Requirements] (Problem) When creating patches strictly segmented by units such as subsystems, there are the following problems (1) and (2) where the number of patches and combinations increases, and maintainability and safety decrease.

[0060] (1) Maintainability: The problem that the maintenance load increases when managing multiple system generations (2) Safety: For each combination of introduced subsystems, etc. × major versions, it becomes difficult to determine and collect the corresponding update patches and apply them correctly in the correct order, resulting in the problem of operator judgment errors.

[0061] Figures 2 and 3 are diagrams for explaining these problems. Figures 2 and 3 show the case where the main system is the HR system and the subsystems are salary and personnel.

[0062] The main content included in each patch is as follows. · Scripts to update DB objects such as tables (hereinafter, "table" has the same meaning as "master" and may be denoted as "master") to the latest · Table data update files, scripts · Binary information of program modules

[0063] The processing performed by the major version patch is as follows. Select the appropriate major version update patch for the subsystem. The major version update patch for the subsystem includes the following content. · Table data update files, scripts · Binary information of program modules

[0064] These can vary depending on the major / minor versions of each subsystem and are units that need to be updated while maintaining consistency.

[0065] In the example shown in Figure 2, in addition to the major version update patch that changes the major Ver of salary from 1 to 2 and the major version update patch that changes the major Ver of personnel from 1 to 2, the minor version update patches 1, 2, ··· for major Ver 1 of salary, the minor version update patches 1, 2, ··· for major Ver 2 of salary, the minor version update patches 1, 2, ··· for major Ver 1 of personnel, and the minor version update patches 1, 2, ··· for major Ver 2 of personnel need to be managed separately. Since the patch lineage only increases with the combination of the major versions of the subsystems, maintainability decreases.

[0066] If, in order to improve maintainability, as shown in Figure 3, patches are simply integrated and applied at the business system level instead of at the subsystem level, etc., there will be a problem that updates cannot be made to combinations that leave old versions of subsystems, etc. intact. In Figure 3, only completely identical combinations are okay, and problems occur where it cannot be applied due to inconsistencies caused by differences in subsystem major versions.

[0067] (Requirement) (1) Regardless of the combination of the major versions of the subsystems, enable the minor version to be incremented with a single patch at the business system level. Since the number of patches becomes one, "maintainability (issue (1))" is solved, and since the operator's judgment no longer occurs, "safety (issue (2))" is also solved.

[0068] (2) Assuming a complex case where there are dependencies between subsystems, etc., enable the control of the major version dependencies between subsystems, etc. This prevents operator errors and leads to the solution of "safety (issue (2))".

[0069] [3-3. Solution] (1) Separate the major version table (master) and the actual table (master) to manage data. Specifically, include data of the major versions of multiple subsystems in one patch. Data spanning multiple major versions is stored in the major version table. Only the data corresponding to the currently introduced and operating subsystem versions is reflected in the actual table.

[0070] (2) Provide a major version update function. Specifically, when updating the major version, check the dependencies. Then, based on the major version table, update the data in the actual table.

[0071] Figure 4 is a diagram for explaining the solution method according to this embodiment. In Figure 4, the processing performed in the major version update job is the processing of "checking the dependencies based on the major version up-check master" and "updating the actual table based on the major version table." Also, in the same figure, 500 is a diagram showing an example of the major version update job screen. The major version update job screen includes an execution button for instructing the execution of the major version update and a major version update selection area for selecting the product (subsystem) for which the major version update is to be performed. In the major version update selection area, a checkbox for selecting a row, the product (personnel, salary), the current major Ver, and the available (updatable) major Ver are displayed. When the checkbox is selected and the execution button is pressed, the product in the selected row is updated to the available major Ver.

[0072] In this way, it is possible to select a subsystem for major update on the major version update job screen, assuming a complex case with dependencies among subsystems, etc., so that the major version dependencies among subsystems, etc. can be controlled (the above requirement (2)).

[0073] In this example, the case where the check boxes in the first and second lines are checked and the major Ver of personnel and salary is updated from 1 to 2 will be described.

[0074] As shown in the figure, patches are created in units of the major version and minor version of the main system (HR system), and include patches for major version updates of the main system and patches for minor version updates, as well as data for version updates of the major versions of multiple subsystems. Therefore, regardless of the combination of major versions of subsystems, the minor version can be increased with one patch for the business system (HR system) unit (the above requirement (1)).

[0075] In the example shown in the figure, patches for major version 2 and minor version updates 1, 2,... of the HR system are shown. This patch includes, for example, the following contents.

[0076] · Binary information of program modules (including the following versions) Salary major Ver1 Salary major Ver2 Personnel major Ver1 Personnel major Ver2

[0077] · Data update files for tables by major version (including the following versions) Salary major Ver1 Salary major Ver2 Personnel major Ver1 Personnel major Ver2

[0078] · Script to update the actual table based on the major version - specific table · Script to update DB objects such as tables to the latest version

[0079] (3 - 4) Effect (1) Safe introduction The following content described in the problems is solved, and mistakes in patch application by operators can be prevented. · Maintainability: Since a single patch can achieve parallel management of multiple generations of multiple subsystems, the maintenance load does not increase. · Safety: Since there is only one patch line, there is no need for people to judge the differences in the major versions of subsystems. Also, if there are dependencies between subsystems, etc., they are controlled within the major version update job.

[0080] (2) Early introduction · Since versions can be marked and provided at the subsystem level instead of at the business system level, the version update function of the subsystem can be provided quickly and in fine - grained units without waiting for the version upgrade of other subsystem systems. As a result, it is possible to respond quickly to changes such as system - compliance changes. · For customers whose systems are in operation, data for major version upgrades can be provided first without changing the major version of the currently introduced and operating subsystems.

[0081] As a result, when it is desired to increase the major version of the subsystem, it can be switched at any timing by executing a major version update job instead of applying a patch.

[0082] Note that in this embodiment, the "business system" is described as an example, but the scope of application is not limited to this and is also applicable to other systems composed of a main system and multiple subsystems. For example, it can be applied to any system (such as multiple web services used by general consumers, device control systems, etc.) to which the same version upgrade concept can be applied.

[0083] [Overview of Processing, etc.] In this section, an overview of the processing of the synchronization control device 100 according to the present embodiment will be described.

[0084] [4-1. Overview] An overview of the present embodiment will be described.

[0085] (Patch Format) The patch format in the present embodiment will be described. The patch format is assumed to include the following contents. · Binary information of program modules · Update of tables

[0086] The tables are mainly classified into the following four types.

[0087] (1) Version control system table: A table that controls the versions of business systems and subsystems.

[0088] (2) Major version-specific table: A master that manages data specific to the major versions of subsystems, etc., and is referred to when updating the actual table during patch application and when executing the major version update job.

[0089] (3) Actual table: A table that is actually used by business systems and subsystems.

[0090] (4) Job module control table: A table for managing modules and linking jobs to modules.

[0091] (Solution) Solutions (1) to (4) in the present embodiment will be described.

[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 the minor version patch of the business system, perform the update as follows. · Major version - specific table: Update including data of past major versions that may be mixed. · Actual table: Only perform data update corresponding to the current major version. · Job module control table (binary information of program modules): Update including modules of past major versions that may be mixed (assuming that the folder or file name is separated for each major version).

[0094] Solution (3): Information on the major version upgrade of the subsystem is included in the minor version patch of the business system. Do not perform the major version upgrade of the subsystem at the timing of patch application (the system operation conforms to the major version before application). Update the version control system table, etc.

[0095] Solution (4): The major version upgrade of the subsystem, etc. is performed by executing the major version update job. Based on the major version - specific table, switch the data from the old major version data in the actual table to the new major version to perform data update equivalent to that during the conventional patch application.

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

[0097] (1) Version control system table The version control system table is a table that controls the versions of the business system and subsystems. For example, it includes the business system Ver master 106a, the subsystem Ver master 106b, the patch application history master 106c, etc.

[0098] Figure 5 is a diagram showing a configuration example of the Business System Ver Master 106a. The Business System Ver 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 a table or the like that associates and registers the main system and the current major Ver. In the example shown in the figure, the main system is the "HR System" and the current major Ver is "3".

[0099] Figure 6 is a diagram showing a configuration example of the Subsystem Ver Master 106b. The Subsystem Ver Master 106b is a master for managing the current major version and the updatable major version of the subsystem, and as shown in Figure 6, it can be composed of a table or the like that associates and registers the product (subsystem), major Ver, and usable Ver. In the example shown in the figure, the first row has the product "Personnel", major Ver "1", and usable Ver "1", and the second row has the product "Salary", major Ver "2", and usable Ver "2".

[0100] Figure 7 is a diagram showing a configuration example 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 it can be composed of a table or the like that associates and registers the main system, major Ver, and minor Ver. In the example shown in the figure, the first row has the main system "HR System", major Ver "2", and minor Ver "0", and the second row has the main system "HR System", major Ver "2", and minor Ver "1". The last row is the current major Ver and minor Ver.

[0101] (2) Table by Major Version The table by major version is a master for managing data by major version of the subsystem, etc., and includes the Menu Display Job Master 106d by major version, etc., and it may be other than this. It is referred to when updating the actual table during patch application and when executing the major version update job.

[0102] FIG. 8 is a diagram showing a configuration example of a menu display job master 106d by major version. The menu display job master 106d is a master for managing jobs available for each major version of each subsystem, and as shown in FIG. 8, it can be configured with a table or the like in which a product (subsystem), a job, and a major version are associated and registered. In the example shown in the figure, the first row is the product "Personnel", the job "Personnel Job A_Ver1", and the major version "1", and the second row is the product "Personnel", the job "Personnel Job B_Ver1", and the major version "1".

[0103] (3) Actual table The actual table is a table actually used by the main system and subsystems, and includes a menu display job master 106e and the like, and may be other than this.

[0104] FIG. 9 is a diagram showing a configuration example of a menu display job master 106e. The menu display job master 106e is for managing jobs available for the current combination of subsystems, and registers available jobs.

[0105] (4) Job module control table The job module control table is a table for managing modules and associating jobs with modules, and includes a job module master 106f, a main system module master, and the like.

[0106] FIG. 10 is a diagram showing a configuration example 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 configured with a table or the like that registers by associating a job, a binary, a module name, and a path. In the example shown in the figure, the first row shows the job "Personnel Job A_Ver1", the binary "Binary Data", the module name "Personnel Job A_Ver1.exe", and the path "Personnel Folder￥1.0Bin". The second row shows the job "Personnel Job B_Ver1", the binary "Binary Data", the module name "Personnel Job B_Ver1.exe", and the path "Personnel Folder￥1.0Bin".

[0107] The main system module master can be configured with a table or the like that registers by associating a module name, a binary, a path, and a major version (see, for example, FIG. 15A).

[0108] (5) Others FIG. 11 is a diagram showing a configuration example of the major version upgrade check master 106g. The major version upgrade check master 106g is a master for managing the stored procedures for checking dependencies during a major version upgrade, and as shown in FIG. 11, can be configured with a table or the like that registers by associating a product and a check stored procedure. In the example shown in the figure, the first row shows the product "Personnel" and the check stored procedure "Personnel Check Stored Procedure". The second row shows the product "Salary" and the check stored procedure "Salary Check Stored Procedure".

[0109] FIG. 12 is a diagram showing a configuration example of the major version upgrade execution stored procedure master 106h. The major version upgrade execution stored procedure master 106h can be configured with a table or the like that registers by associating a product and an execution stored procedure as shown in FIG. 12.

[0110] [4-3. Work Judgment Flow] The processing executed by the application part 102b of the present embodiment will be described with reference to FIG. 13.

[0111] Figure 13 is a diagram showing a work determination flow for versioning from the "version before processing" to the "version after processing (planned for update)". The version is defined as follows.

[0112] · "Version before processing": The version at the start of processing · "Version after processing": The version planned (assumed) for update. The version at the end of processing · "Current version": The version at that point during processing · "Usable version": The version indicating up to which version can be updated. It is held in the version control system table.

[0113] In Figure 13, referring to the business system Ver master 106a, it is determined whether the major version of the business system of the "version before processing" and the "version after processing" is the same (step S1).

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

[0115] If the major version of the business system of the "version before processing" and the "version after processing" is not the same ( "No" in step S1), apply the business system major version upgrade patch (step S4: will be described in detail in the solution policy (1) below), and the process proceeds to step S2.

[0116] In step S2, referring to the patch application history master 106c, it is determined whether the minor version of the business system of the "version before processing" and the "version after processing" is the same. If the minor version of the business system of the "version before processing" and the "version after processing" is the same ( "Yes" in step S2), the process proceeds to step S3.

[0117] If the minor versions of the business systems of "version before processing" and "version after processing" are not the same ( "No" in step S2), apply the minor version update patch for the business system (step S5: will be described in detail in the solution guidelines (2) and (3) below), and proceed to step S3.

[0118] In step S3, referring to the subsystem Ver master 106b, it is determined whether the major versions of the "current version" and "usable version" of each subsystem are the same. If the major versions of the "current version" and "usable version" of each subsystem are the same ( "Yes" in step S3), the flow ends.

[0119] If the major versions of the "current version" and "usable version" of each subsystem are not the same ( "No" in step S3), execute the major version update job (step S6: will be described in detail in the solution guideline (4) below).

[0120] Note that if there is a premise that the information on the major version update of the subsystem has already been applied in the application of the business system minor version patch, the order of subsequent application of the business system minor version update patch and execution of the subsystem major version update job may be swapped. Also, it may be in an order sandwiched like application of the business system minor version update patch → execution of the subsystem major version update job → application of the business system minor version update patch.

[0121] Here, the difference between "applying the patch" in S4 and 5 and "executing the version update job" in S6 will be explained. The "applying the patch" includes the following content. (a) For the above major version update, direct update of the actual data of the main system (b) For the subsystem, reservation data update of the "○○ table by major version" required for "subsequently executing the version update job" (c) Among the above (b), for the "Table by Major Version ○○" corresponding to the major version of the product in the subsystem Ver master, update it to the immediate actual table.

[0122] The "Version Update Job" is a reflection of the change in the subsystem version for the above (b). (It means that the process corresponding to "applying a patch" in the conventional problem is executed later.) In other words, · In "applying a patch", actual data that does not correspond to the major version of the product in the subsystem Ver master is not updated (without changing the major version of the introduced product arbitrarily, and reserving and updating the data necessary for the "Version Update Job"). The scope of responsibility and timing for updating the actual data are different. · In the "Version Update Job", actual data corresponding to the change in the major version of the subsystem Ver master product is updated (changing the major version of the introduced product at an arbitrary timing based on the operator's judgment using the reserved and updated data by major version). As a merit of delaying the execution of the process corresponding to "applying a patch", for the customer's operation of major version upgrade, the customer can switch the major version at an arbitrary timing.

[0123] [4-3. Detailed Mechanism] Regarding the details of the mechanism of this embodiment, it will be described with reference to FIGS. 14 to 19C. Hereinafter, an example of the case where the processing of the operation determination flow in FIG. 13 is implemented according to the solution guidelines (1) to (4) will be described.

[0124] Hereinafter, the movement of data when performing version updates as shown in FIG. 14 will be described by way of example. FIG. 14 shows examples of the major version and minor version of the main system (HR system) and subsystems (personnel, salary) before and after the update. As shown in the figure, hereinafter, the case where the major version of the HR system is "2", the minor version is "1", the major version of personnel is "1", and the major version of salary is "2" before the update, and after the update, the major version of the HR system is "3", the minor version is "2", the major version of personnel is "1", and the major version of salary is "3" will be described.

[0125] (Solution approach (1)) Solution approach (1) will be described with reference to FIGS. 15A to 15C.

[0126] In the operation determination flow of FIG. 13 above, in step S1, it is determined whether the major versions of the business systems of "version before processing" and "version after processing" are the same. Since they are not the same, "No", and a major version upgrade patch for the business system is applied (step S4).

[0127] With reference to FIGS. 15A to 15C, the control when applying a major version upgrade patch for the business system will be described. Here, as described above, the case of applying a patch (for example, a patch for major Ver3 and minor Ver0 of the business system) that raises the major Ver of the business system from "2" to "3" will be described.

[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 the main system "HR system" with the current major Ver "2". The subsystem Ver master 106b has, in the first row, the product "Personnel", major Ver "1", available Ver "1", and in the second row, the product "Salary", major Ver "2", available Ver "2". The patch application history master 106c has, in the first row, the system "HR system", major Ver "2", minor Ver "0", and in the second row, the system "HR system", major Ver "2", minor Ver "1". The main system module master has the module name "Menu.exe", binary "Binary data", path "HR system\2.0Bin", and major Ver "2". An example of enhancing the functionality of the menu itself is shown as an example of a major version upgrade of the business system. The jobs that can be used on the menu are Personnel Job A_Ver1, Personnel Job B_Ver2, Salary Job A_Ver2, Salary Job B_Ver1.

[0129] Apply a patch as shown in Figure 15B. This patch is a major version upgrade patch for the business system to make it the HR system (major Ver 2 → 3), and it executes the actual table update (the explanation of the actual table update is omitted as there is no specific content). The patch information is 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 patch application. When a 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". Also, in the third row of the patch application history master 106c, the history of the main system "HR system", major Ver "3", and minor Ver "0" is updated (added).

[0131] (Solution approach (2)) Regarding solution approach (2), it will be described with reference to Figures 16A to 17.

[0132] In the operation determination flow of Figure 13 above, at step S1, it is determined whether the major versions of the business systems of "version before processing" and "version after processing" are the same. Since they are the same, "Yes". At step S2, it is determined whether the minor versions of the business systems of "version before processing" and "version after processing" are the same. Since they are not the same, "No", and a business system minor version upgrade patch is applied (step S5).

[0133] With reference to Figures 16A to 16C, the control during the application of a business system minor version upgrade patch will be described. Here, when the major Ver of personnel is 1 and the major Ver of salary is 2, control is performed so that only the jobs available for that version can be used.

[0134] Figure 16A shows (1) the version control system table, (2) the table by major version, (3) the actual table, and (4) the job module control table before patch application. There is a corresponding (3) actual table in the (2) table by major version. The following is an example, taking the "menu display job master 106e" that controls the display content of the jobs that can be used by the user on the menu. The (1) version control system table is the same as Figure 15(C).

[0135] The menu display job master 106d has, on the first line, product "Personnel", job "Personnel Job A_Ver1", major Ver "1", and on the second line, product "Personnel", job "Personnel Job B_Ver1", major Ver "1", and so on.

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

[0137] The job module master 106f has, on the first line, job "Personnel Job A_Ver1", binary "Binary Data", module name "Personnel Job A_Ver1.exe", path "Personnel Folder￥1.0Bin", and on the second line, job "Personnel Job B_Ver1", binary "Binary Data", module name "Personnel Job B_Ver1.exe", path "Personnel Folder￥1.0Bin", and so on.

[0138] 600 shows the menu screen, and the job data of the menu display job master 106e is displayed as the jobs available on the menu. When the user selects a job, the module (binary) at the corresponding path is executed by referring to the job module master 106f.

[0139] Apply the patch as shown in Fig. 16B. This patch is a minor version upgrade patch for the business system to make it the HR system (minor Ver0→1), and the patch information shows the business system: HR system, business system major Ver: 3, and business system minor Ver: 1. In this patch, as one of the data in the minor version upgrade of the business system, for the personnel of the subsystem, the job modules of "Personnel Job C_Ver1" of "Major Ver1" and "Personnel Job C_Ver2" of "Major Ver2", and for the salary of the subsystem, the job modules of "Salary Job C_Ver1" of "Major Ver1" and "Salary Job C_Ver2" of "Major Ver2" and other data are added. The patch updates to the latest including the data of the past major versions that may be mixed.

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

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

[0142] Process 2: For each "Product" in the subsystem Ver master 106b, extract the data that matches the "Major Ver" of that "Product" from the major - version - specific menu display job master 106d and update the menu display job master 106e. That is, for the menu display job master 106e, only perform the data update corresponding to the current major version. In this example, among the 4 details newly added to the major - version - specific menu display job master 106d, 2 details that meet the extraction conditions by the "Major Ver" of the "Product" are updated in the menu display job master 106e.

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

[0144] Explain the correspondence between jobs and modules. In the above description, for simplicity of explanation, it was described that jobs and modules correspond one-to-one. In reality, there may be cases where multiple jobs use a common module (using different startup arguments for differentiation). Figure 17 is a diagram showing an example of the job module master 106f when multiple jobs use a common module.

[0145] (Solution approach (3)) Regarding solution approach (3), it will be explained with reference to FIGS. 18A to 18C.

[0146] In the operation determination flow of FIG. 13 above, at step S1, it is determined whether the major version of the business system of the "version before processing" and the "version after processing" is the same. Since they are the same, it is "Yes". At step S2, it is determined whether the minor version of the business system of the "version before processing" and the "version after processing" is the same. Since they are not the same, it is "No", and a business system minor version upgrade patch is applied (step S5).

[0147] With reference to FIGS. 18A to 18C, the control during the application of the business system minor version upgrade patch (which also includes an upgrade of the available major version of the subsystem) will be explained. Here, the case of applying a patch that raises the minor Ver of the HR system from 1 to 2 and the available major Ver of salary from 2 to 3 will be explained.

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

[0149] Apply the patch as shown in FIG. 18B. The patch to be applied is a patch for the major version 3 and minor version 2 of the HR system (which also serves as the major version upgrade patch for the available major version 2→3 of the salary).

[0150] The patch information shows the business system: HR system, business system major version: 3, and business system minor version: 2. For this patch, as data for the major update of the subsystem, data for the job modules of "Salary Job A, B, C_Ver3" in "Major Ver3" of the salary has been added. This patch updates the available Ver of the salary in the subsystem Ver master 106b from 2 to 3.

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

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

[0153] Process 2: For each "product" in the subsystem Ver master 106b, extract the data that matches the "major Ver" of that "product" from the major - version - specific menu - display job master 106d and update the menu - display job master 106e. In this example, although 3 new details have been added to the major - version - specific menu - display job master 106d, since there are no details that match the extraction condition by the "major Ver" of the "product", the menu - display job master 106e is not updated. At this point, the result of the major version upgrade of the subsystem is not reflected in the menu - display job master 106e. Therefore, the jobs available on the menu do not change either.

[0154] Process 3: Reflect the script included in the patch in the subsystem Ver master 106b. In this example, the available Ver of the salary in the subsystem Ver master 106b is updated to "3".

[0155] Process 4: Update the patch application history master 106c based on the patch information to add the main system "HR system", major Ver "3", and minor Ver "2". This time, since the major Ver of the HR system does not change, the business system Ver master 106a is not updated. The available Ver of the salary in the subsystem Ver master is updated in Process 3.

[0156] (Solution (4)) Solution (4) will be described with reference to FIGS. 19A to 19C.

[0157] In the operation determination flow of FIG. 13 above, at step S1, it is determined whether the major version of the business system of "version before processing" and "version after processing" is the same. Since they are the same, "Yes". At step S2, it is determined whether the minor version of the business system of "version before processing" and "version after processing" is the same. Since they are the same, at step S3, it is determined whether the major version of the "current version" and "available version" of each subsystem is the same. Since they are not the same, the major version update job is executed (step S6).

[0158] With reference to FIGS. 19A to 19C, the control during the execution of the major version update job will be described. Here, the case where the major Ver of the salary is updated to 3 will be described.

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

[0160] Figure 19B is a diagram for explaining the major version update job. On the major version update job screen 500, select the product to be updated by the major version update job and press the execute button. In this example, the second row is selected, and the case of updating the major Ver of the product "Salary" from "2" to "3" will be explained.

[0161] Explain the procedure of the process to be executed in the major version update job.

[0162] 1. Determine whether the selected product can be versioned up considering the dependencies. Assuming a complex case with dependencies between subsystems etc., control the major version dependencies between subsystems etc. (the above requirement (2)).

[0163] The major version upgrade check master 106g is registered in association with the product and the check store. In this example, for the salary check store, the determination is that the major Ver of the HR system ≥ the major Ver of the salary system to be updated. Since the major Ver 3 of the HR system = the major Ver 3 of the salary system to be updated, it is determined that the product "Salary" can be versioned up.

[0164] 2. Update the major Ver of the subsystem Ver master 106b to an available Ver for the selected product.

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

[0166] For each selected product, delete the data in the menu display job master 106e where the major Ver in the menu display job master 106d by major version is different from the major Ver in the subsystem Ver master 106b. Also, for each selected product, add the data in the menu display job master 106d where the major Ver is the same as the major Ver in the subsystem Ver master 106b to the menu display job master 106e.

[0167] In this example, among the menu display job master 106e, delete the data of the jobs where the major Ver of salary in the menu display job master 106d by major version is not 3. Add the data of the jobs where the major Ver of salary in the menu display job master 106d by major version is 3 to the menu display job master 106e.

[0168] The major version upgrade execution store master 106h registers the association between the product and the execution store. In this example, the salary execution store updates the information of the major Ver after the switching of the menu display job master 106e based on the menu display job master 106d by major version.

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

[0170] (Supplementary) With reference to Figures 20A and 20B, the case where the check of "1. Determine whether the selected product can be upgraded considering the dependencies" in the above solution (4) fails during the execution of the major version update job will be described.

[0171] From the above situation, further patches are applied, and consider the situation where the My Number System for Personnel (Major Ver1) is added and the available Ver of the Personnel System and the My Number System for Personnel is 2. And assume that the "My Number System for Personnel" depends on the "Personnel System", and in order to increase the version of the "My Number System for Personnel", it is necessary to first update the upper-level "Personnel System" to a new version as a prerequisite. As an example where the check fails, consider the case where only the version of the My Number System for Personnel is increased.

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

[0173] Figure 20B is a diagram for explaining the major version update job. On the major version update job screen 500, select the product to be updated by the major version update job and press the execution button. In this example, the third row is selected, and the case where the major Ver of the product "My Number for Personnel" is updated from "1" to "2" is explained.

[0174] Explain the procedure of the process executed by the major version update job.

[0175] 1. Determine whether the selected product can be versioned up considering the dependencies.

[0176] In the major version update check master 106g, for the personnel-oriented minor number check store of the product "Personnel-oriented Minor Version", in this example, when the major version scheduled for update of the personnel system is greater than or equal to the major version scheduled for update of the personnel-oriented minor number system, it is determined that the version can be updated, and in other cases, it is determined that the version cannot be updated. In this example, since there is no scheduled update for the major version of the personnel system, it remains "1", while the major version of the personnel-oriented minor number system is scheduled to be updated to "2". Therefore, the conditions of the personnel-oriented minor number check store are not met. When it is determined that the version cannot be updated, the process is aborted.

[0177] As described above, according to this embodiment, it is a master for managing the current major version and the updatable major version of the subsystem, the subsystem, the subsystem version master in which the current major version and the available versions are registered in association with each other, and it is a master for managing the available jobs for each major version of each subsystem, and the major version-specific master in which the subsystem, the job, and the major version are registered in association with each other, the actual master in which the jobs available in the current subsystem among the jobs of the major version-specific master are registered, and it is a master for managing the association between each job of the major version-specific master and the module, and the job module master in which the job, the binary, the module, and the path are registered in association with each other, the major version and the minor version of the main system created in units thereof, the patch for major version upgrade and the patch for minor version upgrade of the main system, and for upgrading the major versions of a plurality of subsystems, the version upgrade data for the major version of the subsystem, which is updated by the application of the major version upgrade patch or the minor version upgrade patch, and a DB for storing a patch including the above, and an application unit 102b for applying the patch of the DB to the target system 400 to perform a 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, for different subsystems, using the version upgrade data for the major version of the subsystem of the patch, execute the major version update job of the available version, update the major version of the subsystem version master to the available version, delete the data in the actual master in which the major version in the major version-specific master is different from the major version of the subsystem version master, and add the data in the major version-specific master in which the major version is the same as the major version of the subsystem major version master. Therefore,It becomes possible to easily manage the versions of a plurality of subsystems existing below the main system.

[0178] [5. Contribution to the Sustainable Development Goals (SDGs) Led by the United Nations] According to this embodiment, since it can contribute to promoting business efficiency and appropriate management decisions of enterprises, it becomes possible to contribute to Goals 8 and 9 of the SDGs.

[0179] Also, according to this embodiment, since it can contribute to reducing waste loss and promoting paperless and digitization, it becomes possible to contribute to Goals 12, 13, and 15 of the SDGs.

[0180] Also, according to this embodiment, since it can contribute to strengthening control and governance, it becomes possible to contribute to Goal 16 of the SDGs.

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

[0182] For example, among the respective processes described in the embodiment, all or part of the processes described as being automatically performed can also be performed manually, or all or part of the processes described as being manually performed can be automatically performed by a known method.

[0183] Also, regarding the processing procedures, control procedures, specific names, information including parameters such as registered data and search conditions for each process, screen examples, and database configurations shown in this specification and the drawings can be arbitrarily changed unless otherwise specified.

[0184] Also, regarding the synchronization control device 100, each illustrated component is a functional concept and does not necessarily need to be physically configured as illustrated.

[0185] For example, regarding the processing functions provided by the synchronization control device 100, particularly each processing function performed by the control unit, all or any part thereof may be realized by a CPU and a program interpreted and executed by the CPU, or may be realized as hardware by wired logic. Note that the program is recorded on a non-transitory computer-readable recording medium including programmed instructions for causing an information processing device to execute the processing described in the present embodiment, and is mechanically read by the synchronization control device 100 as necessary. That is, in a storage unit such as a ROM or an HDD (Hard Disk Drive), a computer program for giving instructions to the CPU in cooperation with the OS and performing various processes is recorded. This computer program is executed by being loaded into the RAM, and constitutes the control unit in cooperation with the CPU.

[0186] In addition, this computer program may be stored in an application program server connected to the synchronization control device 100 via an arbitrary network, and all or part of it can be downloaded as necessary.

[0187] In addition, a program for executing the processing described in the present embodiment may be stored in a non-transitory computer-readable recording medium, or may be configured as a program product. Here, this "recording medium" includes any "portable physical medium" such as a memory card, a USB (Universal Serial Bus) memory, an SD (Secure Digital) card, a flexible disk, a magneto-optical disk, a ROM, an EPROM (Erasable Programmable Read Only Memory), an EEPROM (registered trademark) (Electrically Erasable and Programmable Read Only Memory), a CD-ROM (Compact Disk Read Only Memory), an MO (Magneto-Optical disk), a DVD (Digital Versatile Disk), and a Blu-ray (registered trademark) Disc.

[0188] In addition, a "program" is a data processing method described in any language or description method, regardless of the form such as source code or binary code. Note that the "program" is not necessarily limited to being configured singly, and also includes those that are distributed and configured as a plurality of modules or libraries, or those that achieve their functions in cooperation with other separate programs represented by an OS. Regarding the specific configuration, reading procedure, and installation procedure after reading for reading a recording medium in each device shown in the embodiments, well-known configurations and procedures can be used.

[0189] Various databases and the like stored in the storage unit are storage means such as a memory device such as a RAM or a ROM, a fixed disk device such as a hard disk, a flexible disk, and an optical disk, and store various programs, tables, databases, and web page files used for various processes and website provision.

[0190] Further, the synchronization control device 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device to which any peripheral device is connected. Further, it may be realized by implementing the synchronization control device 100 and software (including programs or data, etc.) for realizing the processes described in this embodiment in the device.

[0191] Furthermore, the specific form of the distribution and integration of the devices is not limited to that shown in the drawings, and all or part of them can be functionally or physically distributed and integrated in any unit according to various additions or according to the functional load. That is, the above-described embodiments may be arbitrarily combined and implemented, or the embodiments may be selectively implemented.

Industrial Applicability

[0192] The present invention is useful in all industries and business types.

Explanation of Signs

[0193] 100 Synchronization control device 102 Control unit 102a Creation unit 102b Application unit 102c Master maintenance unit 102d Screen display control unit 104 Communication interface unit 106 Memory unit 106a Business system Ver master 106b Subsystem Ver master 106c Patch application history master 106d Menu display job master by major version 106e Menu display job master 106f Job module master 106g Major version upgrade check master 106h Major version upgrade execution stored procedure master 106i Patch DB 108 Input / output interface unit 112 Input device 114 Output device 200 Server 300 Network 400 System

Claims

1. A synchronization control device for upgrading a target system composed of a main system which is an introduction / management unit of a plurality of subsystems introduced in a component type and having a control unit, and a plurality of subsystems which are introduction / management units of an application group including job modules obtained by further subdividing the main system, wherein the control unit is a master for managing the current major version and the updatable major version of a subsystem, a subsystem, and a subsystem version master in which the current major version and the available versions are registered in association with each other, a master for managing available jobs for each major version of each subsystem, a master for each major version in which a subsystem, a job, and a major version are registered in association with each other, an actual master in which jobs available in the current subsystem among the jobs of the master for each major version are registered, a master for managing the association between each job and module of the master for each major version, a job module master in which a job, a binary, a module, and a path are registered in association with each other, a DB that stores patches including data for upgrading the major version of a subsystem, which are created in units of the major version and minor version of the main system, patches for upgrading the major version of the main system and patches for upgrading the minor version, and are updated by applying the patch for upgrading the major version or the patch for upgrading the minor version, is configured to be accessible to, and includes application means for applying the patch in the DB to the target system to perform an upgrade, the application means is Referring to the subsystem version master, determine whether the current version of the major version of each subsystem is the same as the available version. If they are different, for different subsystems, use the version upgrade data of the major version of the patch for the subsystem to execute the major version update job of the available version, update the major version of the subsystem version master to the available version, delete the data in the actual master where the major version in the master by major version is different from the major version of the subsystem version master, and add the data in the master by major version where the major version is the same as the major version of the subsystem version master. A synchronization control device characterized by this.

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

3. The applying means is characterized in that, for the selected subsystem, determine whether it is possible to upgrade the version considering the dependency relationship, and if it is determined that the version can be upgraded, execute the major version update job. The synchronization control device according to claim 2.

4. The applying means is characterized in that, when the major version of the main system ≥ the available major version of the selected subsystem, it is determined that the version can be upgraded, and the major version update job is executed. The synchronization control device according to claim 3.

5. The control unit further is for managing the current major version of the main system, the main system version master registered by associating the main system with the current major version, and is a master for managing the patch version applied to the main system, and is configured to be accessible to the patch application history master registered by associating the main system, major version, and minor version, and the applying means Referring to the main system version master, determine whether the current major version of the main system is the same as the version scheduled for update. If they are different, apply the patch for major version upgrade among the patches to be applied to the main system. Further, update the current major version of the main system in the main system version master to the updated version, and add the major version of the main system applied to the patch application history master. The synchronization control device according to claim 1, characterized in that.

6. The applying means Referring to the patch application history master, 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, apply the patch for minor version upgrade among the patches to be applied to the main system. Further, reflect the data for version upgrade of the major versions of the multiple subsystems included in the patch to be applied in the major version-specific master and the job module master, and reflect it only in the actual master for the data corresponding to the current major version of the major version-specific master thus reflected. Based on the data for version upgrade of the major versions of the multiple subsystems, update the available major versions of the subsystem version master, and add the minor version of the main system updated to the patch application history master. The synchronization control device according to claim 5, characterized in that.

7. The main system includes an operation system. The synchronization control device according to claim 1, characterized in that.

8. A synchronization control method for performing a version upgrade of a target system composed of a main system, which is an introduction and management unit of a plurality of subsystems introduced in a component type, and a plurality of subsystems, which are introduction and management units of an application group including job modules obtained by further subdividing the main system, executed by an information processing device provided with a control unit, wherein The control unit A master for managing the current major version and the updatable major version of the subsystem, a subsystem, and a subsystem version master in which the subsystem is registered in association with the current major version and the available version It is a master for managing jobs available for each major version of each subsystem, and is a master for each major version that registers by associating a subsystem, a job, and a major version, and an actual master that registers jobs available in the current subsystem among the jobs of the master for each major version, and is a master for managing the association between each job and module of the master for each major version, and is a job module master that registers by associating a job, a binary, a module, and a path, and a DB that stores patches including data for upgrading the major version of a subsystem, which is created in units of the major version and minor version of the main system, and is for patches for upgrading the major version and minor version of the main system, and for upgrading the major versions of a plurality of subsystems, and is updated by applying the patch for upgrading the major version or the patch for upgrading the minor version. is configured to be accessible to is executed in the control unit includes an application step of applying the patch of the DB to the target system to perform version upgrade. In the application step, refer 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 different, for different subsystems, use the data for upgrading the major version of the subsystem of the patch to execute a major version update job for the available version, update the major version of the subsystem version master to the available version, delete data in the actual master where the major version in the master for each major version is different from the major version of the subsystem version master, and add data in the master for each major version where the major version is the same as the major version of the subsystem version master. A synchronization control method characterized by this. Claim 9 It is for causing an information processing apparatus having a control unit to execute, and is a synchronization control program for upgrading the version of a target system composed of a main system which is an introduction / management unit of a plurality of subsystems introduced in a component type, and a plurality of subsystems which are introduction / management units of an application group including job modules obtained by further subdividing the main system, The control unit is, A master for managing the current major version and the updatable major version of a subsystem, a subsystem, and a subsystem version master in which the current major version and the available versions are registered in association with each other, A master for managing available jobs for each major version of each subsystem, and a master-by-major-version master in which the subsystem, job, and major version are registered in association with each other, An actual master in which jobs available in the current subsystem are registered among the jobs of the master-by-major-version master, A master for managing the association between each job of the master-by-major-version master and a module, and a job module master in which the job, binary, module, and path are registered in association with each other, A DB that stores patches including data for upgrading the major version of a subsystem, which is created in units of the major version and minor version of the main system, patches for upgrading the major version and minor version of the main system, and is updated by applying the patch for upgrading the major version or the patch for upgrading the minor version, Is configured to be accessible to, In the control unit, It is a synchronization control program for causing the application process for upgrading the version by applying the patch of the DB to the target system to execute, In the application process, Refer 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, for different subsystems, use the version update data of the major version of the patched subsystem to execute the major version update job of the available version, update the major version of the subsystem version master to the available version, delete the data in the actual master where the major version in the major version-specific master is different from the major version of the subsystem version master, and add the data in the major version-specific master where the major version is the same as the major version of the subsystem version master. A synchronization control program characterized by this is provided.

Images