JPH09282152A - Communication module generation device and communication information file design device - Google Patents

Abstract

(57) [Abstract] [Problem] A communication module which generates a routine process of a communication part of an application module used for communication to improve development efficiency and facilitates work in maintenance and debugging of transaction formats and screen program information. Obtain a generation device and a communication information file design device. SOLUTION: A fixed-form communication that recognizes the transaction format from a communication information file that defines the format of an upstream message and a downstream message as transaction data and screen definition information that defines the definition and behavior of window parts and performs mutual communication. A communication function generating means for generating a function and a communication processing generating means for generating a communication processing are provided. Further, a communication information file generating means for generating a communication information file in cooperation with the screen definition information is provided.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a communication module generation device and communication information file used in a distributed application communication control system for communicating a message between a plurality of information processing devices connected by a network to realize one function. The present invention relates to a design device.

[0002]

2. Description of the Related Art A client-server type will be described as an example of a distributed application communication control system. In the conventional client-server type application, processing that can be performed on the client side is performed by the client application program (also called client application or client program) on the client, and processing that cannot be performed on the client side is performed by the server application program (server application, server) on the server. (Also called a program) is generally performed by making a request. The reason why processing cannot be performed on the client side is that there is a performance problem with the hardware and software on the client side, there is a limit to building large-scale data on the client side from the viewpoint of maintenance and cost, and high-speed batch form output. And so on. A client-server system system is a method in which a powerful machine such as a server takes over the most effective part of the processing on the client side.

In this system, the client machine and the server machine are connected by a certain communication path,
It is performed in the form of a request (or transaction) from the client to the server. A transaction is input / output data between a server and a client. The data transmitted and received by a transaction is called a message. A message sent from the client to the server is called an up message, and a message sent from the server to the client is called a down message. When the client program wants to use the service provided by the server, it communicates the upstream message in the form of a request from the client to the server. The upstream message is composed of a request code for recognizing the service provided by the server and data necessary for the server to execute the service.

On the server, the server program has already been started for the client application and is waiting for the arrival of the upstream message from the client.
When the upstream message arrives, the server program recognizes the request code and executes the required service. At this time, the data in the message that arrived as the upstream message is used. A message is usually composed of a plurality of items, for example, a sequence of divided different data types such as a product code and a date. The processing of the content of the upstream message is determined for each request code. For example, if the request code is “03”, the processing content is a search of the product master database, and the upstream message data has the product code. There is an agreement such as.

Further, in a general client-server system, client applications are distributed to a plurality of terminals, and one server program on the server collectively provides services. However, with this method, it is difficult to provide uniform services to all clients, and it is extremely difficult to develop a server program that meets the requirements of all client programs.

As another client-server type system, there is a method of preparing one dedicated server program for one client application. With this method, since the relationship between the client and the server is always one-to-one, the client program and server side program development is relatively simpler than the method described above. The disadvantage is that when the number of terminals increases, the server programs as many as the number of clients are loaded and executed on the server, which increases the load on the server.

In order to suppress an increase in the load on the server side,
In transaction processing systems, etc., a method of starting a program by starting a transaction is adopted. The upstream message is received once by the transaction processing system, the content is analyzed, the request code is determined, and then the corresponding program is activated to provide the service. Such a transaction processing system is generally used in a large-scale system, and is rarely used in a medium-scale or small-scale system because its operation is complicated.

As described above, the client-server type has various forms and has a wide range of applications. In particular, it is a system form that has been frequently used recently because of the ability to distribute the load and the ability to share the calculations and processing in the fields of which the client and server machines are good. However, since one process is divided into the client side and the server side, application design and development are difficult, and methods such as debugging and maintenance have not yet been established.

FIG. 38 is a diagram showing an example of communication by a client communication object of a client-server type development environment HYPERPRODUCE developed by Mitsubishi Electric Corporation. In the figure, 901 is a client, 902 is a server, and 9
Reference numeral 03 is a client application running on the client 901, and 904 is a server application running on the server 902. Further, 908 is a communication information file, 909 is a client communication object, 9
Reference numeral 30 is a database connected to the server 902.
963 is a transaction format creation tool, 96
Reference numeral 4 is a communication driver, and 965 is a server communication object.

First, the client-server type communication will be described with reference to FIG. Design each transaction format in the communication between the server side and the client side in advance with the transaction format creation tool,
It is recorded in a transaction format file (not shown).
The client application 903 and the server application 9 using the communication information file 908 defined based on the recorded transaction design information.
04 communicates. Client application 90
Client communication object 909 inside 3
Creates an upstream message based on this communication information file 908, communicates with the server application, and converts the character code if necessary. On the server application side, the server communication object 9
The server application 904 incorporating 65 is started in advance. The upstream message including the request from the client application 903 is captured by the server application 904 using the interface of the server communication object 965 of the corresponding server application 904. The transaction data in the captured upstream message is data for processing, and is used as data for updating the database or printing data on a book. When the processing of the server application for the upstream message is completed, the return data of the transaction is returned to the client application as a downstream message via the communication object, if necessary. FIG. 39 is a diagram showing an example of the communication information file. As shown in FIG. 39, the communication information file is composed of a combination of request code 911, upstream transaction 933, and downstream transaction 934. As described above, if the request code is “03”, the processing content is a database search, and the upstream transaction 933 has a “product code”, and the product code is used to search and search the database. As a result, it is described that the obtained product name is transmitted as the down transaction 934. FIG. 40 shows a transaction flow when this processing is performed. As described above, according to the contents defined in the communication information file, the program for performing the transaction is described in the client and the server, and operated as one system.

The problem in this method is the interface of the communication part of the server application and the client application and its program description.
Since the transaction format of communication is created in advance by the transaction format creation tool, the communication program will be created according to the created transaction format. On the client side, it is necessary to write a communication logic description to drive the client communication object for communication, and on the server side, a communication logic description to use the communication library is required. Was.

In the case of such a system, when the transaction between the client program and the server program is changed, it is necessary to make both the client program and the server program consistent and modify the programs respectively.

Further, the information of the normal transaction is often intimately entangled with the design information of the screen, and the item information of the screen and the item information of the transaction have a very high probability of matching, and the matching of them is matched. There is also a need. For example, if a transaction item is described as a numeric type of 8 bytes, it is necessary to specify the item area to be output to the screen as the same numeric type of 8 bytes. In the conventional method, these are the transaction type and the screen item. This setting is done in two places,
The task of achieving consistency often became more difficult as the number of items increased.

