In-line Grip For A Tool Design Example

This page will tell you GRiP specifications. In summary, GRiP system outline will be described and details are explained in chapter 3 and below.

We hope this page helps volunteers who improve GRiP more.

2-1.GRiP system flow

GRiP system flow can be shown in Figure 1 below. Rough outline is that based on the data received from a browser (called JSON data in GRiP,) variable information and fixed information required for automatic creation is obtained, they are combined, and a Web screen, PDF, or CSV is automatically created and displayed on a browser. The explanation along with the number of system flow figure will be described later in 2-2.

About variable information and fixed information, for the example of form reference screen, form number 1 and 2 have the same screen design and control, but displaying form contents are different.

Variable information corresponds to form contents displayed on the screen and fixed information corresponds to the screen design and control information.

In general development method, fixed information is written with html, CSS, or JavaScript, but fixed information in GRiP is the stored data from the design file set by Excel in a GRiP configuration master. And variable information is the output data of RPG to work file based on business logic.

Figure 1: System flow

2-2.System flow explanation

System flow is described sequentially. The red circled number in the system flow figure corresponds to the following clause number at the key explanation point.

(1) When a link or button is clicked on a browser, the parameters to create information on a screen and a Web screen, PDF, or CSV of transition destination is sent to a Web server as JSON data.

(2) CreatePage.php on the Web server receives the JSON data sent from the browser, and decides which automatically created transition destination is a Web screen, PDF, or CSV based on the pattern ID included in the JSON data parameters.

(3) The pattern ID calls the program to automatically create transition destination.

(4) Each automatic creation program obtains variable information and fixed information to create html or PDF. The automatic creation program has branched in (3) above, but the obtaining method of variable information and fixed information is executed by the common function, RL_getMasterDataUseCur.

※About variable information and fixed information

Variable information is the data which displays different contents on a screen according to conditions. For the above example of a form reference screen, the contents of indicated form number should appropriately be displayed. Therefore, variable information can execute RPG each time to obtain the corresponding data from work file.

On the other hand, fixed information does not depend on the data such as screen design, link, button, or input error check by JavaScript on a screen which do not depend on data (Strictly speaking, GRiP can make work file data control these fixed information. Details are described in another part.) Fixed information is created based on the design file. The design file is stored by the GRiP insert tool in a GRiP configuration master.

(5) RL_getMasterDataUseCur function executes api.php to obtain variable information. Api.php executes the stored procedure of IBM i (AS/400) based of the execution program ID included in the JSON data, but before it, parameter information included in the JSON data is inserted in parameter work so that RPG can decide the extracted data. After that, the stored procedure is executed, RPG output the subject data to work file, and then the work file data is obtained connecting to the IBM i (AS/400) database, DB2.

(6)As for fixed information, RL_getMasterDataUseCur function executes DMC_API.class.php and then it is obtained from a GRiP configuration master based on the execution program ID included in the JSON data from MySQL on the Web server.

(7) RL_getMasterDataUseCur function returns JSON combining variable information and fixed information to the automatic creation program of the calling source.

(8) The automatic creation program automatically create html for a Web screen based on the received JSON data and displays it on the browser.

The above has told you the outline about GRiP specifications. In the followings, more detailed specifications will be explained.

GRiP is solution which can convert RPG developed program to open architecture only by Excel file setting. To describe more detailed specifications, it must be in mind that this solution is realized mainly be the following 2 functions.

※The function described here is different from the function introduced in the GRiP functions, but the function to explain GRiP specifications.

（1）The function that Excel setting can develop a Web screen, PDF, or CSV.

（2）The function that RPG output the data displayed on a Web screen, PDF, or CSV to work file.

（3）The function which combines the data that RPG output a Web screen, PDF, or CSV output to work file and the design file information created by Excel to dynamically create html, PDF, or CSV.

4.A design file and a GRiP configuration master

4-1.What a design file is

To explain the above core function (1), a design file and a GRiP configuration master should be explained. It begins with a design file often described before.

A design file can have different setting contents depending on its usage, there are design files for a Web screen, PDF, and CSV. A design file also exists to correspond to special pattern ID described below.

