WO2014049803A1 - 計算機、バッチジョブ生成方法及び記録媒体 - Google Patents

計算機、バッチジョブ生成方法及び記録媒体 Download PDF

Info

Publication number
WO2014049803A1
WO2014049803A1 PCT/JP2012/075001 JP2012075001W WO2014049803A1 WO 2014049803 A1 WO2014049803 A1 WO 2014049803A1 JP 2012075001 W JP2012075001 W JP 2012075001W WO 2014049803 A1 WO2014049803 A1 WO 2014049803A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
format
batch
reorganization
computer
Prior art date
Application number
PCT/JP2012/075001
Other languages
English (en)
French (fr)
Inventor
星野　康
昌洋 津村
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2012/075001 priority Critical patent/WO2014049803A1/ja
Publication of WO2014049803A1 publication Critical patent/WO2014049803A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management

Definitions

  • the present invention relates to a computer, a batch job generation method, and a recording medium, and more particularly to a computer that generates composite data from format data and content data, a batch job generation method, and a non-temporary recording medium that stores a program to be executed by the computer. .
  • Patent Document 1 discloses a technique of dividing a batch processing data processing request (batch job) and performing parallel processing. By using this to divide a batch job including a large amount of batch data, it can be said that a batch job including a small amount of batch data can be interrupted between the divided batch jobs.
  • Patent Document 1 in the case of a form format that has data characteristics such that the size of content data to be embedded in one format is determined in advance, as disclosed in Patent Document 1, a batch job that is simply batch processed is divided. Then, there is a possibility that composite data in which content data to be processed is embedded at a position different from the format data that should be embedded is generated.
  • Fig. 1 schematically shows an example of dividing a batch job simply.
  • the batch data 1 is content data, and is data indicating a credit usage history for each user.
  • the credit usage history of “Tanaka” has 7 records, but the batch data is divided in the middle, and divided into the first half (5a) and the second half (5b).
  • the number of batch jobs for creating a form becomes 1 to 2, and data 5a is processed by the first half batch job, and data 5b is processed by the second half batch job.
  • FIG. 1 schematically shows the credit usage details 10A to 30A, which are form data created based on the batch data of “Tanaka”. It is assumed that one credit usage detail data format has data characteristics of embedding three records of content.
  • the first three records are generated as credit usage details data 10A (embedded in the item fields 13a to 13c), and the remaining two records are generated as credit usage details data 20A. (Embedded in the item fields 23a and 23b).
  • the remaining two records (5b) of the Tanaka data become batch data by the next batch job. Therefore, the remaining two records 5b are embedded in a new form format, and form data is created as the credit usage details 30A.
  • the usage history “6/21, cafe A, 1000 yen” embedded in the item column 33a should be embedded in the item column 23c of the credit usage details data 20 originally. Will be embedded. Thus, it is necessary to generate a batch job in consideration of the data characteristics of the format data.
  • a computer for managing content data for generating composite data by applying to format data the storage unit storing characteristic information including information on the size of content data applicable to the format data, and the content
  • a control unit that generates batch data * 4 corresponding to the characteristic information from the data, and generates a batch job for outputting the content data to be applied to the format in one or more generated batch data units; Apply the computer that has.
  • a batch job can be generated in consideration of the data characteristics of format data to which content data is applied.
  • FIG. 1 is a schematic diagram showing a problem of the prior art.
  • FIG. 2 is a block diagram showing the configuration of the computer system according to the first embodiment to which the present invention is applied.
  • FIG. 3 is a schematic diagram illustrating an example of data characteristic information according to the first embodiment.
  • FIG. 4 is a schematic diagram illustrating an example of reorganization correspondence information according to the first embodiment.
  • FIG. 5 is a schematic diagram illustrating an example of a form format according to the first embodiment.
  • FIG. 6 is a flowchart showing the flow of overall processing of the preprocessing unit of the first embodiment.
  • FIG. 7 is a flowchart showing the flow of the reorganization process of the first embodiment.
  • FIG. 8 is a flowchart showing the flow of the post-processing unit of the first embodiment.
  • FIG. 1 is a schematic diagram showing a problem of the prior art.
  • FIG. 2 is a block diagram showing the configuration of the computer system according to the first embodiment to which the present invention is applied.
  • FIG. 9 is a schematic diagram illustrating an example of form data generated by the computer system according to the first embodiment.
  • FIG. 10 is a block diagram illustrating an example of a computer system according to the second embodiment.
  • FIG. 11 is a schematic diagram illustrating an example of pre-reorganization data according to the second embodiment.
  • FIG. 12 is a schematic diagram illustrating an example of a composite form format according to the second embodiment.
  • FIG. 13 is a schematic diagram illustrating an example of data characteristic information according to the second embodiment.
  • FIG. 14 is a schematic diagram illustrating an example of reorganization correspondence information according to the second embodiment.
  • FIG. 15 is a flowchart showing the flow of processing of the preprocessing unit of the second embodiment.
  • FIG. 16 is a flowchart showing the flow of data reorganization processing of the second embodiment.
  • FIG. 17 is a schematic diagram illustrating an example of form data generated by the computer system according to the second embodiment.
  • FIG. 2 schematically shows the configuration of a computer system 100 to which the present invention is applied.
  • the computer system 100 includes a client 200 and a server 300 that are communicably connected via a network 400.
  • the client 100 is a general-purpose computer device such as a PC, a server, or a mobile computer.
  • the server 300 is also a general-purpose server device.
  • a client / server type will be described as an example.
  • the present invention can also be applied to a single computer in a PC or a server.
  • the client 200 holds pre-reorganization data 210 as, for example, a text format file as monthly usage details for each credit user.
  • pre-reorganization data 210 is a file (for example, batch data 1 shown in FIG. 1) in which records of respective usage details are grouped based on identification information such as “Tanaka data” and “Suzuki data”. Data set).
  • the client 200 holds data characteristic information 230 indicating data characteristics of the form format 310 and reorganization correspondence information 240 that records the correspondence between the data before and after the reorganization.
  • the data characteristic information 230 indicates the size and number of records of content data that can be embedded in the form format. Further, the data characteristic information 230 can be acquired from the server 300, generated by input through the input / output unit 204 of the client 200, or acquired from an external system (not shown). ing. In the present embodiment, the data characteristic information 230 is described as being acquired or received from the server 300.
  • FIG. 3 schematically shows the data characteristic information 230.
  • the data characteristic information 230 holds a format ID 231 for identifying the format data of the form and the data characteristic 232 of the form format 320 in association with each other.
  • data characteristics an example is shown in which the number of data records embedded in a single form format 320 is three records.
  • ID user value
  • the reorganization correspondence information 240 is recorded in association with pre-reorganization data 210 and post-reorganization data 217 obtained by dividing the pre-reorganization data 210 by the reorganization processing by the preprocessing unit 213. This is information for managing the correspondence between data before and after the organization process.
  • FIG. 4 schematically shows the reorganization correspondence information 240.
  • the reorganization correspondence information 240 includes pre-reorganization data identification information 241 that is information for identifying the pre-reorganization data 210 for each credit user, and a reorganization data 217 that is generated from the pre-reorganization data 217.
  • the post-organization data identification information 242 is associated.
  • the reorganization correspondence information 240 when these user IDs are the same for the three records of the pre-reorganization data 210, the reorganization data 217 generated as data for one page of the form is reorganized. “1” is generated as the post-data identification information 242 and is registered in association with the pre-reorganization data identification information 241. On the condition that the pre-reorganization data identification information 241 is the same, information indicating the second page and the third page is sequentially generated for the post-reorganization data 217 regarding the subsequent fourth and subsequent records.
  • a pre-processing unit 213 and a post-processing unit 215 are realized in the main storage device 202 of the server 200 in cooperation with the program and the CPU 201.
  • post-reorganization data 217 is generated from the pre-reorganization data 210 based on the data characteristic information 230.
  • the data characteristic of the form format 320 embeds 3 records of content data per page.
  • one post-reprocessing data 217 is generated for three records from the top of the pre-reedit data 210.
  • the form data generated by the server 300 and output to the client 200 is output as one data (for example, a file) for each page. Even if the credit usage details of the same user span multiple pages, they are output as separate files. Therefore, the post-processing unit 215 combines the form data having the same pre-reorganization data identification information 241 corresponding to the reorganization correspondence information 240 based on the post-reorganization data identification information 242 of the received individual form data. Thus, one collective form data is generated for each user.
  • the post-reorganization data identification information 242 is “1 / 1 ⁇ 3”, and the data for three pages Form data (file) is generated.
  • the three data (files) are combined to generate one form data (file) of the credit usage details for Tanaka.
  • the post-reorganization data identification information 242 is “2/1 page”, so one page of form data (file) is created. Will be.
  • the post-reorganization data buffers 220a to 220c are areas in which post-reorganization data 220 generated by the reorganization processing of the pre-processing unit 213 is temporarily stored.
  • the post-reorganization data buffer 220 has a predetermined buffer capacity, and the buffer size can be arbitrarily set. For example, the number of divisions and the individual buffer capacity of the data buffer 220 after reorganization are designated by an instruction command from the server 300 or the input / output unit 204.
  • the post-reorganization data 217 is stored in the post-reorganization data buffer 220a. After that, if the capacity of 220a is insufficient, it is used in the order of 220b and then 220c. Further, the post-reorganization data group held in one post-reorganization data buffer 220 becomes batch data included in a batch job of one form data creation process. That is, a single batch job is generated in batch data units.
  • the batch job can be divided into a plurality of jobs, and job breaks can be generated, and the processing order of various badge jobs can be adjusted. Will be able to.
  • the batch job may be transmitted to the server 300 when the storage capacity of the post-reorganization data buffers 220a to 220c is satisfied, or the batch job may be transmitted as appropriate, or all reorganization data 217 is generated. May be transmitted at predetermined intervals in the order of the data buffers 220a to 220c after reorganization.
  • the capacity is less than the capacity of one post-reorganization data buffer 220, and the last post-reorganization data 217 stored in the buffer satisfies the data characteristics of the form format 320.
  • batch jobs can be generated.
  • the post-reorganization data 217 stored in each of the post-reorganization data buffers 220a to 220c can be managed as batch data for another batch job.
  • the server 300 includes various form formats 320 and a data processing unit 310.
  • the data processing unit 310 is a functional unit realized by the cooperation between the program and the CPU 301.
  • the post-reorganization data 217 acquired from the client 200 and the form format 320 are combined, and form data 340 for each post-reorganization data 217 is generated in a predetermined data format (for example, PDF). It has become so.
  • the generated form data 340 is transmitted to the requesting client 200 at a predetermined opportunity.
  • FIG. 5 schematically shows an example of the form format 320.
  • a form title 321 (“credit card usage details”) is set as a part of the format, and an issuer display field 322, a user name display field 323, and a usage details display field 325a ⁇ c is provided.
  • the form format 320 holds a plurality of types of data limited to one, and various form data can be generated by a predetermined setting.
  • FIG. 6 shows a processing flow of the preprocessing unit 213.
  • the pre-processing unit 213 receives a form creation processing instruction input via the input / output unit 204 or the like, and acquires a target form format ID and target pre-reorganization data 210 included in the instruction.
  • the form format ID is “A”.
  • the preprocessing unit 215 refers to the data characteristic information 230 based on the designated form format ID, and acquires the data characteristic information corresponding to the form format ID “A”.
  • the preprocessing unit 215 acquires the data characteristic information corresponding to the form format ID “A”.
  • the pre-processing unit 213 executes reorganization processing for generating post-reorganization data 217 from the pre-reorganization data 210 based on the data characteristic information 230. Details will be described later with reference to FIG.
  • the preprocessing unit 213 transmits a batch job to the server 300 as a form data creation target for the reorganized data 217 stored in the post-reorganization data buffer 220a.
  • FIG. 7 shows a flow of reorganization processing of the preprocessing unit 213.
  • the preprocessing unit 215 reads up to three records having the same user ID from the top record of the pre-reorganization data 210.
  • the preprocessing unit 213 adds three records (which may include blank lines) and generates post-reorganization data 217.
  • the user ID (pre-reorganization data identification information 241) of the generated post-reorganization data 217 and the post-reorganization data identification information 242 are associated with each other and recorded in the reorganization association information 240. At this time, the information indicating how many pages the post-reorganization data 217 has in the user ID is also recorded.
  • the preprocessing unit 213 determines whether the generated post-regeneration data 217 can be stored in the post-reorganization data buffer 220a. Specifically, even if the generated post-reorganization data 217 is stored, it is determined whether the total data amount of the post-reorganization data 217 stored in the post-reorganization data buffer 220a is equal to or smaller than the buffer size. . If the data cannot be stored, the process proceeds to S165. If the data can be stored, the preprocessing unit 213 stores the generated post-reorganization data 217 in the post-reorganization data buffer 220a.
  • the preprocessing unit 213 stores the generated post-reorganization data 217 in the post-reorganization data buffer 220b that is the next buffer of the post-reorganization data buffer 220a.
  • the pre-processing unit 213 checks whether there is data that has not yet been generated after the reorganization data 217 in the pre-reorganization data 210 to be processed. If there is, the process returns to S151, and if not, the reorganization process is terminated.
  • FIG. 8 shows a processing flow of the post-processing unit 215.
  • the post-processing unit 215 refers to the reorganization correspondence information 240, requests the server 300 for the form data 340 having the post-reorganization data identification information 242 corresponding to the specific pre-reorganization data identification information 241, and Get this.
  • the pre-reorganization data 241 is “for Tanaka_1”
  • the corresponding post-reorganization data identification information 242 is “page 1 / 1-3”. It is. Therefore, the form data 340 having this identification information is received from the server 300.
  • the post-processing unit 215 combines the received (three) form data 340 (file) to generate one data (file). By this processing, it is possible to obtain credit usage details data of a specific user.
  • FIG. 9 schematically shows form data generated by the computer system 100 of the first embodiment.
  • the left side shows the form data representing the credit usage details for the user “Tanaka”, and the right side shows that of the user “Suzuki”.
  • Each form data page is generated as one file (for example, PDF format) for each user.
  • the form for “Tanaka” consists of 3 pages. As shown in the usage details display column 23c on the second page and the usage details column 33a (dotted line portion) and 33b on the third page, it can be seen that the usage details for one page are displayed without creating a blank in the middle.
  • the number of records of usage details for one page is form data that satisfies the data characteristic of three.
  • the usage details for “Tanaka” are seven records.
  • the form data on the third page is not generated and is useless.
  • Form data generation load and communication load can be reduced.
  • the form data is output to a paper medium and sent to the user. In such a case, however, the paper medium resource on the third page can be saved and the printing load can be reduced. You can also expect.
  • the form data for “Suzuki” since the form data for “Suzuki” has only data for three records, it is generated as form data for one page.
  • the badge job is generated in consideration of the data characteristics of a specific format, it is possible to generate form data that satisfies the data characteristics of the format.
  • content data inconsistency does not occur at the boundary of job division, and batch data can be divided while creating form data that satisfies the format characteristics, thus meeting various requests such as system load and job interruption. It can respond flexibly.
  • the content data to be embedded in the form data is held by the client 200.
  • the CSV data of the content data is stored in the DB service on the cloud.
  • the present invention can also be applied to an M2M configuration that transmits content data to the server 300 existing in the network.
  • the post-processing unit 215 in the DB service or the server 300 it is possible to expect the effects of reducing the load on the client 200 and simplifying the configuration. The above is the description of the first embodiment.
  • a description will be given of a computer system 500 that combines content data to be embedded in a form format together for each form type when the form format is a composite format.
  • FIG. 10 shows the configuration of the computer system 500.
  • the computer system 100 of the first embodiment is different in the processing of the preprocessing unit and the postprocessing unit.
  • the pre-processing unit 513 and the post-processing unit 515 will be particularly described.
  • the same reference numerals are used for components having the same functions and operations as the computer system 100 of the first embodiment, and detailed description thereof is omitted.
  • the preprocessing unit 513 first performs a process of classifying the pre-reorganization data 510 according to the type of the form format 520B, 520C or the like that is the embedding destination.
  • FIG. 11 schematically shows pre-reorganization data 510 of the second embodiment
  • FIG. 12 schematically shows form formats 520B and 520C of the second embodiment.
  • the pre-reorganization data 510 shown in FIG. 11 shows the monthly credit usage details for each user as a CSV file.
  • the difference from the pre-reorganization data 210 of the first embodiment is that data indicating the total usage amount and the usage period (“2012/6”) is added to the first record of each file.
  • the first record 510a is data for the form format 520B
  • the subsequent usage details record 510b is data for the form format 520C.
  • the form format 520B shown in FIG. 12 is the format of the front page of the usage details for each user.
  • a user name display column 323, a usage target period display column 324, and a total usage amount display column 330 for the period are provided.
  • the form format 520C is a format for displaying usage details.
  • FIG. 13 schematically shows an example of the data characteristic information 530. Similar to the data characteristic information 230 of the first embodiment, this is information for managing the relationship between the pre-reorganization data 510 before and after the reorganization processing and the post-reorganization data 517 in association with each other.
  • the format ID 531 is “B”
  • the form format 520B is indicated
  • the format ID 531 is “C”
  • the form format 520C is indicated.
  • the data characteristic of the form format 520B is “1 record / page”, and it is defined that information for one record is embedded around one page.
  • FIG. 14 schematically shows the reorganization correspondence information 240 in the second embodiment.
  • the pre-reorganization data identification information 241 indicates a user ID.
  • the post-reorganization data identification information 242 records a correspondence relationship between the form formats 520B and the post-reorganization data 517 for the 520C with respect to the pre-reorganization data identification information 241.
  • the pre-reorganization data identification information 241 is “for Tanaka_1”
  • the data after reorganization on the first page for the form format ID “B1” the first and second pages for the form format C1 It shows that the data after reorganization corresponds.
  • FIG. 15 shows a processing flow of the preprocessing unit 513.
  • the preprocessing unit 513 acquires the form format ID designated via the input / output unit 204, the form format ID to be created, and the pre-reorganization data 510.
  • the preprocessing unit 513 accesses the data characteristic information 530 and acquires the data characteristic 532.
  • the preprocessing unit 513 refers to the data characteristic of the acquired data characteristic information 530 and determines whether or not the designated form format ID is “composite format”. If it is “composite format”, the process proceeds to S207 (S205: YES), and if it is not “composite format”, the pre-processing unit 513 proceeds to the process of S209 (S205: NO). For example, if the designated form format ID is “A”, the data characteristic 532 indicates that it is a “composite format”.
  • the preprocessing unit 513 classifies each record of the pre-reorganization data 510 acquired in S201 for each type of form format.
  • the first record 510a of the “Tanaka” data is a record embedded in the format data of the form format ID “B” that is the front page of the form.
  • the record 510b is a record embedded in the format of the form format ID “C” which is the usage details.
  • the preprocessing unit 513 classifies these records into respective record groups for the form format IDs “B” and “C”. Which form format data each record is for is determined as data before reorganization. This can be determined by the record position and the character string pattern of the record in 510.
  • the first record is for a format whose form format ID is “B”, and the others are for a format whose form format ID is “C”.
  • This can be realized by setting the policy.
  • the form format ID is for “B”, and if “Month / Day, Description, Amount” is a form, This can be realized by setting a policy such that the format ID is format data for “C”.
  • the preprocessing unit 513 executes a reorganization process on each record group and the like classified in S207.
  • the processing is similar to the reorganization processing (FIG. 5) of the first embodiment. This is a process of converting each record group into post-reorganization data 517 according to the corresponding data characteristic 532. Details will be described later with reference to FIG.
  • the reorganized data 517 is stored in the reorganized data buffers 220a to 220c.
  • step S211 the preprocessing unit 513 transmits the batch job to the server 300 using the post-reorganization data 517 stored in the post-reorganization data buffer 220a as the batch data for creating the form.
  • Figure 16 shows the flow of the reorganization process.
  • the reorganization process of the second embodiment is different from the reorganization process (FIG. 5) of the first embodiment in that in the first step (S250), the type of the form format in which the pre-reorganization data 517 is embedded is determined.
  • Other steps are the same as those in the first embodiment, and S251 to S267 correspond to S151 to S167, respectively.
  • the preprocessing unit 513 determines the form format ID that is the embedding destination of the pre-reorganization data 510 that is the target of the reorganization process. If the ID is “B”, the process proceeds to S257, and if the ID is “C”, the pre-processing unit 513 proceeds to the process of S251.
  • the pre-processing unit 513 reads out one record according to “1 record / page” of the data characteristic 532 for the record for the form format ID “B”, and reorganizes it as data for one page. Add to data 517.
  • the records for the three records read or generated in S251 to S255 are added to the data 517 after reorganization.
  • the preprocessing unit 513 records the data correspondence before and after the reorganization in the reorganization correspondence information 240.
  • the pre-reorganization data identification information 241 is recorded as “Tanaka_1”, for example, and the post-reorganization data identification information 242 is recorded as “B1 / 1 page”. (See FIG. 14).
  • This “B1 / 1 page” indicates that “B1” has a form format ID “B” and its “1” -th data, and “1 page” indicates the number of pages.
  • the pre-reorganization data identification information 241 is, for example, “for Tanaka_1”
  • the post-reorganization data identification information 242 is “C1 / 1-2 page”. (See FIG. 14).
  • This “C1 / 1-2 page” indicates that “C1” has a form format ID “C” and is the “1” -th data, and “1-2 page” indicates each page. Is.
  • the preprocessing unit 513 determines whether the reorganized data 517 generated in S259 can be stored in the data storage buffer 220 (220a). If it can be stored, the process proceeds to S263 (S261: YES), and the data 5517 after reorganization is stored. When the data cannot be stored (S261: NO), the preprocessing unit 513 stores the reorganized data 517 in the next data storage buffer 220 (220b).
  • the preprocessing unit 513 determines whether the pre-reorganization data 517 includes a record in which the data after reorganization is unorganized. If there is, the process returns to S250 to repeat the process, and if not, the process ends.
  • the preprocessing unit 513 transmits a batch job for the reorganization data 517 stored in the data storage buffer 220a as described above to the server 300 (S211 in FIG. 15). That is, a group of records having the same form format ID is transmitted together.
  • the creation process using the same form format can be executed continuously, and there is an advantage that the reading load of the same form format can be reduced. That is, the creation process of the front page (“credit card usage summary”) for “Tanaka” and “Suzuki” and the creation process of the usage details ““ credit card usage details ”” can be performed collectively.
  • the post-processing unit 517 specifies the target form data for each user based on the reorganization correspondence information 240 and acquires the created form data (file). To do. Then, based on the reorganization correspondence information 240, form data (file) for each user in which “credit usage summary” and “credit usage summary” are set is generated.
  • each record is classified according to the form format type by the pre-processing unit 513 (S207), and the post-reorganization data 517 is changed according to the respective data characteristics. Generated.
  • the reorganized data 517 is sequentially stored in the data storage buffers 220a to 220c according to the capacity of the data storage buffer 220 and whether each post-organization data 517 can be stored without being divided.
  • the reorganized data 517 stored in the data storage buffer 220a is transmitted to the server 300 by one batch job.
  • the reorganized data 517 is embedded in the corresponding form format 320B or 320C, and a form data group 340 is created. Thereafter, each form data 340 shown in FIG. 17 is transmitted from the post-processing unit 515 to form data 340 to be a set of forms for a specific user, and transmitted to the client 200.
  • the form data 340 transmitted to the client is combined as a set of form data (file) based on the reorganization correspondence information 240.
  • the above is the description of the second embodiment.
  • the pre-processing unit 517 classifies the records of the pre-reorganization data 510 for the form format ID “B” and “C” according to the form format type, and generates post-reorganization data 517 respectively.
  • the reorganized data 517 for the form format ID “B” may be stored in the same data storage buffer 220a by a predetermined amount.
  • the final object is a set of form data for each user. Therefore, for example, the data storage buffer 220a is filled only with the reorganized data 517 for the form format ID “B”, and the reorganized data 517 for the corresponding form format ID “C” is stored in the data storage buffer 220b.
  • the form data that can be created by the server 300 in accordance with the first batch job is only the front page (“credit usage summary”). If a batch job of a different form is interrupted while a batch job of the reorganized data 517 stored in the data storage buffer 220b is transmitted, the original final object is processed until the processing of the batch job of the different form is completed. It is also possible that not all of the form data can be created.
  • the server 300 By mixing the form format ID “B” and the corresponding form format ID “C” in the data storage buffer 220a input in the first batch job, the server 300 does not wait for completion of processing of different form data. Some form data for each user can be created.
  • the various programs described above can be recorded on various electrical, electronic, magnetic, and / or optical recording media that can be read by a computer.
  • These recording media include main storage devices 202 and 302 and auxiliary storage devices 302 and 303.
  • pre-processing units 213 and 513 and the post-processing units 215 and 515 of the client 200 are configured as functional units realized by cooperation between a program and a CPU.