[0014]

In the conventional client-server type system form, the client program and the server program are often constructed separately, and in that case, a transaction format which is an interface portion between the client program and the server program. After deciding on, it was common to design each program. However, if the screen is designed after deciding the transaction format, the screen image is difficult to grasp. Also, if you modify the screen image,
It was necessary to redefine the transaction corresponding to the corrected screen image. Further, there is a fixed process for communication in both the client program and the server program, and it has been desired to realize a communication module generation device that generates a fixed process part corresponding to an image on a screen.

The present invention has been made in order to solve the above problems, and generates a communication part for communicating with the server program and a routine processing part of the server program from the screen image of the client program. Thus, it is an object of the present invention to shorten the development time of a client-server type program and realize a communication module generation device that generates a program in which both the server and the client cooperate.

Another object of the present invention is to realize a communication information file generating device for generating a communication information file defining a transaction format used for communication while looking at the client program screen.

[0017]

A communication module generation apparatus according to the present invention is a communication module generation apparatus for connecting a first information processing apparatus and a second information processing apparatus to generate a communication module for performing communication processing. The following features are provided. (A) A first communication module including a communication processing unit that performs a communication process on the first information processing apparatus, and (b) a screen including screen items on the second information processing apparatus. And a second communication module that performs a communication process with the first communication module by a predetermined communication function, (c) a screen that stores screen definition information that defines screen items that configure the screen of the second communication module. Definition information storage means,
(D) A communication information file storing communication information defining communication items used for communication between the first communication module and the second communication module, corresponding to the screen definition information, (e) the communication information file Communication function generating means for generating the communication function of the second communication module, and (f) communication processing generating means for generating the communication processing section of the first communication module by referring to the communication information file.

The communication module generation device further comprises:
It is characterized in that comment adding means is provided for taking in the communication information of the communication information file as a comment and adding the comment to at least one of the communication function and the communication processing unit.

The communication module generation device further comprises:
It is characterized by further comprising communication information file generation means for generating the communication information file by referring to the screen definition information stored in the screen definition information storage means.

The screen composed of the above screen items is Wi
Windows (US Microsoft Corporation)
windows supported by
The screen definition information storage means is characterized in that the screen item is defined and stored as a window component forming the window.

The communication information file designing apparatus according to the present invention is characterized by including the following elements. (A) a first communication module including a communication processing unit that performs communication processing on the first information processing device; and (b) a screen configured of screen items on the second information processing device and a predetermined A second communication module that performs a communication process with the first communication module by the communication function of (c) a screen definition that stores screen definition information that defines screen items that configure the screen of the second communication module in advance. Information storage means, (d) a communication information file for storing communication information defining communication items used for communication between the first communication module and the second communication module, corresponding to the screen definition information, (e) Communication information file generating means for generating the communication information file by referring to the screen definition information stored in the screen definition information storage means.

The screen definition information storage means stores the attribute of the screen item in association with the screen item, and the communication information file designing apparatus further refers to the attribute of the screen item to add the communication information to the communication information. It is characterized in that a determination means for determining the validity of the defined communication item is provided.

The communication information file defines an upstream transaction transmitted from the second communication module to the first communication module as the communication information, and the attribute of the screen item is input / output of the screen item. And the determination means determines the communication item by using the input / output attribute of the screen item corresponding to the communication item that constitutes the transmission transaction.

The screen definition information storage means stores the number of elements that define the repetition of the screen item, and the communication information file generation means defines the communication item using the number of elements.

In the communication information file, a request code corresponding to the communication information is stored in combination with the communication information, and the communication information file designing device further comprises:
It is characterized by comprising special display means for specially displaying a screen item corresponding to a communication item constituting communication information corresponding to the request code.

The special display means is characterized in that the screen items are selectively displayed specially according to predetermined conditions.

The communication information file designing device is characterized by further comprising a verification means for verifying the correspondence between the communication item and the screen item and displaying the verification result.

[0028]

BEST MODE FOR CARRYING OUT THE INVENTION

Embodiment 1. In the following embodiments, a client-server system will be described as an example. FIG. 1 is a diagram showing a communication module generation device of the present invention. The communication module generation device of the present invention performs a process of generating a source file of a client-side application communication function and a fixed-form processing partial source file related to server-side communication from screen information of a client-side application. In the figure, 1 is a client machine, 2 is a server machine, 3 is a client application, 4 is a server application, 6 is a communication function of a client side application generated by a communication module generation device, and 7 is generated by a communication module generation device. A file of a communication processing unit which is a fixed part for communication of server side application, 8 is a communication information file stored in advance, 9 is a communication component on the client screen, 10 is an input / output component on the client screen, and 11 is a communication information file. Is the request code stored in.
Reference numeral 100 denotes a screen definition information storage unit including input / output parts. Further, 110 is a communication function generating means for generating a communication function, and 112 is a communication processing unit 7 of the server application.
Is a communication processing generation unit, 114 is a comment addition unit, 116 is a communication information file generation unit that generates the communication information file 8, 118 is a determination unit, 120 is a special display unit, and 122 is a verification unit.

Next, the overall operation will be described with reference to FIG. The communication function generation means 110 refers to the communication information file 8 that defines the communication rules of the client application 3 and the server application 4 by using the communication component 9, the input / output component 10, and the request code 11 on the client application 3, and the client application 3 generates the source code of the communication function 6 of the client side application which associates the communication component 9 with the input / output component 10 and the request code 11 on the client 3. further,
The communication processing generation means 112 generates on the client machine 1 the file 7 of the communication processing unit relating to communication with the client application, which is a routine process in the server side application. The application developer transfers the generated file 7 of the communication processing unit to the server machine 2 and then adds a necessary code to develop the server application.

