Generating Dynamic R Scripts with WebFOCUS
WebFOCUS would only have a fraction of its power without the procedural scripting language called Dialogue Manager. Based on user input, a WebFOCUS procedure can leverage Dialogue Manager to basically rewrite its own code and become something completely different.
This robust flexibility makes WebFOCUS a great complement to the R statistical programming language.
In Part I of this multi-part blog posting, I showed you a simple user interface for graphing data obtained from text mining of legacy reporting applications.
When automatically determining the complexity of any particular reporting procedure, I give the user an option of seeing the results--in addition to the tabular data--graphically. The user can select BoxPlot, Histogram, Plot, or none of the above.
Based on the user's choice, the WebFOCUS procedure needs to generate the appropriate R code.
Here is the line of WebFOCUS code that created the Graph pull-down list:
At run-time, WebFOCUS will have a symbolic variable named &GRAPH containing one of four possible values: BOXPLOT, HISTOGRAM, PLOT, or NONE. If the user was not interested in visualizing the data and selected "NONE," we can skip all of the R logic.
For the three R graph options, however, we need to provide R with several key pieces of information:
Visually, here is the interaction between WebFOCUS and R:
Below is the WebFOCUS logic for doing that. First, we set a symbolic variable named &COUNTPATH with the full path of the file containing named pairs of text scan values and their counts.
Next, we need to deal with the R script. We create a symbolic for the name of the R script (&SCRIPT) as well as provide some file definition details so that WebFOCUS knows where to write the script (a file allocation called "RPROGRAM").
In the third step, we set &GRAPHPATH with the full path name of where R should write the output graph. So far, so good.
Our next step is to create an R script that will use the mined counts from the text scanning to produce the user-selected graph.
Based on the user's graph selection, the WebFOCUS procedure will write one of three different R scripts. Note: I could have made this logic much more succinct and dynamic but I decided to make it more verbose and simpler to read for the purposes of this blog article.
In this step, we write statements to the file allocation "RPROGRAM" which points us back to the particular R script defined earlier as "r_dynamic_script.r" stored in the "r_scripts" folder.
The great thing about WebFOCUS is that, at run-time, it can dynamically change any aspect of the R scripts. My example here is fairly simple, with the only dynamic code being the names of the input and output files (&COUNTPATH and &GRAPHPATH, respectively).
After writing the proper R script, WebFOCUS will then go a block I named "RUN_RSCRIPT."
Here is where WebFOCUS uses the "call_r_dynamic" FOCEXEC discussed in Part II. This call passes in the name of the R script (the value of symbolic variable &SCRIPT) so that R can run the proper code. Within those instructions, we have told R where to find its input file, how to generate the output graph, and where to store the results.
Click here to go to Part IV, where we can take a closer look at the R scripts.
This robust flexibility makes WebFOCUS a great complement to the R statistical programming language.
In Part I of this multi-part blog posting, I showed you a simple user interface for graphing data obtained from text mining of legacy reporting applications.
When automatically determining the complexity of any particular reporting procedure, I give the user an option of seeing the results--in addition to the tabular data--graphically. The user can select BoxPlot, Histogram, Plot, or none of the above.
Based on the user's choice, the WebFOCUS procedure needs to generate the appropriate R code.
Here is the line of WebFOCUS code that created the Graph pull-down list:
At run-time, WebFOCUS will have a symbolic variable named &GRAPH containing one of four possible values: BOXPLOT, HISTOGRAM, PLOT, or NONE. If the user was not interested in visualizing the data and selected "NONE," we can skip all of the R logic.
For the three R graph options, however, we need to provide R with several key pieces of information:
- Where to find the input file (stored in a WebFOCUS Reporting Server folder called "r_data")
- Which R script to run (stored in a WebFOCUS Reporting Server folder called "r_scripts")
- Where to store the output graph (we'll use the same "r_data" folder for input and output)
Visually, here is the interaction between WebFOCUS and R:
Below is the WebFOCUS logic for doing that. First, we set a symbolic variable named &COUNTPATH with the full path of the file containing named pairs of text scan values and their counts.
Next, we need to deal with the R script. We create a symbolic for the name of the R script (&SCRIPT) as well as provide some file definition details so that WebFOCUS knows where to write the script (a file allocation called "RPROGRAM").
In the third step, we set &GRAPHPATH with the full path name of where R should write the output graph. So far, so good.
Our next step is to create an R script that will use the mined counts from the text scanning to produce the user-selected graph.
Based on the user's graph selection, the WebFOCUS procedure will write one of three different R scripts. Note: I could have made this logic much more succinct and dynamic but I decided to make it more verbose and simpler to read for the purposes of this blog article.
In this step, we write statements to the file allocation "RPROGRAM" which points us back to the particular R script defined earlier as "r_dynamic_script.r" stored in the "r_scripts" folder.
The great thing about WebFOCUS is that, at run-time, it can dynamically change any aspect of the R scripts. My example here is fairly simple, with the only dynamic code being the names of the input and output files (&COUNTPATH and &GRAPHPATH, respectively).
After writing the proper R script, WebFOCUS will then go a block I named "RUN_RSCRIPT."
Here is where WebFOCUS uses the "call_r_dynamic" FOCEXEC discussed in Part II. This call passes in the name of the R script (the value of symbolic variable &SCRIPT) so that R can run the proper code. Within those instructions, we have told R where to find its input file, how to generate the output graph, and where to store the results.
Click here to go to Part IV, where we can take a closer look at the R scripts.