Abstract

　フォーマットデータにバッチジョブによりコンテンツデータを適用して合成データを生成する処理において、フォーマットデータのデータ特性を考慮した上でバッチジョブを生成するようにする。フォーマットデータに適用して合成データを生成するためのコンテンツデータを管理する計算機が、フォーマットデータに適用可能なコンテンツデータのサイズに関する情報を含む特性情報を記憶する記憶部と、コンテンツデータから、特性情報に応じたバッチデータを生成し、生成した１又は複数のバッチデータ単位で、フォーマットに適用するコンテンツデータを出力するためのバッチジョブを生成する制御部とを有するようにする。

Description

計算機、バッチジョブ生成方法及び記録媒体
　本発明は、計算機、バッチジョブ生成方法及び記録媒体に関し、特に、フォーマットデータとコンテンツデータとから合成データを生成する計算機、バッチジョブ生成方法及び計算機に実行させるプログラムを格納した非一時的記録媒体に関する。
　クレジットカードの利用明細や各種の請求書等の帳票を作成する業務を始め、特定のフォーマットデータと、個別のコンテンツデータとを合成して所定の合成データを出力するサービスが知られている。このようなサービスでは、計算機に予め雛形となるフォーマットデータを保持させておき、合成させるための一定量や一定期間のコンテンツデータ等を一括してバッチジョブを投入し、動的にフォーマットデータに合成して合成データを生成する手法を用いることがある（所謂バッチ処理を用いる方法である）。
　例えば帳票等は、顧客毎に作成する必要もあり且つ月次等定期的に発行する必要がある。このため大量のデータを頻繁に処理する必要からシステム構築・管理に関するコストが増加するという問題がある。
　この点、近年では、帳票データ作成等を始めとした業務をクラウド上で提供するサービスも出現している。このサービスでは、顧客のカード利用明細等のコンテンツデータが含まれたバッチジョブを受け付け、帳票等のフォーマットデータにコンテンツデータを適用して顧客毎の帳票データ等を合成するサーバを設け、合成データの作成依頼元に提供するようになっている。帳票等の合成データ作成依頼元は、システム構築・管理コストの削減をすることができる。
　ここで、クラウド上の帳票等作成サービスに限らず、バッチ処理により一度に大量の処理対象データを含むバッチジョブを受けた場合を考える。大量の合成データ作成処理は、その分計算機資源（ＣＰＵ、通信帯域等）を占有することから、先の依頼分（バッチジョブ）を処理し終わるまでは、他の依頼（バッチジョブ）を受けたり、ジョブを実行したりすることができないという問題が生ずる場合がある。特に、先の依頼が大量のバッチデータを含んだバッチジョブであって、後の依頼が少量のバッチデータを含んだバッチジョブである場合には、後者の利便性を著しく欠く虞もある。
　特許文献１は、一括処理データの処理依頼（バッチジョブ）を分割して、並列処理する技術を開示する。これを用いて、大量のバッチデータを含むバッチジョブを分割することで、分割したバッチジョブの間に少量のバッチデータを含むバッチジョブを割り込ませることができるともいえる。
特開平８－２８６９６５号公報
　しかしながら、例えば、帳票フォーマットのように、フォーマット１つに埋め込むコンテンツデータのサイズが予め定まっているようなデータ特性を有する場合、特許文献１に開示するように、単純に一括処理するバッチジョブを分割すると、処理対象のコンテンツデータが、本来埋め込まれるはずのフォーマットデータと異なる位置に埋め込まれた合成データが生成される虞がある。
　図１に、バッチジョブを単純に分割する場合の例を模式的に示す。バッチデータ１はコンテンツデータであり、利用者毎のクレジット利用履歴を示すデータである。仮に、図中の点線部分でバッチデータ１を二分割するとする。「田中」のクレジット利用履歴は７レコードあるが、その途中でバッチデータが分割され、前半５つ（５ａ）と、後半２つ（５ｂ）とに分けられる。分割によって帳票作成のバッチジョブ数は１から２となり、５ａのデータは前半のバッチジョブで処理され、５ｂのデータは後半のバッチジョブで処理されることとなる。
　図１の右側は「田中」のバッチデータに基づいて作成された帳票データであるクレジット利用明細１０Ａ～３０Ａを模式的に示したものである。なお、１つのクレジット利用明細データのフォーマットには、コンテンツを３レコード分埋め込むというデータ特性を有するものとする。
　５ａのバッチデータのうち最初の３つのレコード分が、クレジット利用明細データ１０Ａとして生成され（項目欄１３ａ～１３ｃに埋込み。）、残りの２つのレコード分が、クレジット利用明細データ２０Ａとして生成される（項目欄２３ａ及び２３ｂに埋込み。）。ここで、前半のバッチジョブは完了となることから、田中用データの残りの２レコード（５ｂ）は、次のバッチジョブによるバッチデータとなる。よって、残りの２つのレコード５ｂは、新たな帳票フォーマットに埋め込まれ、クレジット利用明細３０Ａとして帳票データが作成されることになる。
　項目欄３３ａに埋め込まれた「６／２１、カフェＡ、１０００円」という利用履歴は、本来クレジット利用明細データ２０の項目欄２３ｃに埋め込まれるべきであるところ、バッチジョブの分割により項目欄３３ａに埋め込まれることとなる。このように、フォーマットデータのデータ特性を考慮した上でバッチジョブを生成する必要がある。
　上記課題を解決するために、例えば請求項１に記載の構成を用いる。即ちフォーマットデータに適用して合成データを生成するためのコンテンツデータを管理する計算機であって、前記フォーマットデータに適用可能なコンテンツデータのサイズに関する情報を含む特性情報を記憶する記憶部と、前記コンテンツデータから、前記特性情報に応じたバッチデータ※4を生成し、生成した１又は複数の前記バッチデータ単位で、前記フォーマットに適用するコンテンツデータを出力するためのバッチジョブを生成する制御部とを有する計算機を適用する。
　本発明によれば、コンテンツデータを適用するフォーマットデータのデータ特性を考慮してバッチジョブを生成することができる。本発明の他の課題や効果は、以下の発明の実施形態の説明から更に明らかになる。
図１は、従来技術の課題を示す模式図である。 図２は、本発明を適用した第１実施形態の計算機システムの構成を示すブロック図である。 図３は、第１実施形態のデータ特性情報の一例を示す模式図である。 図４は、第１実施形態の再編成対応情報の一例を示す模式図である。 図５は、第１実施形態の帳票フォーマットの一例を示す模式図である。 図６は、第１実施形態の前処理部の全体処理の流れを示すフロー図である。 図７は、第１実施形態の再編成処理の流れを示すフロー図である。 図８は、第１実施形態の後処理部の流れを示すフロー図である。 図９は、第１実施形態の計算機システムで生成される帳票データの一例を示す模式図である。 図１０は、第２実施形態の計算機システムの一例を示すブロック図である。 図１１は、第２実施形態の再編成前データの一例を示す模式図である。 図１２は、第２実施形態の複合帳票フォーマットの一例を示す模式図である。 図１３は、第２実施形態のデータ特性情報の一例を示す模式図である。 図１４は、第２実施形態の再編成対応情報の一例を示す模式図である。 図１５は、第２実施形態の前処理部の処理の流れを示すフロー図である。 図１６は、第２実施形態のデータ再編成処理の流れを示すフロー図である。 図１７は、第２実施形態の計算機システムで生成される帳票データの一例を示す模式図である。
　以下に、図面を用いて本発明の実施形態について詳細に説明する。なお、以下の説明では、特定のフォーマットとコンテンツデータとから生成する合成データの一例として、クレジット利用明細の帳票データの作成処理を用いるものとするが、本発明はこれに限定されるものではなく、フォーマットに適用するコンテンツデータのデータ特性を考慮したバッチジョブを生成するものであれば、種々の分野に適用可能である。
　〔第１実施形態〕
  図２に、本発明を適用した計算機システム１００の構成を模式的に示す。計算機システム１００は、クライアント２００と、サーバ３００とがネットワーク４００を介して通信可能に接続されてなる。クライアント１００は、ＰＣ、サーバ或いはモバイル計算機等の汎用のコンピュータ装置である。サーバ３００も、汎用のサーバ装置である。
  なお、本実施形態では、クライアント・サーバ型を例として説明するが、本発明は、ＰＣやサーバ内の単一の計算機にも適用できるものである。
