WO2010053130A1 - 情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラム - Google Patents

情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラム Download PDF

Info

Publication number
WO2010053130A1
WO2010053130A1 PCT/JP2009/068917 JP2009068917W WO2010053130A1 WO 2010053130 A1 WO2010053130 A1 WO 2010053130A1 JP 2009068917 W JP2009068917 W JP 2009068917W WO 2010053130 A1 WO2010053130 A1 WO 2010053130A1
Authority
WO
WIPO (PCT)
Prior art keywords
processing
data
server
processing request
request data
Prior art date
Application number
PCT/JP2009/068917
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 CN200980144072.0A priority Critical patent/CN102203756B/zh
Publication of WO2010053130A1 publication Critical patent/WO2010053130A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G06F13/387—Information transfer, e.g. on bus using universal interface adapter for adaptation of different data processing systems to different peripheral devices, e.g. protocol converters for incompatible systems, open system

Definitions

  • the present invention relates to a client device, a server device, and a framework program used in an information processing system that can realize various client devices by being easily customized.
  • processing request data is transmitted from a client device to a server device
  • processing result data corresponding to the processing request data is generated by the server device
  • processing result data is transmitted from the server device to the client device.
  • a client server system in which not only the server device but also a client device performs input check of processing request data.
  • the present invention has been made in view of the above circumstances, and provides a client device, a server device, and a framework program for use in an information processing system that can be easily customized in order to cope with development and modification of different client devices. For the purpose.
  • the present invention is an information processing system comprising a client device that receives processing request data via an input screen, and a server device that processes the processing request data input to the client device and returns processing result data.
  • a user interface in which the client device has means for capturing processing request data input via an input screen displayed on a user interface unit and means for outputting processing result data from the server device to the user interface unit.
  • the cooperation unit stores processing request check information for determining whether an abnormality has occurred in the processing request data in the built-in memory, and is input by the user interface unit based on the processing request check information
  • Input channel having means for checking whether processing request data is abnormal
  • Communication rule information for converting data corresponding to a communication method with the server device, stored in a built-in memory, and when the processing request data is transmitted to the server device, the communication rule information
  • a data conversion unit comprising: means for converting the processing request data based on the information; and means for converting the processing result data based on the communication rule information when the processing result data is received from the server device
  • a communication control unit having means for transmitting data to the server device and means for receiving processing result data returned from the server device, the user interface cooperation unit, the input check unit, the data conversion unit, and the communication
  • a client device used in an information processing system including a control unit and an overall control unit that individually connects to and controls these units; It is over server apparatus and Framework Program.
  • each device and each part is expressed as “system”.
  • each device and each part may be expressed as “device” or “program”. Also, it may be expressed as a “method” for each system or each device. That is, the present invention can be expressed in any category.
  • the client device includes a user interface cooperation unit, an input check unit, an operation control unit, a data conversion unit, a communication control unit, and an overall control unit. Therefore, each unit connected to the overall control unit can be individually developed, and an information processing system that can be easily customized can be provided.
  • the present invention it is possible to provide a client device, a server device, and a framework program used in an information processing system that can be easily customized even if the design policy of the client device is changed.
  • FIG. 1 is a schematic diagram showing a configuration of an information processing system 1 according to the first embodiment of the present invention.
  • FIG. 2 is a schematic diagram illustrating an example of a screen displayed on the UI device 120 according to the embodiment.
  • FIG. 3 is a schematic diagram illustrating an example of table information stored in the input check device 140 according to the embodiment.
  • FIG. 4 is a flowchart for explaining the operation of the input check device 140 according to the embodiment.
  • FIG. 5 is a schematic diagram illustrating an example of operation rule information stored in the operation control apparatus 150 according to the embodiment.
  • FIG. 6 is a schematic diagram illustrating an example of communication rule information stored in the data conversion apparatus 160 according to the embodiment.
  • FIG. 7 is a schematic diagram illustrating an example of server-side communication rule information stored in the data conversion device 230 according to the embodiment.
  • FIG. 8 is a schematic diagram showing an example of request logic correspondence rule information stored in the logic information reading device 260 according to the embodiment.
  • FIG. 9 is a flowchart for explaining the operation of the information processing system 1 according to the embodiment.
  • FIG. 10 is a diagram illustrating an application example of the information processing system 1 according to the embodiment.
  • FIG. 1 is a schematic diagram showing a configuration of an information processing system 1 according to the first embodiment of the present invention.
  • the information processing system 1 includes a client device 100 that receives “processing request data” via an input screen, and a server device 200 that processes the processing request data input to the client device 100 and returns “processing result data”. I have.
  • the client device 100 includes an overall control device 110, a user interface device 120, a user interface cooperation device 130, an input check device 140, an operation control device 150, a data conversion device 160, and a communication control device 170.
  • each apparatus implement achieves each function, when the "program" obtained from the computer-readable storage medium or network previously is installed in the built-in memory (henceforth only memory) of a computer.
  • the overall control device 110 is individually connected to the user interface cooperation device 130, the input check device 140, the operation control device 150, the data conversion device 160, and the communication control device 170 to control each device.
  • the overall control device 110 is provided with a connection interface with each device, and the connected devices can be individually controlled.
  • the user interface device 120 (hereinafter referred to as the UI device 120) is configured by a general mouse, keyboard, display, and the like, and enables data input / output to the user who operates the client device 100. .
  • processing request data is input via an input screen displayed on the UI device 120.
  • the UI device 120 displays a new employee registration processing screen as shown in FIG. Further, processing request data for requesting registration of employee information input on this screen is transmitted to the server apparatus 200.
  • the user interface cooperation device 130 (hereinafter referred to as the UI cooperation device 130) cooperates with the UI device 120, a function of fetching processing request data input via the UI device 120, and processing result data from the server device 200. Is output to the UI device 120.
  • the input check device 140 stores “processing request check information” in advance in the internal memory 141 for determining whether or not an abnormality (hereinafter also referred to as an error) has occurred in the processing request data. Based on the above, it is checked whether or not an error has occurred in the processing request data fetched by the UI linkage apparatus 130.
  • an abnormality hereinafter also referred to as an error
  • the input check device 140 stores three pieces of table information such as screen check information 1410, screen definition information 1420, and component check information 1430 as shown in FIG.
  • a target screen name 1412 and a check code name 1413 are written in association with the primary key identification information 1411.
  • the target screen name 1412 is information for designating a screen on which processing request data is input as a check target.
  • the check code name 1413 indicates the name of the check code applied to the processing request data input to the target screen name 1412.
  • the check code is stored in the built-in memory 141, and is read by specifying the check code name 1413. Then, “processing request check information” is included in this check code, and it is determined whether or not the processing request data is normal. For example, in the identification information A001 of the screen check information 1410 in FIG. 3, the check code program “CheckForm.checkLoginForm” is called and the process is executed to check the processing request data input to the “LoginForm” screen. .
  • the screen definition information 1420 stores a screen name 1422, a component name 1423, and a type 1424 in association with the primary key identification information 1421.
  • a screen name 1422 is information for designating a screen
  • a component name 1423 is information for identifying a component constituting the screen
  • a type 1424 is for identifying a rule applied to check processing request data input to the component. Information. From this type 1424, a check code name of component check information 1430 described later is selected.
  • the “Name” type rule is applied to the “TextBox1” component on the “EntryForm” screen. Even for components that obtain numerical values, different rules are applied to each component, such as “Age” type rules for “NumberField1” components and “Money” type rules for “NumberField2” components.
  • “Age” type rules for “NumberField1” components and “Money” type rules for “NumberField2” components.
  • a type 1432 and a check code name 1433 are stored in association with the identification information 1431 that is a primary key.
  • the corresponding check code “CheckRule.checkName” is called from the component check information 1430. .
  • the input check device 140 performs the operation of the flowchart shown in FIG.
  • the input check device 140 determines whether or not there is an abnormality in the processing request data, it first refers to the screen definition information 1420 (N1). Then, the input check device 140 executes check codes corresponding to the component types in the order indicated by the identification information 1421 (N2). That is, the input check device 140 collates the input processing request data with the screen name 1422 and the component name 1423 of the screen definition information 1420, and if there is a registered component (N3-Yes), the component name The type 1424 corresponding to is acquired (N4). Subsequently, the input check device 140 reads a check code name 1433 corresponding to the acquired type from the component check information 1430 (N5).
  • the input check device 140 performs processing of the check code indicated by the acquired check code name 1433 on the target component to check whether an error has occurred in the processing request data ( N6). If an error has occurred in the processing request data as a result of the check (N7-Yes), the error content is recorded in the built-in memory (N8). The input check device 140 repeats this process for all component names 1423 stored in the screen definition information 1420 (N2-No).
  • the input check device 140 when the input check device 140 completes the check process in units of components on the input screen, it performs an error check of input data in units of screens.
  • the input check device 140 refers to the screen check information 1410 (N9).
  • the input check device 140 executes check codes corresponding to the target screen name 1412 in the order indicated by the identification information 1411 (N10). That is, the input check device 140 collates the input processing request data with the target screen name 1412 of the screen check information 1410. If there is a registered target screen name (S11-Yes), the target screen name The check code name 1413 corresponding to is read (S12).
  • the input check device 140 executes processing of the check code indicated by the acquired check code name 1433 on the target screen, and checks whether or not an error has occurred in the processing request data (S13). ). As a result of the check, if an error has occurred in the processing request data (N14-Yes), the error content is recorded in the built-in memory (N15). The input check device 140 repeats this process for all target screen names 1412 stored in the screen check information 1410 (N10).
  • the operation control device 150 stores “correction data” for correcting the processing request data in the built-in memory 151 in advance. If the input check device 140 determines that the processing request data is abnormal, the operation control device 150 sets the correction data. Based on this, it is determined whether or not the abnormality of the processing request data can be corrected, and if the correction is possible, the processing request data is corrected. Further, the operation control device 150 stores “processing result check information” for determining whether or not there is an abnormality in the processing result data in the built-in memory 151 in advance, and based on the processing result check information, the server device It has a function of checking whether there is an abnormality in the processing result data returned from 200 and generating error data if there is an abnormality.
  • the operation control device 150 stores operation rule information 1510 as shown in FIG.
  • the operation rule information 1510 stores an error cause 1512, an error type 1513, a target range 1514, and a processing code 1515 in association with the identification information 1511 that is a primary key.
  • the error cause 1512 indicates an input location on the screen of the processing request data determined to be abnormal when the input check device 140 determines that the processing request data is abnormal.
  • the error type 1513 the severity of the error content of the processing request data is written from the comparison with the processing request check information.
  • the error types are roughly classified into three types: “warning”, “correctable”, and “unrecoverable”. In the case of the mildest error, the error type is “warning”.
  • the corresponding processing code is executed in the form of adding an error comment.
  • the error type is “correctable”
  • the data content is corrected by executing the processing code.
  • the processing code is not executed and error information is returned to the request source.
  • a target range 1514 indicates whether the error influence range is a screen unit or a component unit.
  • the processing code 1515 is a program for executing actual processing, and includes “correction data” and “processing result check information”.
  • FIG. 5 shows a range for passing an argument when calling a designated process. Information for adding a comment when the error type is “warning”, correcting data when it is “correctable”, and error processing when “unrecoverable” is shown.
  • the data conversion device 160 stores “communication rule information 1610” for converting data corresponding to the communication method with the server device 200 in advance in the built-in memory 161, and transmits processing request data to the server device 200.
  • the processing request data is converted based on the communication rule information 1610.
  • the data conversion device 160 converts the processing result data based on the communication rule information 1610. In short, this data conversion maintains the independence between the data holding format on the UI device 110 of the client device 100 and the data format for communicating with the server device 200. As shown in FIG.
  • the communication rule information 1610 stores a request name 1612, a communication method 1613, a data conversion method 1614, and a communication destination server information 1615 in association with the primary key identification information 1611. .
  • the request name 1612 is information for checking the type of processing request data.
  • the communication method 1613 is information indicating a method for communicating with the communication destination server device.
  • the data conversion method 1614 is information indicating a conversion method for data transmitted / received in correspondence with the communication method 1613.
  • the communication destination server information 1615 is information indicating a server device that executes processing of processing request data.
  • the communication control device 170 has a function of transmitting processing request data to the server device 200 and a function of receiving processing result data returned from the server device 200. Note that the communication control device 170 can switch the communication method according to the user definition.
  • the server device 200 includes an overall control device 210, a communication control device 220, a data conversion device 230, a data check device 240, an operation control device 250, a logic information reading device 260, and a logic execution device 270.
  • the overall control device 210 is individually connected to the communication control device 220, the data conversion device 230, the data check device 240, the operation control device 250, and the logic information reading device 260 to control each device. That is, the overall control device 210 is provided with a connection interface with each device, and the connected device can be individually controlled.
  • the communication control device 220 has a function of receiving processing request data from the client device 100 and a function of transmitting processing result data to the client device 100.
  • the data conversion device 230 stores “server side communication rule information 2320” for converting data corresponding to the communication method with the client device 100 in the internal memory 231 and receives processing request data from the client device 100. If so, the processing request data is converted based on the server side communication rule information 2320. Further, when transmitting the processing result data to the client device 100, the data conversion device 230 converts the processing result data based on the server side communication rule information 2320. By this data conversion, independence between the data holding format in the server apparatus 200 and the data format for communicating with the client apparatus 100 is maintained.
  • the server side communication rule information 2320 stores a communication method 2322 and a data conversion method 2323 in association with the primary key identification information 2321 as shown in FIG.
  • the communication method 2322 is information indicating a method for communicating with the client device 100.
  • the data conversion method 2323 is information indicating a conversion method for data transmitted / received in correspondence with the communication method 2322.
  • the data check device 240 stores “data check information” for determining whether or not an abnormality has occurred in the processing request data in the built-in memory, and received from the client device 100 based on the data check information. This is to check whether the processing request data is abnormal.
  • the data check information stored in the data check device 240 the same processing request check information stored in the input check device 140 of the client device 100 can be used.
  • the operation control device 250 stores “server-side correction data” for correcting the processing request data in the built-in memory.
  • the server-side correction is performed. Based on the data, it is determined whether or not the abnormality of the processing request data can be corrected. If the correction is possible, the processing request data is corrected.
  • the logic information reading device 260 stores “request logic correspondence rule information 2610” in which the processing request data is associated with the logic code name for processing the processing request data in the built-in memory 261, and the data check device The logic code name applied to the processing request data determined to be normal by 240 or the processing request data corrected by the operation control device 250 is read from the request logic correspondence rule information 2610.
  • the logic information reading device 260 stores request logic correspondence rule information 2610 as shown in FIG.
  • the request logic correspondence rule information 2610 stores a request name 2612 and a logic code name 2613 in association with identification information 2611 that is a primary key.
  • a request name 2612 that matches the logic information reading device 260
  • a logic code name 2613 corresponding to the request name. Is read out.
  • the read logic code name 2613 is sent to the overall control device 210.
  • the logic execution device 270 executes the logic code corresponding to the logic code name 913 read by the logic information reading device 260 and generates processing result data.
  • processing request data is input from the user interface device 120 of the client device 100 (S1). Subsequently, the UI controller 130 is controlled by the overall control device 110, and the input processing request data is taken into the overall control device 110. Then, processing request data is sent from the overall control device 110 to the input check device 140. In the input check device 140, it is checked whether or not an error has occurred in the processing request data by comparison with processing request check information stored in advance (S2). Then, a check result as to whether or not an error has occurred is sent from the input check device 140 to the overall control device 110.
  • the processing request data is sent from the overall control device 110 to the data conversion device 160 as it is.
  • the data conversion device 160 converts the processing request data into data corresponding to the communication method with the destination server device, and sends the converted data to the overall control device 110 (S3).
  • processing request data corresponding to the communication method with the destination server device is transmitted to the server device via the communication control device 170 (S4).
  • step S2 when a check result indicating that an error has occurred in the processing request data is sent to the overall processing device 110 in step S2 (S2-No), the processing request data is sent from the overall control device 100 to the operation control device 150. Is done.
  • the operation control device 150 determines whether or not the error in the processing request data can be repaired by comparison with the correction data stored in advance (S5). If it is determined that the data can be repaired (S5-Yes), the processing request data is corrected by the operation control device 150, and the corrected processing request data is sent to the overall control device 110 (S6). On the other hand, if it is determined that it cannot be repaired (S5-No), error data is generated by the operation control device 150 and sent to the overall control device 110 (S7). In this case, under the control of the overall control device 110, communication with the server device 200 is not performed, and the fact that an error has occurred is output to the UI device 120.
  • processing request data from the client device 100 is received by the function of the communication control device 220 of the server device 200 (S8). Subsequently, the received processing request data is converted into a format that can be processed in the server device 200 by the function of the data conversion device 230 (S9).
  • the data check device 240 determines whether an error has occurred in the received processing request data (S10). Then, a check result as to whether or not an error has occurred in the processing request data is sent from the data check device 240 to the overall control device 210.
  • the read instruction of the logic code name corresponding to the processing request data is totally controlled.
  • the data is sent from the device 210 to the logic information reading device 260.
  • the logic information reading device 260 reads the logic code name from the request logic corresponding rule information based on the request name included in the processing request data, and sends it to the overall control device 210 (S11).
  • the overall control device 210 sends the logic code name to the logic execution device 270.
  • the logic code corresponding to the logic code name is executed, and the executed result is generated as processing result data (S12).
  • processing result data is sent from the logic execution device 270 to the overall control device 210. Subsequently, under the control of the data conversion device 230 of the overall control device 210, the processing result data is converted and transmitted according to the communication method with the client device 100 (S13).
  • the operation control device 250 sets the processing request data. Whether correction is possible is determined based on the server-side correction data (S14). When the operation control device 250 determines that the processing request data can be corrected (S14-Yes), the processing request data is corrected (S15). And it continues to step S11. On the other hand, when the operation control device 250 determines that the processing request data cannot be corrected (S14-No), error data is generated as processing result data (S16). The error data is converted by the data conversion device 230 and then sent to the client device 100.
  • the data conversion device 160 When the processing result data is received from the server device 200 by the client device 100, the data conversion device 160 is controlled by the overall control device 110. Then, the processing result data is converted into a format that can be processed in the client device 100 by the data conversion device 160 (S17).
  • the client device 100 includes the UI cooperation device 130, the input check device 140, the operation control device 150, the data conversion device 160, the communication control device 170, and the overall control device. 110, and the overall control device 110 is individually connected to and controlled by each device, so that each device connected to the overall control device 110 can be individually developed. Therefore, customization such as deleting or adding functions of the information processing system 1 can be easily performed.
  • the client apparatus 100 of the information processing system 1 has a unified interface between the overall control apparatus 110 and each apparatus, and has a configuration that facilitates replacement of communication modules, for example.
  • the server device 200 includes a communication control device 220, a data conversion device 230, a data check device 240, an operation control device 250, a logic information reading device 260, a logic execution device 270, and an overall control device 210.
  • the overall control device 210 is connected and controlled individually to each device, each device connected to the overall control device 210 can be individually developed. Therefore, customization such as deleting or adding functions of the information processing system 1 can be easily performed.
  • the client device 100 may be realized by a construction technique using a rich client with different functions. Thereby, when inputting processing request data, it is possible to provide various user interfaces that are more convenient than general Web applications. Further, the operation control device 150 can perform processing defined on the application side of the client device 100 as post-processing according to the type of error in the processing request data.
  • the information processing system 1 is configured to be controlled by the overall control device 110 connected to each device individually, the development of the rich client system is standardized and contributes to the improvement of productivity and quality.
  • the UI cooperation device 130, the input check device 140, the operation control device 150, the data conversion device 160, the communication control device 170, and the overall control device 110 are realized by incorporating individual programs into a computer. Therefore, a rich client system can be easily constructed by customizing each device.
  • the rich client system is realized, for example, with a configuration as shown in FIG. In this example, four types of client mounting techniques are listed. In addition, here, a configuration in which there are a plurality of client mounting technologies, communication methods, servers, and DBMSs (Database Management System) is shown. A system may be configured.
  • the client device 100A used by the user 50A is an environment that can be realized by a single Web browser.
  • An example is Ajax (Asynchronous JavaScript + XML).
  • the user 50A accesses the information processing system via the browser 51A.
  • the client device 100A is realized by a script operable on a browser such as JavaScript (trademark of Sun Microsystems).
  • the client device 100B used by the user 50B is configured to use the plug-in 52B on the Web browser.
  • An example of this is the use of Flash plug-ins from Adobe (Adobe is a trademark of Adobe Systems).
  • the user 50B needs to install the plug-in 52B on the browser 51B before using the information processing system.
  • the client device 100C used by the user 50C has a configuration that requires a runtime to the client in addition to the plug-in.
  • the user 50C needs to install the runtime module 53C into the client device 100C in addition to the plug-in 52C into the Web browser 51C before using the information processing system.
  • the runtime module 53C can use the resources of the client device 100C.
  • the client device 100D used by the user 50D is configured not to use a Web browser. In the case of this configuration, it is necessary to install the client module in the client device 100D regardless of whether the user 50D is explicit or not.
  • client apparatuses 100A to 100D realized by various mounting technologies and methods, and each corresponds to a plurality of communication methods 61 to 63.
  • server devices 200A and 200B are configured by a plurality of mounting techniques and systems, and correspond to a plurality of communication systems 61 to 63.
  • the method described in the above embodiment is a program that can be executed by a computer as a magnetic disk (floppy (registered trademark) disk, hard disk, etc.), optical disk (CD-ROM, DVD, etc.), magneto-optical disk (MO). ), And can be distributed in a storage medium such as a semiconductor memory.
  • a magnetic disk floppy (registered trademark) disk, hard disk, etc.
  • optical disk CD-ROM, DVD, etc.
  • MO magneto-optical disk
  • the storage medium can store a program and can be read by a computer
  • the storage format may be any form.
  • an OS operating system
  • MW middleware
  • database management software network software
  • the storage medium in the present invention is not limited to a medium independent of a computer, but also includes a storage medium in which a program transmitted via a LAN, the Internet, or the like is downloaded and stored or temporarily stored.
  • the number of storage media is not limited to one, and the case where the processing in the above embodiment is executed from a plurality of media is also included in the storage media in the present invention, and the media configuration may be any configuration.
  • the computer executes each process in the above-described embodiment based on a program stored in a storage medium, and is a single device such as a personal computer or a system in which a plurality of devices are connected to a network. Any configuration may be used.
  • the computer in the present invention is not limited to a personal computer, but includes an arithmetic processing device, a microcomputer, and the like included in an information processing device, and is a generic term for devices and devices that can realize the functions of the present invention by a program. .
  • DESCRIPTION OF SYMBOLS 1 ... Information processing system, 100 ... Client apparatus, 110 ... Overall control apparatus, 120 ... User interface apparatus, 130 ... User interface cooperation apparatus, 140 ... Input check apparatus, 150. ..Operation control device 160 ... Data conversion device 170 ... Communication control device 200 ... Server device 210 ... Overall control device 220 ... Communication control device 230 ... Data Conversion device, 240... Data check device, 250... Operation control device, 260... Logic information reading device, 270.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