Here see the design file for a Web screen. To display the simple Web screen as the left figure below, requires the design file as the right figure below.

Figure 2: A Web screen and a design file

Web screen

A design file

On the Web screen of Figure 2, the information of header and detail design and button and link control and the information which RPG output display contents to which work file and arrange which work file items to a screen are set in the design file, these setting contents can be set at once. The gray shaded lines in the design file are separators of different settings.

Now see more details of a design file.

Figure 3: Close up of the design file

Look at the left figure. The upper left part of the design file in Figure 2 is closed up.

In A column, alphabets are arranged. This division is to state the setting contents called specification division.

C of the cell A1 means comment line. It is not used to configure a screen, so it can be inserted if necessary. The left figure uses it for setting item title and division explanation.

P of the cell A2 is called P specifications and indicates which RPG is used.

F of the cel A4, A9, and A17 is called F specifications, means setting type such as screen design or link, whose name is indicated by the name of the B column. See the column 4. "F02: GBS_F02" is input in the cell B4. It means that the information set here is stored in the master named GBS_F02 of a GRiP configuration master.

Stored setting details can be set at each column and GBS_F02 has setting items till AS column of Excel. This matches with the field of GBS_F02 of a GRiP configuration master.

In each setting item, the values input by D specifications declared D of the cell A7 into each column are registered. Similarly, at the 9 column setting items of GBS_F03 are registered with the 12 to 15 columns of D specifications and at the 17 column GBS_F05.

That is a design file can apply setting items to the template which is horizontal expansion of a GRiP configuration master fields. In other words, each GRiP configuration master is totally maintained by Excel. Therefore, now Excel using method is adopted, but Excel is not necessary if any method can easily maintain a GRiP configuration master.

4-2.Relationship of GRiP configuration master title and JSON data

Design file F specifications indicates a GRiP configuration master name. The cell B4 of Figure 3 above has indicated F02: GBS_F02. The name of the GRiP configuration master is at the right side of colon (:), GBS_F02. What is the left side, F02? This is the abbreviated name of GBS_F02 used by JSON data. As JSON data is described later, based on JSON data obtained from a browser, CreatePage.php is obtaining screen configuration information, JSON data is handled in program as an array, and finally becomes the form combining fixed information and variable information. At that time, the abbreviated name of the GRiP configuration master is used for array key. Its abbreviated name and formal name are related.

※Example of JSON data and a GRiP configuration master

