JP2009025977A - Operation history function in middle-ware - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an operation history function for customizing information to be recorded for every system of a customer, in order to prevent operation history from being unnecessarily recorded when unlimited number of users use a Web application, and the recording amounts of the operation history increases, while the operation history function is utilized for the management or analysis of the system by recording the contents of such operations as the registration, update, deletion, display and retrieval of data. <P>SOLUTION: This operation history function in middle-ware is provided with a means for performing processing in response to a request generated when displaying, retrieving or registering data; a means for acquiring the contents of a request in the processing: a means for acquiring the contents of the result of the processing; a means for storing the contents of the request and the contents of the result; a means for selecting the contents of the request and the contents of the result to be stored by item; and a means for customizing the means according to the characteristics of a project. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to middleware that provides an operation history function that records requests and responses to a server and leaves them as a history in an information processing system such as a client server system or a Web application server.

  With the progress of computerization of documents, the spread of networks, and the increase in capacity of storage devices, the digitized documents are collectively managed on a server and are referred to by a plurality of users. On the other hand, in order to protect useful resources and information that exist on open networks, users who access the server are authenticated to maintain confidentiality.

  Under such circumstances, an operation history function for recording operation contents of a user accessing a server resource and leaving the recorded contents as a history has been considered. The operation history is intended not only as a function of an access log but also as a function of providing information useful for work analysis and business improvement by processing the recorded information. For example, the server administrator can measure the frequency of access to the server, the work administrator can measure the registration status of the document, and each user can check his / her work history.

  In addition, there is a case where such an information processing system is provided as middleware that can be customized in detail in order to meet customer needs.

As a conventional example, there is one that shortens the development period of a database search system and customizes an access environment to the database according to individual users (see Patent Document 1).
JP-A-9-134271

  As described above, the operation history function can record the contents of various operations such as data registration, update, deletion, display, and search. However, the usage purpose of the operation history function is different for each customer system, and the information to be recorded is also different. The amount of daily recorded data in the operation history is likely to increase, and unnecessary recordings only press the recording medium for the customer. Therefore, it is necessary to provide a function for customizing the contents of the operation history to be recorded.

  When the system is provided as middleware, it is necessary to provide a mechanism that can extend the operation history function along the mechanism for realizing the customization described above.

