Fairlight OneGate
Documentation
Current Version: 04.02.00
Released: 11/08/07

OGCGIXML Accessibility for filePro

One application that was highly in mind during the creation of OneGate is filePro. Using OneGate with filePro is quite easy with a filePro onegate database and the OGCGIXML processing table. This integration package is available with your regular OneGate licensing fee, at no additional charge.

In short, OGCGIXML is a OneGate-specific XML parsing system that takes OneGate-generated XML and populates records in a filePro database, which you may then look up from any of your applications. This makes filePro CGI work just about as "plug and play" as possible.

To install and utilise OGCGIXML, follow the following steps:

  1. Extract the OGCGIXML archive for your platform into the appropriate filepro PFDIR directory. The database name that all the relevant files will be placed in is onegate.

  2. Make sure that permissions are correct for filePro to access the database.

  3. In versions of OneGate prior to 04.00.00 with OGCGIXML 1.4 or lower, you had to configure OneGate for your filePro application, passing -rw %i on the command line to [dr](report|clerk). In your application, you would look for the value contained in @PW in your lookup to the onegate table. As of version 04.00.00 with OGCGIXML 1.5, all legacy code works correctly as it sits. However, for new applications you can omit the passing via -rw %i, and instead look for the value from ONEGATE_INFILE when performing your lookup(s). Please bear in mind that it's really the version of OGCGIXML installed that determines whether you can use this less resource-demanding behaviour--that version of the parser was simply released with OneGate 04.00.00.

  4. In your processing table, DECLARE GLOBAL OGParseResult(4,*,g) so that you may check the parse status after the next step.

  5. In your processing table, place a CALL "onegate/ogcgixml" statement. The table should only be called once to parse the incoming XML data.

  6. Check the contents of OGParseResult. The potential values are PASS on success, or FAIL on error.

  7. Assuming success, look up your fields in the onegate database. The fields are:

    1. Application ID (999,*)
    2. Field Name (100,*)
    3. Field Value (999,*)
    4. File Upload Field (1,YESNO)
    5. Original Filename (300,*)
    6. File Size (20,.0)
    7. File Name (300,*)
    8. Cookie Field (1,YESNO)
    9. TextArea Field (1,YESNO)

The Application ID field should be used for lookups, as all fields for the current transaction have the value contained in the environment variable ONEGATE_INFILE stored in that field.

Each record is one name/value relation from the incoming CGI data. If you have multiple values for one name, there will be multiple records, each with the same Field Name, but with the respective Field Values.

Value fields have empty fields for Original Filename, File Size, and File Name, and the File Upload Field will contain "N".

File fields will have an empty Field Value field, contain "Y" in the File Upload Field, have populated Original Filename and File Size fields, and contain the safe filename in the File Name field. You are responsible for handling the actual uploaded file as needed, with your own processing. (Keep in mind that filePro need not handle the file itself. You can use other system commands to deal with the file as needed.)

One may utilise the TEXTAREA field in the field definition file for a program set to send the contents of a field to a file, rather than to the database itself. filePro users will particularly wish to do this if the anticipated input is greater than 999 characters in length, as this is filePro's real field limitation, and any further contents will be truncated if the TEXTAREA option is not used. If you use this method (see the Configuration Instructions page), the entire field contents will be saved to a separate file, and the Field Value will contain the path to that file. As with file uploads, you are responsible for handling the TEXTAREA file(s) as necessary.

Fields that are not filled in will not have an entry stored in the onegate database. If no entry for a field is present, either the field was optional to OneGate and not submitted, or the field was submitted but left empty. Check accordingly.

In addition, requested cookies are inserted into this database. Cookies will have the Cookie Field set to "Y". In this fashion, it is possible to have the same name appear as both a cookie and as a field in your form, and still tell them apart. Cookies which are requested but not available will not have an entry stored in the onegate database. Check accordingly.

Note that you should delete the field records after use. It is not self-cleaning. You can delete them as you go, or you can set up an automated process to clean them periodically to keep the database as small as possible.

Using OGCGIXML is not the only way to access the XML data from filePro. You may supply your own XML parsing routine as you see fit. This integration feature is provided as an added bonus to make web-enabling your applications with OneGate even easier.

Note: Never use the -bg or -bs flags to [dr]report if that is the only program creating the output file. Doing so would cause OneGate to attempt to read the output file, which will not exist yet since filePro would immediately place itself in the background and appear to have completed, when in reality it would just have started. Even if other programs generate the data, using these flags will more than likely generate anomalous results that you do not want.

For a more complete demonstration of OneGate integration to filePro, please look at my FLFSS project, which includes complete maps, source, flow description, and my OneGate configuration for the project.

Note: The following variables are used by OGCGIXML, and should not be declared in automatic processing or in a calling table:


Back to Table of Contents

Copyright 2003-2007, Fairlight Consulting. All rights reserved.

Back to Fairlight Consulting