{

"data": {

"F00": [

"F01": [

{

"ABVCA0": "N0001",

"ABVCB0": "00",

"ALVCA": "N000027",

"WRKGBS003": "00005",

"WRKGBS005": "G00300C"

}

"F02": [　　　　　　　　　　　　　//Showing this part is GBS_F02 of a GRiP configuration master

[

"A",

"1",

"HED",

"0",

"2",

"0",

"2.5

4-3.A GRiP insert tool

4-3-1.Outline of the GRiP insert tool

The GRiP insert tool divides the indicated design file by F specification unit and stores it into the GRiP configuration master of MySQL. Moreover not described so far, the GRiP configuration master also exists in DB2 of IBM i (AS/400), so it is also stored here at the same timing.

In addition, a design file can arrange work file items and at that time the actual item name of work file is not used but another name called screen item ID is set. Web screen automatic creation program does not use the actual item name of work file but uses the screen item ID for processing, so that the screen item ID should be indicated in the design file beforehand (for setting, please refer development procedure of GRiP introduction, procedure 6/7 Excel setting (Arrangement of work file items).) Therefore, when an API server connects with IMB i (AS/400), the screen item ID should refer to work file to obtain work file items and insert parameter work, so that logic file is created whose actual item name of work file is replaced with the screen item ID. Later 4-3-3. Processing details of the GRiP insert tool will explain it including an actual image.

4-3-2.Starting the GRiP insert tool

The GRiP insert tool divides the indicated design file by F specification unit and stores it into the GRiP configuration master. The GRiP insert tool is provide as exe file, and a design file creator can double click json_ins.exe and start the GRiP insert tool as the figure below.

Figure 4: A GRiP insert tool

GRiP insert tool connects with IBM i (AS/400) by ODBC to create a GRiP configuration master on DB2, so that ODBC setting information is required. Moreover, The URL to execute the program (GripImport.php) copying the GRiP configuration master to MySQL should be registered in JSON_Ins.exe.config file beforehand.

※Setting example of JSON_Ins.exe.config

<?xml version="1.0" encoding="utf-8"?>

</appSettings>

</configuration>

4-3-3.Processing details of the GRiP insert tool

The insert tool has 3 processing, so they are explained sequentially.

（1）The Grip insert tool deletes and insert D specification contents to the GRiP configuration master defined by F specifications. At this time, the GRiP configuration master stored in IBM i (AS/400) is processed first.

（2）P01004C of IBM i (AS/400) CL is called. P01004C creates logic file of screen ID logic file. At that time, for the logic file name, the first letter of work file W is changed to X.

The figure below is the close up of F13: GBS_F13 of the design file in Figure 2 above. This is the part where web screen detail part is designed, and the work file items displayed on detail is applied. Please note the left red box. This item is the actual item name of work file. Figure 6 below is the table layout of work file actually referred. Please make sure that the individual item part in the red box at the lower left of Figure 6 is set to the red box part of the design file. Moreover, in the red box part at the upper right of Figure 6, work file name is displayed, where the name is WM01050B.

Next, please note the right box of Figure 5. Here is the screen item ID. It can be seen that another name is input. Then, see Figure 7. It can be confirmed that the individual item part in the lower left red box becomes the screen item ID in Figure 5. Moreover, it can also be confirmed that the work file name in the red box at the upper right of Figure 7.

Figure 5: Example of screen item ID

DDS Figure 6: Work file DDS

DDS Figure 7: Logic file DDS

（3）Finally, GRiPImport.php is executed and the contents of the GRiP configuration master of IBM i (AS/400) is inserted to the GRiP configuration master of MySQL. In these procedures so far, the GRiP configuration master is created from the design file.

4-4.Type and role of the GRiP configuration master

Several GRiP configuration masters exist according to their roles. The GRiP configuration master created by the design file in Figure 2 above is explained. However, the GRiP configuration master is different for PDF or CSV, and setting items of a complex screen even for the same web screen increases proportionally, so that the following GRiP configuration master is not everything. Please refer here for more details.

Here in a design file, it should be defined which GRiP configuration master is used in F0001A:GBS_0001A, so that even if it is set in F specifications and D specifications of a design file but if it is not indicated in GBS_0001A, it becomes invalid. Please note it.

Then note the red box part of Figure 8. This is the GRiP configuration master required to display the Web screen of Figure 2 above. From F01 to F91 indicated in JSON file is abbreviated name and the right side is full name. Among them, F01 (parameter work), F04 (work A), and F14 (work B) are variable information. Namely, work file. The work file set in Figure 6 above is set as F14.

Here # should be attached to the full name by rule other than work file, so that # is attached to the fixed information other than F01, F04, or F14 mentioned before.

Figure 8: Grip configuration master indication

※About a GRiP configuration master

F01・・・The actual name of parameter work is indicated. Here exists variable data of parameter work.

F02・・・Header part design is set.

F03・・・Work file items arrange at header part are indicated. Moreover, work file items can also be allocated to the header frame set in F02. Links set for work file items can also be indicated here.

F04・・・The actual name of the work file (work A) indicated in F03 is indicated. Here exists variable data of header part.

F05・・・Button allocation at the upper right of a screen is set.

F07・・・The GRiP configuration master configuring a screen detail part is indicated. Here F11, F13, and F17 are indicated.

F11・・・Display fixed columns of detail can be set. In case that the number of detail columns is large and they should be scrolled to the right direction, the number of columns until which scroll is fixed is indicated.

F13・・・The work file items allocated in detail part are indicated. Similar to F03, links set for work file items can also be indicated here.

F14・・・The actual name of the work file (work B) indicated in F13 is indicated. Here exists variable data of detail part.

F17・・・The sort order of detail is set.

F91・・・The motion when a link or button is clicked is set.

F0001A・・・The information of Figure 8 is also stored as the GRiP configuration master.

5-1.JSON data sent by a browser

GRiP system flow starts when a system user click a link or button on a browser. Hereby CreatePage.php on a Web server is executed, while the browser information is sent. In GRiP, this data is called JSON data. The reason is that it is sent in JSON format. No change.

JSON data is roughly classified into para and data as a sample below. Para is storing the data required when CreatePage.php executes processing.

Data is the screen information of a browser. It is separated more for each role, F01 is shown in the below sample, and there are also F00, F02, F03, F04, and more. These are types of a GRiP configuration master described in 4-4 above and the data included there is screen configuration information.

※JSON data sample

JSON

{

"data": {

"F01": [ //Part inserted in parameter work

[

"00013",

"R09041C"

]

"para": [　　　　　　　　　　　　 //Parameter part transferred to CreatePage.php

"000100", 　　　 // Site code

"00001", 　　　　 // Company code

"A0002", 　　　　 // Login ID

"192.168.1.85", // address

"20121019", 　 // System date

"144028", 　 // System time

"00013", 　 // Pattern ID

"R09041C", 　 // Execution program ID

"00021", 　 // Work ID

"0001611513", 　 // Work data sequential number

"00200", 　　　　 // Calling source pattern ID

"J01040C", // Calling source program ID

"00017", 　 // Calling source work ID

"0001611512", 　 // Calling source work data sequential number

"B0288"　 // Action ID

]

}

Other data than JSON data is sent from a browser, so that the following information is sent.

（1）param0・・・Action ID (ID to classify the processing executed by a browser such as clicking a registration button, return button, and link)

（2）param1・・・Pre-execution information Execution classification (0: without pre-execution, 1: with pro-execution)

（3）param2・・・Pre-execution information Execution program ID (pre-execution program ID)

（4）param3・・・Pre-execution information Work ID

（5）param4・・・Transition destination information Pattern ID

（6）param5・・・Transition destination information Execution program ID

（7）param6・・・Transition destination information Work ID

（8）param7・・・Transition destination information URL

（9）param8・・・Transition destination information Parameter

（10）param9・・・Calling source information Pattern ID

（11）param10・・・Calling source information Program ID

（12）param11・・・Calling source information Work ID

（13）paran12・・・Calling source information Work data sequential number

（14）userinfo・・・Site code, company code, login ID, and IP address is set.

5-2.Processing details of CreatePage.php

5-2-1.Receiving JSON data

CreatePage.php executed by clicking the link or button of a browser reads JSON data first and converts it to the array php can process.

5-2-2.Pre-execution processing

CreatePage.php has pre-execution processing before the condition branch with pattern ID. The pre-execution is for example executed when the registration button is clicked in a form registration screen and transited to a form list screen. Comparing it with the system flow of Figure 1 above, the timing to click the registration button in a form registration screen corresponds to processing 1. And the screen transition to display a form list screen on a browser corresponds to processing 8. However for procedure, if a registration button is clicked, the processing to register the form data of a form registration screen to database is required. The processing to register the form data before displaying the form list screen is solved by the pre-execution processing in GRiP.

The pre-execution processing is only executed when the pre-execution processing is indicated by a design file as the red box part of Figure 9 below, its information is held in a browser, it is set in param1 (pre-execution classification) of the data sent to the browser at 5-1 above, and CreatePage.php executes if the pre-execution classification is 1.

Figure 9: Pre-execution indication example Setting to transit to a form list screen after the pre-execution registers order receive data

However, the pre-execution processing is not special processing but only 5-3 described below is antecedently executed. From this, automatic creation processing of unnecessary html or PDF is not executed, and only stored procedure can be executed.

5-2-3.Pattern branch (Web screen, PDF, CSV)

CreatePage.php refers the pattern ID included in JSON data, decides which type (pattern), a Web screen or PDF, is to be output, and then branches to the program automatically creating html, PDF, or CSV.

（1）Pattern ID: 5 Pattern to automatically create a Web screen

（2）Pattern ID: 12 Pattern to automatically create CSV output program

（3）Pattern ID: 13 Pattern to automatically create PDF output program

※Special pattern

A special pattern is pattern ID :6 condition branch.

For example, a combo box has three options, registration, printing, or CSV, and the selected processing is executed when the processing button is clicked. In this case, the executed pattern is different depending on the option, so that normal pattern ID cannot process it. Moreover, only one of a transition destination screen and parameter after clicking a link or button can be set in a design file.

Therefore in these cases, it is resolved by changing the transition destination and parameter by the combo box value at the RPD side, and the setting information required then can be applied by pattern ID: 6.

5-3.Processing details of api.php (obtaining variable information)

5-3-1.API server connecting Web and IBM i (AS/400)

The data displayed on a screen is changed by condition, so that it is obtained from a work file. The details explained here corresponds to the core function (2) above.

The work file the data is obtained from is set in GBS_F0001A of a GRiP configuration master, each automatic creation program branching with the pattern ID based on the information obtains the work file data, but the Web server where these programs exist cannot directly communicate with IBM i (AS/400) where RPG and a work file exists.

Therefore in GRiP, the function to exchange data between a Web server and IBM i (AS/400) by the module group called API server is prepared. The reason describing it as the data exchange here is that each automatic creation program not only obtains the data from a work file but also needs to send the browser input value to IBM i (AS/400) as parameter.

In Figure 1 above, an API server works with Linux or Windows, but it can work with the environment where php can work, so that it can work on ZendServer on IBM i (AS/400.) The latter well matches when a work file is obtained and higher performance can be obtained.

※Why a API server is constructed?

If the connection destination from a Web server is limited to IBM i (AS/400,) connecting DB2 by ODBC does not require a API server. The reason to construct a API server is to make GRiP with

the mechanism regardless of database type

GRiP obtains the fixed information to construct a screen from MySQL and the variable information from a DB2 work file. The data obtained from the work file is sent through a API server in JSON format to a Web server, and processed as an array by php. In other word, GRiP accepts any database if the data of the work file can be selected.

Therefore, if it is necessary to be adapted to new database, without any change of the Web server which automatically creates html, it is sufficient only to expand the AIP server which communicates with the database, executes stored procedure, and obtains the work file.

5-3-2.Obtaining work data sequential number

The explanation order is a little bit complicated, each automatic creation program transfer JSON data by RL_getMasterDataUseCurl function using cURL to api.php existing in a API server, in order to obtain variable information from a work file required for construction such as html. Api.php decides first with work ID included in JSON data which work data sequential number is succeeded or newly numbered.

※Work ID and work data sequential number

Work ID It is used to control the RPG side processing. For example, it can be controlled in confirmation mode if the work ID is 2 and in registration mode if 3.

Work data sequential number It means the sequential number numbered for each processing and is the key when a work file is obtained. All work files have work data sequential numbers and the work data sequential number is always the key for GRiP processing. Therefore, every time when a Web screen or PDF is displayed, data is stored in the work file by the work data sequential number unit. The work file is variable information to display a screen, the screen operation log is stored by the work data sequential number unit. This must be strong debug data of system operation for system administrators or developers. Off course the number of work files increases every time when any processing is executed, so that they should be regularly removed.

If the work ID is succeeded, work data sequential number is not newly numbered and the work data sequential number included in JSON data is unchanged and used. If the work ID is newly numbered, numbering management of work data sequential number is performed at IBM i (AS/400,) stored procedure is executed. At that time, 999 is temporarily set for work ID. If the work ID is 999, the stored procedure calls RPG PA0030, newly numbers and obtains work data sequential number. After obtaining the work data sequential number, the original work ID is recovered and forwards to the next processing.

5-3-3.Inserting JSON data into work file of IBM i (AS/400) by an API server

After obtaining the work data sequential number, api.php deletes and inserts the parameter sent at param8 of 5-1 (9) above among received JSON data to the parameter work indicated in a GRiP configuration master using the work data sequential number as the key by SQL. The parameter work is the work file to store the parameter required when RPD executes a program.

Explained more concretely, shown in Figure 10 below, a maintenance screen is displayed from a list screen with parameter of unit code clicked. The maintenance screen output the contents to be displayed to a work file based on the received unit code.

On the list screen side, when transiting to the maintenance screen by a design file, the unit code is indicated as parameter at the red box part of lower columns in Figure 11 below. The parameter should be indicated with the screen item ID, the screen item ID already set is indicated at the red box part of the upper column F13 of Figure 11.

Figure 10: Parameter sending example

A list screen

A maintenance screen

Figure 11: Parameter setting example

※Action ID

The blue box part of Figure 11 is the ID to decide the type when a link or button is clicked. In F13, a link on unit code and the action ID of L0001 are set, and in F91the motion when the link is clicked.

From this, at tie timing that unit code is clicked, JSON data and other information from (1) to (14) listed in 5-1 above are sent to CreatePage.php. Among the sent data, in param8 of (9) described above, the unit code is set. These data is integrated to JSON data in CreatePage.php, and the parameter is set in F01 data part of JSON data (refer to the below sample,) and transferred to api.php.

Api.php uses the key of the execution program ID and work ID included in JSON data, obtains the file name of the parameter work RPG refers from a GRiP configuration master (obtains the actual name of F01, namely work file name, from GBS_F0001A,) and insert the F01 content of JSON data to the parameter work.

From this, RPG which outputs the data displayed on a maintenance screen to a work file can obtain unit code from a parameter work and output corresponding data.

※F01 of JSON data

{

"data": {

"F01": [

{

"0": "00005",

"1": "M01051C",

"AMVCA": "00001"　　　　　// Unit code is transferred as parameters

}

"para": [

"000100",

"00001",

"A0002",

"10.0.101.85",

"20121109",

"145601",

"00005",

"M01051C",

"00017",

"0000000000",

"00005",

"M01050C",

"00021",

"0001613437",

"L0001"

]

}

On the other hand, how is for the same screen. It is the case on a list screen only to change the displayed contents indicating search conditions. As the example of Figure 12 below, it is the case that the search condition is input at the header part and the re-search button is pushed.

Figure 12: Example to re-create the work file of the same screen

A list screen

Adding extraction conditions

In this case, the execution program ID included in the JSON data sent by clicking a re-search button, is the same execution program ID as the list screen. The parameter is inserted to the parameter work similar to the example transiting to the maintenance screen, but the search condition input in the header part is required when RPG output the result to the work file which meets the search condition. Therefore, JSON data also includes the header input item and the data is inserted in the work A which is the work file for the list screen header.

More detailed explanation is needed. The work files required for the list screen of Figure 12 are the parameter work storing the parameter received from the previous screen, the work A storing the displayed data on the screen header part, and the work B displaying the detail part. The detail should always be output by RPG according to search conditions, but how about the header part. This part requires the browser input data. RPG cannot directly refer to the browser input data, so that through an API server the JSON data is inserted in the work A. Look at the JSON data sample below. F04 of data is the work A data sent when the extraction condition is added to the header part of Figure 12 above and the re-search button is clicked.

From this, RPG can refer to the parameter work and work A and output the corresponding detail data to the work B

※Example that the work A value is included in the JSON data

{

"data": {

"F00": [

"F01": [

{

"WRKGBS003": "00005",

"WRKGBS005": "M01002C"

}

"F04": [　　　　　　　　　　　　　　　　　//　F04 is a value of the work A

{

"0A749": "",

"0X001": "0",

"0X002": "現場マスタ　一覧",

"0X003": "",

"0X003_E": "0",

"ABVCA0": "N0001",

"ABVCB0": "00",

"ABVMA0": "株式会社　辻建設",

"ACVCA": "",

"ACVMA": "",

"AGVMAVF": "1",

"AIVCA": "",

"AIVMA": "",

"ALVCAVF": "1",

"ALVCAVL": "N000052",

"ALVCAVS": "N000053",

"ALVMAVF": "1",

"ALVMBVF": "1",

"ALVMBVL": "ﾚﾝｹｲﾃｽﾄｹﾞﾝﾊﾞ",

"ALVMBVS": "",

"ALVMCVF": "1",

"ALVMDVF": "1",

"ALVMDVL": "",

"ALVMDVS": "",

"ALVYM": "0",

"B110": "0",

"B110_2": "0",

"B111": "0",

"B111_2": "1",

"B112": "0",

"B112_2": "1",

"B113": "0",

"B113_2": "1",

"B114": "0",

"B114_2": "1",

"Q02A": "N000001", 　　　　　　// Newly added extraction condition

"Q02B": "1",

"Q02C": "1",

"Q02D": "45",

"Q02I": "50",

"Q02K": "1",

"Q02L": "1"

}

5-3-4.Obtaining work file data by executing stored procedure

After the parameter required to execute RPG and information input on a Web screen are inserted in a work file, api.php executes CL to execute RPG. At that time, RPG program ID obtained from JSON data is the parameter. From this, CL calls RPG. RPG refers to the previous parameter work, and output the data displayed on a screen to the work file. For the processing of the same screen, referring to the work A and B other than the parameter work, the data displayed on a screen is overwritten in the work A and B.

In this manner, RPG executes batch processing based on the parameter received from a API server and only the screen display data is extracted various masters and transaction data, so that GRiP calls CL and RPG stored procedure. To actually call CL, stored procedure must be created.

After stored procedure is executed, api.php selects the work file data with SQL, converts it to JSON format, and return it to RL_getMasterDataUseCur function.

5-4.Processing details of DMC_API.class.php (Obtaining fixed information)

Next, core function (3) above is explained. RL_getMasterDataUseCurl function which has obtained variable information in these processing then transfers JSON data to DMC_API_MySQL function of DMC_API.class.php to obtain fixed information. DMC_API_MySQL function obtains fixed information from the master contents targeting the masters other than the work file of a GRiP configuration master (fixed information of the actual name with # in GBS_F0001A.)

Since RL_getMasterDataUseCurl function exists on a Web server, it is not required to connect to IBM i (AS/400) to obtain fixed information. Therefore, considering the performance, the structure is adopted on which fixed information can be quickly obtained, as MySQL is located on the same server where the Web server is installed and where the GRiP configuration master is stored.

5-5.Web screen display

5-5-1.Processing details of P00005.php

In case of Web, pattern ID is 5. In this case of the branch processing of 5-2-3 above, P00005.php is called from CreatePage.php. Processing details of P00005.php is to obtain fixed information and variable information, process them, and transfer information to the Smarty template required to display the screen. After transferring all information to the template, the template file is read and the Web screen is displayed. Through these processing series, html, JavaScript, and CSS are automatically created.

Concretely, RL_getMasterDataUseCurl function executes the above processing from 5-3 to 5-4 and receives JSON data combining fixed information and variable information. Based on the JSON data, it is set in the Smarty template required to actually display the screen. At that time, if JSON data has F07 (GRiP configuration information to create a table,) the table is displayed on the Web screen using Sigma Grid, so that the data is processed required to display Sigma Grid.

In addition, using RL_createHTMLGroupItems2function, RL_createTableHTMLGroupItems function, and RL_createContentsHTMLByF07 function, html is created from JSON data. Moreover, RL_getAjaxComboArray function creates the data for incremental search.

All data previously processed is set in the Smarty template. On this occasion, as the Smarty template file classified in case of pattern ID 5, the Web screen display template such as P00005.tpl is selected from the config file (app.conf) for Smarty. P00005.tmp reads header.tpl, creates the header part of reading html, and reads P00005_c.tpl to create CSS. JavaScript is automatically created by reading P00005_s.tpl. Subsequently, all screen information is created by reading P00005_m.tpl and footer.tpl.

Finally, the Smarty display function displays the Web screen based on the contents set in the template.

The pattern ID of PDF is 13. In this case of the above branch processing 5-2-3, CreatePage.php calls RL_pattern13 function. This function and also RL_getMasterDataUseCurl function execute the processing from 5-3 to 5-4 and JSON data combining fixed information and variable information is received. Based on this JSON data, RL_createGeneralReportPDF function is used to create actual PDF. From the received JSON data, RL_createGeneralReportPD function sets value to the parameter required when FPDF publishes PDF (more specifically, the corresponding value is set to the argument of the FPDF method such as SetFont based on the JSON data,) and finally displays PDF on a browser using the FPDF OutPut method.