In order to achieve the above-described object, the present invention includes means for performing processing in response to a request generated by an operation such as data display, search, or registration, and means for acquiring the content of the request in the processing;
Means for obtaining the content of the processing result, means for storing the content of the request and the content of the result, means for selecting the content of the request to be stored and the content of the result in item units, and a project for the means It is characterized by having means for customizing according to the characteristics of.

  According to the present invention, it is possible to provide middleware that can expand the operation history function in accordance with a function that can customize the contents of the operation history to be recorded and a mechanism for realizing the customization.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a schematic diagram showing a configuration example of a network system according to an embodiment of the present invention.

  1, the network system includes LANs 105 and 106 and the Internet 104, client personal computers (hereinafter referred to as client PCs) 101 and 102 connected to the LAN 105, and an HTTP (Hypertext Transfer Protocol) server connected to the LAN 106. Reference numeral 107 denotes a Web application server 108 and a client PC 103 directly connected to the Internet 104.

  The client PCs 101, 102, and 103 are used when registering a new data file on the Web application server 108, or searching or referring to the data file.

  The HTTP server 107 is a server that receives a request transmitted from the client PCs 101, 102, and 103 via the LAN 105, the Internet 104, and the LAN 106 using the HTTP protocol. When the Web application server 108 receives the request from the client PC transferred from the HTTP server 107, the Web application server 108 executes processing based on the request and returns the processing result to the client PCs 101, 102, and 103.

  The database 109 is connected to the web application server 108 and stores electronic data received by the web application server 108 from a client PC or the like.

  By organically combining the HTTP server 107, the web application server 108, and the database 109, the server functions as a web database system.

  FIG. 2 is a block diagram showing a configuration example of the WEB application server 108 as an apparatus for managing the operation history function of the present invention. 2, a WEB application server 108 includes a system bus 1, a CPU 2, a program memory (hereinafter abbreviated as PMEM) 3, an external storage control unit 4, an input control unit 10, a keyboard 11, a pointing device 12, a video image memory (hereinafter referred to as a VRAM). 7, a display output control unit 8, and a CRT display (hereinafter abbreviated as CRT) 9.

  Each of the above components is connected to the system bus 1. The CPU 2 is a central processing unit that controls each component via the system bus 1 and executes a program based on a control program stored in a ROM (not shown). The PMEM 3 is a memory for appropriately selecting and reading a control program for executing conditional branch processing from the ROM. Data input from the keyboard 11 is stored as code information in the PMEM 3 which is also a text memory.

  The external storage control unit 4 controls writing / reading of data to / from an external storage device (in this embodiment, a hard disk and a floppy (registered trademark) disk). A hard disk (hereinafter abbreviated as HD) 5 is an external storage device for data files. A floppy (registered trademark) disk (hereinafter abbreviated as FD) 6 is an external storage device for data files.

  Input devices such as a keyboard 11 and a pointing device 12 are connected to the input control unit 10. The operator issues an operation command to the system by operating the keyboard 11. The pointing device 12 is used by an operator to instruct the processing of image information on the CRT 9, and a mouse is used in the present embodiment (hereinafter referred to as the mouse 12). The operator arbitrarily moves the cursor on the CRT 9 in the X direction / Y direction with the mouse 12 and selects a command icon on the command menu to give an instruction for processing. Also do.

  The VRAM 7 is a memory in which character data and graphic data displayed on the CRT 9 are developed as bitmap data. The display output control unit 8 controls display on the CRT 9. The CRT 9 is a display unit that displays a screen and the like shown in FIG. The display method is not limited to the CRT, but may be a liquid crystal.

  In the present embodiment, the process definition module 102 is stored in the ROM (not shown). However, the process definition module 102 may be stored in the HD 5 or FD 6 or on another device connected to the network. It is good also as a structure to store. Further, the process definition module can be supplied to another system or another device via a storage medium or a network.

  FIG. 3 is a block diagram illustrating a configuration example of modules of the client PC and the Web application server.

  In FIG. 3, client PCs 101, 102, and 103 each access the Web application server 108 using a Web browser. The Web application server 108 includes a presentation layer 301 serving as an interface with the outside, a business logic layer 302 that performs business logic processing, and a data access layer 303 that accesses a database. The program modules of the presentation layer 301, business logic layer 302, and data access layer 303 are loaded on the memory of the Web application server 108 in response to a request from the client PC, and the corresponding processing is executed.

  The HTTP server 107 transfers requests from the client PCs 101, 102, and 103 to the Web application server 108.

  The program modules of the presentation layer 301, the business logic layer 302, and the data access layer 303 mounted on the Web application server 108 may be provided in the form of middleware. The middleware is implemented with basic functions constituting the system, and includes, for example, functions such as a user management function, a user authentication function, a data creation function, a data management function, a data search function, and a database access function. The system developer uses or customizes the functions of the middleware to provide the system that the customer needs.

  Next, with reference to FIG. 4 to FIG. 10, a flow until creating a database for customizing the operation history function in the middleware will be described.

  FIG. 4 is a flowchart showing a flow until creation of a database for customizing the operation history function in the middleware.

  FIG. 5 is a diagram showing a process up to creation of a database for customizing the operation history function in the middleware, and files generated in the process.

  In FIG. 4, information for the operation history function is described in the source code (step S401). Reference numeral 501 in FIG. 5 indicates the source code in step S401. FIG. 6 is a diagram illustrating a description example of the source code 501.

  In FIG. 6, a source code 501 is an example in which Java (registered trademark) is used as a development language. A part indicated by a frame 601 is a comment line described as information for the operation history function. “@Opehist” in 601 indicates a character string for identifying the information of the operation history function. “Key =” indicates a character string for designating the name of a parameter to be stored in the operation history in this class. For example, “key = login_id” indicates that a parameter named “login_id” is an operation history storage target. “Scope =” indicates a character string for specifying a parameter acquisition destination object. For example, “scope = ActionForm” indicates that the parameter acquisition destination is an object “ActionForm” in the class argument. The parameter acquisition destination may be the class INPUT argument or the OUTPUT argument. “Property =” is a character string for designating the property name of the parameter and its data type in the object designated by “scope =”. For example, “property = loginId (java (registered trademark) .lang.String)” indicates that the property name of the parameter is loginId and the data type thereof is java (registered trademark) .lang.String.

  Next, in FIG. 4, the source code is read (step S402), information of the operation history function in each class is extracted from the read source code (step S403), and an intermediate file describing the extracted information f1 is created (step S404). Reference numeral 502 in FIG. 5 denotes the intermediate file f1 in step S404. FIG. 7 is a diagram illustrating a description example of the intermediate file 502.

  In FIG. 7, an intermediate file 502 is an example of a file described in an XML (eXtensible Markup Language) format. The contents of the <opehist> tag, <key> tag, <scope> tag, and <property> tag correspond to the information described in FIG.

  Next, in FIG. 4, the configuration file related to the presentation layer 301 of the Web application server of the Web application server is read (step S405), and information related to the external interface of the presentation layer 301 is acquired (step S406). Reference numeral 503 in FIG. 5 denotes an external interface configuration file in step S405. FIG. 8 is a diagram illustrating a description example of the configuration file 503.

  In FIG. 8, the configuration file 503 indicates that two interfaces, / Login and / LoginAdmin, are defined using the LoginAction class.

  Next, in FIG. 4, the intermediate file 502 is read (step S407), and the correspondence information between the interface and the class is created by comparing with the contents of the configuration file 503 (step S408). Based on the correspondence information between the interface and the class, an intermediate file f2 describing the information for each interface is created (step S409). Reference numeral 504 in FIG. 5 denotes the intermediate file f2 in step S409. FIG. 9 is a diagram illustrating a description example of the intermediate file 504.

  In FIG. 9, an intermediate file 504 is an example of a file described in the XML format, and information on two interfaces is shown. The path attribute of the interface tag indicates the path information specified in the configuration file 503 in FIG. 8, that is, the definition name of the interface. In the type attribute of the interface tag, type information designated by the configuration file 503 in FIG. 8, that is, the class name is shown. The key attribute of the param tag indicates information on the key tag specified in the intermediate file 502 in FIG. 7, that is, the interface parameter name. The scope attribute of the param tag indicates the scope tag information specified in the intermediate file 502 in FIG. 7, that is, the parameter storage destination object. The property attribute of the param tag indicates the property tag information specified in the intermediate file 502 in FIG. 7, that is, the parameter variable name in the parameter storage destination object. The type attribute of the param tag indicates the type attribute of the property tag specified in the intermediate file 502 of FIG. 7, that is, the data type of the parameter. The key attribute of the param tag indicates information on the key tag specified in the intermediate file 502 in FIG. 7, that is, the interface parameter name.

  That is, the intermediate file 504 is obtained by expanding the class information of the intermediate file 502 for each interface based on the interface information of the configuration file 503. This is an operation for enabling customization of the operation history for each interface.

  Next, in FIG. 4, a database table T_1 is created based on the intermediate file 504 (step S410), and 505 in FIG. 5 indicates the table T_1 created in step S410. FIG. 10 is a diagram illustrating a description example of the table 505 on the database.

  In FIG. 10, reference numeral 1001 denotes a path in which information described in the path attribute of the interface tag of the intermediate file 504 is stored. A parameter name 1002 stores information described in the key attribute of the param tag of the intermediate file 504. Reference numeral 1003 denotes an object in which parameters are stored, and information described in the scope attribute of the param tag of the intermediate file 504 is stored. Reference numeral 1004 denotes a parameter variable name in the object in which the parameter is stored. Information described in the property attribute of the param tag of the intermediate file 504 is stored. Reference numeral 1005 denotes a parameter variable data type, which stores information described in the type attribute of the param tag of the intermediate file 504. Reference numeral 1006 denotes a flag for determining whether or not to store parameter information as an operation history. If the value is 1, the flag is stored. If the value is 0, the parameter information is not stored.

  Next, a storage data customization work example of the operation history function will be described with reference to FIG.

  In FIG. 11, reference numeral 1101 denotes an example of a screen configuration for customizing the storage contents of the operation history. A screen 1101 is a screen displayed by a Web browser on the client PC 101 (102, 103). The Web application server 108 refers to the table 505 stored in the database 109 and passes the contents to the client PC 101 (102, 103). 1102 is an interface name, 1103 is a parameter name held by the interface, and 1104 is a description of the interface name. Reference numeral 1105 denotes a check box for setting whether to store parameter information as an operation history. When the check box is checked and information is sent to the Web application server 108, the Web application server 108 refers to the table 505 stored in the database 109 and sets the value of the storage flag 1006 of the corresponding parameter to 1. For the parameters whose check boxes are not checked, the value of the storage flag 1006 is set to 0.

  FIG. 12 is a flowchart showing a flow of storing operation history information. When the Web application server 108 is executed, various requests are transmitted from the client PC 101 (102, 103) to the Web application server 108. The Web application server 108 receives a request from the client PC 101 (102, 103) by the presentation layer 301 and calls an interface according to the request (step S1201). The called interface executes processing designated by the program (step S1202). After executing the processing, the interface refers to the operation history table 505 (step S1203). From the operation history table 505, a record in which the path 1001 indicates its own interface is referred to, and a parameter for which 1 is set in the storage flag 1006 is extracted (step S1204). For the parameters extracted in step S1204, the values of the value acquisition destination object 1003, parameter variable name 1004, and data type 1005 are acquired (step S1205). The interface acquires values for the parameters extracted in step S1204 based on the information acquired in step S1205 (step S1206). First, the object specified by the acquisition destination object 1003 is acquired from the interface arguments. The variable specified by the parameter variable name 1004 is acquired from the acquired objects as the data type specified by the data type 1005. The acquired parameters are stored in the database as operation history information. The storage destination is not only the database but also files.