　情報処理システム（１）は、処理要求データを入力画面を介して受け付けるクライアント装置（１００）と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置（２００）とを備える。クライアント装置（１００）は、ＵＩ連携装置（１３０）・入力チェック装置（１４０）・動作制御装置（１５０）・データ変換装置（１６０）・通信制御装置（１７０）・全体制御装置（１１０）を備えており、全体制御装置（１１０）が各装置に個別に接続して制御する。

Description

情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラム
　本発明は、カスタマイズが容易に行えることにより様々なクライアント装置を実現し得る情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラムに関する。
　従来から、各種の業務処理がクライアントサーバシステムにより実行されている。一般的に、クライアントサーバシステムでは、クライアント装置からサーバ装置に処理要求データを送信し、サーバ装置で処理要求データに対応する処理結果データを生成し、サーバ装置からクライアント装置に処理結果データを送信する。
　ここで、システム全体の処理性能を最適化するために、サーバ装置のみならず、クライアント装置で処理要求データの入力チェック等を行う形態のクライアントサーバシステムもある。
　これまで、クライアントとしての機能を実現する装置自体の性能が未熟であったため、また、クライアント装置毎に高級な機能を備えるコストが高かったため、Ｗｅｂを用いたシステムが多く開発されてきた。
　これに関し、近年では、単なるＷｅｂアプリケーションに比べ画面設計の自由度を高くするために、リッチクライアント化の傾向にある。リッチクライアントでは、従来に比べクライアント装置上での複雑な処理が実行されることになる。そのため、クライアント装置のシステム全体の開発に占めるコストは増加している。
特開２００６－７２９７８号公報
　しかしながら、一般的なクライアントサーバシステムにおいて、新規クライアント装置の開発や、既存のクライアント装置の設計方針が変更されると、クライアント装置の機能を全て作り直しており、多大な開発コストを要する傾向がある。
　特にデータエントリ系のシステム等においては、システムの利便性が業務効率化に影響するため、クライアント装置においてユーザのデータ入出力を支援するための機能が多く設けられている。よって、クライアント装置自体の開発、改造の対象となる機能が多くなる。
　本発明は上記実情に鑑みてなされたものであり、異なるクライアント装置の開発、および改造に対応するため、容易にカスタマイズし得る、情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラムを提供することを目的とする。
　本発明は、処理要求データを入力画面を介して受け付けるクライアント装置と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置とを備えた情報処理システムであって、前記クライアント装置が、ユーザインタフェース部に表示される入力画面を介して入力された処理要求データを取り込む手段と前記サーバ装置からの処理結果データを前記ユーザインタフェース部に出力する手段とを有するユーザインタフェース連携部、前記処理要求データに異常が生じているか否かを判定するための処理要求チェック情報を内蔵メモリに記憶しており、該処理要求チェック情報に基づいて、前記ユーザインタフェース部により入力された処理要求データの異常の有無をチェックする手段を有する入力チェック部、前記サーバ装置との通信方式に対応させてデータを変換するための通信ルール情報を内蔵メモリに記憶しており、前記サーバ装置へ前記処理要求データを送信する場合に前記通信ルール情報に基づいて該処理要求データを変換する手段と前記サーバ装置から前記処理結果データを受信する場合に前記通信ルール情報に基づいて該処理結果データを変換する手段とを有するデータ変換部、前記処理要求データを該サーバ装置に送信する手段と、前記サーバ装置から返信される処理結果データを受信する手段とを有する通信制御部、前記ユーザインタフェース連携部、前記入力チェック部、前記データ変換部、前記通信制御部、これら各部へ個別に接続して制御する全体制御部、を備えた情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラムである。
　なお、本発明は、各装置、各部の集合体を「システム」として表現したが、これに限らず、以下の記載では各装置、各部毎に「装置」又は「プログラム」として表現してもよく、また、システム又は各装置毎に「方法」として表現してもよい。すなわち、本発明は、任意のカテゴリーで表現可能となっている。
＜作用＞
　従って、本発明は、クライアント装置が、ユーザインタフェース連携部と、入力チェック部と、動作制御部と、データ変換部と、通信制御部と、全体制御部とを備えており、全体制御部が各部へ個別に接続して制御するので、全体制御部に接続する各部を個別に開発することができ、容易にカスタマイズし得る情報処理システムを提供することができる。
　本発明によれば、クライアント装置の設計方針が変更されても容易にカスタマイズし得る、情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラムを提供することが可能となる。
図１は、本発明の第１の実施形態に係る情報処理システム１の構成を示す模式図である。 図２は、同実施形態に係るＵＩ装置１２０に表示される画面の一例を示す模式図である。 図３は、同実施形態に係る入力チェック装置１４０に記憶されるテーブル情報の一例を示す模式図である。 図４は、同実施形態に係る入力チェック装置１４０の動作を説明するためのフローチャートである。 図５は、同実施形態に係る動作制御装置１５０に記憶される動作ルール情報の一例を示す模式図である。 図６は、同実施形態に係るデータ変換装置１６０に記憶される通信ルール情報の一例を示す模式図である。 図７は、同実施形態に係るデータ変換装置２３０に記憶されるサーバ側通信ルール情報の一例を示す模式図である。 図８は、同実施形態に係るロジック情報読出装置２６０に記憶される要求ロジック対応ルール情報の一例を示す模式図である。 図９は、同実施形態に係る情報処理システム１の動作を説明するためのフローチャートである。 図１０は、同実施形態に係る情報処理システム１の適用例を示す図である。
　以下、図面を参照して本発明の実施形態を説明する。
＜第１の実施形態＞
（情報処理システムの構成）
　図１は本発明の第１の実施形態に係る情報処理システム１の構成を示す模式図である。
　情報処理システム１は、「処理要求データ」を入力画面を介して受け付けるクライアント装置１００と、クライアント装置１００に入力される処理要求データを処理して「処理結果データ」を返信するサーバ装置２００とを備えている。
　クライアント装置１００は、全体制御装置１１０・ユーザインタフェース装置１２０・ユーザインタフェース連携装置１３０・入力チェック装置１４０・動作制御装置１５０・データ変換装置１６０・通信制御装置１７０を備えている。なお、各装置は、予めコンピュータ読み取り可能な記憶媒体またはネットワークから得られた「プログラム」がコンピュータの内蔵メモリ（以下、単にメモリと記載する）にインストールされることにより、それぞれの機能を実現する。
　全体制御装置１１０は、ユーザインタフェース連携装置１３０・入力チェック装置１４０・動作制御装置１５０・データ変換装置１６０・通信制御装置１７０に個別に接続して各装置を制御するものである。換言すると、全体制御装置１１０には、各装置との接続インタフェースが設けられており、接続された装置に対して個別に制御が可能となっている。
　ユーザインタフェース装置１２０（以下、ＵＩ装置１２０と記載する）は、一般的なマウスやキーボード、ディスプレイ等で構成され、クライアント装置１００を操作するユーザに対してデータの入出力を可能にするものである。ここでは、ＵＩ装置１２０に表示される入力画面を介して、処理要求データが入力される。例えば、ＵＩ装置１２０では、図２に示すような従業員新規登録処理画面などが表示される。また、この画面上で入力された従業員情報の登録を要求する処理要求データがサーバ装置２００に送信される。
　ユーザインタフェース連携装置１３０（以下、ＵＩ連携装置１３０と記載する）は、ＵＩ装置１２０と連携し、ＵＩ装置１２０を介して入力された処理要求データを取り込む機能と、サーバ装置２００からの処理結果データをＵＩ装置１２０に出力する機能とを有するものである。
　入力チェック装置１４０は、処理要求データに異常（以下エラーともいう）が生じているか否かを判定するための「処理要求チェック情報」を予め内蔵メモリ１４１に記憶しており、この処理要求チェック情報に基づいて、ＵＩ連携装置１３０により取り込まれた処理要求データにエラーが生じているか否かをチェックする。
　具体的には、入力チェック装置１４０は、図３に示すような、画面チェック情報１４１０、画面定義情報１４２０及びコンポーネントチェック情報１４３０の３つのテーブル情報を記憶している。
　画面チェック情報１４１０には、主キーの識別情報１４１１に対応づけて、対象画面名１４１２とチェックコード名１４１３とが書き込まれている。対象画面名１４１２は、処理要求データが入力された画面をチェック対象として指定するための情報である。チェックコード名１４１３は、対象画面名１４１２に入力された処理要求データに適用されるチェックコードの名称を示す。チェックコードは内蔵メモリ１４１に格納されており、チェックコード名１４１３の指定により読み出される。そして、このチェックコードの中に「処理要求チェック情報」が含まれており、処理要求データが正常であるか否かが判定される。例えば、図３の画面チェック情報１４１０の識別情報Ａ００１では、“LoginForm”画面に入力された処理要求データのチェックには、“CheckForm.checkLoginForm”のチェックコードのプログラムが呼び出されて処理が実行される。
　画面定義情報１４２０には、主キーの識別情報１４２１に対応づけて、画面名１４２２、コンポーネント名１４２３、タイプ１４２４が記憶されている。画面名１４２２は画面を指定する情報であり、コンポーネント名１４２３は画面を構成するコンポーネントを識別する情報であり、タイプ１４２４はコンポーネントに入力される処理要求データのチェックに適用されるルールを識別するための情報である。このタイプ１４２４から、後述するコンポーネントチェック情報１４３０のチェックコード名が選択される。図３の画面定義情報１４２０の識別情報Ｂ００１の例では、“EntryForm”画面上の“TextBox1”コンポーネントに“Name”タイプのルールが適用される。また、数値を取得するコンポーネントであっても、“NumberField1”コンポーネントには“Age”タイプのルール、“NumberField2”コンポーネントには“Money”タイプのルール、というようにコンポーネントごとに異なるルールが適用されることもある。
　コンポーネントチェック情報１４３０には、主キーである識別情報１４３１に対応づけて、タイプ１４３２とチェックコード名１４３３とが記憶される。図３の例では、“EntryForm”画面の“TextBox1”コンポーネントは画面定義情報１４２０によって“Name”タイプであるので、これに対応するチェックコードである“CheckRule.checkName”がコンポーネントチェック情報１４３０から呼び出される。
　さらに詳しくは、入力チェック装置１４０は、図４に示すフローチャートの動作を行なう。入力チェック装置１４０は、処理要求データに異常があるか否かを判定する場合、まず画面定義情報１４２０を参照する（Ｎ１）。それから、入力チェック装置１４０は、識別情報１４２１で示された順にコンポーネントのタイプに対応するチェックコードを実行する（Ｎ２）。すなわち、入力チェック装置１４０は、入力された処理要求データと、画面定義情報１４２０の画面名１４２２及びコンポーネント名１４２３とを照合し、登録されているコンポーネントがあれば（Ｎ３－Ｙｅｓ）、そのコンポーネント名に対応するタイプ１４２４を取得する（Ｎ４）。続いて、入力チェック装置１４０は、取得したタイプに対応するチェックコード名１４３３をコンポーネントチェック情報１４３０から読み出す（Ｎ５）。そして、入力チェック装置１４０は、対象となるコンポーネントに対し、取得したチェックコード名１４３３で示されたチェックコードの処理を実行して、処理要求データにエラーが生じているか否かのチェックを行う（Ｎ６）。チェックの結果、処理要求データにエラーが生じている場合（Ｎ７－Ｙｅｓ）には、そのエラー内容を内蔵メモリに記録する（Ｎ８）。入力チェック装置１４０は、この処理を、画面定義情報１４２０に記憶されている全てのコンポーネント名１４２３について繰り返す（Ｎ２－Ｎｏ）。
　次に、入力チェック装置１４０は、入力画面上でのコンポーネント単位でのチェック処理が完了すると、画面単位での入力データのエラーチェックを実施する。まず、入力チェック装置１４０は、画面チェック情報１４１０を参照する（Ｎ９）。それから、入力チェック装置１４０は、識別情報１４１１で示された順に、対象画面名１４１２に対応するチェックコードを実行する（Ｎ１０）。すなわち、入力チェック装置１４０は、入力された処理要求データと、画面チェック情報１４１０の対象画面名１４１２とを照合し、登録されている対象画面名があれば（Ｓ１１－Ｙｅｓ）、その対象画面名に対応するチェックコード名１４１３を読み出す（Ｓ１２）。そして、入力チェック装置１４０は、対象画面に対し、取得したチェックコード名１４３３で示されたチェックコードの処理を実行して、処理要求データにエラーが生じているか否かのチェックを実行する（Ｓ１３）。チェックの結果、処理要求データにエラーが生じている場合（Ｎ１４－Ｙｅｓ）には、そのエラー内容を内蔵メモリに記録する（Ｎ１５）。入力チェック装置１４０は、この処理を画面チェック情報１４１０に記憶されている全ての対象画面名１４１２について繰り返す（Ｎ１０）。
　動作制御装置１５０は、処理要求データを修正するための「修正データ」を予め内蔵メモリ１５１に記憶しており、入力チェック装置１４０により処理要求データに異常があると判定された場合、修正データに基づいて、処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正するものである。また、動作制御装置１５０は、処理結果データに異常があるか否かを判定するための「処理結果チェック情報」を予め内蔵メモリ１５１に記憶しており、処理結果チェック情報に基づいて、サーバ装置２００から返信された処理結果データの異常の有無をチェックするとともに、異常があればエラーデータを生成する機能を有している。
　具体的には、動作制御装置１５０は、図５に示すような動作ルール情報１５１０を記憶する。動作ルール情報１５１０には、主キーである識別情報１５１１に関連づけて、エラー原因１５１２、エラー種別１５１３、対象範囲１５１４、処理コード１５１５が記憶されている。エラー原因１５１２は、入力チェック装置１４０により処理要求データに異常があると判定された場合、異常があると判定された処理要求データの画面上での入力箇所を示す。エラー種別１５１３には、処理要求チェック情報との比較から、処理要求データのエラー内容の重大度が書き込まれる。ここでは、エラー種別は“警告”、“補正可能”、“修復不能”の３つに大別される。最も軽度のエラーの場合はエラー種別が“警告”となる。この場合、エラーのコメントを付記する形で対応する処理コードが実行される。エラー種別が“補正可能”である場合は、処理コードの実行により、データ内容が修正される。エラー種別が“修復不能”である場合は、処理コードの実行は行なわれず、エラー情報が要求元に差し戻される。対象範囲１５１４は、エラーの影響範囲が画面単位なのかコンポーネント単位なのかを示している。処理コード１５１５は、実際の処理を実行するプログラムであり、「修正データ」及び「処理結果チェック情報」が含まれている。図５には、指定された処理を呼び出す際の引数を受け渡す範囲が示されている。エラー種別が“警告”の場合のコメントの付加、“補正可能”の場合のデータの修正、“修復不能”の際のエラー処理を規定する情報が示される。
　データ変換装置１６０は、サーバ装置２００との通信方式に対応させてデータを変換するための「通信ルール情報１６１０」を予め内蔵メモリ１６１に記憶しており、サーバ装置２００へ処理要求データを送信する場合、この通信ルール情報１６１０に基づいて処理要求データを変換するものである。また、データ変換装置１６０は、サーバ装置２００から処理結果データを受信する場合、通信ルール情報１６１０に基づいて処理結果データを変換する。要するに、このデータ変換によって、クライアント装置１００のＵＩ装置１１０上でのデータの保持形式と、サーバ装置２００と通信するためのデータの形式との間での独立性が保たれることになる。なお、通信ルール情報１６１０には、図６に示すように、主キーの識別情報１６１１に対応づけて、リクエスト名１６１２・通信方式１６１３・データ変換方式１６１４・通信先サーバ情報１６１５が記憶されている。リクエスト名１６１２は、処理要求データの種類を照合するための情報である。通信方式１６１３は、通信先サーバ装置と通信する方式を示す情報である。データ変換方式１６１４は、通信方式１６１３に対応させて送受信するデータの変換方式を示す情報である。通信先サーバ情報１６１５は、処理要求データの処理を実行させるサーバ装置を示す情報である。
　通信制御装置１７０は、処理要求データをサーバ装置２００に送信する機能と、サーバ装置２００から返信される処理結果データを受信する機能とを有するものである。なお、通信制御装置１７０は、通信方式をユーザ定義により切り替えることが可能である。
　サーバ装置２００は、全体制御装置２１０・通信制御装置２２０・データ変換装置２３０・データチェック装置２４０・動作制御装置２５０・ロジック情報読出装置２６０・ロジック実行装置２７０を備えている。
　全体制御装置２１０は、通信制御装置２２０・データ変換装置２３０・データチェック装置２４０・動作制御装置２５０・ロジック情報読出装置２６０に個別に接続して各装置を制御するものである。すなわち、全体制御装置２１０には、各装置との接続インタフェースが設けられており、接続された装置に対して個別に制御が可能となっている。
　通信制御装置２２０は、処理要求データを該クライアント装置１００から受信する機能と、クライアント装置１００へ処理結果データを送信する機能とを有する。
　データ変換装置２３０は、クライアント装置１００との通信方式に対応させてデータを変換するための「サーバ側通信ルール情報２３２０」を内蔵メモリ２３１に記憶しており、クライアント装置１００から処理要求データを受信する場合、サーバ側通信ルール情報２３２０に基づいて該処理要求データを変換する。また、データ変換装置２３０は、クライアント装置１００へ処理結果データを送信する場合、サーバ側通信ルール情報２３２０に基づいて処理結果データを変換する。このデータ変換によって、サーバ装置２００でのデータの保持形式と、クライアント装置１００と通信するためのデータの形式との間での独立性が保たれる。なお、サーバ側通信ルール情報２３２０には、図７に示すように、主キーの識別情報２３２１に対応づけて、通信方式２３２２・データ変換方式２３２３が記憶されている。通信方式２３２２は、クライアント装置１００と通信する方式を示す情報である。データ変換方式２３２３は、通信方式２３２２に対応させて送受信するデータの変換方式を示す情報である。
　データチェック装置２４０は、処理要求データに異常が生じているか否かを判定するための「データチェック情報」を内蔵メモリに記憶しており、このデータチェック情報に基づいて、クライアント装置１００から受信した処理要求データの異常の有無をチェックするものである。データチェック装置２４０が記憶するデータチェック情報は、クライアント装置１００の入力チェック装置１４０が記憶する処理要求チェック情報と同様のものを利用することができる。
　動作制御装置２５０は、処理要求データを修正するための「サーバ側修正データ」を内蔵メモリに記憶しており、データチェック装置２４０により処理要求データに異常があると判定された場合、サーバ側修正データに基づいて、処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば処理要求データを修正する。
　ロジック情報読出装置２６０は、処理要求データと、この処理要求データを処理するためのロジックコード名とを対応づけた「要求ロジック対応ルール情報２６１０」を内蔵メモリ２６１に記憶しており、データチェック装置２４０により異常が無いと判定された処理要求データ、あるいは動作制御装置２５０により修正された処理要求データに対して適用されるロジックコード名を要求ロジック対応ルール情報２６１０から読み出すものである。
　具体的には、ロジック情報読出装置２６０は、図８に示すような要求ロジック対応ルール情報２６１０を記憶する。要求ロジック対応ルール情報２６１０には、主キーである識別情報２６１１に関連づけて、リクエスト名２６１２とロジックコード名２６１３とが記憶されている。全体制御装置２１０からロジック情報読出装置２６０にクライアント装置１００から発行された処理要求データが送出され、ロジック情報読出装置２６０に合致するリクエスト名２６１２があると、そのリクエスト名に対応するロジックコード名２６１３が読み出される。読み出されたロジックコード名２６１３は全体制御装置２１０に送出される。
　ロジック実行装置２７０は、ロジック情報読出装置２６０により読み出されたロジックコード名９１３に対応するロジックコードを実行して処理結果データを生成するものである。
（情報処理システムの動作）
　次に本実施形態に係る情報処理システム１の動作を図９のフローチャートを用いて説明する。
　始めにクライアント装置１００からサーバ装置２００に処理要求データを送信する際の手順を説明する。
　まず、クライアント装置１００のユーザインタフェース装置１２０から処理要求データが入力される（Ｓ１）。続いて、全体制御装置１１０によりＵＩ連携装置１３０が制御されて、入力された処理要求データが全体制御装置１１０に取り込まれる。そして、全体制御装置１１０から入力チェック装置１４０に処理要求データが送出される。入力チェック装置１４０では、予め記憶された処理要求チェック情報との比較により、処理要求データにエラーが生じているか否かがチェックされる（Ｓ２）。そして、入力チェック装置１４０からエラーが生じているか否かのチェック結果が全体制御装置１１０に送出される。
　全体制御装置１１０に、入力チェック装置１４０からエラーが生じていない旨のチェック結果が送出された場合（Ｓ２－Ｙｅｓ）、全体制御装置１１０からデータ変換装置１６０に処理要求データがそのまま送出される。続いて、データ変換装置１６０により、処理要求データが送信先サーバ装置との通信方式に対応したデータに変換され、変換されたデータが全体制御装置１１０に送出される（Ｓ３）。そして、全体制御装置１１０の制御により、通信制御装置１７０を介して、送信先サーバ装置との通信方式に対応した処理要求データが当該サーバ装置に送信される（Ｓ４）。
　一方、ステップＳ２において、処理要求データにエラーが生じている旨のチェック結果が全体処理装置１１０に送出された場合（Ｓ２－Ｎｏ）、全体制御装置１００から動作制御装置１５０に処理要求データが送出される。
　そして、動作制御装置１５０により、予め記憶された修正データとの比較により、処理要求データのエラーが修復可能であるか否かが判定される（Ｓ５）。修復可能であると判定された場合（Ｓ５－Ｙｅｓ）、動作制御装置１５０により処理要求データが修正され、修正された処理要求データが全体制御装置１１０に送出される（Ｓ６）。一方、修復可能ではないと判定された場合（Ｓ５－Ｎｏ）、動作制御装置１５０によりエラーデータが生成されて全体制御装置１１０に送出される（Ｓ７）。この場合、全体制御装置１１０の制御により、サーバ装置２００との通信は行なわれず、エラーが生じた旨がＵＩ装置１２０に出力される。
　次にサーバ装置２００がクライアント装置１００から処理要求データを受信したときの手順を説明する。
　まず、サーバ装置２００の通信制御装置２２０の機能により、クライアント装置１００からの処理要求データが受信される（Ｓ８）。続いて、データ変換装置２３０の機能により、受信された処理要求データがサーバ装置２００内で処理可能な形式に変換される（Ｓ９）。
　次に、データチェック装置２４０で、受信した処理要求データにエラーが生じているか否かが判定される（Ｓ１０）。そして、処理要求データにエラーが生じているか否かのチェック結果がデータチェック装置２４０から全体制御装置２１０に送出される。
　データチェック装置２４０から全体制御装置２１０に処理要求データにエラーが生じていない旨のチェック結果が送出されると（Ｓ１０－Ｙｅｓ）、その処理要求データに対応するロジックコード名の読出命令が全体制御装置２１０からロジック情報読出装置２６０に送出される。続いて、ロジック情報読出装置２６０により、処理要求データに含まれるリクエスト名に基づいて要求ロジック対応ルール情報からロジックコード名が読み出され、全体制御装置２１０に送出される（Ｓ１１）。続いて、全体制御装置２１０により、ロジックコード名がロジック実行装置２７０に送出される。ロジック実行装置２７０では、ロジックコード名に対応するロジックコードが実行され、実行された結果が処理結果データとして生成される（Ｓ１２）。そして、ロジック実行装置２７０から全体制御装置２１０に処理結果データが送出される。続いて、全体制御装置２１０のデータ変換装置２３０の制御により、クライアント装置１００との通信方式にあわせて処理結果データが変換されて送信される（Ｓ１３）。
　一方、ステップＳ１０において、データチェック装置２４０から全体制御装置２１０に処理要求データにエラーが生じている旨のチェック結果が送出されると（Ｓ１０－Ｎｏ）、動作制御装置２５０により、処理要求データの修正が可能であるか否かがサーバ側修正データに基づいて判定される（Ｓ１４）。処理要求データの修正が可能であると動作制御装置２５０により判定された場合（Ｓ１４－Ｙｅｓ）、処理要求データが修正される（Ｓ１５）。そして、ステップＳ１１に続く。これに対し、処理要求データの修正が不可能であると動作制御装置２５０により判定された場合（Ｓ１４－Ｎｏ）、処理結果データとしてエラーデータが生成される（Ｓ１６）。そして、このエラーデータがデータ変換装置２３０により変換された後、クライアント装置１００に送出される。
　次にクライアント装置１００がサーバ装置２００から処理結果データを受信したときの手順を説明する。
　クライアント装置１００によりサーバ装置２００から処理結果データが受信されると、全体制御装置１１０によりデータ変換装置１６０が制御される。そして、処理結果データがデータ変換装置１６０によりクライアント装置１００内で処理可能な形式に変換される（Ｓ１７）。
　続いて、全体制御装置１１０の動作制御装置１５０の制御により、予め記憶された処理結果チェック情報との比較から、処理結果データにエラーが生じているか否かが確認される（Ｓ１８）。エラーが生じていなければ（Ｓ１８－Ｙｅｓ）、処理結果データがＵＩ装置１２０を介して出力される（Ｓ１９）。一方、エラーが生じていれば、動作制御装置１５０により、エラーデータが生成される（Ｓ１８－Ｎｏ，Ｓ７）。そして、エラーデータがＵＩ装置１２０を介して出力される。
（情報処理システムの効果）
　以上説明したように、本実施形態に係る情報処理システム１は、クライアント装置１００が、ＵＩ連携装置１３０・入力チェック装置１４０・動作制御装置１５０・データ変換装置１６０・通信制御装置１７０・全体制御装置１１０を備えており、全体制御装置１１０が各装置に個別に接続して制御するので、全体制御装置１１０に接続する各装置を個別に開発することができる。それゆえ、情報処理システム１の機能を削除または追加するといったカスタマイズを容易に行なうことができる。
　換言すると、本実施形態に係る情報処理システム１のクライアント装置１００は、全体制御装置１１０と各装置とのインタフェースが統一化されており、例えば通信モジュールの入れ替え等が容易な構成となっている。
　このため、新規にリッチクライアントのシステムを構築する場合においても、既存のファットクライアントやシンクライアントに対応したシステムから、同じインタフェースに基づく各装置を流用することが可能となる。
　また、情報処理システム１は、サーバ装置２００が、通信制御装置２２０・データ変換装置２３０・データチェック装置２４０・動作制御装置２５０・ロジック情報読出装置２６０・ロジック実行装置２７０・全体制御装置２１０を備えており、全体制御装置２１０が各装置に個別に接続して制御するので、全体制御装置２１０に接続する各装置を個別に開発することができる。それゆえ、情報処理システム１の機能を削除または追加するといったカスタマイズを容易に行なうことができる。
　また、クライアント装置１００は、各機能が異なるリッチクライアントを用いる構築技術により実現されてもよい。これにより、処理要求データの入力に際して、一般的なＷｅｂアプリケーションに比して利便性の高い様々なユーザインタフェースを提供することができる。更に、動作制御装置１５０によって、処理要求データのエラーの種類に応じた後処理としてクライアント装置１００のアプリケーション側で定義した処理もできる。
　そして、情報処理システム１は、全体制御装置１１０が各装置と個別に接続して制御する構成であるので、リッチクライアントシステムの開発を標準化し、生産性と品質の向上に資するものである。
　また、クライアント装置１００において、ＵＩ連携装置１３０・入力チェック装置１４０・動作制御装置１５０・データ変換装置１６０・通信制御装置１７０・全体制御装置１１０は、個別のプログラムがコンピュータに組み込まれることにより実現されるので、各装置のカスタマイズにより、リッチクライアントシステムを容易に構築することができる。
　リッチクライアントシステムは、例えば図１０に示すような構成で実現される。この例では、４種類のクライアントの実装技術が挙げられている。なお、ここでは、クライアントの実装技術、および通信方式、サーバ、ＤＢＭＳ(Database Management System)がそれぞれ複数ある構成を示しているが、この一部分でシステムを構成してもよいし、さらに複数利用してシステムを構成してもよい。
　ユーザ５０Ａが利用するクライアント装置１００Ａは、Ｗｅｂブラウザ単体で実現可能な環境である。Ajax(Asynchronous JavaScript + XML)などの例がこれにあたる。ユーザ５０Ａはブラウザ５１Ａを介して情報処理システムにアクセスする。クライアント装置１００ＡはJavaScript（サン・マイクロシステムズ社の商標）などのブラウザ上で稼動可能なスクリプトにより実現される。
　ユーザ５０Ｂが利用するクライアント装置１００Ｂは、Ｗｅｂブラウザ上のプラグイン５２Ｂを利用する構成である。Adobe社（Adobeはアドビシステムズ社の商標）のFlashプラグインを用いた例などがこれにあたる。この構成の場合には、ユーザ５０Ｂは情報処理システム利用前にブラウザ５１Ｂ上へプラグイン５２Ｂの導入を済ませておく必要がある。
　ユーザ５０Ｃが利用するクライアント装置１００Ｃは、プラグインに加えてクライアントへのランタイムが必要となる構成である。この構成の場合には、ユーザ５０Ｃは情報処理システム利用前にＷｅｂブラウザ５１Ｃへのプラグイン５２Ｃの導入に加えて、クライアント装置１００Ｃへのランタイムモジュール５３Ｃの導入が必要である。ランタイムモジュール５３Ｃは、クライアント装置１００Ｃの資源を利用することが可能である。
　ユーザ５０Ｄが利用するクライアント装置１００Ｄは、Ｗｅｂブラウザを利用しない構成である。この構成の場合には、ユーザ５０Ｄの明示・非明示に関らず、クライアント装置１００Ｄへのクライアントモジュールのインストール作業が必要となる。
　以上のように、さまざまな実装技術とその方式により実現されたクライアント装置１００Ａ～１００Ｄがあり、それぞれ複数の通信方式６１～６３に対応している。
　また、サーバ装置２００Ａ，２００Ｂも同様に、複数の実装技術と方式とにより構成され、また複数の通信方式６１～６３に対応している。
　これにより、構築する情報処理システムにおいて、クライアント装置、サーバ装置、通信方式に関する必要な要件により、それぞれのサーバ装置及びクライアント装置の実現技術と通信方式とを選択することが可能となる。また、これらは共存可能であり、複数の方式によるクライアントを単一システム内に同居させることもできる。また、通信方式が合致すれば、異なる実現技術によるクライアント装置もしくはサーバ装置と接続可能である。
＜その他＞
　なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に構成要素を適宜組み合わせてもよい。
　なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
　また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
　また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。
　さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
　また、記憶媒体は１つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
　尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
　また、本発明におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
　１・・・情報処理システム、１００・・・クライアント装置、１１０・・・全体制御装置、１２０・・・ユーザインタフェース装置、１３０・・・ユーザインタフェース連携装置、１４０・・・入力チェック装置、１５０・・・動作制御装置、１６０・・・データ変換装置、１７０・・・通信制御装置、２００・・・サーバ装置、２１０・・・全体制御装置、２２０・・・通信制御装置、２３０・・・データ変換装置、２４０・・・データチェック装置、２５０・・・動作制御装置、２６０・・・ロジック情報読出装置、２７０・・・ロジック実行装置。