FIG. 2 is a schematic view of an operation screen of the communication module generation device. In the figure, 12 is a main screen of the communication module generation device, 13 is a request code input area, and 14 is an upstream transaction design area, while designing an upstream transaction that defines communication items from the client application to the server application, Display the image. Reference numeral 15 denotes a downlink transaction design area, which displays an image of the designed downlink transaction while designing a downlink transaction that defines communication items from the server application to the client application. 16 is an add button. By pressing this,
The request code designated in the request code input area 13, the upstream transaction format designed in the upstream transaction design area 14 and the downstream transaction format designed in the downstream transaction design area 15 are added to the communication information file 8. The addition of the transaction format to the communication information file 8 is performed by the communication information file generating means 116. 17, 18, 1
9 is a menu item. 3 is a pull-down menu of the menu item 17 shown in FIG. 2, 20 is a "new creation" menu for newly creating a module, 21
Is an "open" menu for reading the already generated module, and 22 is a menu for designating "end" of the apparatus.
FIG. 4 is a pull-down menu of the menu items shown in 18 of FIG. 2, and 23 is an item for executing "generation" of the code. FIG. 5 is a pop-up window when 23 of FIG. 4 is selected. 24 is a server file name input area for inputting the file name of the server module, and 25 is a client file name input for inputting the file name of the communication module of the client. Area, 26 is a button for execution.

FIG. 6 is a diagram showing a client screen 27 displayed by the client application 3 shown in FIG. In this embodiment, it is assumed that the client screen is defined using Visual Basic. Visual Basic is the US Micr
Micr, a trademark of Soft Corporation
Microsoft is Microsoft Corporation of the United States
ation is a registered trademark. In FIG. 6, 131 to 136 and 140 to 146 are labels used only for the purpose of displaying on the screen, and 231-23.
The boxes 6 and 240 to 246 indicate input / output parts which are items used for input / output.
This label and input / output parts are compatible with Windows (US Mi
A window component corresponding to Microsoft Corporation) and inherits the definition and behavior of the window component.

The operation of the communication information file generation screen will be described with reference to FIGS. 2 is started with the client screen 27 shown in FIG. 6 being displayed, and a predetermined request code is entered in the request code input area 13, and 14, 15
Design upstream transactions and downstream transactions in the design area. (Client screen 27
The procedure for designing a transaction from 1 to 3 will be described in detail in the third embodiment. ) When the design is completed, the add button 16 is pressed. As described above, it is possible to define a plurality of combinations of request codes, upstream transactions, and downstream transactions in the communication information file.
The screens 4 and 15 are cleared, and the design is ready again. After the necessary design is completed, generate the communication module code. The code of the communication module is generated by selecting 23 in FIG. In FIG. 5, the server file name is input to the server file name input area 24, and the client file name is input to the client file name input area 25, and a button 26 for executing the command is pressed. The function 6 is generated, and the server-side source file is generated by the communication processing generation means.

FIG. 7 is a block diagram of the client-side application communication function 6. In the figure, 11 is a request code, 28 is a communication component input buffer, 29 is a communication component output buffer, 30 is data input to an input / output component, and 31 is data output to an input / output component.
In the communication component 9, the data substituted in the input buffer 28 is communicated to the server application as an upstream transaction, and the result processed by the server application is substituted in the output buffer 29. The data in the input buffer 28 is also called upstream data, and the data in the output buffer 29 is also called downstream data. Figure 2 shows the format of the input buffer for communication.
2 is designated by the upstream transaction design area 14 and the format of the output buffer is designated by the downstream transaction of FIG. Each item of the upstream transaction and the downstream transaction corresponds to one of the window parts which are the screen items constituting the screen displayed by the client application. This will be described in detail in the third embodiment.

FIG. 8 is a flow chart of the operation of the client side application communication function. FIG. 9 is a diagram showing a source code of a communication function generated by the communication function generating means. FIG. 10 is a diagram showing the format of the communication information file. As shown in FIG. 10, the communication information file includes an index section 301 and a data section 302.
The index unit 301 is composed of a plurality of index information 303.
One index information 303 has a request code 304,
An upstream message pointer 305 that points to the storage position of the upstream message, a downstream message pointer 306 that points to the storage position of the downstream message, an upstream block number 307 that is the number of blocks of the upstream message, a downstream block number 308 that is the number of blocks of the downstream message, etc. I remember. The upstream message definition information 310 stores a block length 311, the number of items 312, and item information 313 and 314. Similarly, the downlink message definition information 320 includes block length 321, item number 322, item information 323, 3
Remember 24.

A description will be given according to the flow chart of FIG. In S1, the request code 11 is specified as the attribute of the communication component 9,
In S2, the number NU of items of upstream transactions is obtained. The number of items NU of the upstream transaction is the number of items 3 shown in FIG.
12 obtained. This is the same as the number of items in the input buffer of the communication component 9. In S3 to S6, for all items from the 0th item to the NU-1st item of the upstream transaction, the data assigned to the window component on the client screen that matches the transaction item is the item in the buffer of the input component of the communication component. To create upstream data. In step S7, communication with the server is performed and downlink data is obtained in the output buffer of the communication component 9. In S8, the number of items ND of the downlink transaction is obtained. The item number ND of the downlink transaction can be obtained by referring to the item number 322 shown in FIG. In S9 to S12, for all items from the 0th item to the ND-1th item of the downstream transaction, the item data of the output buffer is substituted into the window component on the client screen that matches the transaction item.

As described above, the communication function generating means is shown in FIG.
According to the flow chart shown in FIG. 5, a client-side application communication function that performs processing of setting data in the input buffer of the communication component 9 and setting data in the input / output component of the output buffer is generated.

FIG. 11 is a flow chart showing the flow of server application processing. The part 32 is a part of routine processing in the server application. In the server application, when the program is started, the preparation for accepting the request from the client is initialized (S13).
Do with. In step S14, the process is sorted by the request code 11 upon receiving the upstream transaction from the client. If the request code is terminated, the server application termination processing shown in S15 is performed. If the request code is an error, error processing (S16) is performed. In other cases, the processing corresponding to each request code is performed in S17. Sends a down message to the client program in S18. Since the processing corresponding to each request code is unique to the application,
That part is an atypical process and is outside the generation target of the communication process generation means.

12 and 13 show sample lists of server applications. The sample programs shown in FIGS. 12 and 13 are coded in a language called progress II. In FIG. 12, reference numeral 350 is a part for connecting with the client program. Reference numeral 352 is a portion for receiving an upstream message from the client application. Reference numeral 354 is a portion for allocating the processing according to the request code. Reference numeral 356 is a part that describes a process of returning a result. In addition, 358 and 3 shown in FIG.
Reference numerals 62, 366 and 370 are descriptions indicating that it is necessary to create a subroutine for processing corresponding to the request code. Reference numerals 357, 361, 365, and 369 are comment statements described in Embodiment 2 described later. Also, 360,
Reference numerals 364 and 368 indicate positions of subroutines that are outside the generation target of the communication processing generation means and need to be coded later. The sample program of the server application shown in FIGS. 12 and 13 is for explaining the structure of the server application, and does not perform the processing corresponding to the client screen shown in this embodiment. Further, the present invention may be applied to a server application coded in a language other than Progress II.