　クライアント２００には、クレジット利用者毎の月次の利用明細として、再編前データ２１０が、例えばテキスト形式のファイルとして保持される。本実施形態では、ＣＳＶ形式のファイルを適用するものとする。
  再編成前データ２１０は、例えば図１に示すバッチデータ１のように、「田中用データ」や「鈴木用データ」といった識別情報を基に、夫々の利用明細のレコードがグループ化されたファイル（データセット）になっている。
　また、クライアント２００には、帳票フォーマット３１０のデータ特性を示すデータ特性情報２３０及び再編成前後の各データの対応関係を記録する再編成対応情報２４０が保持される。
　データ特性情報２３０は、帳票フォーマットに埋め込むことが可能なコンテンツデータのサイズやレコード数等を示す。また、データ特性情報２３０は、サーバ３００から取得されたり、クライアント２００の入出力部２０４を介した入力により生成したり、外部のシステム（不図示）から取得したりすることが可能なようになっている。本実施形態では、データ特性情報２３０をサーバ３００から取得又は受信するものとして説明する。
　図３に、データ特性情報２３０を模式的に示す。データ特性情報２３０は、帳票のフォーマットデータを識別するフォーマットＩＤ２３１と、その帳票フォーマット３２０のデータ特性２３２とが対応付けられて保持される。図において、データ特性としては、単一の帳票フォーマット３２０に埋め込むデータレコードの数が３レコード分である例を示している。また、他のデータ特性として、単一の帳票フォーマットに埋め込むことのできるコンテンツデータの利用者の値（ＩＤ）が同一である例を示している。
　図２に戻り、再編成対応情報２４０は、再編成前データ２１０と、それが前処理部２１３による再編成処理によって分割された再編成後データ２１７とが対応付けられて記録されており、再編成処理前後のデータの対応関係を管理する情報である。
　図４に、再編成対応情報２４０を模式的に示す。再編成対応情報２４０は、クレジット利用者毎の再編成前データ２１０を識別する情報である再編成前データ識別情報２４１と、その再編成前データから生成された再編成後データ２１７を識別する再編成後データ識別情報２４２とが対応付けられてなる。
　例えば、データ特性情報２３０（図３）に示す帳票フォーマットＩＤ２３１が「Ａ」の場合、そのデータ特性は、「３レコード／ページ」であり、「利用者ＩＤ＝同値／ページ」である。再編成対応情報２４０では、再編成前データ２１０の３レコード分について、これらの利用者ＩＤが同一である場合、帳票１ページ分のデータとして生成された再編成後データ２１７に対して、再編成後データ識別情報２４２として「１」を生成し、再編成前データ識別情報２４１と対応づけて登録される。再編成前データ識別情報２４１が同一であることを条件に、後続する４つ目以降のレコードに関する再編成後データ２１７について、順次２ページ目、３ページ目を示す情報が生成され、「１／１-３」のように登録されるようになっている。同図において、再編成前データ識別情報２４１が「田中用_1」であるデータは、再編成後データ識別情報２４２が「１」の「１～３ページ」である再編成後データ２１７と対応する例を示している。
　図２に戻り、サーバ２００の主記憶装置２０２には、プログラムとＣＰＵ２０１との協働により、前処理部２１３と、後処理部２１５とが実現されるようになっている。
  前処理部２１３では、データ特性情報２３０に基づいて、再編成前データ２１０から再編成後データ２１７が生成されるようになっている。具体的には、データ特性情報２０３において、帳票フォーマット３２０のデータ特性は、１ページ当たり３レコードのコンテンツデータを埋め込むようになっている。前処理部２１３では、再編集前データ２１０の先頭から３レコード分で１つの再処理後データ２１７が生成されるようになっている。