[Other embodiments]
In the above-described embodiment, the case where the HTTP server 107 and the Web application server 108 are configured separately has been described as an example. However, the present invention is not limited to this. An apparatus (housing) can also be used.

  The present invention can be achieved by supplying a software program that realizes the functions of the above-described embodiments to a computer or CPU, and reading and executing the supplied program by the computer or CPU.

  In this case, the program is supplied directly from a storage medium storing the program, or downloaded from another computer or database (not shown) connected to the Internet, a commercial network, a local area network, or the like. Supplied.

  The form of the program may be in the form of object code, program code executed by an interpreter, script data supplied to an OS (operating system), and the like.

  The present invention also supplies a computer or CPU with a storage medium storing a software program that implements the functions of the above-described embodiments, and the computer or CPU reads and executes the program stored in the storage medium. Can also be achieved. In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the storage medium storing the program code constitutes the present invention. As a storage medium for storing the program code, for example, ROM, RAM, NV-RAM, floppy (registered trademark) disk, hard disk, optical disk, magneto-optical disk, CD-ROM, MO, CD-R, CD-RW, DVD -ROM, DVD-RAM, DVD-RW, DVD + RW, magnetic tape, nonvolatile memory card, and the like.

  The function of the above-described embodiment is not only by executing the program code read from the computer, but the OS or the like running on the computer performs part or all of the actual processing based on the instruction of the program code. Can also be realized.

  Further, the functions of the above-described embodiment are obtained by writing a program read from a storage medium into a function expansion board inserted into a computer or a memory provided in a function expansion unit connected to a computer, and It can also be realized by executing a part or all of the actual processing by the CPU or MPU provided in the function expansion board or function expansion unit based on the instruction of the program.