FIG. 14 shows a flow chart of the source code generation of the server side routine processing part. First, in S19, the information in the communication information file is analyzed, and the connection process with the client program (corresponding to 350 in FIG. 12) is described in the source file based on the analyzed information (S20). Next, S2
In step 1, an upstream message reception process (corresponding to 352 in FIG. 12) that is a connection with the client application is added to the source file, and in S22, a part of the distribution process for each request code (corresponding to 354 in FIG. 12) is a loop statement. Add the one described in to the source file. In this case, the request code is an end code that is predetermined for all those in the communication information file, and any other code is regarded as an error. Next, in S23, the process of returning the result to the client application (corresponding to 356 in FIG. 12) is added to the source file, and in S24, the disconnection process with the client program (not shown) is added to the source file. Next, in S25, as a subroutine process, the entrance of the process for each request code (35 in FIG. 13).
9, 363, 367), a subroutine for performing termination processing (corresponding to 367 in FIG. 13) and a subroutine for performing error processing (corresponding to 371 in FIG. 13) are described in the source file.

As described above, by automatically generating the source program of the routine processing part, the application developer can generate the program by only describing the source program of the original part for the server side application. . In this embodiment, the client application and the server application are software, and the communication function generating means and the communication processing generating means generate the source code. However, the same function is realized by hardware. It may be configured. Alternatively, it may be configured to generate firmware. Moreover, you may implement combining these.

Embodiment 2 In the present embodiment, an example will be described in which a comment sentence is added in the communication processing partial source program generation which is the routine processing of the server application described in the first embodiment. Also, in the communication function generation of the client application,
The case of adding a comment sentence is also described. Since the basic processing is the same as that of the first embodiment, only the parts different from the first embodiment will be described.

By inserting a comment in the source program, the programmer can easily understand and the maintainability of the source program is improved. In the generation of the client-side communication function, the item name, the data type, and the length of the upstream transaction item of the communication component 9 are described as a comment statement at the time of the process of S4 of FIG. 150 of FIG.
Indicates the comment text of the upstream transaction. Similarly, in S10 of FIG. 8, the item name, the data type, and the length of the item of the downlink transaction are described as a comment statement as shown in 151 of FIG. Further, by generating the comment of the request code when adding the code for communication in S7, the readability as a communication function is improved. In the routine processing partial source program generation of the server application, S19 to S in FIG.
A comment sentence is inserted in each of 25. FIG.
349 is a comment part corresponding to S20 of FIG. Similarly, 351 to S21, 353 to S22, 3
55 is a comment sentence corresponding to S23, respectively. Further, 357, 361, 365 and 369 in FIG.
It is a comment sentence corresponding to S25 of 4.

By thus inserting the comment sentence, it becomes easy to grasp the flow of the program. Further, the distinction between the routine processing portion and the non-routine processing portion becomes clear, and even when the program is modified or changed, the modified portion is easy to understand and the development efficiency is improved.

Embodiment 3. In the present embodiment, first,
The format of the communication information file which is the communication rule for the server application and the client application to operate in cooperation with each other will be described. In addition, in this embodiment, the screen items that configure the screen displayed by the application are window components that configure the window,
Microsoft Vis made by Microsoft Corporation
A case where screen definition is performed using dual Basic will be described.

FIG. 15 shows the structure of the communication information file. Reference numeral 33 is an upstream transaction designed in 14 of FIG. 2, and 34 is a downstream transaction designed in 15 of FIG. It is necessary to specify the upstream transaction and the downstream transaction as a pair with respect to one request code, and normally, the communication information file is a file including one or a plurality of paired information.

16 and 17 are diagrams showing the correspondence between screen items displayed on the screen of the client application and each item of the upstream transaction and the downstream transaction. 16 and 17 show that the format used for the screen item of each item of the upstream transaction and the downstream transaction is designed from the attribute of the window component of the client screen. A transaction is divided into one or more items, and information of each item includes an item name, a data type, a data length, and the like.
In FIG. 16, the first item of the upstream transaction has an item name of FLDKNUM, a data type of 9 types indicating a numerical value, and a length (data length) of 8. This is an input / output component 23 that can input up to 8 bytes that handles 9 types of data with the name FLDKNUM on the client screen 6.
It is designed from the attributes of 1.

18 and 19 are views showing a part of the definition information of the screen items of the client screen 6 shown in FIG. In the figure, reference numerals 152 and 160 to 164 represent the types of window parts. Reference numeral 152 denotes a label, and the name of the window component (Label) corresponding to the member number 131 on the client screen 6 is as shown in FIG.
153 Label1 shown in FIG. As shown in 154, this window component called Label1 indicates that the characters "membership number" are displayed.
FldBoxes 160 to 164 shown in FIG. 19 represent window types called single item input / output components. The window name corresponding to the screen item 231 of the client screen 6 is FLDKNUM172, and 174 is FLDK.
It indicates that the NUM 172 is a window component having a length of 8 bytes that handles 9 type data. Similarly,
Items are also defined for the screen items 233 and 235, and the upward transaction definition of the communication information file is made using this definition information. That is, the attribute of the screen item 231 becomes the attribute of the upstream transaction communication item 380, and the attribute of the screen items 233 and 235 is designed as the attribute of the communication items 382 and 384. Similarly, using the attributes of the screen items 232, 234, 236, the communication items 390, 392, 3 of the downlink transaction shown in FIG.
Each of the 94 attributes is designed.

As described above, by defining the screen item of the client screen by using the window component corresponding to Windows, the screen is designed by using the attribute prepared in advance in the system (Windows) as the window component. Alternatively, it is possible to define communication items corresponding to the screen items that form the screen. This eliminates the need for the application designer to design each attribute of each item that configures the screen, and also eliminates the need to set rules for design. The method of retaining the attributes of window parts varies slightly depending on the type of window part.When designing the items of a transaction, you can design each item of the transaction from the attributes of the window part, or from the client screen to specify the communication function from the transaction information designed. When creating, it is necessary to consider what kind of window part is. Further, the tabular input / output parts to be described later are also required to determine whether or not the input / output parts are input / output parts. Further, the window component information can be used in the case of reusing the communication information file described later. Therefore, it is effective to add the type of window component as the information stored in the communication information file.