Claims (8)

  1. 　処理要求データを入力画面を介して受け付けるクライアント装置（１００）と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置（２００）とを備えた情報処理システム（１）に用いる前記クライアント装置であって、
    　入力画面を表示するユーザインタフェース部（１２０）と、
    　前記ユーザインタフェース部に表示される入力画面を介して入力された処理要求データを取り込む手段と、前記サーバ装置からの処理結果データを前記ユーザインタフェース部に出力する手段とを有するユーザインタフェース連携部（１３０）と、
    　前記処理要求データに異常が生じているか否かを判定するための処理要求チェック情報を内蔵メモリに記憶しており、該処理要求チェック情報に基づいて、前記ユーザインタフェース部により入力された処理要求データの異常の有無をチェックする手段を有する入力チェック部（１４０）と、
    　前記サーバ装置との通信方式に対応させてデータを変換するための通信ルール情報を内蔵メモリに記憶しており、前記サーバ装置へ前記処理要求データを送信する場合、前記通信ルール情報に基づいて該処理要求データを変換する手段と、前記サーバ装置から前記処理結果データを受信する場合、前記通信ルール情報に基づいて該処理結果データを変換する手段とを有するデータ変換部（１６０）と、
    　前記処理要求データを該サーバ装置に送信する手段と、前記サーバ装置から返信される処理結果データを受信する手段とを有する通信制御部（１７０）と、
    　前記ユーザインタフェース連携部と、前記入力チェック部と、前記データ変換部と、前記通信制御部とに個別に接続して制御する全体制御部（１１０）と、
    を備えたことを特徴とするクライアント装置。
  2. 　請求項１に記載のクライアント装置において、前記処理要求データを修正するための修正データを内蔵メモリに記憶しており、前記入力チェック部により処理要求データに異常があると判定された場合にエラーデータを生成する手段と、前記修正データに基づいて、該処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正する手段とを有した、前記全体制御部で制御される動作制御部（１５０）を備えたことを特徴とするクライアント装置。
  3. 　処理要求データを入力画面を介して受け付けるクライアント装置（１００）と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置（２００）とを備えた情報処理システム（１）に用いる前記サーバ装置であって、
    　前記処理要求データを該クライアント装置から受信する手段と、前記クライアント装置へ前記処理結果データを送信する手段とを有するサーバ側通信制御部（２２０）と、
    　前記クライアント装置との通信方式に対応させてデータを変換するためのサーバ側通信ルール情報を内蔵メモリに記憶しており、前記クライアント装置から前記処理要求データを受信する場合、前記サーバ側通信ルール情報に基づいて該処理要求データを変換する手段と、前記クライアント装置へ前記処理結果データを送信する場合、前記サーバ側通信ルール情報に基づいて該処理結果データを変換する手段とを有するサーバ側データ変換部（２３０）と、
    　前記処理要求データに異常が生じているか否かを判定するためのデータチェック情報を内蔵メモリに記憶しており、該データチェック情報に基づいて、前記クライアント装置から受信した処理要求データの異常の有無をチェックする手段を有するデータチェック部（２４０）と、
    　前記処理要求データと、該処理要求データを処理するためのロジック識別情報とを対応づけた要求ロジック対応ルール情報を内蔵メモリに記憶しており、前記データチェック部により異常が無いと判定された処理要求データ、あるいはサーバ側動作制御部により修正された処理要求データに対して適用されるロジック識別情報を前記要求ロジック対応ルール情報から読み出すロジック情報読出部（２６０）と、
    　前記ロジック情報読出部により読み出されたロジック識別情報に対応するロジック情報を実行して処理結果データを生成するロジック実行部（２７０）と、
    　前記サーバ側通信制御部と、前記サーバ側データ変換部と、前記データチェック部と、前記ロジック情報読出部とに個別に接続して制御するサーバ側全体制御部（２１０）と、
    を備えたことを特徴とするサーバ装置。
  4. 　請求項３に記載のサーバ装置において、前記処理要求データを修正するためのサーバ側修正データを内蔵メモリに記憶しており、前記データチェック部により処理要求データに異常があると判定された場合にサーバ側エラーデータを生成する手段と、前記サーバ側修正データに基づいて、該処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正する手段とを有した、前記サーバ側全体制御部で制御されるサーバ側動作制御部（２５０）を備えたことを特徴とするサーバ装置。
  5. 　処理要求データを入力画面を介して受け付けるクライアント装置（１００）と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置（２００）とを備えた情報処理システム（１）に用いる、諸情報を記憶する内蔵メモリを備えた前記クライアント装置で動作するフレームワークプログラムであって、
    　前記入力画面を表示させる表示処理（１２０）を前記クライアント装置に順次実行させるプログラムコード、
    　前記表示される入力画面を介して入力された処理要求データを取り込む処理と、前記サーバ装置からの処理結果データを前記表示処理に出力する処理とを含むユーザインタフェース連携処理（１３０）を前記クライアント装置に順次実行させるプログラムコード、
    　前記処理要求データに異常が生じているか否かを判定するための処理要求チェック情報を内蔵メモリに記憶しており、該処理要求チェック情報に基づいて、前記入力画面を介して入力された処理要求データの異常の有無をチェックする処理を含む入力チェック処理（１４０）を前記クライアント装置に順次実行させるプログラムコード、
    　前記サーバ装置との通信方式に対応させてデータを変換するための通信ルール情報を内蔵メモリに記憶しており、前記サーバ装置へ前記処理要求データを送信する場合、前記通信ルール情報に基づいて該処理要求データを変換する処理と、前記サーバ装置から前記処理結果データを受信する場合、前記通信ルール情報に基づいて該処理結果データを変換する処理とを含むデータ変換処理（１６０）を前記クライアント装置に順次実行させるプログラムコード、
    　前記処理要求データを該サーバ装置に送信する処理と、前記サーバ装置から返信される処理結果データを受信する処理とを含む通信制御処理（１７０）を前記クライアント装置に順次実行させるプログラムコード、
    　前記ユーザインタフェース連携処理と、前記入力チェック処理と、前記データ変換処理と、前記通信制御処理とに個別に接続して制御する全体制御処理（１１０）を前記クライアント装置に順次実行させるプログラムコード、
    　を備えたことを特徴とするフレームワークプログラム。
  6. 　請求項５に記載のフレームワークプログラムにおいて、
    　前記処理要求データを修正するための修正データを内蔵メモリに記憶しており、前記入力チェック処理により処理要求データに異常があると判定された場合にエラーデータを生成する処理と、前記修正データに基づいて、該処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正する処理とを含む、前記全体制御処理で制御される動作制御処理（１５０）を前記クライアント装置に順次実行させるプログラムコード、を更に備えたことを特徴とするフレームワークプログラム。
  7. 　処理要求データを入力画面を介して受け付けるクライアント装置（１００）と、該クライアント装置に入力される処理要求データを処理して処理結果データを返信するサーバ装置（２００）とを備えた情報処理システム（１）に用いる、諸情報を記憶する内蔵メモリを備えた前記サーバ装置で動作するフレームワークプログラムであって、
    　前記処理要求データを該クライアント装置から受信する処理と、前記クライアント装置へ前記処理結果データを送信する処理とを含むサーバ側通信制御処理（２２０）を前記サーバ装置に順次実行させるプログラムコード、
    　前記クライアント装置との通信方式に対応させてデータを変換するためのサーバ側通信ルール情報を内蔵メモリに記憶しており、前記クライアント装置から前記処理要求データを受信する場合、前記サーバ側通信ルール情報に基づいて該処理要求データを変換する処理と、前記クライアント装置へ前記処理結果データを送信する場合、前記サーバ側通信ルール情報に基づいて該処理結果データを変換する処理とを含むサーバ側データ変換処理（２３０）を前記サーバ装置に順次実行させるプログラムコード、
    　前記処理要求データに異常が生じているか否かを判定するためのデータチェック情報を内蔵メモリに記憶しており、該データチェック情報に基づいて、前記クライアント装置から受信した処理要求データの異常の有無をチェックする処理を含むデータチェック処理（２４０）を前記サーバ装置に順次実行させるプログラムコード、
    　前記処理要求データと、該処理要求データを処理するためのロジック識別情報とを対応づけた要求ロジック対応ルール情報を内蔵メモリに記憶しており、前記データチェック処理により異常が無いと判定された処理要求データ、あるいはサーバ側動作制御処理により修正された処理要求データに対して適用されるロジック識別情報を前記要求ロジック対応ルール情報から読み出すロジック情報読出処理（２６０）を前記サーバ装置に順次実行させるプログラムコード、
    　前記ロジック情報読出処理により読み出されたロジック識別情報に対応するロジック情報を実行して処理結果データを生成するロジック実行処理（２７０）を前記サーバ装置に順次実行させるプログラムコード、
    　前記サーバ側通信制御処理と、前記サーバ側データ変換処理と、前記データチェック処理と、前記ロジック情報読出処理とに個別に接続して制御するサーバ側全体制御処理（２１０）を前記サーバ装置に順次実行させるプログラムコード、
    　を備えたことを特徴とするフレームワークプログラム。
  8. 　請求項７に記載のフレームワークプログラムにおいて、
    　前記処理要求データを修正するためのサーバ側修正データを内蔵メモリに記憶しており、前記データチェック処理により処理要求データに異常があると判定された場合にエラーデータを生成する処理と、前記サーバ側修正データに基づいて、該処理要求データの異常が修正可能であるか否かを判定するとともに、修正可能であれば該処理要求データを修正する処理とを含む、前記サーバ側全体制御処理で制御されるサーバ側動作制御処理（２５０）を前記サーバ装置に順次実行させるプログラムコード、を更に備えたことを特徴とするフレームワークプログラム。
