JP2004038559A - Web application control unit, program, and network system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable a display to be mounted in isolation from the place where a scrolling has been decided even if an entire scrolling cannot be seen by reducing management manhour and coding manhour of a module at developing Web application, and to improve efficiency in development. <P>SOLUTION: The system is provided with a request receiving means for receiving from a client a request including identification information on job processing to be performed together with data of an intended job processing, a job processing sorting means for sorting processing to the job processing module corresponding to the identification information of the received job processing and acquiring a processed result, a generated screen control means for sorting the screen generation processing of the processed result to any one of a plurality of screen generating modules on the basis of the identification and the processed result of the job processing module, and a screen generating means composed of a plurality of screen generating modules outputted in response to a requesting client. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a Web application control apparatus that receives a request issued by a client when accessing a Web application, determines a business to be executed based on the request, and determines information to be output and a display method based on the business execution result. The present invention relates to a Web application control device, a network system, and a program that reduce the number of application development steps and enable efficient development.
[0002]
[Prior art]
2. Description of the Related Art In recent years, systems using server-side technology in Web application systems on the Internet and intranet have become widespread.
In recent Web application development, several methods are known for designing an application on a server.
FIG. 17 shows an outline of a method of designing a module (Servlet) that receives a request from a client, a module (Bean) that performs business processing, and a module (JSP) that outputs a screen (hereinafter, referred to as an individual method). FIG. 1 is a diagram showing a configuration disclosed in Japanese Patent Application Laid-Open No. 2001-344105.
In the method shown in FIG. 17, a request receiving unit 1701 for receiving a business processing request transmitted from a client as an input, a business processing module 1702 for performing a business processing result in accordance with the request content, and a processing result screen are displayed. The screen generation module to be generated and 1703 are associated with each other on a one-to-one basis, a business process corresponding to the content of the business process request received by the request receiving unit 1701 is executed by the corresponding business process module 1702, and a screen corresponding to the result Is generated by the corresponding screen generation module 1703, and the generated screen is returned to the requesting client as a response (output) to the business processing request.
[0003]
On the other hand, as shown in FIG. 18, one representative module (request receiving unit) 1801 receives a request from a client, and a business processing module and a screen transition determination module according to the request content are determined by a business processing determining unit 1802. The business process according to the determination result is distributed to any one of the plurality of business process modules 1803-1 to 1803-n and executed, and the screen transition according to the result is determined by the screen transition determination module 1804. Is generated by the screen generation module 1805 and returned to the requesting client as a response (output) to the business processing request (hereinafter referred to as an engine method). (Published March 15, 2002, Author: Katsuhiko Yuura, etc., Publisher: Soft Research Center), pages 129-131.
[0004]
[Problems to be solved by the invention]
The above-mentioned conventional technology has been developed in accordance with the shortening of the development cycle in recent system development. In particular, when a business system or business service is disclosed on the Web, shortening the development cycle is a strong requirement as customer needs. In a Web application system, it is required not only to periodically change the design and information of a Web page, but also to publish a new service on the system at an early stage and to quickly expand the service. In order to respond to those customer needs and to respond to the development cycle of the Web application system, it is necessary to reduce the development work and speed up the development work.
[0005]
However, the conventional method has the following problems.
In the case of the individual system shown in FIG. 17 disclosed in Japanese Patent Application Laid-Open No. 2001-344105, since a module for receiving a request is created in one-to-one correspondence with a screen generation module, the module for receiving a request always has a screen. The same number is required. Therefore, as the number of screens increases, the number of modules that accept requests also increases. Modules that accept requests are separately loaded into memory at the time of execution, so as the number of screens increases, the number of request acceptance modules loaded on memory also increases, resource consumption increases, and performance decreases There is a problem.
In addition, as a problem in terms of management, there is a problem that the number of man-hours for managing the module increases as the number of screens increases. In addition, even if the module that accepts the request has several lines of coding, it is necessary to perform the coding. Therefore, there is a problem that the load of the coding increases as the number of screens increases.
[0006]
On the other hand, in the engine system of FIG. 18, after one request receiving module receives a request from a client on behalf of the client, a business processing module to be executed is determined from a plurality of business processing modules. At that time, a screen transition definition file 1806 that defines screen transition information is required. Further, in order to change the output screen according to the result of the business process, it is necessary to implement the screen transition determination module 1804 for each business process module.
In the case of the engine system as described above, only one module may receive the request. For this reason, the problem that management man-hours and costs increase does not occur.
[0007]
However, in order to determine the business process module to be executed, a screen transition definition file that defines screen transition information is required. For this reason, when the screen transition is complicated, the plane transition definition file is also complicated, and there is a problem that the burden of designing and creating the screen transition definition file increases.
Furthermore, since the entire screen transition is described in the screen transition definition file, there is a problem that the implementation cannot be started unless the entire screen transition is visible.
[0008]
An object of the present invention is to make it possible to implement a Web application by having at least one module in a system that receives a request from a client at the time of developing the Web application, to increase the number of screens, and increase the resource consumption, An object of the present invention is to solve the problem that the man-hour for managing the module increases and the man-hour for coding the module increases.
Furthermore, by eliminating the need for a screen transition definition file, the man-hours required to design and create the screen transition definition file are reduced, and even if the entire screen transition is not visible, the screen transition can be implemented independently from the point where the screen transition is determined. In this way, it is possible to improve the efficiency of development.
[0009]
[Means for Solving the Problems]
In order to achieve the above object, a Web application control device according to the present invention distributes a business process according to a request content from a client to one of a plurality of business process modules prepared in advance, and transmits a process result to a request source. A web application control device for replying to a client,
Request receiving means for receiving a request including identification information of the business process to be executed together with data to be processed from the client, and distributing the process to a business process module corresponding to the received identification information of the business process; A business process distribution unit to acquire, a generated screen control unit that allocates a screen generation process of a processing result to one of a plurality of screen generation modules based on the identification information and a processing result of the business processing module, And a screen generating unit comprising a plurality of screen generating modules for generating screen data and outputting the data as a response to the requesting client.
The system further comprises a plurality of business scenario modules each describing a scenario for performing a different business process using the plurality of business process modules, wherein the business process distribution means corresponds to the business scenario module as identification information of the business process. The received identification information is received from the client, and the process is distributed to the business scenario module corresponding to the received identification information.
[0010]
Also, in a network system including a client that transmits a business processing request, and an application server that receives the business processing request via a network, executes business processing according to the request content, and returns a processing result to the requesting client. The client has means for transmitting a request including identification information of a business process to be executed together with data to be processed,
Request receiving means for receiving, from the client, a request including identification information of a business process to be executed together with data to be processed,
A business processing distribution unit for allocating a processing to a business processing module corresponding to the identification information of the business processing received from the client among a plurality of business processing modules prepared in advance, and obtaining a processing result; and the identification information and the business processing module Generating screen control means for distributing the screen generation processing of the processing result to one of a plurality of screen generation modules based on the processing result of the above, and generating the screen data of the allocated processing result and outputting it as a response to the requesting client Screen generating means comprising a plurality of screen generating modules.
The application server may further include a plurality of business scenario modules each describing a scenario for performing a different business process using the plurality of business process modules, and the business process distribution unit may include, as identification information of the business process, It is characterized in that identification information corresponding to the business scenario module is received from a client, and processing is distributed to the business scenario module corresponding to the received identification information.
[0011]
A Web application control program that distributes a business process according to the content of a request from a client to one of a plurality of business process modules prepared in advance, and returns a processing result to a client of the request source. A request receiving step of receiving a request including identification information of a business process to be executed together with data to be executed, and a business process of allocating a process to a business processing module corresponding to the received identification information of the business process and obtaining a processing result A distribution step, a generation screen control step of allocating a screen generation process of the processing result to one of the plurality of screen generation modules based on the identification information and the processing result of the business processing module, and generating screen data of the allocated processing result And output it as a response to the requesting client Web application control program, characterized in that it comprises a surface generating step.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, an embodiment of the present invention will be specifically described with reference to the drawings.
1 and 2 are block diagrams showing a configuration example of an embodiment of a network system to which the present invention is applied.
The processing program control device 110 constituting the Web application control device according to the present invention exists in the application server 104 of the Web application 107.
The Web application 107 is an application that can be used on the Internet 102, and includes a Web server 103 that receives a request from the client 101, an application server 104 that performs business processing, a database server 105 that accesses a database 106, and a database 106. ing.
The client 101 receives an operation by the user 100, transmits an input message 130 to the web application 107 via the Internet 102, receives an output message 131 from the web application 107, and presents the web browser 141 and an individual application to the user 100. 142 or an application or a hardware device.
[0013]
As shown in FIG. 2, the application server 104 receives the input message 130 from the client 101 and performs a business process according to the content of the received input message in a plurality of business scenario modules 114 (scenarios 1 to N). ) 1141 to execute the program, receive the execution result, determine the screen generation module 116 that generates the output message 131, and a plurality of business modules 115 including the business 1 to the business L , A business scenario module 114 for executing a series of business, a business module 115 composed of business 1 to business L for performing business processing, and a screen generation module 116 for generating an output message 131 to be returned to the client 101. Exists.
Each task scenario module 1141 is assigned an ID for uniquely identifying each task scenario module 1141. One business scenario module 1141 exists for each process performed after a request from the client 101 is received until a response is made to the client 101.
Each business scenario module 1141 is a module in which a plurality of business modules are used in combination and a scenario for obtaining a predetermined processing result is described. It has been described. As the scenario, one or more business module names required to obtain a predetermined processing result, the execution order of the business modules, and the like are described.
Also, each business module 1151 exists for one business process, and the screen generation module 116 includes a plurality of screen generation modules (screen generation 1 to M) 1161. There is one.
[0014]
As shown in FIG. 2, the business processing program control device 110 distributes the processing by passing the input data 121 to the request receiving unit 111 that receives the input electronic message 130 transmitted by the client 101 via the Internet 102, and receives the business processing result. A business processing distribution unit 112, a generated screen control unit 113 that determines a screen generation module 116 to be executed according to the business processing result 117, input data 121, an execution scenario ID 122, a business result code 123, output information 124, a generated screen determination table It is composed of a memory 120 for storing the data 125.
The request receiving unit 111, the business process distribution unit 112, and the generation screen control unit 113 that constitute the business process program control device 110 are specifically configured by a program.
[0015]
Hereinafter, each component of the business processing program control device 110 according to the present invention will be described.
The request receiving unit 111 is a module that receives a request from the client 101. The request receiving unit 111 receives an input electronic message 130 having a format configuration as shown in FIG. 3, acquires an execution scenario ID 204 and input data 205 from the input electronic message 130, and stores them in the input data 121 and the execution scenario ID 122 on the memory 120, respectively. Is performed.
Since the request receiving unit 111 does not include a process depending on each screen generation module 116, there is no need to associate the request reception unit 111 with the screen generation module 116 as in the conventional individual method. Therefore, at least one request reception unit 111 may be provided on the application server 104 irrespective of the screen generation module 116.
[0016]
After deciding a business scenario module 1141 (any one of scenarios 1 to N) for executing a business process according to the request content, the business process distribution unit 112 passes the input data 121 on the memory 120 to execute the business process. This is a module that is executed and receives the business process result 117. When determining the business scenario module 1141 (any one of the scenarios 1 to N), the business process distribution unit 112 acquires the execution scenario ID 122 from the memory 120. Each business scenario module 1141 is provided with a scenario ID for uniquely identifying the business scenario module 1141, and the business scenario module 1141 to be executed is uniquely determined from the execution scenario ID 122. Therefore, a screen transition definition file that defines screen transition information required by the conventional engine method to determine the task scenario module 1141 to be executed becomes unnecessary.
[0017]
After executing the business process, the business process distribution unit 112 receives the business process result 117 from the business scenario module 114, acquires the business result code 503 and the output information 504 as shown in FIG. 120 are stored as a business result code 123 and output information 124, respectively.
The generation screen control unit 113 is a module that determines and executes the screen generation module 116 that generates the output telegram 131. When determining the screen generation module 1161 (any of the screen generations 1 to M), the screen generation module 1161 is determined with reference to the generation screen determination table 125 based on the execution scenario ID 122 and the business result code 123 in the memory 120.
[0018]
FIG. 3 is a diagram showing the structure of the input telegram 130.
The input message 130 includes an HTTP header 201, a current screen ID 202, an event ID 203, an execution scenario ID 204, input data 205, and "&" 206 connecting each item.
The HTTP header 201 is a header of a message when communicating by HTTP. The current screen ID 202 is the ID of the screen currently displayed on the client 101. The event ID 203 is an ID corresponding to an event that has occurred on the client 101. The execution scenario ID 204 is the ID of the business scenario module 1141 to be executed, and is used when the business process distribution unit 112 determines the business scenario module 1141 to be executed. The input data 205 is data that is input from the client 101 and serves as input for business processing, and each data is connected with “&” 206. Note that the current screen ID 202 and the event ID 203 are generally used in business processing.
[0019]
FIG. 4 is a diagram showing the structure of the output telegram 131.
The output telegram 131 includes an HTTP header 301, a screen layout 302, an output 303 of a business result, and a processing code 304 for an event.
The HTTP header 301 is a header used for HTTP communication. The screen layout 302 is HTML related to the screen layout. The business result output 303 is the HTML of a portion that displays the result of executing the business process. The processing code 304 for the event is a code for executing processing performed on the client 101 when an event such as a button click on the screen occurs.
[0020]
FIG. 5 is a diagram showing the structure of the input data 121.
The input data 121 is a hash table having a pair of a key 401 and a value 402, and includes a current screen ID 403, an event ID 404, and other data 405. The current screen ID 403 is the ID of the screen currently displayed on the client 101, and the event ID 404 is the ID of an event that has occurred on the client 101. Other data 405 is data input from the client 101 and is input data for business processing.
[0021]
FIG. 6 is a diagram showing the structure of the business processing result 117.
The business process result 117 is a hash table having a pair of a key 501 and a value 502. The business processing result 117 includes a business result code 503 and output information 504. The business result code 503 is a code indicating a state of a result of executing the business in the business scenario module 1141. The output information 504 is information for generating the output telegram 131 as a result of the business process.
[0022]
FIG. 7 is a diagram showing the structure of the generation screen determination table 125.
The generation screen determination table 125 is a table in which the scenario ID is taken in the row direction 602 and the business result code is taken in the column direction 601, and the ID of the screen generation module 116 to be executed is set in each column 603.
The generation screen determination table 125 is used when the generation screen control unit 113 determines the screen generation module 116 to be executed.
[0023]
FIG. 8 is a flowchart showing the operation in the above configuration.
Hereinafter, the operation from receiving a request from a client to returning a business process result will be described according to this flowchart.
First, the client 101 generates an input message 130 including the execution scenario ID 204 by the operation of the user 100, and transmits the input message 130 to the Web server 103 via the Internet 102 (step 701). The Web server 103 receives the input electronic message 130 and passes it to the application server 104 (Step 702).
The request receiving unit 111 on the application server 104 receives the input message 130, acquires the execution scenario ID 204 and the input data 205 from the input message 130 (Step 703), and stores the acquired execution scenario ID 204 and the input data 205 in the memory 120. The above execution scenario ID 122 is stored as the input data 121 (step 704).
[0024]
The business process distribution unit 112 acquires the execution scenario ID 122 from the memory 120 (step 705), and determines to distribute the process to the business scenario module 1141 corresponding to the acquired execution scenario ID 122 (step 706). Further, the input data 121 is obtained from the memory 120, and the obtained input data 121 is passed to the business processing module 1141 determined in step 706 and called (step 707).
The called business scenario module 1141 receives the input data 121, executes the business module 1151 necessary for executing the business process, and executes the business process (Step 708).
Further, a business process result 117 is generated, and a business result code 503 which is a code indicating a status of the business process result and output information 504 which is information used when generating the output message 131 are stored in the business process result 117. Then, it returns to the business process distribution unit 112 (step 709).
[0025]
The business process distribution unit 112 receives the business process result 117, acquires the business result code 503 and the output information 504 from the business process result 117 (Step 710), and compares the acquired business result code 503 and the output information 504 with the business process result. The result code 123 and the output information 124 are stored in the memory 120 (step 711).
Next, the generation screen control unit 113 acquires the execution scenario ID 122 and the business result code 123 from the memory 120 (Step 712).
The generation screen control unit 113 refers to the generation screen determination table 125 in the memory 120, refers to the row of the execution scenario ID 122 acquired in step 712, and the column of the business result code 123, and sets the screen generation module set in the corresponding column The ID of the screen generation module 1161 is acquired, and the screen generation module 116 corresponding to the acquired ID of the screen generation module 1161 is executed (step 713).
[0026]
The screen generation module 1161 receives the output information 124 from the memory 120, generates an output telegram 131, and transmits it to the client 101 (Step 714). The client 101 interprets the received output message 131 and displays it in a format that can be browsed by the user 100 (step 715).
[0027]
Next, the operation of the present exemplary embodiment will be specifically described using a simple example of a Web application.
FIG. 9 is a diagram illustrating an example of screen transition of the Web application.
The web application shown in FIG. 9 includes a member information input screen 810, an input content confirmation screen 820, and a member registration screen 830. Screen IDs of the respective screens are G0001, G0002, and G0003, respectively.
The member information input screen 810 is a screen on which the user 100 inputs member information in order to register as a member.
The member information input screen 810 includes an input box for a name 811, a name (kana) 812, a mail address 813, a telephone number 814, and a “register” button 815. When the “register” button 815 is pressed, the screen transitions to an input content confirmation screen 820.
[0028]
The input content confirmation screen 820 is a screen for confirming to the user 100 whether or not the information input by the user 100 on the member information input screen 810 is correct.
The input content confirmation screen 820 includes a name 821, a name (kana) 822, an email address 823, a telephone number 824, a “register” button 825, and a “cancel” button 826 input by the user 100 on the member information input screen 810. You. When the “register” button 825 is pressed, the information input on the member information input screen 810 is stored in the database 106, and the screen transits to a member registration completion screen 830. When the “cancel” button 826 is pressed, the screen returns to the member information input screen 810. At this time, in the input boxes for the name 811, the name (kana) 812, the mail address 813, and the telephone number 814 on the member information input screen 810, the information previously input by the user 100 on the member information input screen 810 is used as an initial value. indicate.
[0029]
The member registration completion screen 830 is a screen that notifies the user 100 that the member registration has been completed. The member registration completion screen 830 includes a registration completion message 831 and a “go to registration screen” button 832.
When the “to registration screen” button 832 is pressed, the screen transits to a member information input screen 810. At this time, input boxes for the name 811, the name (kana) 812, the mail address 813, and the telephone number 814 on the member information input screen 810 are blank.
[0030]
Next, the operation when the “register” button 815 is pressed on the member information input screen 810 of the web application in FIG. 9 will be described with reference to FIGS. 10 to 14 and along the flowchart in FIG.
First, when the user 100 inputs a name 811, a name (kana) 812, an e-mail address 813, and a telephone number 814 on the member information input screen 810 and presses a “register” button 815, the client 101 generates an input message 130. Then, the input electronic message 130 is transmitted to the Web server 103 via the Internet 102.
The input message 130 contains the ID of the business scenario to be executed as the execution scenario ID 204 (in this example, the ID of the business scenario for executing the business of registering the member information = G001).
[0031]
FIG. 10 is a diagram illustrating an example of an input message generated based on information input on the member information input screen 810 in FIG.
An HTTP header 901 is an HTTP header portion including a data transmission method and information of the client 101.
The key of the current screen ID 902 is “C”, and the value is set to the screen ID “G0001” of the member information input screen 810. The event ID 903 has a key “E” and a value “G0001-01”. The execution scenario ID 904 has a key “R” and a value “S0002”.
The input data 905 has items of NAME, KANA_NAME, MAIL, and TEL, whose values are “Hiraoka”, “Hiraoka”, “aaa@xxxxxx.co.jp”, and “045- * 23-4 **”, respectively. 7 ".
[0032]
The Web server 103 receives the input message 130 and passes it to the application server 104.
The request receiving unit 111 on the application server 104 receives the input telegram 130 and acquires the execution scenario ID 904 “S0002” and the input data 905 from the input telegram 130 in FIG. The acquired execution scenario ID 904 “S0002” and the input data are stored in the memory 120 as the execution scenario ID 122 and the input data 121, respectively.
[0033]
FIG. 11 is a diagram illustrating an example of the input data 121.
In this example, the current screen ID 902 is set to 1001, the event ID 903 is set to 1002, and the input data 905 is set to 1003 in FIG.
Next, the business process distribution unit 112 acquires the execution scenario ID 122 “S0002” from the memory 120, and distributes the process to the business scenario module 1141 corresponding to “S0002” on a one-to-one basis. At the time of distribution of this processing, the input data 121 is acquired from the memory 120 and passed to the business processing module 1141.
The business scenario module 1141 of the scenario IDS0002 receives the input data 121, executes one or a plurality of business modules 1151 necessary for executing business processing, and returns a business processing result 117.
[0034]
FIG. 12 is a diagram illustrating an example of the work result 117.
The job result code 1101 shown in FIG. 12 is “0”. For example, suppose that “0” indicates that the task has been completed normally, and if an error occurs during the execution of the task, a value other than “0” corresponding to the occurred error is set as the task result code 1101. The output information 1102 of the business result 117 is information to be output on the input content confirmation screen 820, and the values input to the name 811, the name (kana) 812, the mail address 813, and the telephone number 814 on the member information input screen 810. It is.
Next, the task processing distribution unit 112 receives the task processing result 117, acquires the task result code 1101 “0” and the output information 1102 from the task processing result 117, and acquires the acquired task result code 1101 “0” and the output information. 1102 are stored in the memory 120 as a work result code 123 and output information 124, respectively.
[0035]
FIG. 13 is a diagram showing an example of the generation screen determination table 125.
The generation screen control unit 113 acquires the execution scenario ID 122 “S0002” and the task result code 123 “0” from the memory 120, and determines the screen generation module to be executed with reference to the generation screen determination table 125.
For example, when the generation screen determination table 125 is as shown in FIG. 13, the generation screen control unit 113 refers to the generation screen determination table 125, and sets the column 1201 corresponding to the execution scenario ID “S0002” and the business result code “ With reference to the row 1202 corresponding to “0”, P0002 set in the corresponding column 1203 is acquired. Then, the screen generation module 1161 (one of screen generations 1 to M) corresponding to P0002 is executed.
[0036]
Next, the screen generation module 1161 acquires the output information 124 (contents of 1102 in FIG. 12) from the memory 120, generates an output telegram 130, and transmits the output telegram 130 to the client 101. The client 101 receives the output message 131 and presents the input content confirmation screen 820 of FIG. 9 to the user 100.
[0037]
FIG. 14 is a diagram illustrating an example of the output telegram 130.
An HTTP header 1301 is a header for communication using HTTP. The screen layout 1302 is HTML for displaying the input content confirmation screen 820. The job result output 1303 is HTML that displays the result of the job, and embeds information that is displayed on the screen by the user 100 on the member registration input screen 810 and information to be transmitted as the input message 130 in the next event. Part. The processing code 1304 for the event is a code describing a process of generating the input message 130 including the execution scenario ID 204 and transmitting the input message 130 to the Web server 103 when the “register” button 825 and the “cancel” button 826 are pressed. ing.
[0038]
Here, a method of embedding the execution scenario ID 204 in the input message 130 will be described.
When the “register” button 825 is pressed, an onClick event 1305 of the “register” button 825 is generated. In the onClick event 1305, a performEvent function 1306 is called with “G0002-01” 1307 and “S0003” 1308 as arguments.
The performEvent function, when called, has a function of embedding an event ID and an execution scenario ID in an input message and transmitting the input message to a server.
In the performEvent function 1306, the received first argument “G0002-01” is set as an event ID in “E” 1309 of the hidden field. Further, the second argument “S0003” is set as the execution scenario ID in “R” 1310 of the hidden field. Finally, a submit 1311 is executed, and the input electronic message 130 is transmitted to the Web server 103. As described above, the client 101 embeds the event ID 203 and the execution scenario ID 204 in the input telegram 130.
[0039]
FIGS. 15 and 16 are diagrams showing a method of designing an argument of the performEvent function 1306. FIG.
Specifically, this is an example of the design of the input content confirmation screen 820.
First, an event that occurs on the screen is designed, and an event list 1401 is created as a list of events. The event list 1401 is created for each screen generation module 1161. Next, an input message 130 to be transmitted from the client 101 to the Web server 103 when an event occurs is designed, and an item transmission specification 1402 is created. The item transmission specification 1402 describes the execution scenario ID 204 and the input data 205 of the input electronic message 130 to be transmitted. The item transmission specification 1402 is created for each event entered in the event list 1401.
For example, in the case of the input content confirmation screen 820, the event ID “G0002-01” 1103 of the item transmission specification 1402 is set in the first argument 1307 of the performEvent function 1306 when the “register” button 825 is pressed. In the second argument 1308, the execution scenario ID “S0003” 1404 of the item transmission specification 1402 is set.
With such a design, individual screens can be independently designed and mounted even if the entire screen transition is not visible.
[0040]
【The invention's effect】
As described above, according to the present invention, it is not necessary to associate a module that receives a request from a client with a module that performs business processing or a module that outputs a screen. Therefore, at least one module that accepts a request can be mounted on the system, and the restriction on the number of modules that accept a request is relaxed. As a result, even if the number of screens increases, the number of modules that accept requests does not increase, and it is possible to prevent an increase in resource consumption that occurs in the individual scheme, that is, deterioration in performance. Further, it is possible to prevent an increase in coding man-hours and management man-hours due to an increase in modules for receiving requests.
Further, according to the present invention, there is no need for a screen transition definition file that defines screen transition information necessary for an engine system as in the related art to determine a task processing module to be executed. As a result, the man-hours required for designing and implementing the screen transition definition file can be reduced. Furthermore, even if the entire screen transition is not visible, since the screen transition can be independently developed from the determined place, efficient development becomes possible.
[Brief description of the drawings]
FIG. 1 is a configuration diagram illustrating an embodiment of a network system to which the present invention is applied.
FIG. 2 is a configuration diagram showing an embodiment of a business processing program control device according to the present invention.
FIG. 3 is a diagram showing an example of an input telegram;
FIG. 4 is a diagram illustrating an example of an output telegram;
FIG. 5 is a diagram illustrating an example of input data.
FIG. 6 is a diagram illustrating an example of a business process result.
FIG. 7 is a diagram illustrating an example of a generation screen determination table.
FIG. 8 is a flowchart showing the operation of the embodiment of the present invention.
FIG. 9 is a diagram illustrating an example of screen transition of a Web application.
FIG. 10 is a diagram showing a specific example of an input telegram;
FIG. 11 is a diagram showing a specific example of input data.
FIG. 12 is a diagram illustrating a specific example of a business process result.
FIG. 13 is a diagram illustrating a specific example of a generation screen determination table.
FIG. 14 is a diagram illustrating a specific example of an output telegram;
FIG. 15 is a diagram illustrating a method of designing an argument of a performEvent function.
FIG. 16 is a diagram illustrating a method for designing an argument of a performEvent function.
FIG. 17 is a diagram showing an individual system which is one of the prior arts.
FIG. 18 is a diagram showing an engine system which is one of the prior arts.
[Explanation of symbols]
101: client, 102: Internet, 103: Web server,
104: Application server, 105: Database server, 106: Database, 107: Web application, 110: Processing program control device, 111: Request receiving unit, 112: Business process distribution unit, 113: Generation screen control unit, 114: Business Scenario module, 115: Multiple business modules, 116: Screen generation module, 117: Business result, 120: Memory, 121: Input data, 122: Execution scenario ID, 123: Business result code, 124: Output information, 125: Generation Screen determination table, 130 ... input message, 131 ... output message.

