INFORMATION PROCESSING SYSTEM AND INFORMATION PROCESSING METHOD
An information processing system including at least one computer includes a first assigning part that receives from a device a process request including device process identification information identifying a predetermined process unit of the device and assigns request identification information identifying the process request; and a storage part that stores the device process identification information and the request identification information in association with each other in connection with a process executed in response to the process request.
Latest RICOH COMPANY, LTD. Patents:
- Data processing apparatus, data processing system, and data processing method
- Information display system, information display method, and non-transitory recording medium
- Power conversion device, image forming apparatus, and power conversion control method
- Software service integration in a central software platform
- Display device
This application is based on and claims the benefit of priority of Japanese Patent Application No. 2013-010822 filed on Jan. 24, 2013, and Japanese Patent Application No. 2013-246954 filed on Nov. 29, 2013, the entire contents of which are incorporated herein by reference.
BACKGROUND OF THE INVENTION1. Field of the Invention
The disclosures herein generally relate to an information processing system and an information processing method.
2. Description of the Related Art
There are services that are provided by having a device such as an image forming apparatus cooperate with a computer that is connected to the device via a LAN (local area network) or a WAN (wide area network), such a computer simply being referred to as “server” hereinafter. For example, a service may involve having an image forming apparatus scan image data of a document and transfer the image data to a server, and having the server perform an image process on the image data or store the image data in a predetermined storage.
When an error occurs in a service provided through cooperation of a device and a server as described above, it may be difficult to determine the correspondence between a process executed at the device and a process executed at the server that are associated with the same service. Generally, logs are individually recorded at the server and the device. Thus, a correspondence between a process at the device side and a process at the server side may be determined by referring to their logs to find matching logs (see e.g., Japanese Laid-Open Patent Publication No. 2010-161714; Japanese Laid-Open Patent Publication No. 2008-129955; Japanese Laid-Open Patent Publication No. 2012-084041).
However, to match up the logs of the device and the server, the timing of the processes have to be accurately determined. As one way of determining the timing of the processes of the device and the server, time information may be used, for example. That is, the correspondence between a process of the device and a process of the server may be determined based on time information of the logs related to the above processes that are maintained at the device side and the server side, respectively.
However, when time information is used to determine the correspondence between a process of the device and a process of the server, system time information at the device side and system time information at the server side have to match. Also, even if the system time information at the device side and the system time information at the server side match, messages transferred between the device and the server may be delayed, and a start time of a process to be executed by the server in response to a request from the device may be unstable. Further, a server may cooperate with a plurality of devices, and the server may execute a plurality of processes in parallel in response to receiving requests from a plurality of devices.
Thus, determining a correspondence between a process of a device and a process of a server based on time information may actually be quite difficult.
Accordingly, there is a demand for a technique that can facilitate the determination of a correspondence between processes that are executed over a network.
SUMMARY OF THE INVENTIONAccording to one embodiment of the present invention, an information processing system with at least one computer includes a first assigning part that receives from a device a process request including device process identification information identifying a predetermined process unit of the device and assigns request identification information identifying the process request, and a storage part that stores the device process identification information and the request identification information in association with each other in connection with a process executed in response to the process request.
According to an aspect of the present invention, determination of a correspondence between processes executed over a network may be facilitated.
In the following, embodiments of the present invention are described with reference to the accompanying drawings.
The device usage environment 2 is an environment where devices 20 that are capable of cooperating with a service provided by the cloud service system 1 are used. For example, the device usage environment 2 may correspond to an office of a company. In
The image forming apparatus 20a may be a multifunction peripheral (MFP), a printer, a scanner, or a facsimile machine, for example. The projector 20b is a device that projects image data. The teleconference device 20c is a device used to conduct a teleconference. Note that aspects of the present embodiment may be applied to devices other than those illustrated above.
The cloud service system 1 includes at least one computer and is configured to provide various services through cooperation with the device 20. For example, as a service provided in cooperation with the image forming apparatus 20a, the cloud service system 1 may provide a service of storing, in a predetermined storage, image data of a document scanned by the image forming apparatus 20a and transmitted to the cloud service system 1 from the image forming apparatus 20a, or delivering the image data to a predetermined delivery destination (such a service being referred to as “cloud scan service” hereinafter). Also, the cloud service system 1 may provide a service of having the image forming apparatus 20a download print data that has been uploaded in the cloud service system 1 beforehand and execute a print job based on the print data (such a service being referred to as “cloud print service” hereinafter).
Note that a service provided by the cloud service system 1 does not necessarily have to be a cloud service. For example, the cloud service system 1 may also act as a server side system of a general server-client system. Also, in some embodiments, the network N1 may be a local area network (LAN).
The application layer 120 includes applications for implementing the services provided by the cloud service system 1 (referred to as “server applications” hereinafter). In
The common service layer 130 includes functions common to multiple server applications or basic functions used by multiple server applications. In
Functions of the common service layer 130 may be disclosed to the application layer 120 via a platform API (application programming interface) 150. That is, the application layer 120 is able to use the functions of the common service layer 130 that are disclosed via the platform API 150.
The database layer 140 includes a database (storage part) that stores relevant information of a process to be executed at the application layer 120 or the common service layer 130, for example. In
The log storage part 141a stores logs. The user information storage part 142a stores user attribute information of services provided by the cloud service system 1. The device information storage part 142b stores attribute information related to the devices 20 that cooperate with the cloud service system 1 to provide services. The application information storage part 142c stores setting information and other relevant information set up with respect to the server applications. For example, the setting information may be stored with respect to each user.
Note that the form of classification of software and storage parts illustrated in
In
The segment g1 is a segment positioned at the forefront with respect to the network N1. In
The segment g2 is a segment corresponding to the application layer 120. In
The segment g3 is a segment corresponding to the common service layer 130. In
Note that process requests to the log management server 131, the authentication server 132, and the content processing server 133 may be arranged in a format conforming to the platform API 150. The platform API 150 may be a REST (representational state transfer) based API or some other type of API implemented via a network, for example.
The segment g4 is a segment corresponding to the data base layer 140. In
Note that firewalls FW are arranged between the segments g and between the network N1 and the segment g1.
In the network configuration as illustrated in
As illustrated in
A program for implementing a process at the computer may be provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is loaded in the drive unit 100, the program may be installed in the secondary storage device 102 from the recording medium 101 via the drive unit 100. However, the program does not necessarily have to be installed from the recording medium 101, and may alternatively be downloaded from another computer via a network, for example. The secondary storage device 102 stores files and data as well as installed programs.
The memory unit 103, in response to a command to activate a program, reads the program from the secondary storage device 102 and stores the read program. The CPU 104 executes functions of the computer in accordance with a program stored in the memory unit 103. The interface unit 105 is used as an interface for establishing connection with a network.
Note that the functional components of the application layer 120 and the common service layer 130 illustrated in
The client application 21 is an application that cooperates with one of the server applications to provide a service of the server application to a user. The server application and the client application 21 are basically arranged to correspond to each other on a one-to-one basis. Thus, for example, when a user wishes to use the cloud scan service, the user has to install a client application 21 corresponding to the cloud scan service in the image forming apparatus 20a.
The application platform 22 includes an API for developing the client application 21 and an execution environment for the client application 21. The API may be in the form of a set of functions, or object-oriented classes and class methods, for example. The application platform 22 may provide an API related to a scan function, an API related to a print function, and an API related to a copy function to the client application 21, for example. In one embodiment, the application platform 22 may include the Java (registered trademark) VM (virtual machine). In this case, the client application 21 may be implemented using the Java programming language.
The application platform 22 may also have a mechanism for enabling cooperation between the server application and the client application 21, and a function to record a log related to a process executed at the image forming apparatus (referred to as “device log” hereinafter), for example.
The device log storage part 24 stores a device log. The device log storage part 24 may be implemented using a secondary storage device included in the image forming apparatus 20a or a storage device connected to the image forming apparatus 20a via a network, for example.
The uploading unit 23 executes a process for uploading a device log stored in the device log storage part 24 to the log storage server 141.
Note that devices 20 other than the image forming apparatus 20a such as the projector 20b and the teleconference device 20c may have software configurations similar to that illustrated in
In the following, process steps executed in the cloud service system 1 are described.
In step S101, some type of operation is made by an operator of the image forming apparatus 20a. In the case where a request has to be sent to the cloud service system 1 in response to the operation, the client application 21 sends a message including the request to the print application 120c via the application platform 22 (step S102).
Description d1 in message m1 describes a process being requested. In
Description d2 in message m1 includes fields (items) of the message header. Each field is represented in the format <field name>: <value>. For example, the value of field “X-CUID” corresponds to identification information called CUID (client unique ID). In the present embodiment, CUID corresponds to identification information assigned to each predetermined process unit of the image forming apparatus 20a. In the present embodiment, an example of a predetermined process unit of the image forming apparatus 20a may correspond to a sequence of processes that are executed from when an operation made by an operator is detected until a response corresponding to the operation is output. The CUID may be assigned to each and every operation including an operation for simply prompting a screen transition, for example. Alternatively, the CUID may be assigned to each operation that triggers transmission of a message to the cloud service system 1, for example. The CUID may be assigned by the application platform 22 of
The value of the field “X-Device-ID” may be a device number, for example. The device number refers to identification information assigned to each individual image forming apparatus 20a. For example, a manufacturer serial number or a MAC (media access control) address may be used as the device number. The device number may be stored in a storage device of the image forming apparatus 20a, for example.
Note that field names that start with “X-” correspond to fields extended in the present embodiment.
The value of the field “User-Agent” may be a service name corresponding to the client application 21 to be operated. Note that the information included in parentheses in this field corresponds to version information of the application platform 22.
Description d3 of message m1 includes user information for identifying the operator. The user information may include an organization ID (“organization_id”) and a user ID (“user_id”), for example. The organization ID is identification information of the organization to which the user (operator) belongs. The user ID is identification information assigned to each user for identifying the user within the organization. In the present embodiment, the cloud service system 1 is configured to be used by a plurality of organizations (e.g., companies). Thus, even if a user ID may be unique within an organization, a common user ID may be used across different organizations, for example. Accordingly, the organization ID may be used as identification information in contemplation of such possible overlap of user IDs across different organizations, for example.
Note that the organization ID and the user ID may be input during a login operation performed before the process steps illustrated in
All messages addressed to the cloud service system 1 are first received at the Internet gateway 111. Thus, the message m1 is also received by the Internet gateway 111. Upon receiving the message m1, the Internet gateway 111 generates a request ID (RID) corresponding to identification information identifying a request from a device 20 and includes the generated RID in the message m1 (step S103). That is, the Internet gateway 111 generates a new RID having a new value each time a message (request) is received from outside the cloud service system 1 and includes the generated RID in the corresponding message. Thus, the CUID and the RID basically correspond to one another on a one-to-one basis.
Next, the Internet gateway 111 transfers a message m1-1 corresponding to the message m1 having the RID included therein to the application server 121 having the print application 120a installed therein (step S104).
The message m1-1 addressed to the application server 121 on the segment g2 is first received at the application gateway 122. The application gateway 122 generates a unique ID (UID) corresponding to identification information for identifying each message (process execution request) addressed to a server on the segment g2 and includes the generated UID in the message m1-1 (S105). That is, the application gateway 122 generates a new UID each time a message (request) is received from outside the segment g2 and includes the generated UID in the corresponding message.
Next, the application gateway 122 transfers a message m1-2 corresponding to the message m1-1 having the UID included therein to the application server 121, the destination of the message (step S106).
When the application server 121 receives the message m1-2, the print application 120c executes a process according to the request described in description d1 of the message m1-2. During execution of such a process, a process request may have to be issued to another server within the cloud service system 1. For example, an authentication request may have to be issued to the authentication server 132 (authentication part 132a). In this case, the print application 120c may transmit a message m2 including an authentication request to the authentication server 132 (step S107). In addition to including a description of the authentication request, the message m2 includes an “X-Device-ID” field, an “X-RID” field, a “User-Agent” field, and user information, for example. The field values of the fields included in the message m2 may be identical to the field values of the same field names included in the message m1-2. Also, the user information included in message m2 may be identical to the user information (description d3) included in the message m1-2. That is, a process request exchanged between servers within the cloud service system 1 based on a request from a device 20 is configured to include the RID assigned to the request and information items such as the device number, the service name, and user information included in the message describing the request. Accordingly, the RID, the device number, the service name, and the user information may be transmitted to each of the servers receiving such a process request. On the other hand, the message m2 does not include the UID included in the message m1-2. This is because the UID included in the message m1-2 is identification information for identifying the process request to the application server 121 whereas the message m2 is related to a process request to the authentication server 132.
The message m2 addressed to the authentication server 132 on the segment g3 is first received by the common service gateway 134. Upon receiving the message m2, the common service gateway 134 generates a UID for identifying each message addressed to a server on the segment g3 and includes the generated UID in the message m2 (step S108). That is, the common service gateway 134 generates a new UID each time a message (process request) is received from outside the segment g3 and adds a new field “X-UID” including the generated UID as the field value in the received message.
Next, the common service gateway 134 transmits a message m2-1 corresponding to the message m2 having the UID included therein to the authentication server 132 (step S109).
Upon receiving the message m2-1, the authentication server 132 executes an authentication process according to the authentication request included in the message m2-1 (step S110). Next, the authentication server 132 records a log related to the authentication process in the secondary storage device 102 within the authentication server 132 (step S111). In the following descriptions, a log recorded by a server within the cloud service system 1 is referred to as “server log.”
Specifically, the server log L1 of
The value of the “level” field indicates a level of the server log. The level of the server log refers to the content type of the server log. For example, potential field values of the “level” field include “INFO” and “ERROR”. “INFO” indicates that the corresponding server log includes information related a process that has been executed. “ERROR” indicates that the corresponding server log is related to an error.
The value of the “result” field is a numeric value (code) representing a result of the process executed by the authentication server 132. The value of the “method” field indicates a method included in the process request (message m2-1) to the authentication server 132. The value of the “path” field indicates a path of a URL (uniform resource locator) indicating the process request. The value of the “app_id” field corresponds to identification information assigned to a program module that has executed the process corresponding to the process request by the authentication server 132. That is, the value of the “app_id” field corresponds to an ID of the program module that prompts the authentication server 132 to implement the function of the authentication part 132a. The value of the “app_name” field indicates a name of the program module identified by the “app_id” field value assigned by a developer of the program module, for example. The value of the “ip” field indicates the IP address of the authentication server 132 that has executed the process corresponding to the process request. The value of the “total_runtime” field indicates the processing time of the process requested by the process request.
The value of the “X-RID” field indicates the RID of the request to which the process request belongs. The request to which the process request belongs refers to the request from the image forming apparatus 20a corresponding to the source of the process request. Thus, the value of the “X-RID” field included in the message m2-1 is transferred to the “X-RID” field of the server log L1. The value of the “X-UID” field indicates the UID assigned to the process request. Thus, the value of the “X-UID” field included in the message m2-1 is transferred to the “X-UID” field of the server log L1. The value of the “X-Device-ID” field corresponds to the device number of the image forming apparatus 20a corresponding to the sender of the request associated with the process request. Thus, the value of the “X-Device-ID” field included in the message m2-1 is transferred to the “X-Device-ID” field of the server log L1. The value of the “UserAgent” field indicates the service name of the service used by the image forming apparatus 20a corresponding to the sender of the request to which the process request belongs. Thus, the value of the “User-Agent” field included in the message m2-1 is transferred to the “UserAgent” field of the server log L1.
The value of the “organization_id” field represents the organization ID of the corresponding organization of the image forming apparatus 20a that has sent the request associated with the process request. Thus, the organization ID included in the message m2-1 is transferred to the “organization_id” field of the server log L1.
The value of the “user_id” field represents the user ID of the operator of the image forming apparatus 20a corresponding to the sender of the request associated with the process request. Thus, the user ID included in the message m2-1 is transferred to the “user_id” field of the server log L1.
The “inquiry_code” field may be a valid field in the case where “ERROR” is the field value of the “level” field. In such a case, the value of the “inquiry_code” field is a numeric value specifying the error (error code). The value of the “time” field indicates the time and date when the server log L1 was recorded. The value of the “micro_second” field represents the time the server log L1 was recorded in microsecond units.
Next, the authentication server 132 transmits a response to the message m2-1 (step S112). The response may include information indicating whether or not the authentication process was successful, for example. The response is transmitted to the application server 121 via the common service gateway 134 (step S113). More specifically, the response is transmitted to the application server 121 via the common service gateway 134 and the application gateway 122.
Also, the authentication server 132 transmits the server log L1 recorded in step S111 to the log management server 131 (log management part 131a) at a suitable timing (step S114). Note that recording of the server log L1 and transmission of the server log may be may be executed asynchronously. Upon receiving the server log L1, the log management server 131 transmits a message m3 including a storage request for storing the server log L1 to the log storage server 141 (step S115).
In addition to including a description of the server log L1 itself and a description of the storage request for storing the server log L1, the message m3 includes an “X-Device-ID” field, an “X-RID” field, a “User-Agent” field, and user information, for example. The field values of the fields included in the message m3 may be identical to the field values of the same field names included in the message m2-1. Also, the user information included in the message m3 may be identical to the user information included in the message m2-1.
The message m3 addressed to the log storage server 141 on the segment g4 is first received by the database gateway 143. Upon receiving the message m3, the database gateway 143 generates a UID for identifying each message addressed to a server on the segment g4 and includes the generated UID in the message m3 (step S116). That is, the database gateway 143 generates a new UID each time a message (process request) is received from outside the segment g4 and adds a new field “X-UID” including the generated UID as the field value in the received message.
Next, the database gateway 143 transmits a message m3-1 corresponding the message m3 having the generated UID included therein to the log storage server 141 (step S117). Upon receiving the message m3-1, the log storage server 141 may store the server log L1 related to the authentication process included in the message m3-1 in the secondary storage device 102 of the log storage server 141, for example. Next, it is assumed below that during execution of a process of the print application 120c of the application server 121 that has received the response from the authentication server 132, a process request related to content processing has to be made to the content processing server 133 (referred to as “content processing request” hereinafter). In this case, the print application 120c transmits a message m4 including the content processing request to the content processing server 133 (step S121). In addition to including a description of the content processing request, the message m4 includes an “X-Device-ID” field, an “X-RID” field, a “User-Agent” field, and user information, for example. The field values of the fields included in the message m4 may be identical to the field values of the same field names included in the message m1-2. Also, the user information included in the message m4 may be identical to the user information (description d3) included in the message m1-2. However, the message m4 does not include the UID included in the message m1-2.
The message m4 addressed to the content processing server 133 on the segment g3 is first received by the common service gateway 134. Upon receiving the message m4, the common service gateway 134 generates a UID for identifying each message addressed to a server on the segment g3 and includes the generated UID in the message m4 (step S122). Note that the UID included in the message m4 is different from the UID included in the message m1-2 addressed to the application server 121 in step S105 or the UID included in the message m2 addressed to the authentication server 132 in step S107. That is, the UID is identification information for identifying each process request exchanged between servers within the cloud service system 1.
As described above, in executing a plurality of processes based on a single request from the image forming apparatus 20a, a UID with a different value is preferably assigned to each process request or process to be executed in response to the request from the image forming apparatus 20a. That is, the UID is identification information for identifying or distinguishing each process or process request.
However, in the present embodiment, in step S105, the application gateway 122 generates and includes the UID in the message m1-2 whereas in steps S105 and S122, the common service gateway 134 generates and includes the UID in the message m2 or the message m4. That is, a plurality of units (gateways) are configured to generate and assign a UID with respect to a process request or a process to be executed in response to the same request from the image forming apparatus 20a. In such a case, even though the uniqueness of each UID generated by the same UID assigning unit (gateway) may be ensured, the uniqueness of each UID associated with the same RID cannot be ensured in the case where a plurality of gateways are configured to generate and assign a UID to a process request or process associated with the same request.
In this respect, for example, the UID may be randomly generated using random numbers. In another example, timers of the gateways may be synchronized and time information detected by the timers may be included in the UID. In yet another example, the gateways may be configured to establish communication with each other so that they may exchange UID values that have already been assigned. In another example, one gateway (e.g., the Internet gateway 111) may be configured to integrally manage UIDs that have already been assigned and the other gateways may be configured to make inquiries to the Internet gateway 111 regarding the UIDs that have already been assigned. The other gateways may be configured to assign a UID that has not yet been assigned and then notify the Internet gateway 111 of the newly assigned UID.
By implementing one of the above-described measures, for example, UIDs associated with the same RID may be prevented from overlapping. Note, however, that other measures may be implemented to avoid an overlap of the UIDs.
Next, the common service gateway 134 transmits a message m4-1 corresponding the message m4 having the generated UID included therein to the content processing server 133 (step S123).
Upon receiving the message m4-1, the content processing server 133 may execute content processing based on the content processing request included in the message m4-1 (step S124). Then, the content processing server 133 may store a server log related to the content processing in the secondary storage device 102 of the content processing server 133, for example (step S125).
Next, the content processing server 133 transmits a response to the message m4-1 (step S126). The response may include information relating to whether the requested content processing has been successfully executed, for example. The response is transmitted to the application server 121 via the common service gateway 134 (step S127). More specifically, the response is transmitted to the application server 121 via the common service gateway 134 and the application gateway 122.
Also, the content processing server 133 transmits the server log L2 recorded in step S125 to the log management server 131 (log management part 131a) at a suitable timing (step S128). Note that the transmission of the server log L2 may be performed asynchronously with respect to the recording of the server log L2. Upon receiving the server log L2, the log management server 131 includes the received server log L2 in a message m5 representing a storage request for storing the server log L2 to the log storage server 141 (step S129).
In addition to including a description of the server log L2 itself and a description of the storage request for storing the server log L2, the message M5 includes an “X-Device-ID” field, an “X-RID” field, a “User-Agent” field, and user information, for example. The field values of the fields included in the message m5 may be identical to the field values of the same field names included in the message m4-1. Also, the user information included in the message m5 may be identical to the user information included in the message m4-1.
Next, process steps similar to those performed with respect to the message m3 (steps S116 and S117) are performed with respect to the message m5 (steps S130 and S131). In this way, the server log L2 may be stored in the secondary storage device 102 of the log storage server 141.
Also, when the application server 121 receives the response from the content processing server 131 and when all relevant processes associated with the request from the image forming apparatus 20a are completed, the print application 120c records a server log related to a process executed by the print application 120c (step S141). The server log may be recorded in the secondary storage device 102 of the application server 121, for example.
The server log L3 includes a “X-CUID” field in addition to the fields included in the server logs L1 and L2 described above. In the example illustrated in
As described above, a server log recorded in the application server 121 that performs overall process control of the processes called by a request from a device 20 such as the image forming apparatus 20a includes the CUID in addition to the RID corresponding to the request. In this way, a correspondence between the RID and the CUID may be stored in the server log of the application server 121.
Note that as the field values of the “X-RID” field, the “X-UID” field, the “X-Device-ID” field, the “UserAgent” field, the “organization_id” field, and the “user_id” field of the server log L3, the field values of the corresponding field names included in the message m1-2 may be transferred.
Next, the print application 120c (application server 121) transmits a response to the message m1-2 (step S142). The response may include information indicating whether the process executed in response to the request included in the message m1-2 has been successfully executed, for example. The response may be transmitted to the image forming apparatus 20a via the application gateway 122 and the Internet gateway 111 (steps S143 and S144).
When the response is received at the image forming apparatus 20a, the application platform 22 stores a device log related to the process executed in response to the operation made in step S101 in the device log storage part 24 (step S145).
The value of the “Timestamp” field represents the generation date/time of the device log. The value of the “CUID” field represents the CUID assigned to the user operation that has triggered the recording of the device log. That is, the CUID assigned to the operation made by the operator in step S101 is recorded as the field value of the field “CUID” in the device log to be recorded in step S145. Note that the “CUID” field value of the first device log listed in
The value of the “action” field represents the actual content of the request to the cloud service system 1. The value of the “Location” field represents identification information of data to be processed according to the request represented by the field value of the “action” field. The value of the “Result” field indicates whether the process executed in response to the operation made in step S101 has been successfully completed. Note that “error” is indicated as the field value of the “Result” field of the second device log listed in
Note that the format of the fields included in the device log may be identical to the format of the fields included in the server logs recorded by the servers of the cloud service system 1.
After step S145, the relevant client application 21 to be operated prompts an operation panel of the image forming apparatus 20a to display a message indicating the result of the process executed in response to the operation made in step S101 (step S146).
Meanwhile, the application server 121 transmits the server log L3 recorded in step S141 to the log management server 131 (log management part 131a) at a suitable timing (step S151). Note that the transmission of the server log L3 may be performed asynchronously with respect to the recording of the server log L3. Upon receiving the server log L3, the log management server 131 includes the received server log L3 in a message m6 representing a storage request for storing the server log L3 and transmits the message m6 to the log storage server 141 (step S152).
Next, process steps similar to those performed with respect to the message m3 (steps S116 and S117) are performed with respect to the message m5. In this way, the server log L3 may be stored in the secondary storage device 102 of the log storage server 141.
In the following, an uploading process for uploading a device log recorded in the image forming apparatus 20a to the log storage server 141 is described.
In step S201, the uploading part 23 of the image forming apparatus 20a transmits a message m11 including a device log uploading request for uploading a device log stored in the device log storage part 24.
Description d7 of the message m11 illustrated in
Step S201 of
As described above, all messages addressed to the cloud service system 1 are first received by the Internet gateway 111. Accordingly, the message m11 is received by the Internet gateway 111. Upon receiving the message mil, the Internet gateway 111 generates a RID with respect to the request included in the message m11 and includes the generated RID in the message m1l (step S202). For example, a new field “X-RID” including the generated RID as the field value may be added to the description d6 of the message m11 illustrated in
Next, the Internet gateway 111 transfers a message m11-1 corresponding to the message m11 having the RID included therein to the log management server 131 (step S203).
The message m11-1 addressed to the log management server 131 on the segment g3 is first received at the common service gateway 134. The common service gateway 134 generates a UID with respect to the message m11-1 and includes the generated UID in the message m11-1 (S204). For example, a new field “X-UID” including the generated UID as the field value may be added to the description d6 of the message m11 illustrated in
Next, the common service gateway 134 transmits a message m11-2 corresponding to the message m11-1 having the UID included therein to the log management server 131 (step S205).
Where case 1 is implemented, the log server 131 records the device log included in the description d7 of the received message m11-2 in the secondary storage device 102 of the log management server 131 (S211). Then, the log management server 131 transmits a response to the message m11-2 (step S241).
Thereafter, the log management server 131 may include the device log recorded in step S211 in a message m12 representing a storage request for storing the device log and transmit the message m12 at a suitable timing to the log storage server 141 (step S212).
Note that in addition to including a description of the storage request for storing the device log, the message m12 may include a “X-Device-ID” field, an “X-RID” field, and a “User-Agent” field, for example. The field values of these fields may be the same as the field values of the corresponding field names included in the massage m11-2.
The message m12 addressed to the log storage server 141 on the segment g4 is first received by the database gateway 143. Upon receiving the message m12, the database gateway 143 generates a UID to the message m12 and includes the generated UID in the message m12 (step S213).
Next, the database gateway 143 transmits a message m12-1 corresponding the message m12 having the generated UID included therein to the log storage server 141 (step S214). Upon receiving the message m12-1, the log storage server 141 may store the device log included in the message m12-1 in the secondary storage device 102 of the log storage server 141, for example. In a preferred embodiment, the device log and the server log are separately stored.
Where case 2 is implemented, the log management server 131 extracts the device log from the description d7 of the received message m11-2, includes the device log in the message 12 representing the storage request for storing the device log, and transmits the message 12 to the log storage part 141 (step S221). Then, process steps similar to the above process steps S213 and S214 are performed (steps S222 and S223). In this way, the device log included in the message m12-1 may be recorded in the secondary storage device 102 of the log storage server 141. Then, the log management server 131 transmits a response to the message m11-2 (step S241).
Note that in both case 1 and case 2, the response transmitted in step S241 is transferred to the image forming apparatus 20a via the common service gateway 134 and the Internet gateway 111 (steps S242 and S243).
In some embodiments, a device log related to the device log uploading process may be recorded at the image forming apparatus 20a that receives the response from the log management server 131.
In the following, an exemplary manner of browsing logs such as server logs and device logs that have been stored in the log storage server 141 by the processes of
For example, the log browsing terminal may display a log browsing screen as illustrated in
The search condition input region 510 accepts an input of a value or value range for a field included in a server log as a search condition. In the example illustrated in
When a search condition is input into one of the input fields of the search condition input region 510 and a search button 511 is pressed, the log browsing terminal transmits a server log search request to the log management server 131. The search request designates the search condition input to the search condition input region 510. In response to the search request, the log management server 131 searches for sever logs matching the search condition from the sever logs stored in the log storage server 141. The log management server 131 then returns a list of server logs matching the search condition to the log browsing terminal.
The log browsing terminal them prompts the log display region 520 to display the list of server logs. The log display region 520 displays the field values of the fields of each server log that is listed. When one of the field values of one of the server logs displayed in the log display region 520 is selected by double-clicking the field value, for example, the log browsing terminal may transmit the selected field value as a search refinement condition to the log management server 131. In response to such a search request, the log management server 131 may further refine the search. For example, when a field value of the “X-RID” field is double-clicked, only server logs including the selected value as the RID may be displayed. Also, a device log including the CUID corresponding to the selected RID may be searched. In this way, a viewer of the log browsing screen may easily determine the correspondence between a process at the device 20 side and a process at the server side of a series of processes executed over a network.
Note that
As described above, in the first embodiment, a CUID, which is assigned to a predetermined process unit at the device 20 side and recorded in a device log, and a RID, which is assigned to a request from the device 20 at the server side and recorded in each server log related to each process executed at the server side in response to the request are stored in association with each other. In this way, the correspondence between operations and processes at the device 20 side and processes at the server side may be accurately determined. Also, when an error occurs at the server side, the operation at the device 20 side that has triggered the error may be quickly determined, for example. Also, usage of a function at the server side by the device 20 side may be analyzed and useful information for marketing purposes may be derived, for example.
In the following, a second embodiment of the present invention is described. Note that features of the second embodiment that differ from the first embodiment are described below. Accordingly, it may be assumed that aspects of the second embodiment that are not particularly described below may be identical to the first embodiment.
In the second embodiment, the application platform 22 of the image forming apparatus 20a assigns a RID. That is, the application platform 22 assigns a RID to a message to be transmitted to the cloud service system 1, includes the RID in the message, and transmits the message including the RID to the cloud service system 1. In the present embodiment, a CUID does not necessarily have to be assigned. Thus, for example, in step S102 of
In the present embodiment, the RID may include the device number of the image forming apparatus 20a and the identification information assigned to the message at the image forming apparatus 20a, for example. Such an arrangement may be favorable for purposes of avoiding an overlap of RIDs in the case where a plurality of image forming apparatuses 20a or other devices 20 are configured to assign an RID to a message to be transmitted to the cloud service system 1, for example.
At the cloud service system 1 side, the Internet gateway 111, the application gateway 122, the common service gateway 134, and the database gateway 143 (generically referred to as “gateway” hereinafter) may execute process steps illustrated in
Upon receiving a message, the gateway determines whether a RID is included in the received message (step S301). If a RID is not included in the message (NO in step S301), the gateway generates a RID and includes the generated RID in the message (S302).
Next, the gateway determines whether a UID is included in the message (step S303). If a UID is not included in the message (NO in step S303), the gateway generates a UID and includes the generated UID in the message (step S304).
As can be appreciated from
Note that a message generated within the cloud service system 1 is an example of a message that may not have a RID assigned thereto by the image forming apparatus 20a.
Also, in the second embodiment, each of the servers (computers other than the gateway) may perform process steps as illustrated in
Upon receiving a message, the server determines whether a RID is included in the received message (step S311). If a RID is not included in the message (NO in step S311), the server generates a RID and includes the generated RID in the message (S312).
Next, the server determines whether a UID is included in the message (step S313). If a UID is not included in the message (NO in step S313), the server generates a UID and includes the generated UID in the message (step S314). If a UID is included in the message (YES in step S313), the server generates a new UID and replaces the UID included in the received message with the newly generated UID (step S315).
As can be appreciated from
In the following, a third embodiment of the present invention is described. Note that features of the third embodiment that differ from the second embodiment are described below. Accordingly, it may be assumed that aspects of the third embodiment that are not particularly described below may be identical to the second embodiment. Also, the third embodiment may be implemented in conjunction with the first embodiment.
Upon receiving the message m4-1, the content processing part 133a of the content processing server 133 executes the process steps illustrated in
Next, the content processing part 133a records a server log related to the content process in the secondary storage device 102 of the content processing server 133 (step S125).
Next, the content process part 133a transmits a response to the message m4-1 (step S126).
Meanwhile, the asynchronous process part 133b of the content processing server 133 periodically monitors the job queue. In monitoring the job queue, the asynchronous process part 133b generates a job ID (JID) corresponding to identification information for identifying each job to be executed by the asynchronous process part 133b (step S401). Next, the asynchronous process part 133b acquires job information from the job queue (step S402). In a preferred embodiment, the generated JID may be stored in association with the job information in the job queue. In this way, the job information registering side (the content process part 133a in the present example) may be informed of the JID corresponding to the job stored in the job queue. In a further embodiment, the JID may be used to check an execution status of a job, for example. Note that job information may not be acquired in step S402 when the job queue is empty. In such a case, the JID generated in a previous monitoring session may be used to in the next monitoring session, for example.
When job information is obtained in step S402, the asynchronous process part 133b sends a process request to a relevant server that is capable of executing the process called by the acquired job information. In the present example, the job information is related to a mail transmission request for a group of files. Thus, the asynchronous process part 133b sends a mail transmission request for the group of files to the mail server 135 (step S403).
Next, the asynchronous process part 133b records a server log related to the asynchronous process in the secondary storage device 102 of the content processing server 133 (step S404). Server log L5 of
Meanwhile, the mail server 135 that receives the mail transmission request for the group of files transmits the requested group of files via email in response to the mail transmission request (step S405). Next, the mail server 135 records a server log related to the mail transmission process in the secondary storage device 102 of the mail server 135 (step S406). Server log L6 of
The server log L6 includes information on the correspondence between the RID and the JID. Specifically, in
Note that a job to be executed based on job information does not necessarily have to be executed at once. For example, a job to be executed based on one set of job information may be divided into plural job units and executed separately by the asynchronous process part 133b. In such a case, a different JID may be assigned to each of the job units and a server log related to each job unit may be recorded, for example.
As described above, in the third embodiment, a JID is assigned to a process (job) that is executed asynchronously with respect to a request including a RID, and the correspondence between the RID and the JID is recorded in a server log. In this way, even when processes associated with a request from a device 20 are performed asynchronously, the correspondence between operations and processes at the device 20 side and processes at the server side may still be determined.
In the following, a fourth embodiment of the present invention is described. Note that features of the fourth embodiment that differ from those of the second and third embodiments are described below. Accordingly, it may be assumed that aspects of the fourth embodiment that are not particularly described below may be identical to the second and third embodiments. The fourth embodiment may also be implemented in conjunction with the first embodiment.
The log utilizing part 131b provides an API for enabling utilization of a log stored in the log storage part 141a (log storage server 141) as a part of the platform API 150. The log analyzing part 131c analyzes or counts relevant logs stored in the log storage part 141a. The application management part 136a executes a process related to a server application provided in the application layer 120.
The fourth embodiment is described below in connection with an exemplary API that may be provided by the log utilizing part 131b (referred to as “log utilizing API” hereinafter).
First, with respect to case A of
Next, with respect to case B of
In the following, specific examples of log utilizing APIs are described. As a first specific example of a log utilizing API, a getLogAll method is described below. The interface specification of the getLogAll method is as follows:
getLogAll (application ID, start date/time, end date/time, (tenant ID), (device ID), (device type))
The getLogAll method includes an application ID, a start date/time, and an end date/time as required arguments and includes a tenant ID, a device ID, and a device type as optional arguments. That is, arguments in parentheses (tenant ID, device ID, and device type in the above example) represent arguments that may be designated on an optional basis. Note that the same form of notation is used to represent the interface specifications of other log utilizing APIs described below. The return value of the getLogAll method corresponds to a list of logs specified by the parameters designated by the arguments.
The application ID is an argument corresponding to the “app_id” field of a log. The start date/time and the end date/time are arguments of the “time” field of a log. The tenant ID is an argument corresponding to the “organization_id” field of a log. The device ID is an argument corresponding to the “X-Device-ID” field of a log. The device type is an argument corresponding to the device type of the device 20 stored in the device information storage part 142 in association with the device ID of the device 20, for example. The device type may be classified based on the function and purpose of the device 20, for example. Exemplary values of the device type of the device 20 include “MFP”, “projector”, and “teleconference”. “MFP” represents the device type for the image forming apparatus 20a, “projector” represents the device type for the projector 20b, and “teleconference” represents the device type for the teleconference device 20c.
In response to the call for the getLogAll method, the log utilizing part 131b searches for a log having an “app_id” field value matching the application ID designated as the argument and a “time” field value within the start date/time and the end date/time designated as the arguments from the logs stored in the log storage part 141a. In a case where the tenant ID is designated, the log utilizing part 131b may refine the search to a log having an “organization_id” field value matching the designated tenant ID. Also, in a case where the device type is designated, the search may be refined to a log having a “X-Device-ID” field value that is associated with a device type in the device information storage part 142a matching the device type of the argument.
Alternatively, the device type may be included in the logs.
The field value of the “device_cat” field of a server log may be acquired from the device information storage part 142b based on the field value of the “X-Device-ID” field of the server log, or the field value of the “device_cat” field may be acquired from a device log. In the case where the field value is acquired from a device log, the device log may be arranged to include a field indicating the device type.
As a second specific example of a log utilizing API, a getClientReport method is described below. The interface specification of the getClientReport method is as follows:
getClientReport (application ID, start date/time, end date/time, (device ID), (device type), (detailed information flag))
The getClientReport method includes an application ID, a start date/time, and an end date/time as required arguments and includes a device ID, a device type, and a detailed information flag as optional arguments. The return value of the getClientReport method corresponds to the number of users of a server application with the designated application ID in each type of device 20 that cooperates with the cloud service system 1 during each unit period (e.g., one month) of a period from the start date/time to the end date/time. The application ID, the start date/time, the end date/time, the device ID, and the device type that may be designated as arguments may be identical to the arguments with the corresponding names in the getLogAll method. The detailed information flag as an optional argument includes the values “true” or “false”. The detailed information flag is described in detail below.
In response to the call for the getClientReport method, the log utilizing part 131b sends an information acquisition request to the log analyzing part 131c for information indicating the number of users of the server application with the designated application ID in each type of device 20 during each unit period of a period from the start date/time to the end date/time.
The log analyzing part 131c searches for a log having an “app_id” field value matching the application ID designated as the argument, a “time” field value within the start date/time and the end date/time designated as the arguments, and a “path” field value representing authentication from the logs stored in the log storage part 141a. That is, the number of users is counted based on the number of authentications performed to enable users to log in. In a case where at least one of the device ID and the device type is designated as an argument, the search may be refined in a manner similar to the refined search implemented in the getLogAll method.
Next, the log analyzing part 131c classifies the logs obtained by the search according to the device type, and with respect to each set of logs classified by device type, counts the number of logs within each unit period of a period defined by the “time” field values of the logs. The log analyzing part 131c returns information indicating the count result to the log utilizing part 131b. The log utilizing part 131b generates a return value based on the returned information and transmits the generated return value to the client.
The return value transmitted by the log utilizing part 131b may be HTML data representing a chart or a graph as illustrated in
Note that
In the case where a device ID is designated as an argument in the call for the getClientReport method, the number of users of the device 20 with the designated device ID for each month may be obtained as the return value. Also, in the case where a device type is designated as an argument, a row or a line of the chart or graph illustrated in
In the case where the return value as illustrated in
Note that although the number of users for each unit period of one month is counted in the above examples, the unit period may be changed according to the manner in which the start date/time and the end date/time are designated in the call for the getClientReport method. For example, when the start date/time and the end date/time are specified down to the month, the number of users may be counted on a monthly basis. When the start date/time and the end date/time are specified down to the day of the month, the number of users may be counted on a daily basis. When the start date/time and the end date/time are specified down to the time of the day, the number of users may be counted on an hourly basis. In this way, the unit period used as a basis for counting the number of users may be determined based on the smallest time unit that is designated in the start date/time and end date/time, for example.
As a third specific example of a log utilizing API, a getJobReport method is described below. The interface specification of the getJobReport method is as follows:
getJobReport (application ID, start date/time, end date/time, (delivery destination), (content format))
The getJobReport method includes an application ID, a start date/time, and an end date/time as required arguments and includes a delivery destination and a content format as optional arguments. The return value of the getJobReport method corresponds to the number of times a server application with the designated application ID has executed a job of a cloud scan service within each unit period of a period from the start date/time to the end date/time designated. The application ID, the start date/time, and the end date/time that may be designated as arguments may be identical to the arguments with the corresponding names in the getLogAll method. The delivery destination as an optional argument may take the value “true” or “false”. The content format as an optional argument may take the value “true” or “false”. The value “true” indicates that the number of times a job has been executed is to be counted with respect to each content format of contents that have been delivered.
In response to the call for the getJobReport method, the log utilizing part 131b sends an information acquisition request to the log analyzing part 131c for information indicating the number of times the server application with the designated application ID has executed a job of the cloud scan service within each unit period of a period from the start date/time to the end date/time.
The log analyzing part 131c searches for a log having an “app_id” field value matching the application ID designated as an argument, a “time” field value within the start date/time and the end date/time designated as arguments, and a “path” field value representing delivery, from the logs stored in the log storage part 141a.
Next, with respect to logs obtained from the above search, the log analyzing part 131c counts the number of logs within each unit period based on the “time” field values of the logs. Note that in the case where the value “true” is designated as the argument for the delivery destination, the logs are separately counted with respect to each delivery destination. Also, in the case where the value “true” is designated as the argument for the content format, the logs may be separately counted with respect to each content format of the delivered contents. The log analyzing part 131c returns information indicating the count result to the log utilizing part 131b. The log utilizing part 131b generates a return value based on the returned information and transmits the generated return value to the client.
The return value transmitted by the log utilizing part 131b may be HTML data representing a chart or a graph as illustrated in
Note that the unit period may be changed according to the manner in which the start date/time and the end date/time are designated as in the getClientReport method.
To enable counting of logs based on the delivery destination or the content format as described above, a server log may be arranged to have a configuration as illustrated in
As a fourth specific example of a log utilizing API, a getErrorReport method is described below. The interface specification of the getErrorReport method is as follows:
getErrorReport (application ID, start date/time, end date/time, (error location))
The getErrorReport method includes an application ID, a start date/time, and an end date/time as required arguments and includes an error location as an optional argument. The return value of the getErrorReport method corresponds to information indicating the number of error occurrences related to a process of a server application with the designated application ID within each unit period of a period from the start date/time to the end date/time designated. The application ID, the start date/time, and the end date/time that may be designated as arguments may be identical to the arguments with the corresponding names in the getLogAll method. The error location as an optional argument is an argument for limiting the location of the error occurrence. For example, error occurrences may be distinguished based on the server specified as the error location.
In response to the call for the getErrorReport method, the log utilizing part 131b sends an information acquisition request to the log analyzing part 131c for information indicating the number of error occurrences in the server application with the designated application ID within each unit period of a period from the start date/time to the end date/time.
The log analyzing part 131c searches for a log having an “app_id” field value matching the application ID designated as an argument, a “time” field value within the start date/time and the end date/time designated as arguments, and a “level” field value that is indicated as “ERROR” from the logs stored in the log storage part 141a.
Next, with respect to logs obtained from the above search, the log analyzing part 131c classifies the logs according to the type of error.
For example, if the field value of the “result” field of a log is “401⇄, the log may be classified under authentication error. Further, in some embodiments, the classification result based on the error type may be further classified based on the field value of the “inquiry_code” field (i.e., error code). Based on the “time” field values of the logs, the log analyzing part 131c counts the number of logs within each unit period with respect to each error type and with respect to each error code. The log analyzing part 131c returns information indicating the count result to the log utilizing part 131b. The log utilizing part 131b generates a return value based on the returned information and transmits the generated return value to the client.
The return value transmitted by the log utilizing part 131b may be HTML data representing a chart or a graph as illustrated in
In the case where a value such as “authentication” is designated as an argument for the error location in the call for the getErrorReport method, a return value as illustrated in
As the error location, values such as “own application” or “content” may be designated as the argument in addition to the value “authentication”. In the case where “own application” is designated, the return value may be a breakdown of errors that have occurred at the application server 121 having the server application with the designated application ID installed therein. In the case where “content” is designated, the return value may be a breakdown of errors that have occurred at the content processing server 133.
As a fifth specific example of a log utilizing API, a getCustomerReport method is described below. The interface specification of the getCustomerReport method is as follows:
getCustomerReport (application ID, start date/time, end date/time, section)
The getCustomerReport method includes an application ID, a start date/time, an end date/time, and a section as required arguments. The return value of the getCustomerReport method corresponds to information relating to the number of users of a server application with the designated application ID within each unit period of a period from the start date/time to the end date/time designated which information is indicated with respect to each attribute designated by the section. The application ID, the start date/time, and the end date/time that may be designated as arguments may be identical to the arguments with the corresponding names in the getLogAll method. The section is an argument designating an attribute based on which users are classified. Exemplary values that may be designated as the argument for the section include “industry” and “employee number”.
In step S601, the log utilizing part 131b receives the call for the getErrorReport method. In response to the call, the log utilizing part 131b sends an information acquisition request to the log analyzing part 131c for information indicating the number of users of the server application with the designated application ID within each unit period of a period from the start date/time to the end date/time and with respect to each attribute designated by the section (step S602).
The log analyzing part 131c searches for a log having an “app_id” field value matching the application ID designated as an argument, a “time” field value within the start date/time and the end date/time designated as arguments, and a “path” field value representing authentication from the logs stored in the log storage part 141a (steps S603 and S604). Next, the log analyzing part 131c classifies logs obtained from the above search based on the field value of the “organization_id” field (i.e., organization ID) of the logs, and acquires, for each of the organization IDS, a corresponding value of the attribute designated by the argument for the section stored in the user information storage part 142a in association with the organization ID (steps S605 and S606). For example, the value “industry” or “employee number” may be acquired in this process step.
Next, the log analyzing part 131c returns information indicating the count/analysis result to the log utilizing part 131b (step S608). The log utilizing part 131b generates a return value based on the returned information and transmits the generated return value to the client (step S609).
The return value transmitted by the log utilizing part 131b may be HTML data representing a chart or a graph as illustrated in
Note that the application ID used as an argument of the above described APIs may be statically assigned to each server application, for example. Alternatively, the application ID may be dynamically assigned to each server application as illustrated in
During an activation process for activating the application server 121 (step S701), a server application may execute the following process steps.
First, the server application designates attribute information of the server application such as an application name and vendor name of the server application, and transmits a server application registration request to the application management part 136a (step S702). The vendor name refers to identification information of the software vendor that has developed the server application. Note that because the uniqueness of an application name may at least be ensured under the same software vendor, a server application may be unambiguously identified based on a combination of an application name and a vendor name. Note also that other items of information related to the server application may be included in the server application registration request.
In response to the server application registration request, the application management part 136a generates an application ID corresponding to identification information for uniquely identifying each server application and returns the generated application ID to the server application that has sent the server application registration request (step S703). The application management part 136a may store the application ID in association with the attribute information of the server application designated in the server application registration request in the application information storage part 142a, for example.
When the activation process is completed, the server application designates the returned application ID and transmits an activation complete notification to the application management server 136a (step S704). In response to the activation complete notification, the application management part 136a may store information indicating that the server application with this application ID is currently running in a record for this application ID within the application management information storage part 142c, for example.
In a case where the application ID is dynamically assigned, it may be difficult for the client side to acquire the value of the application ID corresponding to the argument of a log utilizing API. Accordingly, in one embodiment, the application ID corresponding to the argument of the log utilizing API may be replaced by the application name or a combination of the application name and the vendor name, for example. In this case, the log utilizing part 131b may refer to the application management information storage part 142c, replace the application ID with the application name or a combination of the application name and vendor name, and execute a process according to the called API, for example.
In another embodiment, an API that returns an application name corresponding to an application ID may be provided as one of the functions provided by the platform API 150.
Note that the interface specifications of the log utilizing APIs described above may be changed or modified as desired. Also, some other log utilizing API may be added as well, for example.
Also, note that the cloud service system 1 described above corresponds to an exemplary embodiment of an information processing system. The Internet gateway 111 corresponds to an exemplary embodiment of a first assigning part and a receiving part. The log storage server 141 corresponds to an exemplary embodiment of a storage part. The application gateway 122, the common service gateway 134, and the database gateway 143 correspond to exemplary embodiments of a second assigning part.
The application server 121, the log management server 131, the authentication server 132, and the content processing server 133 correspond to exemplary embodiments of a process part.
Although the present invention has been described above with reference to certain embodiments, the present invention is not limited to these embodiments, and numerous variations and modifications may be made without departing from the scope of the present invention.
Claims
1. An information processing system including at least one computer, the information processing system comprising:
- a first assigning part that receives from a device a process request including device process identification information identifying a predetermined process unit of the device, and assigns request identification information identifying the process request; and
- a storage part that stores the device process identification information and the request identification information in association with each other in connection with a process executed in response to the process request.
2. The information processing system as claimed in claim 1, further comprising:
- a second assigning part that assigns process identification information identifying each process unit of a process called by the process request;
- wherein the storage part stores, with respect to each process unit, the request identification information assigned to the process request to which the process unit belongs and the process identification information assigned to the process unit in association with each other.
3. The information processing system as claimed in claim 2, further comprising:
- a plurality of process parts that are connected to each other via a network and are configured to execute the process unit;
- wherein the second assigning part assigns the process identification information to the process unit in response to a process unit execution request issued from one of the plurality of process parts to another one of the plurality of process parts.
4. An information processing system including at least one computer, the information processing system comprising:
- a receiving part that receives from a device a process request including request identification information identifying the process request;
- a second assigning part that assigns process identification information identifying each process unit of a process called by the process request; and
- a storage part that stores, with respect to each process unit, the request identification information and the process identification information assigned to the process unit in association with each other.
5. The information processing system as claimed in claim 4, further comprising:
- a plurality of process parts that are connected to each other via a network and are configured to execute the process unit;
- wherein each of the plurality of process parts correspond to the second assigning part.
Type: Application
Filed: Jan 22, 2014
Publication Date: Jul 24, 2014
Applicant: RICOH COMPANY, LTD. (Tokyo)
Inventor: Kiyohiro HYO (Tokyo)
Application Number: 14/160,689
International Classification: H04L 12/24 (20060101);