　更に、前処理部２１３では、他のデータ特性である「利用者のＩＤ＝同値／ページ」に基づき、３レコード分の利用者のＩＤが同値（同一人物）であるかが判定される。具体的には、３レコードの先頭レコードの利用者のＩＤと、２番目のレコードの利用者のＩＤが同値であるかが判定される。同値で無い場合、前処理部２１３では、２番目及び３番目のレコードの代わりに、空のレコード（ダミー）を２つ生成し、先頭のレコードと２つの空レコードとで再編成後データ２１７が生成されるようになっている。
  なお、本実施形態ではレコード数の例を説明するが、レコード数の代わりにデータサイズをデータ特性とする場合には、空のレコードの変わりに、不足分のデータを追加して再編成後データ２１７が生成されるようになっている。
　後処理部２１５では、再編成対応情報２４０に基づき、サーバ３００の帳票作成処理において合成された帳票データが、同一利用者毎に結合された帳票データが生成されるようになっている。サーバ３００で生成され、クライアント２００に出力された帳票データは、ページ毎に１つのデータ（例えば、ファイル）として出力される。同一利用者のクレジット利用明細が複数ページにわたる場合であっても、それぞれ別のファイルとして出力される。
  よって、後処理部２１５では、受信した個々の帳票データの再編成後データ識別情報２４２を基に、再編成対応情報２４０において対応する再編成前データ識別情報２４１が同一である帳票データ同士を結合する処理が行なわれ、利用者毎に１つの纏まった帳票データが生成されるようになっている。