Next, the communication information file generating means for generating the communication information file will be described.

FIG. 20 shows a state in which a transaction design is performed using the communication information file generating means by dragging the window component of the client screen 6 with the mouse and dropping it in the upstream transaction design area 14. There is. Reference numeral 231 is a window component on the client screen for setting the attribute of the transaction item, and 36 is a rectangle indicating that the window component is being dragged. FIG. 21 shows a flowchart of the transaction design process by the communication information file generating means. In S26, the request code is designated in 13 of FIG. In S27, the window component 231 is selected from the client screen, and in S28, it is determined whether or not it is an input / output component. Whether or not it is an input / output component is determined by looking at the type of component selected in S27. For example, FldB
ox is an input / output component. Further, in the case of a button control for accepting a mouse click, since it is not an input / output component, the window component is not selected without dragging in S29, and the process returns to S27 again. If it is determined in S28 that the component is an input / output component,
The component is dragged and displayed in a state of being distinguished from other window components such as the window component 231 on the client screen 6. When the mouse is moved in the dragged state, when the mouse cursor is inside the main screen 12, a rectangle such as 36 is displayed and moves together with the mouse cursor. If you drop a rectangle on the window of 14 or 15, after checking S31 and S32,
In S33, the transaction item is set. S3
The processing of 1 and S32 will be described in the fourth embodiment. The type of window component, the item name, the item name, the type of data to be handled, and the maximum length of data are set in the transaction item, and the display is updated. The item name and the item name are set to be the same as the name of the window component, and the type of data to be handled and the maximum length of the data are set to the type of the window component and information obtained from each attribute. For example, as described above, for the item name of 380, the item name of the window component 231 is obtained by referring to 172 of FIG. However, regarding the types of window parts and item names,
Not displayed on 4 and 15. When designing items continuously, the process returns from S34 to S27. When it is confirmed that both the upstream transaction and the downstream transaction are designed, the process proceeds to S35, and in the case of designing the transaction for another request code,
The process returns to S26.

The position where the window component is dropped is 1
If you drop it on any item already set, you can insert the newly designed item before that item and drop it on the right side of all already set items. If you do, a new item will be added.

As described above, according to the communication information file generating means of the present invention, the transaction item is designed and designed by dragging the window component on the client screen and dropping it on the transaction design area. By displaying on the screen and confirming it, it is possible to interactively design a transaction that matches the client screen by only operating the mouse.

Embodiment 4 In the present embodiment, when designing a transaction format from the input / output components described in the third embodiment, a determination means for performing an error check based on the types and attributes of the input / output components and the transaction types will be described.

FIG. 22 shows an example of attributes of input / output parts. The input / output parts have attributes common to other window parts and attributes unique to the parts. In the case of the example in FIG. 22, as common attributes, individual attributes of parts such as the background color of 37,
There are attributes associated with other parts, such as the 38 tab order. Next, as attributes unique to the part, there are, for example, a window attribute 40 for setting the type and length of data to be handled, an input / output type 41, and other unique attributes 42. The input / output type 41 selects input / output capable of data input from a keyboard and output by a program, and output-only capable of output only by a program. Other unique attributes 42 include attributes relating to edit display, such as displaying 1000 as ¥ 1,000 when outputting numerical data.

The upstream transaction is a communication from the client application to the server application, and is for sending the data input on the client screen to the server. The input / output component for which the output only is set in 41 cannot be input from the keyboard on the client screen, and is therefore inappropriate as a component for upstream transactions. Also, for the same reason, like the label control, it does not accept input from the keyboard,
A component prepared only for output is also inappropriate as a component for upstream transactions. Therefore,
When an input / output component is dropped on the upstream transaction design area, it is necessary to check whether the transaction can be designed from that component.

FIG. 23 shows a flowchart of the error check performed by the judging means when setting the item. If an input / output component is dropped in the upstream transaction design area, the type of component is checked in S36. If the type of component is label control, it is determined that it is not appropriate as an item for upstream transactions because it is for output only.
In addition, the text control has no attribute related to the input / output type, so it is determined to be appropriate. HPCFLD.VBX, HPCF
IELD.VBX is a single-item input / output component and has the characteristics shown in FIG. In this case, it is determined to be inappropriate when the output only is set in the input / output type attribute in S37. HPCSHT.VBX is a tabular input / output component with repeating items, and attributes are set for each column. If output-only is set in the input / output type attribute of all columns, keyboard data cannot be input to any item on the part, so it is determined to be inappropriate as an upstream transaction item. To do.

As described above, the determination unit checks the error based on the transaction type and the type / attribute of the input / output component at the time of designing the transaction, thereby preventing a correct transaction from being designed and sending meaningless data to the server application. It is also effective for improving application development efficiency and effective communication efficiency.

Embodiment 5 FIG. In the present embodiment, array type structure data that defines repetition of transaction items from a tabular input / output component that has repetition of items when designing a transaction format from the input / output components described in the third embodiment. The operation of the communication information file generating means when designing the above will be described.

24 and 25 show an example of a transaction when a transaction is designed from a tabular input / output component on the client screen. Reference numeral 43 is a tabular input / output component, and 44 is a designed transaction. 45, 46 items in a transaction are designed as part of 47. 47 and 48 are parent items,
45 and 46 are called child items. FIG. 26 is a diagram showing a part of the definition information of the client screen 1006 shown in FIG. In the figure, 470 is the type of window component RP
It represents C (for communication). Further, 472 indicates that the type of window component is SHT (tabular format). 474 has a window component type of FldB
It indicates that it is an input / output component of ox (single item).

24 and 25, the operation of designing transaction items from the tabular input / output component 43 will be described. The tabular input / output component 43 has m rows and n
Suppose it is a tabular format with columns. Tabular input / output parts 4
When 3 is dragged with the mouse and dropped on the transaction design area, the transaction item 47 is designed from the attributes of the first line 447 of the tabular input / output component 43. Transaction item 47 from the attribute of the first column 445
The first child item 45 of the transaction item 47 is designed, and the second child item 46 of the transaction item 47 is designed from the attribute of the second column 446. Similarly, up to the nth column of the tabular input / output parts are designed. Further, the same operation is repeated for each row of the tabular input / output component 43. Therefore, by repeating m times, all transaction items are designed from the tabular input / output component 43.