Claims (5)

A Web application control device for allocating a business process according to a request content from a client to one of a plurality of business process modules prepared in advance and returning a processing result to a requesting client,
Request receiving means for receiving a request including identification information of a business process to be executed together with data to be processed from the client;
A business process allocation unit that allocates a process to a business process module corresponding to the received identification information of the business process, and obtains a process result;
A generation screen control unit that allocates a screen generation process of a processing result to one of a plurality of screen generation modules based on the identification information and a processing result of the business processing module;
A web application control apparatus, comprising: a screen generating unit configured to generate screen data of a sorted processing result and output the screen data as a response to a requesting client; A plurality of business scenario modules each describing a scenario for performing a different business process using the plurality of business process modules, wherein the business process distribution means includes an identification corresponding to the business scenario module as identification information of the business process. The Web application control device according to claim 1, wherein information is received from a client, and processing is distributed to a business scenario module corresponding to the received identification information. In a network system including a client that transmits a business processing request and an application server that receives the business processing request via a network, executes a business process according to the request content, and returns a processing result to the requesting client,
The client has means for transmitting a request including identification information of a business process to be executed together with data to be processed,
The application server,
Request receiving means for receiving a request including identification information of a business process to be executed together with data to be processed from the client;
A business process allocation unit that allocates a process to a business process module corresponding to the identification information of the business process received from the client among a plurality of business process modules prepared in advance, and obtains a process result;
A generation screen control unit that allocates a screen generation process of a processing result to one of a plurality of screen generation modules based on the identification information and a processing result of the business processing module;
A network system comprising: a screen generating unit configured to generate screen data of a sorted processing result and output the screen data as a response to a requesting client; The application server further includes a plurality of business scenario modules each describing a scenario for performing a different business process using the plurality of business process modules, and the business process distribution unit includes the business process as identification information of the business process. 4. The network system according to claim 3, wherein identification information corresponding to the scenario module is received from a client, and processing is distributed to a business scenario module corresponding to the received identification information. A Web application control program for allocating a business process according to a request content from a client to one of a plurality of business process modules prepared in advance, and returning a processing result to a requesting client,
A request receiving step of receiving a request including identification information of a business process to be executed together with data to be processed from the client;
A business process allocation step of allocating a process to a business process module corresponding to the received identification information of the business process, and acquiring a process result;
A generation screen control step of allocating a screen generation process of a processing result to one of a plurality of screen generation modules based on the identification information and a processing result of the business processing module;
A screen generation step of generating screen data of the sorted processing result and outputting the screen data as a response to the requesting client.

Images