　例えば、図４の「田中用_１」の再編成前データ識別情報２４１を有する再編成前データは、再編成後データ識別情報２４２が、「1／１-３」であり、３ページ分の帳票データ（ファイル）が生成されることになる。後処理部２１５では、この３つのデータ（ファイル）が結合され、田中用のクレジット利用明細の帳票データ（ファイル）が１つ生成されることになる。同様に、再編成前データ識別情報２４１が「鈴木用_２」である場合、再編成後データ識別情報２４２は「２／１ページ」であることから、１ページの帳票データ（ファイル）が作成されることになる。
　図２に戻り、再編成後データバッファ２２０ａ～ｃは、前処理部２１３の再編成処理によって生成された再編成後データ２２０が一時的に格納される領域である。再編成後データバッファ２２０は、所定のバッファ容量を有し、バッファサイズは任意に設定可能なものとなっている。例えば、サーバ３００や入出力部２０４からの指示コマンドによって、再編成後データバッファ２２０の分割数や個々のバッファ容量が指定されるようになっている。
　再編成後データ２１７は、再編成後データバッファ２２０ａに格納され、その後、２２０ａの容量が不足したら２２０ｂ、次いで２２０ｃの順に使用されるようになっている。更に、１つの再編成後データバッファ２２０に保持した再編成後データ群が、１つの帳票データ作成処理のバッチジョブに含まれるバッチデータとなる。即ちバッチデータ単位で、単一のバッチジョブが生成されることになる。
　つまり、クレジット利用明細の帳票データ作成処理のバッチジョブに含まれる再編成前データ２１０が大量である場合、その処理中は他の帳票データ作成のバッチジョブを実行することができない。そこで、１つのジョブが大量の再編成前データ２１０を含む場合は、バッチジョブを複数に分割することで、ジョブの切れ目を発生させることができ、各種のバッジジョブの処理順等を調節することができるようになる。
　なお、バッチジョブをサーバ３００に送信するタイミングは、再編成後データバッファ２２０ａ～ｃの格納容量が満たされたときに、適宜バッチジョブを送信してもよいし、全ての再編成データ２１７の生成が完了したときに、再編成後データバッファ２２０ａ～ｃの順番で、所定間隔で送信してもよい。
　このように、クライアント２００では、１つの再編成後データバッファ２２０の容量以下であって、そのバッファ内に格納された最後の再編成後データ２１７が帳票フォーマット３２０のデータ特性を満たすものとなるように、バッチジョブを生成することができるようになっている。夫々の再編成後データバッファ２２０ａ～ｃに格納された再編成後データ２１７は、別のバッチジョブ用のバッチデータとして管理することが出来る事になる。
　次いで、サーバ３００の構成を説明する。
  サーバ３００は、種々の帳票フォーマット３２０と、データ処理部３１０とを有する。データ処理部３１０は、プログラムと、ＣＰＵ３０１との協働により実現される機能部である。データ処理部３２０では、クライアント２００から取得した再編成後データ２１７と、帳票フォーマット３２０とが合成され、再編成後データ２１７毎の帳票データ３４０が所定のデータ形式（例えば、ＰＤＦ等）で生成されるようになっている。生成された帳票データ３４０は、所定の契機で要求元であるクライアント２００に送信されるようになっている。
　図５に、帳票フォーマット３２０の例を模式的に示す。帳票フォーマット３２０は、帳票タイトル３２１（『クレジットカード利用明細』）がフォーマットの一部として設定され、コンテンツデータの適用領域として発行人表示欄３２２、利用者名表示欄３２３及び利用明細表示欄３２５ａ～ｃが設けられる。
　なお、帳票フォーマット３２０は、１つに限らす複数種類のデータが保持されており、所定の設定により、種々の帳票データが生成可能となっている。
　以上の構成を有する計算機システム１００の処理の流れについて、図６～８を用いて説明する。
  図６に、前処理部２１３の処理の流れを示す。
  Ｓ１０１で、前処理部２１３は、入出力部２０４等を介して入力された帳票作成処理の指示を受け、その指示に含まれる対象の帳票フォーマットＩＤ及び対象の再編成前データ２１０を取得する。ここでは、帳票フォーマットＩＤが「Ａ」であるものとする。
　Ｓ１０３で、前処理部２１５は、指定された帳票フォーマットＩＤに基づき、データ特性情報２３０を参照し、当該帳票フォーマットＩＤ「Ａ」に対応するデータ特性情報を取得する。ここでは、図３に例示する「３レコード／ページ」及び「利用者ＩＤ＝同一／ページ」の２つの特性データを取得するものとする。
　Ｓ１０５で、前処理部２１３は、データ特性情報２３０に基づいて、再編成前データ２１０から、再編成後データ２１７を生成する再編成処理を実行する。詳細は図７を用いて後述する。
　Ｓ１０７で、前処理部２１３は、再編成後データバッファ２２０ａに格納された再編成後データ２１７について、帳票データ作成対象としてバッチジョブをサーバ３００に送信する。
　図７に、前処理部２１３の再編成処理の流れを示す。
  Ｓ１５１で、前処理部２１５は、再編成前データ２１０の先頭レコードから利用者ＩＤが同一のレコードを３つ分まで読み出す。
  Ｓ１５３で、前処理部２１５は、読み出したレコードの数が３より少ないかを判断する。少なくない場合（＝３）、Ｓ１５７に進み、少ない場合、前処理部２１５は、３に満たないレコード数分の空行を挿入する。
　Ｓ１５７で、前処理部２１３は、３つ分のレコード（空行を含む場合もある）を加えて、再編成後データ２１７を生成する。
  Ｓ１５９で、生成した再編成後データ２１７の利用者ＩＤ（再編成前データ識別情報２４１）と、再編成後データ識別情報２４２とを対応付けて、再編成対応情報２４０に記録する。このとき、その再編成後データ２１７が、その利用者ＩＤにおいて何ページ目であるかの情報も記録する。
　Ｓ１６１で、前処理部２１３は、生成した再生成後データ２１７が、再編成後データバッファ２２０ａに格納できるか否かを判断する。具体的には、生成した再編成後データ２１７を格納しても、再編成後データバッファ２２０ａに格納された再編成後データ２１７の総データ量がそのバッファサイズ以下であるか否かを判断する。格納できない場合、Ｓ１６５に進み、格納できる場合、前処理部２１３は、生成した再編成後データ２１７を再編成後データバッファ２２０ａに格納する。
　Ｓ１６５で、前処理部２１３は、再編成後データバッファ２２０ａの次のバッファである再編成後データバッファ２２０ｂに、生成した再編成後データ２１７を格納する。
  Ｓ１６７で、前処理部２１３は、処理対象である再編成前データ２１０で、再編成後データ２１７を未だ生成していないデータがあるかチェックする。有る場合には、Ｓ１５１に戻り、無い場合には再編成処理を終了する。
　次に、図８に、後処理部２１５の処理の流れを示す。
  Ｓ１８１で、後処理部２１５は、再編成対応情報２４０を参照し、特定の再編成前データ識別情報２４１に対応する再編成後データ識別情報２４２を有する帳票データ３４０を、サーバ３００に要求し、これを取得する。
  例えば、図４の再編成対応情報２４０の例であれば、再編成前データ２４１が「田中用_1」である場合、対応する再編後データ識別情報２４２は、「１／１－３ページ」である。よって、この識別情報を有する帳票データ３４０をサーバ３００から受信する。