FIG. 27 shows a flowchart for designing transaction items from tabular input / output parts. First, in S39, a tabular input / output component is selected as a transaction item by dragging and dropping the mouse from the client screen, and the transaction item name is changed from the name (473 in FIG. 26) set as the attribute of the input / output component. (73, 74, 75 in FIG. 25) are obtained. S
In 40, the number of rows (480 in FIG. 26) and the number of columns (476 in FIG. 26) set as the attributes of the tabular input / output component are obtained. Y is the number of the child item with respect to the parent item. Reference numeral 478 in FIG. 26 indicates that the detailed information of each line is described as a separate file. The definition of each element of the tabular input / output component describes the details of the definition of each element similarly to the definition of the single item input / output component shown in FIG. The processing after S41 is performed by referring to another file in which this detail is described. When the first row is set as a fixed item as a table label in S41, the first row is not a transaction item, and therefore in S42, it is specified to start the process from the first row. If the first line is not a label, the process starts from the 0th line in S43. The value of S42 and S43 is stored in the variable C. In S44, it is checked whether or not the first column is set as a fixed item as a label of the table, and similarly to the case of the row, the first column is designated as the first line or the 0th line in S45 and S46. The first column is stored in the variable R in S47, and S48 is set.
Then, it is checked whether the attribute related to the input / output type in the R column is input only in the design of the upstream transaction.
If the attribute related to the input / output of the R column in the upstream transaction is not input only, the C of the tabular input / output component is selected in S49.
The attribute of the Yth child item of the Xth item of the transaction item is set from the attribute of the row R column. At this time, the name of the child item is the name of the input / output component to which the information of the row number and the column number is added, as shown in 80 to 86 of FIG. S
In S50 and S51, the operations of S48 and S49 for all columns are performed in a loop. S52, S53 S for all rows
The processes of 47 to S51 are performed in a loop. Before moving to the next processing in S53, a parent item is newly defined. In this case, the parent item names are the same, but the array number is incremented by one as shown at 74 in FIG. In FIG. 25, 47 is a parent item set from the first line of the tabular input / output component, and 48 is a parent item set from the second line.

As described above, according to the communication information file generating means of the present invention, the items of the transaction structure array can be designed from the tabular input / output parts.

Embodiment 6 FIG. In the present embodiment, an example will be described in which, when designing the transaction format from the input / output components described in the third embodiment, the redesign is performed using the already created communication information file.

FIG. 28 shows the file selection screen 50 when 21 shown in FIG. 3 is selected from the menu of 17 from the main screen of FIG. 51 is a communication information file name input area for designating a communication information file name already created, and 52 is a server side source file name for inputting the source file name of the server side program corresponding to the communication information file input in 51. Input area, 53 is 51
This is a client-side source file name input area for inputting the source file name of the client-side program corresponding to the communication information file input in. 52 and 5
3 is an option, and is an area that need not be specified if it is not necessary.

FIG. 29 is a flow chart showing the processing of the special display means when the already created communication information file is read. The communication information file already generated is input in S54, and the request code is specified in the request code input area on the main screen 12 of FIG. 2 in S55. S5
In step 6, the number of upstream transaction items NU and the number of downstream transaction items ND corresponding to the request code specified in step S55 are obtained, and in steps S57 to S60, the client screens corresponding to the 0th to NU-1st items of the upstream transaction. Search for the above window part by matching the item name with the name of the window part. As described in the above-described embodiment, the names of the window parts that form the screen and the item names of the communication items in the communication information file match, so that they can be used as matching keys. When a match is found, a process of displaying the changed window part by special display and changing it is performed by a loop process. In S61 to S64, the loop processing is performed for the 0th item to the ND-1th item of the downlink transaction as in the case of the uplink transaction.

Reference numeral 54 in FIG. 30 shows a client screen when the processing of the special display means shown in FIG. 29 is performed. In this example, since all the input / output windows are designated as the items of the up transaction or the down transaction, all the input / output windows (input / output parts) are displayed in a thick frame. In this embodiment, thick frame display is performed as an example of special display, but other special display such as color change display may be used. In this way, the special display means displays the window component corresponding to the transaction item of the transaction separately from the other window components that do not correspond, so that the item can be visually recognized easily and the item change, etc. Easy to maintain.

Embodiment 7 In the present embodiment, another example of the display of the transaction screen in the case of designing the transaction format from the input / output components described in the third embodiment by using the already created communication information file for redesign explain. Since the basic function is the same as that of the sixth embodiment, only the difference will be described.

FIG. 31 shows a pull-down menu of the option menu on the main screen. Each option provided in the pull-down menu is explained.
55 is a mode that does not change the display of the client screen, which is the default menu when a new communication information file is created, and 56 is an input / output window (parts, below) on the client screen corresponding to all items of upstream transactions and downstream transactions. The same) is the mode to change the display. 57 is a mode for changing the display of the input / output window on the client screen corresponding to all the items of the upstream transaction, 58 is a mode for changing the display of the input / output window on the client screen for all the items of the downstream transaction, and 59 is Select any item of up transaction or down transaction,
In this mode, the display of the input / output window on the client screen corresponding to the item is changed.