PCT/JP2009/068917 2008-11-05 2009-11-05 情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラム WO2010053130A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN200980144072.0A CN102203756B (zh) 2008-11-05 2009-11-05 信息处理系统中使用的客户端装置、服务器装置以及框架程序

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008284727A JP5144473B2 (ja) 2008-11-05 2008-11-05 情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラム
JP2008-284727 2008-11-05

Publications (1)

Publication Number Publication Date
WO2010053130A1 true WO2010053130A1 (ja) 2010-05-14

Family

ID=42152937

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/068917 WO2010053130A1 (ja) 2008-11-05 2009-11-05 情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラム

Country Status (3)

Country Link
JP (1) JP5144473B2 (ja)
CN (1) CN102203756B (ja)
WO (1) WO2010053130A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102298742A (zh) * 2010-06-23 2011-12-28 精工爱普生株式会社 预付卡处理装置、预付卡处理系统、预付卡处理装置的处理方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6629157B2 (ja) 2016-09-06 2020-01-15 株式会社東芝 システム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004171556A (ja) * 2002-11-08 2004-06-17 Tokio Marine & Fire Insurance Co Ltd 損害保険処理のためのデータを収集するためのプログラム、方法及び装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0546555A (ja) * 1991-08-21 1993-02-26 Kobe Nippon Denki Software Kk コマンド解析方式
JP2912066B2 (ja) * 1991-10-18 1999-06-28 日本電気情報サービス株式会社 コマンド入力頻度学習装置
JP4643900B2 (ja) * 2003-11-05 2011-03-02 株式会社野村総合研究所 チェックコード生成機能を有する入力チェックシステム
JP2007316759A (ja) * 2006-05-23 2007-12-06 Hitachi Ltd 画面データ生成方法、画面データ生成システム、及びプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004171556A (ja) * 2002-11-08 2004-06-17 Tokio Marine & Fire Insurance Co Ltd 損害保険処理のためのデータを収集するためのプログラム、方法及び装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Hitachi no Rich Client - Product 1 EUR Form Web Kankyo demo Kami to Doyo no Image de Hyoji ? Nyuryoku ? Shutsuryoku ga Kano ni", OPEN MIDDLEWARE REPORT, vol. 31, 1 April 2005 (2005-04-01), pages 12 - 14 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102298742A (zh) * 2010-06-23 2011-12-28 精工爱普生株式会社 预付卡处理装置、预付卡处理系统、预付卡处理装置的处理方法
CN102298742B (zh) * 2010-06-23 2014-05-14 精工爱普生株式会社 预付卡处理装置、预付卡处理系统、预付卡处理装置的处理方法