　Ｓ１８３で、後処理部２１５は、受信した（３つの）帳票データ３４０（ファイル）を結合し、１つのデータ（ファイル）を生成する。この処理により、特定の利用者のクレジット利用明細データを得ることができる。
　最後に、図９に、第１実施形態の計算機システム１００によって生成される、帳票データを模式的に示す。
  左側は、利用者「田中」用のクレジット利用明細を表した帳票データであり、右側は、利用者「鈴木」のそれを表す。各帳票データページは、利用者毎に１つのファイル（例えば、ＰＤＦ形式）のファイルとして生成される。
　「田中」用の帳票は３ページからなる。２ページ目の利用明細表示欄２３c及び３ページ目の利用明細欄３３ａ（点線部）並びに３３ｂに示すように、１ページ分の利用明細が途中に空欄を作ることなく表される様がわかる。１ページ分の利用明細のレコード数は３つというデータ特性を満足する帳票データとなる。
　特に、本実施形態の場合、「田中」用の利用明細は７つのレコードであったが、６つのレコードしかなかった場合には、３ページ目の帳票データが生成されることがなく、無駄な帳票データの生成負荷や通信負荷を低減させることができる。帳票データを紙媒体等に出力して利用者に送ることも一般に行われるが、このような場合にも、３ページ目の紙媒体資源の節約や印刷負荷等を低減させることができるという効果を期待することもできる。
　更に、「鈴木」用の帳票データは、３レコード分のデータしかないため、１ページ分の帳票データとして生成される。「田中」用の帳票データ３０Ａ（３ページ目）には、２レコード分の利用明細表示欄３３ｂ及び３３ｃがあるが、これらには、「鈴木」用の「６／１２　レストランＢ　１５００円」といったデータが埋め込まれることがない。即ち「利用者ＩＤ＝同一／ページ」というデータ特性を満足する帳票データとなる。
　以上、第１実施形態の計算機システム１００によれば、特定のフォーマットのデータ特性を考慮してバッジジョブを生成するため、フォーマットのデータ特性を満足した帳票データを生成することができる。
　また、ジョブ分割の境目でコンテンツデータの不整合が発生せず、フォーマット特性を満足した帳票データを作成しつつバッチジョブの分割を可能とすることから、システム負荷やジョブの割込みといった種々の要求に柔軟に対応することができる。
　なお、第１実施形態の計算機システムでは、帳票データに埋め込むコンテンツデータをクライアント２００で保持するように構成しているが、クラウド上のＤＢサービスにコンテンツデータのＣＳＶデータを格納しておき、クラウド上に存在するサーバ３００にコンテンツデータを送信するＭ２Ｍの構成にも適用できるものである。この場合、前処理部２１３をＤＢサービス乃至サーバ３００に配置するのが好ましい。また、後処理部２１５もＤＢサービスやサーバ３００に設けることで、クライアント２００の負荷低減や構成の簡易化という効果も期待することができる。
  以上が、第１実施形態の説明である。
　〔第２実施形態〕
  第１実施形態では、帳票フォーマットが単一である場合について説明した。しかしながら、種別の異なるフォーマットを組合せて、一組の帳票データ等を作成することも一般に行われている（複合フォーマット）。
  例えば、クレジット利用明細の場合も、図１２に示すように、１ページ目には宛名や請求金額の合計等を案内し、詳細な利用明細に関しては表形式のフォーマットで一覧表示することもある。これらの帳票を合わせて１つのクレジット利用明細として１組の帳票となる。
　第２実施形態では、帳票フォーマットが複合フォーマットである場合に、帳票フォーマットに埋め込むコンテンツデータを、帳票の種別毎にまとめて合成する計算機システム５００について説明する。
　図１０に、計算機システム５００の構成を示す。第１実施形態の計算機システム１００とは、特に、前処理部及び後処理部の処理が異なる。以下、第２実施形態の計算機システム５００において、特に、前処理部５１３、後処理部５１５として説明する。また、第１実施形態の計算機システム１００と機能・動作が同一の構成要素は同一符号を用いるものとし、詳細な説明を省略する。
　前処理部５１３では、再編成処理において、先ず、再編成前データ５１０を、埋込み先である帳票フォーマット５２０Ｂ、５２０Ｃ等の種別に応じて分類する処理が行われる。図１１に、第２実施形態の再編成前データ５１０を、図１２に、第２実施形態の帳票フォーマット５２０Ｂ及び５２０Ｃを模式的に示す。
　図１１に示す再編成前データ５１０は、利用者毎の月次のクレジット利用明細をＣＳＶ形式のファイルとして示している。第１実施形態の再編成前データ２１０と異なるのは、各ファイルの先頭レコードが利用合計金額と、利用期間（「２０１２／６」）とを示すデータが追加されている点である。先頭レコード５１０ａは、帳票フォーマット５２０Ｂ用のデータであり、それ以降の利用明細レコード５１０ｂは、帳票フォーマット５２０Ｃ用のデータである。
　図１２に示す帳票フォーマット５２０Ｂは、利用者毎の利用明細のフロントページのフォーマットである。利用者名表示欄３２３、利用対象期間表示欄３２４、当該期間の利用合計金額表示欄３３０が設けられる。帳票フォーマット５２０Ｃは、利用明細を表示するフォーマットである。
　図１３に、データ特性情報５３０の例を模式的に示す。第１実施形態のデータ特性情報２３０と同様に、再編成処理前後の再編成前データ５１０と、再編成後データ５１７との関係を対応付けて管理する情報である。
　第２実施形態のデータ特性情報５３０では、データ特性として帳票フォーマット同士の関係もデータ特性として管理するようになっている。即ちフォーマットＩＤ５３１が「Ａ」のものについては、そのデータ特性５３２は、「複合フォーマット」に関する関係性が定義されている。「１ページ目＝フォーマットＢ適用」、「２ページ目＝フォーマットＣ適用」という具体に、帳票フォーマットＡが、帳票フォーマットＢとＣからなることがデータ特性として定義される。
  なお、本実施形態において、フォーマットＩＤ５３１が「Ｂ」の場合は、帳票フォーマット５２０Ｂと、「Ｃ」の場合は、帳票フォーマット５２０Ｃを示すものとする。
　帳票フォーマット５２０Ｂのデータ特性は、「１レコード／ページ」であり、１ページ辺りに１レコード分の情報が埋め込まれることが定義される。帳票フォーマット５２０Ｃのデータ特性は、「３レコード／ページ」、「利用者ＩＤ＝同一／ページ」であり、第１実施形態と同様である。
　図１４に、第２実施形態における再編成対応情報２４０を模式的に示す。再編成前データ識別情報２４１は、利用者のＩＤを示す。再編成後データ識別情報２４２は、再編成前データ識別情報２４１に対し、帳票フォーマット５２０Ｂと５２０Ｃ用の再編成後データ５１７の対応関係が記録される。図において、再編成前データ識別情報２４１が「田中用_１」に対しては、帳票フォーマットＩＤが「Ｂ１」について１ページ目の再編成後データ、帳票フォーマットＣ１については、１及び２ページ目の再編成後データが対応することを示している。
　以上の構成を有する計算機システム５００の処理の流れについて図を用いて説明する。
  図１５に、前処理部５１３の処理の流れを示す。
  Ｓ２０１で、前処理部５１３は、入出力部２０４を介して指定された帳票フォーマットＩＤ及び帳票作成の対象となる帳票フォーマットＩＤ及び再編成前データ５１０を取得する。
  Ｓ２０３で、前処理部５１３は、データ特性情報５３０にアクセスし、データ特性５３２を取得する。
　Ｓ２０５で、前処理部５１３は、取得したデータ特性情報５３０のデータ特性を参照し、指定された帳票フォーマットＩＤが、「複合フォーマット」であるか否かについて判断する。「複合フォーマット」であればＳ２０７の処理に進み（Ｓ２０５：ＹＥＳ）、「複合フォーマット」でなければ、前処理部５１３はＳ２０９の処理に進む（Ｓ２０５：ＮＯ）。例えば、指定された帳票フォーマットＩＤが「Ａ」であれば、そのデータ特性５３２によって、「複合フォーマット」であることが分かる。
　Ｓ２０７で、前処理部５１３は、Ｓ２０１で取得した再編成前データ５１０の各レコードを、帳票フォーマットの種別毎に分類する。例えば、図１１の再編成前データ５１０では、「田中」用データの先頭レコード５１０ａは、帳票のフロントページである帳票フォーマットＩＤ「Ｂ」のフォーマットデータに埋め込まれるレコードであり、それ以降の利用明細レコード５１０ｂは、利用明細である帳票フォーマットＩＤ「Ｃ」のフォーマットに埋め込まれるレコードである。前処理部５１３は、これらのレコードを帳票フォーマットＩＤ「Ｂ」用及び「Ｃ」用という夫々のレコード群に分類する
　各レコードがどの帳票フォーマット用のデータであるか否かは、再編成前データ５１０におけるレコードの位置やレコードの文字列のパターンによって判断することができる。レコードの位置を利用する場合、利用者単位のレコード群のうち、先頭レコードは帳票フォーマットＩＤが「Ｂ」であるフォーマット用であり、その他は帳票フォーマットＩＤが「Ｃ」であるフォーマット用とする等のポリシを設定することで実現できる。
  他方、文字列のパターンを利用する場合は、文字列が「年／月，金額」の場合は、帳票フォーマットＩＤが「Ｂ」用で、「月/日，摘要，金額」の場合は、帳票フォーマットＩＤが「Ｃ」用のフォーマットデータである等のポリシを設定することで実現できる。
