Page edited by Dave Smith/**/
- 1 Overview
- 2 Platform Software Requirements
- 3 Installation and Setup
- 4 Monitoring and Management
- 5 Web Application Configuration
OECN VXS (VMS XML Service) is a replacement for the USP middleware used by the OECN RPC Service. VXS supports both OpenVMS/Alpha and OpenVMS/I64 platforms. VXS is based on HTTP and uses a REST-like interface for transferring XML between Java clients and the back-end (COBOL) RPC services.Icon
The USP based version of the OECN RPC Service is considered obsolete and unsupported. All ITC's should be upgraded to the OECN VXS version of the RPC service.
- Uses standard HTTP protocols instead of a proprietary TCP protocol.
- Uses HTTP "keepalive" to reduce TCP/IP stack resources for idle client connections.
- The connection listener and server processes are isolated. Failure or restarting of the listener does not affect established server processes. Likewise, failure of a server does not affect the listener or other servers.
- Requires Java installed on the OpenVMS server.
- Slightly slower connection start up times. Users may notice a longer delay when first logging in.
VXS consists of three major components:
- VXS Listener: A Java-based HTTP process which listens for incoming connections on a defined port (defaults to 8099). The listener is responsible for validating the client connection request, launching the server process and directing the initial handshake between the client and server process.
- VXS Server: A Java-based HTTP process which handles requests for a single client. The Server is launched by the Listener after a valid connection request. After a successful connection, the server is entirely independent of the Listener.
- *VXS Client: A Java-based HTTP client which handles the transport of OECN RPC messages to the VXS Server. The VXS client software is embedded into the SSDT Web Applications and SOAP services.
The basic connection process is as follows:
- The Client requests a connection by contacting the VXS listener on the configured port
- The Listener validates the request and launches a VXS Server process to handle the connection
- The Server allocates an ephemeral port from the TCP/IP stack, initiates an HTTP listener on the port and sends the allocated port to the Listener
- The Listener redirects the Client to the port allocated by the Server
- The Client and Server handshake to validate the connection and then begin normal OECN RPC operations
Note that OECN VXS is strictly a connection manager and message transport service. It does not perform authentication or any other RPC function. Authentication is handled in the OECN RPC layer after the connection is established.
Because VXS's server allocates an ephemeral port it does not, and is not intended to, function through a firewall. VXS is intended to be used on an OpenVMS server which is near the web application servers it supports.Platform Software Requirements
- OpenVMS/Alpha 8.3 or OpenVMS/I64 8.3 or higher
- Java JDK 5.0-7 (Alpha) or Java JDK 5.0-6 (I64) or higher (http://h18012.www1.hp.com/java/download/index.html)
- OpenVMS ECO's as required by Java
The OpenVMS kit containing the VXS Listener and Server is available to OECN ITC's via OECN_DOWNLOAD. The kit is called VXS-n-n-n.BCK where "n-n-n" is the version number. The first production release is VXS-2-2-0.BCK.Installation
- Install the appropriate JDK version
Unpack the VXS-n-n-n.BCK saveset with the following command:$ BACKUP VXS-n-n-n.BCK/SAVE device:[*...]
- The above command will create device:[OECN_VXS]
The kit contains binaries for both OpenVMS/Alpha and OpenVMS/I64.Configuration
The VXS distribution contains VXS_CONFIG.COM which handles the configuration, startup and shutdown of the VXS Listener. Execute the procedure and choose the "Configure" option. The procedure will prompt for the following options:ParameterDescriptionTCP port for VXS/HTTP ListenerEnter the port to use for the HTTP listener. The default is 8099Service Inactivity TimeoutEnter the number of minutes of client inactivity before the server shuts down. This should be less than the inactivity of the SOAP and web applications. The default is 20 minutes.Service usernameThe VMS UAF username the VXS Listener and Services will run under. This defaults to SYSTEM. The quotas and privileges available to the VXS processes will be determined by this account. See below if you wish to use a non-SYSTEM account for the VXS processesVMS startup batch queueThe batch queue to use to startup the VXS Listener. This must be a batch queue started during SYSTARTUP_VMS.COM and available whenever the Listener is restarted.Service Username Requirements
In order to run VXS under a non-SYSTEM account, the account must meet the following requirements:
- Default privileges: NETMBX, TMPMBX, IMPERSONATE, SYSPRV
- Minimum Quotas:
- Fillm: 4096
- BIOlm: 4000
- Enqlm: 4000
- Bytlm: 2000000
- Pgflquo: 700000
- WSquo: 16000
- WSextent 32767
- JTquota: 5128
These should be considered minimum quotas. Quotas may need be be increased in some environments.Logicals affecting OECN RPC
Several logicals affect the behavior of the OECN RPC service.OECN$RPC_DEBUG_username
Enables RPC debug mode for the specified user. Causes additional debug messages to be logged to the session log file (OECN$VXS_LOGS:VXS_*.LOG) and causes request and response XML files to be written to user's SYS$LOGIN. Must be defined system-wide or as a process logical in an OECN RPC prologue file.
For example:$ DEFINE OECN$RPC_DEBUG_SMITH "YES"
Enables debugging mode for the VMS user "SMITH".OECN$ACME_PROCESS_TYPE
The OECN RPC service uses the ACME system services to authenticate and impersonate users. This logical determines the type of VMS process (NETWORK or REMOTE) to use for authentication. The choice of process type determines which SYSUAF and VMS security policies apply to the process.
NETWORK will apply the SYSUAF /NETWORK access restrictions and will ignore expired passwords.
REMOTE will apply SYSUAF /REMOTE access restrictions and will prevent login with expired passwords.
This logical must be defined as a system-wide logical or in an OECN RPC Prologue procedure. For example, to treat OECN RPC processes as REMOTE:$ DEFINE/SYSTEM OECN$ACME_PROCESS_TYPE "REMOTE"
The default is "NETWORK" for compatibility with previous releases.
This features has been available since the March 2007 release.Startup
Add the following line to the SYSTARTUP_VMS.COM procedure:$ @SYS$SYSDEVICE:[OECN_VXS]VXS_CONFIG START Shutdown or Restart
To shutdown or restart the VXS Listener, use:$ @OECN$VXS:VXS_CONFIG STOP or RESTART
Stopping or restarting only affects the VXS Listener. It does not affect Server processes that are already connected.Monitoring and ManagementLogicals
VXS_CONFIG creates the following logicals:
- OECN$VXS_ROOT: A rooted logical defining the top-level installation directory of VXS
- OECN$VXS: The execution directory for VXS
- OECN$VXS_LOGS: Directory where Listener and Service log files are written
The Listener Startup log file is named VXS_LISTENER_STARTUP.LOG in OECN$VXS_LOGS. This is the log file for the batch job submitting when the startup procedure is run by other than the "Service username".
The Listener log file is VXS_LISTENER.LOG. This file contains console messages for the listener. Check this log file if the Listener fails to start or will not accept connections.
Log files for each Server are named: VXS_nnn_xxx.LOG in OECN$VXS_LOGS. A log file is created for each successful connection by a VXS Client. "nnn" is a hexidecimal number representing the Listener instance and "xxx" is a hexidecimal number unique to each client. Check this log file if the client is unable to connect and for RPC (COBOL) errors during the user's session.Verifying Listener is Running
Since the VXS Listener is an HTTP server, it will respond to HTTP requests from a web browser. To check the that the Listener is running, use a web browser to go to http://yourhost:8099/. If the VXS Listener is functioning, it will display it's version and build information and a status message indicating the state of the listener.VMS ProcessesListener
The VXS Listener process is named "VXS$LST-1". The process can be stopped and started using VXS_CONFIG.Servers
Prior to authentication by the user, server processes operating on behalf of a VXS Client will be named VXS_nnn_xxx (using the same naming convention as the log files). After successful authentication, the Server process will impersonate the authenticated user and the process name will be changed to the username being impersonated.
The Server processes will have the following characteristics:
- The process name will be the username of the authenticated user
- The image will be JAVA$JAVA
- The username will be the "Service username" that the VXS service is running under
Using FSYS (from NWOCA'S Pubdom), you could list the VXS process with a command like:$ FSYS/IMAGE=JAVA/ALL/SHOW=(PID,PROC,USER,IMAGE)
If you have other Java applications running, you could filter the list by the username VXS is running under, for example:$ FSYS/IMAGE=JAVA/ALL/SHOW=(PID,PROC,USER,IMAGE) OECNVXS Web Application Configuration
Each SSDT Web Application or SOAP service which is to use VXS, must be configured with an appropriate URL to use VXS. This is done by changing the appropriate properties file for the application. See the application's installation guide for detailed instructions on configuring each application's connection string.
For VXS connection strings, the URL must be in the following format:vxshttp://server:port/OECN_RPC
Where "server" is the domain name or IP address of the OpenVMS server running VXS and "port" is the port where VXS is listening (default is 8099).
For example, to configure the USAS SOAP service to use VXS, edit the UsasService.properties file and change the USPConnectionString to:USPConnectionString=vxshttp://yourserver.org:8099/OECN_RPC
After restarting or reloading the SOAP service, subsequent connections will use VXS.
Note: For historical reasons, the connection string parameter in the applications is called "USPConnectionString". Future releases will rename this parameter to a more appropriate name.Web Application Compatibility
Web applications released by the SSDT after 1-Sep-2008 are fully compatible with VXS. Applications released prior to that date must have a "Build Date" after 1-Sept-2008 to work with VXS. You can check the Build Date by viewing the "version.properties" file of the application in question, or use the "Admin/Configuration" option in the application.
If the "Build Date" of the application is less than 1-Sep-2008, then you must install a newer build prior to using VXS. The SSDT has placed recent builds of all current versions in OECN_DOWNLOAD as of 1-Sept-2008. If you need an older version of a Web Application or SOAP service (perhaps to support a third-party vendor), then you can request a fresh build of the specific version from the SSDT.
The following web applications are dependent on OECN RPC and will need a recent build date to work with VXS:
- USAS SOAP Service
- USAS Web (if Standalone mode)
- USAS SOAP Service
- USAS Web (if Standalone mode)
- EMIS SOAP
Note: The EMIS Web Applications (emisweb*.war) are not directly dependent on OECN RPC.USP Coexistence
USP and VXS can both be used on an OpenVMS server. It is not necessary to switch all SSDT web applications to VXS at the same time. That is, you can use VXS for one web application while continuing to use USP for the others, or use USP for older applications and use VXS for new installations.View Online · View Changes Online Dave Smith 2014-02-28T22:23:42Z
Page edited by Melissa Diemer
This page contains links to documentation for setup, installation and management of SSDT Web-based Applications. These documents are intended for technical support staff who are configuring and managing the servers.Architecture Overview
The SSDT Web Applications provide web-enabling features of existing State Software Applications. Currently, these are USAS, USPS and EMIS. The data files for the applications are RMS (ISAM) files on the OpenVMS server.
In order to provide access to the legacy data via a web interface, the SSDT has implemented an RPC (Remote Procedure Call) protocol called the 'OECN RPC Service'. OECN RPC is based on XML using several layered and open source software products. Java is then used to create a SOAP service layer on top of the OECN RPC service to provide a standards-based API interface to the target application. Finally, a Java web application provides the user interface functions.Web Application Documents
The table below describes the documentation available for each layer of the application. Because of similarities in the applications, some documentation in common across multiple SSDT applications. Separate documents are provided when necessary to describe differences between applications.
It is important to follow the documentation in the correct order to build the entire environment. For example, you can not skip directly to the USAS Install Guide. The USAS Web application requires the correct J2EE environment and the J2EE environment is not useful unless the OECN RPC service is in place. On the other hand, once you have the environment built, all the applications can installed to the same infrastructure.
OECN VXS (OECN RPC)
OECN VXS for OECN RPC Setup and Installation. Replacement for USP on Alpha and I64.
Describes the Java and J2EE environment required by the applications. This includes platform selection, installation and configuration.
Describes the process of installing a Web Archive (WAR file) into the J2EE container. The basic installation is identical for each application.
Application Specific Supplements:
- EMIS Web Install Guide
- USAS Web Install Guide
- USPS Web Install Guide
- USASDW Web Install Guide and USASDW Manager Utility
The documents above Describe the unique configuration and management for the individual applications.
Supplementary documentation with trouble shooting and optimization tips for USP, OECN RPC and Java
FAQ and answers that have not yet found their proper home in the correct document.Developer Guides
Documentation for programmers and third party developers interested in interfacing with State Software web services:View Online · View Changes Online Melissa Diemer 2014-02-20T21:12:30Z
Page edited by Melissa Diemer/**/
- 1 Introduction
- 2 Requirements
- 3 Download Instructions
- 4 Installation and Configuration
- 5 Usage
- 6 Database Backup and Maintenance
- 7 USAS Data Extraction/Load Process Details
USASDW Manager is the replacement for the "SSWAT_LOAD" process for updating and loading the USASDW database (previously known as the SSWAT database). The USASDW database is a SQL database which is intended to be used in conjunction with the USASDW (USAS Data Warehouse) web application. These components can be installed on a single server or on two separate servers.
Please see the USASDW Web Install Guide for information on installing the USASDW web application component.Requirements
- The USASDW Manager utility may be executed from either a Windows or a Linux server
- This server must be running Java 1.7
- The utility does not need to run on the same server where the database is located
- The USASDW Manager utility does not use DTS, so this compatibility pack is no longer needed.
- The USASDW Manager utility has been tested against databases using both SQL Server 2000 and SQL Server 2012, and is anticipated to run without problems on SQL Server 2008
The most recent usasdwmanager .zip file may be downloaded from http://nwoca.org:8000/oecn_download/. You must have the password of your sites OECN_* account to access this download page.
Note: The USAS extraction programs are released as part of the normal USAS state software release on OpenVMS. You should also have the latest version of USAS, including mandatory patches, prior to extracting data from USAS.Installation and Configuration
- Extract the usasdwmanager zip file into an empty folder on the server you are going to run it from. This does not have to be the same server where the database is located.
- Update the following properties in the /conf/usasdw.properties file to contain your database and ftp information:
- database.server=server name where the database resides
- database.name=name of your database, e.g. SSWAT_DB
- database.user=SQL login user, is typically "sswatuser"
- database.password=password for database.user
- ftp.host=OpenVMS FTP Server Address of the OpenVMS system that contains the USAS data files
- ftp.username=OpenVMS login username
- ftp.password=password for the ftp.username
- ftp.path=OpenVMS Directory containing the USAS files to load
- ftp.delete.after.transfer=true or false
The USASDW Manager application performs the same basic functions as the SSWAT_LOAD process did, which are:
- Creates the database tables, views, functions and procedures
- Upgrades the database from one version to the latest
- FTP's the load files from the OpenVMS server
- Creates/drops 'staging" tables
- Loads delimited files into staging tables
- Updates production tables from staging tables
Execute the utility using the commands below depending on your operating system. Executing it without providing any arguments will give you a brief help message giving you a list of the available functions.
YOUR_FULL_PATH/bin/usasdwmanager [arguments]Valid Arguments
The following table lists the available functions which are provided as arguments when executing the utility. For the typical nightly load process, you should use the "all" function as the argument. The other functions would typically be used under SSDT direction.
Creates USASDW database tables, views, functions, and procedures. Will also upgrade them to the current version.
Note: The database itself must already exist before running this utility.upgradeUpgrades USASDW database to current versiondropDrops USASDW databasetransferTransfers (via FTP) files from VMS serverloadLoads files into database staging tablesupdateUpdates live tables from staging tablesallTransfers, loads, and updates USASDW databaseenvDumps current environment to console
Initial Conversion from SSWAT_LOAD process
When initially converting from using the SSWAT_LOAD process to the USASDW Manager process, you should run the USASDW Manager utility using the "Create" function. This is a one-time thing which will initially add a new table containing the version of the database (current version at the time of this writing is 5). You can confirm this ran correctly by looking for the presence of the new table 'dbo.tblMetaInfo'.Scheduling the USASDW Manager Load Process
A job should be scheduled to run periodically (usually nightly) to run the USASDWManager utility using the "all" argument. The specific mechanics of this will vary based on the operating system and version you are using. The following illustrates an example of the "action" when scheduling the job via the Windows Task Scheduler:
When using Windows Task Scheduler, be sure to check the box to run if user is logged in or not.
Scheduling of this job must be coordinated with the extraction process on the OpenVMS system. The load process will transfer and process any and all files that are found in the FTP directory at the time that it runs. Thus, the job needs to begin after the VMS extraction process has completed and all files to be loaded are available in the FTP directory on the VMS server.
Please note that when the zip file is extracted, the resulting folder contains the version that was released as part of the folder name (e.g., usasdwmanager-2.0.0). When new versions are released, it will be necessary to update the path in the scheduled task to reflect the latest version installed.Log Files
The USASDW Manager load process will create a detailed log file in the USASDW Manager directory created when the utility was unpacked. The most recent log file will be named usasdwmanager-prod.LOG. Older logs will be renamed to contain the date, for example usasdwmanager-prod-yyyy-mm-dd.LOG. You should review the log file when the loads do not appear to be working. You should also review the log file occasionally to look for any errors. The last line in the log should read "Completed phase: live.update" if the process completed. However, most errors in the data will not cause the entire load process to fail, but may cause data to be incomplete or invalid.
The log files are not automatically removed. Therefore, you should periodically remove old log flies or schedule a job to remove them.Database Backup and Maintenance
After you have created and loaded data into your USASDW database, you will want to add the database to your backup procedures. You should also establish a maintenance plan to allow MS SQL to optimize the indexes and data files periodically.
Also note that the database recovery model should be set to “Simple” in order to keep the transaction log from growing too large during the load process. You will not be able to backup the transaction log for this database.
Note: You should backup the USASDW database regularly. You should not have to reload all historical data and user information if the database fails or is lost for some reason. However, the USASDW database is not a transactional system and benefits little from more sophisticated recovery models.USAS Data Extraction/Load Process Details
The USASDW Manager load procedure controls how the USAS data from the OpenVMS system is loaded into the SQL database. The procedure can be used to incrementally update the database. The bulk of the data needs to be loaded only once, and then smaller periodic updates will keep it up-to-date.Overview
The loading process is a multi-step process involving both the OpenVMS system and the Windows SQL Database system. The process must be coordinated properly. The loading process is meant to be flexible and not to enforce a particular schedule on the ITC. The ITC may choose to load all data each night, or subsets of data each night. Also, historical data may be loaded once (over a period of days or weeks) and then not reloaded thereafter.OpenVMS Process Overview
Data to be imported into the database must first be extracted from USAS and placed in the FTP directory that was specified in the usasdw.properties file. As much or as little data as desired may be placed in this directory to be processed by the load procedure. The ITC may extract all districts or a sub-set of districts. They may also extract all data types, or a sub-set of data types.
It is useful to understand that the USAS extractions operate on a fiscal year basis. You may load or reload entire fiscal years, and you may reload a partial fiscal year (a fiscal year for which not all data is present due to a purge) so long as you are careful to specify which fiscal years should be considered partial fiscal years.
See below for additional information and details about the extraction process.SQL Database Process Overview
The bulk of the processing occurs on the Windows or Linux server. The basic phases of loading the data are:
- FTP data from OpenVMS system to Windows/Linux temporary folder (defaults to "loadfiles", located in the USASDW Manager installation directory)
- Load data into temporary staging tables in USASDW database
- Determine what data in live tables is to be replaced (if any) and remove it. Then transfer new data from staging tables into USASDW live tables.
The USASDWManager load utility performs these phases. This utility is a script that can be used interactively or scheduled to run automatically. It will pick up whatever files are found in the FTP directory and load them automatically.
Figure 1 - USASDW Export/Load Process:OpenVMS Process: Extracting Data from USAS
The SSWAT_USAS_EXPORT.COM in OECN$BUD provides the basic extract routines for USAS.
SSWAT_USAS_EXPORT will write all files to OECN$SSWAT_USAS_OUTPUT. That logical must be pointed to the FTP directory as defined in the usasdw.properties file. This may be done as a system-wide logical, or as a process logical in the job running the procedure. The export process may be run as a privileged or non-privileged user. The user must have read access to the USAS data and write access to the USASDW Manager FTP directory.
SSWAT_USAS_EXPORT accepts several parameters that indicate the type of data to extract (Vendors, Accounts, etc), the fiscal year(s) of the transactions and whether any fiscal year(s) should be considered ‘partial’ fiscal years. See the comments in the DCL procedure for details about the options available.
The most common options will be one of:
$ @OECN$BUD:SSWAT_USAS_EXPORT “ALL” “ALL”
$ @OECN$BUD:SSWAT_USAS_EXPORT “ALL” “CURRENT”
$ @OECN$BUD:SSWAT_USAS_EXPORT “ALL” “2000” “2001”
$ @OECN$BUD:SSWAT_USAS_EXPORT “ALL” “2000” “2002” “2000”
The first command extracts all data types and transactions for all fiscal years in the current files. This option would be useful for an initial load of a school district, or when loading historical data for a district.
The second command extracts all data types but only transactions for the current fiscal year and the prior fiscal year (as defined by USASDAT). The prior fiscal year is assumed to be a ‘partial’ fiscal year. This would be useful for nightly loads of districts after the initial loads.
The third example extracts all data types but only FY2000 and FY2001 transactions. This is useful for extracting specific fiscal year(s) from a set of historical files, without extracting all years.
The fourth example extracts all data types for FY2000 through FY2002, with FY2000 being a ‘partial’ fiscal year. This would be useful if the USAS files were purged with a purge date in the FY2000 fiscal year. Since not all of the FY2000 data will be on file, the load will only update the records that are on file, and will not delete whatever data already existed in the SSWAT database for FY2000.
Prior to running the procedure, keep the following in mind:
- OECN$SSWAT_USAS_OUTPUT must be defined to the SSWAT FTP directory
- The user running the extraction must have write access to the FTP directory and must have OECN_USAS or OECN_SYSMAN identifiers.
- OECN$DTA must be defined to the USAS data directory containing the data to be extracted. OECN$AR$DTA must be defined to the USAS Accounts Receivable data directory. The user must have read access to the data files.
- SSWAT exports are currently only supported for USAS 6.1. If you have older archives, you should convert them to USAS 6.1, or contact the SSDT if that is not possible.
- The extract files are not appended together. This means extractions for multiple districts may be executed simultaneously to improve throughput. Also, if an error is made, bad files may be deleted from the FTP directory without disturbing the others.
- The FTP transfer process will remove the files from the SSWAT FTP directory after successful transfer. Therefore, it is not necessary to empty the FTP directory prior to beginning a new set of extractions. Extractions may be performed throughout the day to be processed with the next run of the process on the SQL server.
SSWAT_USAS_EXPORT.COM extracts data for a single district (one set of USAS files). ITC's are left to their own devices for processing or submitting jobs to extract multiple districts. Sites who are in need of an automated method for processing a routine against multiple districts should consider implementing SETUPENV. SETUPENV provides features adequate for establishing district configurations and automatic processing of many tasks, including SSWAT extracts.
For example, if districts that are using SSWAT were configured in SETUPENV to have APPLICATION=USAS and CATEGORIES=SSWAT, then current data for all districts could be extracted with the following DCL:
$$ define OECN$SSWAT_USAS_OUTPUT dcuu:[sswat ftp directory]$ SETUPENV/RESET$ set noon$ Loop:$ SETUPENV/NEXT/LOG/APPLICATION=USAS/CATEGORIES="*SSWAT*"$ if f$trnlnm("OECN$SETUP_ENTRY").eqs."" then goto EndLoop$ Gosub ProcessDistrict$ goto Loop$ EndLoop:$ Exit$$ ProcessDistrict:$ @OECN$BUD:SSWAT_USAS_EXPORT ALL CURRENT$ return
A more sophisticated version of such a procedure might submit one batch job per district instead of running them in series. Doing so may improve throughput by allowing multiple jobs to run simultaneously, subject to other loads on the system.
See the OECN System Managers Manual for details on SETUPENV.Loading Historical Data
The USASDW database is designed to hold multiple years of historical data. Transactions are keyed by fiscal year. This means that even if the same transaction number is used in multiple fiscal years, the transactions will be kept separately.
However, only the current “Account Master” and “Vendor Master” records are kept in the database. This means that historical transactions may become “orphaned” (i.e. transactions may exist without accounts or vendors). The current web interface may not permit querying of these transactions.
Therefore, it is important to understand that although you may load as much historical transaction history as you wish, you should always have the “current” account master and vendor master loaded.
Furthermore, the current USASDW extraction and load are limited to loading one file of each type per district in each run of the load program. Therefore, for a given district, you cannot load both “current” and “historical” data in a single run.
When extracting historical data you should either:
- Extract/load the oldest archive transactions first. Because any set of archived USAS data files may have multiple years, subsequent archives may supersede some fiscal years. For example, if the first archive has fiscal years 1998 and 1999 and the second archive has 1999 and 2000, the loading the second archive last will cause 1999 transactions to replace those loaded from the first archive. This is appropriate because the second archive is most likely to have the correct versions of the transactions, including any error corrections.
- Extract/load specific years from each archive. You can run SSWAT_USAS_EXPORT with specific years for each archive. In the example above, you could request that 1998 be extracted from the first archive and 1999 and 2000 be extracted from the second archive. In this case, the fiscal years would not overlap and the order that the data is loaded is irrelevant.
When extracting historical data, you should extract from a given archive and load that data on the SQL server immediately. You may extract archive data for multiple districts, but you should do one extract per district for a given run of the SQL load process. Again, this is because the load process will only load one file of each type per district. Therefore, the process for loading archive data might be:
- Extract data from an archive for one district or a set of districts.
- Execute the SSWAT_USAS_LOAD process on the Windows Server to load the data.
- Repeat steps 1 and 2 for each archive to be loaded
Finally, after loading historical data, you should immediately reload the current data so that the Account master and Vendor master are from the current USAS files for each district. Alternatively, you could extract archived transaction data and omit the Account and Vendor data. This would prevent the archive master files from overwriting the current master data. For example, the following DCL command extracts all years from a set of files, but omits the Account and Vendor master files:
$ @OECN$BUD:SSWAT_USAS_EXPORT “PO,CHECK,INVOICE,RECEIPT,REQ,AR” ALL
This second method is preferable because it prevents the current master from being overwritten and reduces processing time of the loads.View Online · View Changes Online Melissa Diemer 2014-02-20T17:20:25Z