It is the schematic which shows the structural example of the network system which concerns on embodiment of this invention. It is a block diagram which shows the structural example of the WEB application server as an apparatus which performs an operation history function. It is a block diagram which shows the structural example of the module of a client PC and a web application server. It is a flowchart which shows the flow until the database for operation history function customization based on embodiment of this invention is produced. It is a figure which shows the process until it produces the database for operation history function customization based on embodiment of this invention, and the file produced | generated in the process. It is a figure which shows the program source code which described the information of the operation history function based on embodiment of this invention. It is a figure which shows the intermediate file which extracts and creates the information regarding the operation history function from the source code based on Embodiment of this invention. It is a figure which shows the file which defined the interface list in the web server application based on embodiment of this invention. It is a figure which shows the intermediate file which described the information regarding the operation history function for every interface based on embodiment of this invention. It is a figure which shows the table of the database based on embodiment of this invention. It is a figure which shows the setting screen of the database based on embodiment of this invention. It is a flowchart which shows the flow of operation history information storage based on embodiment of this invention.

Claims (8)

Means for processing in response to a request generated by a user operation;
Means for acquiring the content of the request in the processing;
Means for obtaining the content of the result of the processing;
Means for storing the content of the request and the content of the result;
A program characterized by having means for customizing said means according to the characteristics of a project. In claim 1, having means for selecting the content of the request to be stored and the content of the result in item units,
2. The program according to claim 1, further comprising means for customizing said means according to characteristics of a project.   3. The program according to claim 2, further comprising a user interface for selecting the content of the request to be stored and the content of the result in item units. In claim 2, the means for obtaining the input and output from the program source code;
Means for associating a request generated by a user operation with a process to be executed;
3. The program according to claim 2, further comprising extracting an input and an output of processing executed by a request generated by a user operation from the means for associating with the acquired content. Means for processing in response to a request generated by a user operation;
Means for acquiring the content of the request in the processing;
Means for obtaining the content of the result of the processing;
Means for storing the content of the request and the content of the result;
A customization support system comprising means for customizing the above-mentioned means in accordance with characteristics of a project. In Claim 5, it has a means to select the contents of the request to memorize and the contents of the result in item units,
6. The customization support system according to claim 5, further comprising means for customizing said means according to characteristics of a project.   7. The customization support method according to claim 6, further comprising a user interface for selecting the content of the request to be stored and the content of the result in item units. The means for obtaining the input and output from the program source code according to claim 6,
Means for associating a request generated by a user operation with a process to be executed;
7. The customization support method according to claim 6, further comprising: extracting input and output of processing executed by a request generated by a user operation from the means for associating with the acquired content.

Images