　Ｓ２０９で、前処理部５１３は、Ｓ２０７で分類した夫々のレコード群等に対し、再編成処理を実行する。ここでの処理は、第１実施形態の再編成処理（図５）と類似するものである。夫々のレコード群を対応するデータ特性５３２に応じて再編成後データ５１７に変換する処理である。詳細は図１６を用いて後述する。なお、再編成後データ５１７は、再編成後データバッファ２２０ａ～２２０ｃに格納されるようになっている。
　Ｓ２１１で、前処理部５１３は、再編成後データバッファ２２０ａに格納された再編成後データ５１７を帳票作成のバッチデータとしてバッチジョブをサーバ３００に送信する。
　図1６に、再編成処理の流れを示す。第２実施形態の再編成処理は、最初のステップ（Ｓ２５０）で、再編成前データ５１７が埋め込まれる帳票フォーマットの種別を判断する点が第１実施形態の再編成処理（図５）と異なる。他のステップは第１実施形態と同様であり、Ｓ２５１～Ｓ２６７が、Ｓ１５１～Ｓ１６７に夫々対応する。
　Ｓ２５０で、前処理部５１３は、再編成処理の対象とする再編成前データ５１０の埋め込み先である帳票フォーマットＩＤを判定する。ＩＤが「Ｂ」であればＳ２５７に進み、ＩＤが「Ｃ」であれば、前処理部５１３は、Ｓ２５１の処理に進む。
　Ｓ２５７で、前処理部５１３は、帳票フォーマットＩＤ「Ｂ」用のレコードに対しては、データ特性５３２の「１レコード／１ページ」に従い、レコードを１つ読出し１ページ分のデータとして再編成後データ５１７に加える。帳票フォーマットＩＤ「Ｃ」用のレコードに対しては、Ｓ２５１～Ｓ２５５で読出し又は生成した３レコード分のレコードを再編成後データ５１７に加える。
　Ｓ２５９で、前処理部５１３は、再編成前後のデータ対応関係を再編成対応情報２４０に記録する。帳票フォーマットＩＤ「Ｂ」用の再編成後データ５１７については、再編成前データ識別情報２４１を、例えば「田中用_1」とし、再編成後データ識別情報２４２を「Ｂ１／１ページ」として記録する（図１４参照）。この「Ｂ１／１ページ」は、「Ｂ１」が、帳票フォーマットＩＤが「Ｂ」で、その「１」番目のデータであることを示し、「１ページ」はページ数を示すものである。
　帳票フォーマットＩＤ「Ｃ」用の再編成後データ５１７については、再編成前データ識別情報２４１を、例えば「田中用_1」とし、再編成後データ識別情報２４２を「Ｃ１／１-２ページ」として記録する（図１４参照）。この「Ｃ１／１-２ページ」は、「Ｃ１」が、帳票フォーマットＩＤが「Ｃ」で、その「１」番目のデータであることを示し、「１-２ページ」は夫々のページを示すものである。
　Ｓ２６１で、前処理部５１３は、Ｓ２５９で生成した再編成後データ５１７が、データ格納バッファ２２０（２２０ａ）に格納可能か否かを判断する。格納できるときはＳ２６３に進み（Ｓ２６１：ＹＥＳ）、再編成後データ５５１７を格納する。格納できない場合（Ｓ２６１：ＮＯ）、前処理部５１３は再編成後データ５１７を次のデータ格納バッファ２２０（２２０ｂ）に格納する。
　Ｓ２６７で、前処理部５１３は、再編成前データ５１７に、再編成後データが未編成であるレコードがあるか判断する。ある場合には、Ｓ２５０に戻って処理を繰り返し、無い場合には処理を終了する。
　この後、前処理部５１３は、上述のようにデータ格納バッファ２２０ａに格納した再編成データ５１７を対象としたバッチジョブをサーバ３００に送信する（図１５のＳ２１１）する。即ち帳票フォーマットＩＤを同一とするレコード群を纏めて送信することになる。サーバ３００の帳票作成処理において、同一の帳票フォーマットを利用した作成処理を連続して実行することができ、同一帳票フォーマットの読込み負荷が低減できるという利点がある。即ち「田中」用及び「鈴木」用のフロントページ（「クレジットカード利用概要」）の作成処理や、利用明細「「クレジットカード利用明細」」の作成処理を一括して行うことができる。
　後処理部５１７は、第１実施形態と同様（図８）に、再編成対応情報２４０に基づいて、利用者毎に対象の帳票データを指定して、作成された帳票データ（ファイル）を取得する。そして、再編成対応情報２４０に基づいて、「クレジット利用概要」と、「クレジット利用概要」とがセットになった利用者毎の帳票データ（ファイル）を生成する。
　最後に、第２実施形態の計算機システム５００における帳票作成処理を、図１７に模式的に示す。「田中」用、「鈴木」用の再編成前データ５１０は、前処理部５１３によって帳票フォーマット種別に応じて各レコードが分類され（Ｓ２０７）、夫々のデータ特性に応じて再編成後データ５１７が生成される。再編成後データ５１７は、データ格納バッファ２２０の容量及び各編成後データ５１７を分割せずに格納できるか否かに応じて、順次データ格納バッファ２２０ａ～ｃに格納される。データ格納バッファ２２０ａに格納された再編成後データ５１７は、１つのバッチジョブによってサーバ３００に送信される。
　サーバ３００では、夫々の再編成後データ５１７を、対応する帳票フォーマット３２０Ｂ又は３２０Ｃに夫々埋め込み、帳票データ３４０群が作成される。
  その後、図１７に示された各帳票データ３４０は、後処理部５１５から、特定利用者の１組の帳票となる帳票データ３４０の指定を受け、クライアント２００に送信される。クライアントに送信された帳票データ３４０は、再編成対応情報２４０に基づいて、１組の帳票データ（ファイル）として結合されることとなる。
  以上が、第２実施形態の説明である。
　このように第２実施形態の計算機システム５００によれば、帳票が「複合フォーマット」からなる場合であっても、帳票フォーマットのデータ特性が満足された帳票データを生成することができる。
　また、計算機システム５００によれば、帳票フォーマットのデータ特性を満足した帳票データを生成しつつバッチジョブの分割を行うことができる。
　上述のように第２実施形態の計算機システム５００について説明したが、本発明は上記例に限定されるものではない。例えば、前処理部５１７では、帳票フォーマット種別に応じて、帳票フォーマットＩＤ「Ｂ」用と、「Ｃ」用との再編成前データ５１０のレコードを分類し、それぞれ再編成後データ５１７を生成するようにしたが、帳票フォーマットＩＤ「Ｂ」用の再編成後データ５１７を夫々所定量ずつ同一のデータ格納バッファ２２０ａに格納するようにしてもよい。
　「複合フォーマット」の帳票作成の場合、最終目的物は、利用者毎の一組の帳票データである。したがって、例えば、データ格納バッファ２２０ａが帳票フォーマットＩＤ「Ｂ」用の再編後データ５１７のみで満たされ、対応する帳票フォーマットＩＤ「Ｃ」用の再編成後データ５１７がデータ格納バッファ２２０ｂに格納された場合、最初のバッチジョブに応じてサーバ３００で作成することのできる帳票データは、フロントページ（「クレジット利用概要」）のみである。データ格納バッファ２２０ｂに格納された再編成後データ５１７のバッチジョブを送信する間に、異なる帳票のバッチジョブを割り込ませると、異なる帳票のバッチジョブの処理が完了するまでは、当初の最終目的物である帳票データの全てが作成できないということも考えられる。
　最初のバッチジョブで投入するデータ格納バッファ２２０ａに、帳票フォーマットＩＤ「Ｂ」と、それに対応する帳票フォーマットＩＤ「Ｃ」とを混在させることで、サーバ３００における異なる帳票データの処理完了を待たずに、利用者毎の一部の帳票データを作成することができる。
　また、上述の種々のプログラムは、コンピュータが読み取りを可能とする電気、電子、磁気及び／又は光学的な種々の記録媒体に記録可能なものである。また、それら記録媒体には、主記憶装置２０２、３０２、補助記憶装置３０２及び３０３が含まれる。
　以上、本発明を実施するための形態について説明したが、本発明は上記例に限定されるものではなく、その趣旨を逸脱しない範囲で種々の構成や手順等を適用可能である。
　例えば、クライアント２００の前処理部２１３並びに５１３及び後処理部２１５並びに５１５をプログラムと、ＣＰＵとの協働により実現する機能部として構成する例を用いたが、これらの全部又は一部をハードウェアとして構成することも当然に可能である。
　再編成前データ…２１０
　前処理部…２１３、５１３
　再編成後データ…２１７、５１７
　再編成後データバッファ…２２０ａ、２２０ｂ、２２０ｃ
　後処理部…２１５、５１５
　データ特性情報…２３０、５３０
　再編成対応情報…２４０
　帳票フォーマット…３２０、５２０Ｂ、５２０Ｃ
　帳票データ…３４０