Also Published As

Publication number Publication date
CN102203756A (zh) 2011-09-28
JP5144473B2 (ja) 2013-02-13
JP2010113478A (ja) 2010-05-20
CN102203756B (zh) 2017-03-29

Similar Documents

Publication Publication Date Title
US9576257B2 (en) Integrating data-handling policies into a workflow model
CN103069385B (zh) 用于动态加载基于图的计算的系统和方法
US20100070553A1 (en) Dynamic service invocation and service adaptation in bpel soa process
US8302092B2 (en) Extensible data driven deployment system
US8943518B2 (en) Managing and optimizing workflows among computer applications
US8370281B2 (en) Self-modification of a mainframe-based business rules engine construction tool
US20060224702A1 (en) Local workflows in a business process management system
US11463544B1 (en) Administration of services executing in cloud platform based datacenters
US8364625B2 (en) Mainframe-based business rules engine construction tool
US9116705B2 (en) Mainframe-based browser
US20230168872A1 (en) Generating user interfaces for administration of services executing in cloud platforms
US11968203B2 (en) Administration of services executing in cloud platform based datacenters using token with data structure
US9665352B2 (en) COBOL reference architecture
US9507839B2 (en) Method for determining a supported connectivity between applications
JP2009054151A (ja) 通信メッセージ・インスタンス投入方法、データ・インスタンス投入方法、通信メッセージ・インスタンス投入装置、および、コンピュータ読取可能媒体
US8510707B1 (en) Mainframe-based web service development accelerator
Li et al. Automatic test case selection and generation for regression testing of composite service based on extensible BPEL flow graph
US20070225943A1 (en) Executable application operation monitoring system
US20100122258A1 (en) Versioning and effectivity dates for orchestration business process design
JP5144473B2 (ja) 情報処理システムに用いるクライアント装置、サーバ装置及びフレームワークプログラム
Kongdenfha et al. Web service adaptation: Mismatch patterns and semi-automated approach to mismatch identification and adapter development
CN110825383B (zh) 一种视频交互方法、装置及计算机可读存储介质
CN107608672A (zh) 一种ui模块管理器、ui模块管理方法和系统
JP5404528B2 (ja) データ処理装置及びデータ処理方法及びプログラム
US8479175B1 (en) Mainframe-based web service development accelerator

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980144072.0

Country of ref document: CN

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

Ref document number: 09824829

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: 09824829

Country of ref document: EP

Kind code of ref document: A1