32 and 33 are flowcharts of the operation when an item is specified from the pull-down menu of the option menu. In S160, an item is selected from the pull-down menu of the option menu on the main screen.
The conditions that can be specified in this case are "all items (56)" for changing the display of the input / output parts on the client screen corresponding to all items of the upstream transaction and the downstream transaction, as shown in FIG. Change the display of all input / output components on the client screen corresponding to the item "Upbound Transaction (5
7) ”, changing the display of all input / output components on the client screen corresponding to all items of the down transaction“ Down transaction (58) ”, on the client screen corresponding to any item of the up transaction or the down transaction This is one of the "arbitrary items (59)" for changing the display of the input / output parts. If no condition is specified, "Do not specify (55)" is selected. "All items" in the options menu of the main screen
If is selected, the same processing as the processing described in the sixth embodiment is performed in S162. If "upstream transaction" is selected, the number of upstream transaction items NU is determined in S166.
Get. In S167 to S170, the window component on the client screen corresponding to each of the 0th item to the NU-1st item of the upstream transaction is searched for by matching the item name with the window component name, and matching is performed. The process of changing the display of the window component that has been removed is performed by a loop process. When "Downlink transaction" is selected from the option menu of the main screen, similarly, the number of items ND of the downlink transaction is obtained in S171, and the 0th item to the ND-1th item of the downlink transaction are obtained in S172 to S175. Then, a loop process is performed to search for the corresponding window component on the client screen by matching the item name with the name of the window component and change the display of the matched window component. When "arbitrary item" is selected in the option menu of the main screen, in S176, an arbitrary item is selected from the upstream transaction design area or the downstream transaction design area on the main screen by a designation method such as mouse clicking. The window component corresponding to the item selected in S177 is searched for by matching the selected item name with the name of the window component, and the display of the matched window component is changed. If you select "Specify nothing" in the option menu of the main screen, nothing is processed.

FIG. 34 shows a screen when "upstream transaction" is specified as a condition. A window 60 corresponding to each item of the upstream transaction is displayed in a thick frame. Further, on the main screen, all items in the upstream transaction design area are displayed in bold frames. FIG. 35 is a screen when “arbitrary item” is specified as a condition, 61 is an item selected in the transaction design area of the main screen, and 62 is an input / output window on the client screen corresponding to the selected item. .

As described above, the special display means specially displays the items according to the contents designated by the options, so that the relationship between the transaction items and the client screen can be visually known.

Embodiment 8 FIG. In this embodiment, when designing a transaction format from the input / output components described in Embodiment 3, verification is performed from the screen information of the transaction screen when redesigning using the communication information file already created. An embodiment of detecting an error by means will be described. Since the basic function is the same as that of the sixth embodiment, only the difference will be described.

In step S58 of the flowchart of FIG. 29, the transaction item is matched with the name of the input / output component on the client screen, but in this case, there is no input / output component with the same name. Is shown in FIG. In step S78, an input / output component on the client screen that matches the transaction item name is searched. If the item cannot be retrieved, the display of the transaction item is changed in S79. If a matching input / output component on the client screen is found, the display of the input / output component on the client screen and the transaction item on the main screen is changed in the same manner as in the above-described embodiment in S80. FIG. 37 shows an example of the main screen changed in S79 and S80. Reference numeral 63 is an item for which no corresponding input / output component exists on the client screen. The item 61 of the transaction whose display has been changed in S79 and the item 63 of the transaction whose display has been changed in S80 have different appearances, so that it can be understood that there is an error.

As described above, when the client screen is changed, the verification means of the present invention verifies the consistency with the communication information file already designed, and as a result of the verification, changes the display of the corresponding item. Display it so that you can easily see it. This makes it possible to easily detect a defect in the program.

[0075]

As described above, according to the present invention, the communication function generating means refers to the communication information file storing the data format of the transaction data corresponding to the request code for communication, and the communication item of the transaction data is referred to. And a window part item are associated with each other to generate a communication function for passing data between items in the communication part of the communication module, and the communication processing generation means allows communication between the communication module and another communication module for which communication consistency can be obtained. Since the routine processing part of is generated, there is an advantage that it is possible to easily realize the communication part which is the most difficult to obtain the consistency when developing an application for communicating on the network while keeping the consistency.

Further, since the comment adding means for inserting a comment sentence into the program content of at least one of the communication function and the communication process generated by the communication module generating device is provided, the automatically generated program can be easily maintained and debugged. It becomes possible to do.

Further, it is possible to generate a communication information file using the screen definition information.

Further, according to the present invention, Windows
It becomes possible to easily establish a link between the data format of the transaction data and the information about the window component on the screen by using the rule and attribute of the window component that is used as a standard in.

Further, according to the present invention, a transaction is interactively performed by designating a window component defined in the screen definition information, copying the attribute of the window component, and setting it as an item attribute of transaction data. It can be designed, and there is no inconsistency between the screen of the communication module and the transaction format, and the program development productivity is improved.

Further, according to the present invention, the means for checking the input / output attribute of the window part and determining whether or not it can be the item attribute of the transaction data is provided.
It is possible to prevent operational mistakes when designing transactions interactively, and improve program development productivity and program reliability.

Further, when the window part is a tabular input / output part, means for making transaction data an item attribute of the array type structure is provided, so that a transaction can be interactively designed, and program development / production can be performed. The property is improved.

Since the means for displaying all the corresponding window parts displayed on the screen by the communication module from the referred transaction information separately from other window parts are provided, the transaction and the screen can be easily grasped and maintained. Is possible.

Further, an up-down transaction, a down-transaction, and a narrowing function according to arbitrary transaction items and conditions are provided to distinguish the window parts corresponding to the narrowed down transaction items displayed on the communication module from other window parts. Since the means for displaying is provided, it becomes possible to easily grasp and maintain a specific transaction or screen item.

Further, since the function of matching each item of the transaction with the window part of the screen information and the function of explicitly specifying the transaction item that does not match are provided, the contradiction between the screen information and the item of the transaction format is eliminated. It is possible to easily grasp and maintain transactions and screens easily.

[Brief description of drawings]

FIG. 1 is an overall structural diagram showing a communication module generation device and a communication information file design device of the present invention.

FIG. 2 is a general view of a main window of the communication module generation device according to the embodiment of this invention.

FIG. 3 is a general view of a file menu of the communication module generation device according to the embodiment of this invention.

FIG. 4 is a general view of a code generation menu of the communication module generation device according to the embodiment of this invention.

FIG. 5 is a schematic view of a pop-up menu shown from a file menu of the communication module generation device according to the embodiment of the present invention.

FIG. 6 is a diagram showing an example of a client screen according to the embodiment of the present invention.

FIG. 7 is a configuration diagram of a communication component according to the embodiment of this invention.

FIG. 8 is a flowchart of communication function processing according to the embodiment of this invention.

FIG. 9 is a diagram showing a source code of a communication function generated according to the present invention.

FIG. 10 is a diagram showing a communication information file format of the present invention.

FIG. 11 is a flowchart of server-side processing according to the embodiment of this invention.

FIG. 12 is a diagram of a sample list showing the structure of the server application of the present invention.

FIG. 13 is a diagram of a sample list showing the structure of a server application of the present invention.

FIG. 14 is a flowchart of communication processing generation means according to the embodiment of the present invention.

FIG. 15 is a configuration diagram of a communication information file according to the embodiment of this invention.

FIG. 16 is a diagram showing a relationship between a client screen and a transaction according to the embodiment of this invention.

FIG. 17 is a diagram showing a relationship between a client screen and a transaction according to the embodiment of this invention.

FIG. 18 is a diagram showing a part of definition information of a client screen according to the embodiment of the present invention.

FIG. 19 is a diagram showing a part of definition information on a client screen according to the embodiment of the present invention.

FIG. 20 is a diagram illustrating a transaction design from the client screen according to the embodiment of this invention.

FIG. 21 is a flow chart of transaction design by the communication information file generating means according to the embodiment of the present invention.

FIG. 22 is a configuration diagram of attributes of input / output parts according to the embodiment of the present invention.

FIG. 23 is a flow chart of error check by the judging means when setting items of a transaction according to the embodiment of this invention.

FIG. 24 is a diagram showing an example of transactions designed with the tabular input / output parts according to the embodiment of the present invention.

FIG. 25 is a diagram showing an example of a transaction designed with a tabular input / output component according to the embodiment of the present invention.

FIG. 26 is a diagram showing definition information of tabular input / output parts according to the embodiment of the present invention.

FIG. 27 is a flowchart for designing a transaction from the tabular input / output component according to the embodiment of this invention.

FIG. 28 is a diagram showing an example of a pop-up menu for inputting a communication information file name according to the embodiment of the present invention.

FIG. 29 is a flowchart of a process for changing the display of the client screen by inputting the communication information file name according to the embodiment of this invention.

FIG. 30 is a diagram showing an example of a client screen according to the embodiment of the present invention.

FIG. 31 is an outline view of an option menu according to the embodiment of the present invention.

FIG. 32 is a flow chart of processing when an item is selected in the option menu according to the embodiment of the present invention.

FIG. 33 is a flowchart of processing when an item is selected in the option menu according to the embodiment of this invention.

FIG. 34 is a diagram showing an example of a main screen and a client screen according to the embodiment of the present invention.

FIG. 35 is a diagram showing an example of a main screen and a client screen according to the embodiment of the present invention.

FIG. 36 is a flowchart of error checking by the verification means according to the embodiment of the present invention.

FIG. 37 is a diagram showing an example of a main screen and a client screen according to the embodiment of the present invention.

FIG. 38 is a configuration diagram showing a conventional example.

FIG. 39 is a diagram showing a conventional communication information file.

FIG. 40 is a diagram showing a conventional communication example.

[Explanation of symbols]

1 client, 2 server, 3 client application, 4 server application, 8 communication information file, 9 communication component, 10 input / output component, 11
Request code, 12 main screen, 13 request code input area, 14 upstream transaction design area, 15 downstream transaction design area, 1
6 add button, 100 screen definition information storage means, 11
0 communication function generating means, 112 communication processing generating means, 1
14 comment adding means, 116 communication information file generating means, 118 judging means, 120 special display means, 12
2 Verification means.

Claims (11)

[Claims] 1. A communication module generation device for connecting a first information processing device and a second information processing device to generate a communication module for performing communication processing, comprising: A first communication module including a communication processing unit for performing communication processing on the first information processing apparatus; and (b) a screen configured of screen items and a predetermined communication module on the second information processing apparatus. A second communication module that performs communication processing with the first communication module by a communication function, (c) Screen definition information storage that stores screen definition information that defines screen items that configure the screen of the second communication module means,
(D) A communication information file storing communication information defining communication items used for communication between the first communication module and the second communication module, corresponding to the screen definition information, (e) the communication information file Communication function generating means for generating the communication function of the second communication module, and (f) communication processing generating means for generating the communication processing section of the first communication module by referring to the communication information file. 2. The communication module generation device further comprises comment adding means for taking communication information of the communication information file as a comment and adding the comment to at least one of the communication function and the communication processing unit. The communication module generation device according to claim 1. 3. The communication module generation device further comprises communication information file generation means for generating the communication information file with reference to the screen definition information stored in the screen definition information storage means. The communication module generation device according to claim 1 or 2. 4. The screen composed of the screen items is W
Windows (US Microsoft Corporation
4. A window supported by a trademark), and the screen definition information storage means defines and stores the screen item as a window component that constitutes the window. Communication module generator. 5. A communication information file designing device having the following elements: (a) a first communication module having a communication processing unit for performing communication processing on the first information processing device; and (b) a second communication module. A second communication module for performing communication processing with the first communication module by a screen composed of screen items and by a predetermined communication function on the information processing device; (c) a screen of the second communication module Screen definition information storage means for storing in advance screen definition information defining screen items to be configured, and (d) communication used for communication between the first communication module and the second communication module corresponding to the screen definition information. A communication information file storing communication information defining items, and (e) a communication information file generating the communication information file with reference to the screen definition information stored in the screen definition information storage means. Yl generating means. 6. The screen definition information storage means stores a screen item attribute in association with the screen item, and the communication information file design apparatus further refers to the screen item attribute to perform the communication. 6. The communication information file designing apparatus according to claim 5, further comprising a judging unit for judging the validity of the communication item defined in the information. 7. The communication information file defines an upstream transaction transmitted from the second communication module to the first communication module as the communication information, and the attribute of the screen item is input / output of the screen item. Is an input / output attribute that defines whether or not the communication item is determined, and the determination unit determines the communication item by using the input / output attribute of the screen item corresponding to the communication item that constitutes the transmission transaction. 6. The communication information file design device described in 6. 8. The screen definition information storage means stores the number of elements that define repetition of the screen item, and the communication information file generation means defines the communication item using the number of elements. The communication information file design device according to any one of claims 5 to 7. 9. The communication information file stores a request code corresponding to the communication information in combination with the communication information, and the communication information file designing device further configures communication information corresponding to the request code. 6. The communication information file design device according to claim 5, further comprising a special display means for specially displaying a screen item corresponding to the communication item. 10. The communication information file designing apparatus according to claim 9, wherein the special display means selectively displays the screen item under special conditions. 11. The communication information according to claim 5, wherein the communication information file designing device further comprises verification means for verifying correspondence between the communication item and the screen item and displaying a verification result. File design device.