Claims (13)

  1. 　フォーマットデータに適用して合成データを生成するためのコンテンツデータを管理する計算機であって、
    　前記フォーマットデータに適用可能なコンテンツデータのサイズに関する情報を含む特性情報を記憶する記憶部と、
    　前記コンテンツデータから、前記特性情報に応じたバッチデータを生成し、
    　生成した１又は複数の前記バッチデータ単位で、前記フォーマットに適用するコンテンツデータを出力するためのバッチジョブを生成する制御部と
    を有する計算機。
  2. 　請求項１に記載の計算機であって、
    　前記制御部が、前記特性情報に応じた前記バッチデータを生成する際、前記特性情報に含まれる前記サイズに関する情報を満たすバッチデータを生成する計算機。
  3. 　請求項２に記載の計算機であって、
    　前記制御部が、前記特性情報に応じた前記バッチデータを生成する際、生成するバッチデータが前記サイズに関する情報が示すサイズより少ない場合、不足分のデータを追加して前記サイズに関する情報を満たすバッチデータを生成する計算機。
  4. 　請求項１に記載の計算機であって、
    　前記制御部が、前記バッチジョブを出力し、
    　該バッチジョブによって生成された複数の前記合成データを結合する計算機。
  5. 　請求項１に記載の計算機であって、
    　前記コンテンツデータは、同一の識別情報によってデータがグループ化された１又は複数のデータセットからなるものであり、
    　前記制御部が、前記特性情報に応じた前記バッチデータを生成する際、更に、前記識別情報が同一のデータでバッチデータを生成する計算機。
  6. 　請求項５に記載の計算機であって、
    　前記制御部が、前記バッチジョブを出力し、
    　該バッチジョブによって生成された複数の前記合成データを、前記同一の識別情報に基ついて結合する計算機。
  7. 　請求項５に記載の計算機であって、
    　前記フォーマットデータは、フォーマットが異なる第１フォーマットデータ及び第２フォーマットデータを少なくとも含み、
    　前記特性情報は、前記第１及び第２フォーマット毎の前記サイズに関する情報を含み、
    　前記制御部が、前記第１及び第２フォーマットデータの各々に適用する前記データを前記１又は複数のデータセットからそれぞれ抽出し、
    　抽出したデータ毎に、前記第１及び第２フォーマット毎のサイズに応じたバッチデータを生成し、
    　生成したバッチデータ単位で、前記第１及び第２フォーマットデータに適用するコンテンツデータを出力するためのバッチジョブを生成し、
    　該バッチジョブを出力し、
    　前記バッチジョブによって生成された前記第１及び第２フォーマットデータ毎の合成データを、前記同一の識別情報に基づいて結合する計算機。
  8. 　請求項１～７の何れか一項に記載の計算機であって、
    　前記サイズに関する情報は、レコード数に関する情報を含む計算機。
  9. 　請求項１～７の何れか一項に記載の計算機であって、
    　前記フォーマットデータには、帳票フォーマットを含み、
    　前記合成データには、帳票データを含む計算機。
  10. 　請求項１～７の何れか一項に記載の計算機であって、
    　前記コンテンツデータには、テキストデータ形式のファイルを含む計算機。
  11. 　請求項１０に記載の計算機であって、
    　前記テキストデータ形式のファイルには、ＣＳＶ形式のファイルを含む計算機。
  12. 　フォーマットデータに適用して合成データを生成するためのコンテンツデータをバッチ処理する計算機のバッチジョブ生成方法であって、
    　前記計算機が、
    　記憶装置に記憶された、前記フォーマットデータに適用可能なコンテンツデータのサイズに関する情報を含む特性情報に基づいて、前記コンテンツデータから、前記特性情報に応じたバッチデータを生成するステップと、
    　生成した１又は複数の前記バッチデータ単位で、前記フォーマットに適用するコンテンツデータを出力するためのバッチジョブを生成するステップと、
    を含むバッチジョブ生成方法。
  13. 　フォーマットデータに適用して合成データを生成するためのコンテンツデータをバッチ処理する計算機に、
    　前記フォーマットデータに適用可能なコンテンツデータのサイズに関する情報を含む特性情報を保持する手順と、
    　前記コンテンツデータから、前記特性情報に応じたバッチデータを生成する手順と、
    　生成した１又は複数の前記バッチデータ単位で、前記フォーマットに適用するコンテンツデータを出力するためのバッチジョブを生成する手順と、
    を実行させるためのプログラムを格納する非一時的な記録媒体。
PCT/JP2012/075001 2012-09-28 2012-09-28 計算機、バッチジョブ生成方法及び記録媒体 WO2014049803A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/075001 WO2014049803A1 (ja) 2012-09-28 2012-09-28 計算機、バッチジョブ生成方法及び記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/075001 WO2014049803A1 (ja) 2012-09-28 2012-09-28 計算機、バッチジョブ生成方法及び記録媒体

Publications (1)

Publication Number Publication Date
WO2014049803A1 true WO2014049803A1 (ja) 2014-04-03

Family

ID=50387266

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/075001 WO2014049803A1 (ja) 2012-09-28 2012-09-28 計算機、バッチジョブ生成方法及び記録媒体

Country Status (1)

Country Link
WO (1) WO2014049803A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016057667A (ja) * 2014-09-05 2016-04-21 富士ゼロックス株式会社 情報処理装置及び情報処理プログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10286998A (ja) * 1997-04-11 1998-10-27 Brother Ind Ltd 長尺印刷装置
JP2000148451A (ja) * 1998-11-18 2000-05-30 Nec Corp バッチジョブ負荷分散方法および負荷分散システム
JP4678794B1 (ja) * 2009-11-16 2011-04-27 株式会社ジェイ エスキューブ データエントリーシステム
JP2011239351A (ja) * 2010-05-13 2011-11-24 Ricoh Co Ltd デジタルフロントエンドサーバ、その制御方法、画像形成装置及びプリントシステム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10286998A (ja) * 1997-04-11 1998-10-27 Brother Ind Ltd 長尺印刷装置
JP2000148451A (ja) * 1998-11-18 2000-05-30 Nec Corp バッチジョブ負荷分散方法および負荷分散システム
JP4678794B1 (ja) * 2009-11-16 2011-04-27 株式会社ジェイ エスキューブ データエントリーシステム
JP2011239351A (ja) * 2010-05-13 2011-11-24 Ricoh Co Ltd デジタルフロントエンドサーバ、その制御方法、画像形成装置及びプリントシステム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016057667A (ja) * 2014-09-05 2016-04-21 富士ゼロックス株式会社 情報処理装置及び情報処理プログラム
US10354238B2 (en) 2014-09-05 2019-07-16 Fuji Xerox Co., Ltd. Information processing apparatus, information processing method, and storage medium

Similar Documents

Publication Publication Date Title
US9063992B2 (en) Column based data transfer in extract, transform and load (ETL) systems
US8731973B2 (en) Overlaying images in automated insurance policy form generation
US8656021B2 (en) Methods and apparatus for constructing an execution environment in which the application operates
JP5939123B2 (ja) 実行制御プログラム、実行制御方法および情報処理装置
CN103198090A (zh) 用于优化虚拟桌面环境中的存储分配的方法和系统
JP4678794B1 (ja) データエントリーシステム
CN108257031B (zh) 医疗保险产品发布方法、装置及存储介质
CN107943542A (zh) 一种配置信息管理方法、装置、可读介质及存储控制器
KR20140110777A (ko) 정보 처리 시스템, 정보 처리 장치, 정보 처리 장치의 제어 방법 및 프로그램
CA2737734A1 (en) Overlaying images in automated insurance policy form generation
CN112651826A (zh) 授信额度管控系统、方法及可读存储介质
JP2020197873A (ja) 情報処理システム、及び情報処理システムの制御方法
US10706225B2 (en) Form management system and method
WO2014049803A1 (ja) 計算機、バッチジョブ生成方法及び記録媒体
US20220335016A1 (en) Management device, management method, and non-transitory computer-readable recording medium
CN102467355B (zh) 信息处理设备及方法
CN111105111B (zh) 阅读管理方法、设备、系统及存储介质
JP2011233104A (ja) 情報処理システム、情報処理装置、情報処理方法、プログラム、記録媒体
CN112651668A (zh) 一种航班资源分配方法、装置及服务器
JP6927771B2 (ja) 販売管理装置、販売管理方法、および、販売管理プログラム
KR102546847B1 (ko) Erp의 커스터마이징 자동화 처리 및 커스터마이징된 erp 솔루션의 제공 방법, 장치 및 시스템
US20230401181A1 (en) Data Management Ecosystem for Databases
CN114416805B (zh) 数据核对方法、装置、计算机设备和存储介质
JP7237677B2 (ja) 業務支援装置、業務支援プログラムおよび業務支援方法
JP7089444B2 (ja) コンテンツ成功報酬配分装置、コンテンツ成功報酬配分方法およびコンテンツ成功報酬配分プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12885508

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12885508

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP