APPX/Net - Cross-Platform Data Sharing

APPX/Net - Cross-Platform Data Sharing

Introduction to APPX/Net

APPX/Net is a data access facility allowing an APPX engine running on one APPX machine (like a desktop PC) to read and write AppxIO data stored on another APPX machine (like a Unix or NT APPX Server). APPX/Net performs conversions necessary to ensure that binary data in AppxIO files can be accessed properly across the network. It turns the APPX engine into a true network-aware client/server data server as well as client.

APPX/Net is often used as a behind the scenes conduit of information on an APPX/Server to APPX/ODBC servers , sitting on Client PCs.

An APPX system can be set up to access ALL of its applications and data, including the 0apps, across the network, or only some of its applications and data across the network. The main guideline is that the application design files for an application, and all database(s) containing data for that application, must all be located on the same machine. This ensures all data files stay in sync with their design specifications.

With that in mind, potential configurations, in increasing order of performance, include:

APPX/Net Configuration Options
100% APPX/Net
Remote applications
Mixed local and remote applications

100% APPX/Net. This is the easiest configuration to set up. Since all that is (currently) required to use APPX as a 100% APPX/Net client is the APPX engine, it also is a desirable option for clients whose disk space might be limited or whose administrator wishes to minimize the number of APPX program files installed on client machines in order to simplify future upgrades. Since all design files and data (even for the 0apps) are accessed across the APPX/Net network connection, it does not have the performance of other configurations, although the impact of this is minimized by locally cacheing all compiled EMs.
Remote applications. This configuration requires a local copy of the APPX runtime environment, in addition to the APPX engine. A client configured in this fashion is basically its own autonomous unit, with its own System Registration, own list of Users, own Printers and Forms specifications, etc. However, all non-APPX-supplied applications are accessed across the network. This provides improved performance over Configuration #1, although it requires storing and maintaining both the complete APPX run-time environment and site-specific (or client-specific) data on individual APPX/Net client PCs. Even with the increased maintenance requirements, there are situations in which this configuration is appropriate. One good example would be if you wish to configure APPX on a Windows machine, to work as both an APPX/Net client of your main UNIX-based APPX system and an APPXODBC server, so that the data stored on UNIX can be accessed by PC productivity packages like Crystal Reports. Having the APPX runtime environment and System Administration files local to the Windows machine will improve performance. Additionally, you gain the benefit of being able to define different Printers, Forms and in 4.0 Saved Dispositions, on the server and each APPX/Net client system. When the System Administration files are shared, all Printer, Form and Disposition information valid for ANY of the APPX systems sharing those System Administration files is combined in the centralized files, allowing users to select Printers, Forms or Dispositions which are not valid on their system.
Mixed local and remote applications. (It is anticipated that most sites with run with Configuration #1 or Configuration #2, but this is here for completeness in case you need it.) This configuration requires a local copy of the APPX runtime environment, in addition to the APPX engine, and local copies of selected APPX applications and their associated database(s). As with configuration #2, a client configured in this fashion is its own autonomous unit. You might wish to configure an APPX/Net client in this fashion if you need to access selected data items from a main APPX system, but most of your application is standalone and does not require centrally-stored data.

All of these configurations feature a local copy of the APPX engine, which is "appx" on UNIX platforms and "appx.exe" on Windows platforms, and local storage of all compiled EMs. A summary of where other pieces of the application environment are stored, under each configuration, is below:

Configuration	Stored on client	Accessed remotely
100% APPX/Net	APPX engine Compiled run-time and application EMs	APPX run-time design files and data APPX System Administration files (shared among server and all APPX/Net clients configured as "100% APPX/Net") All end-user applications All end-user data
Remote applications	APPX engine APPX run-time design files and data APPX System Administration files, including lists of Users, Printers, Forms, Application names and Database names Compiled run-time and application EMs	All end-user applications All end-user data
Mixed local and remote applications	APPX engine APPX run-time design files and data APPX System Administration files, including lists of Users, Printers, Forms, Application names and Database names Compiled run-time and application EMs Selected end-user applications Selected end-user data	Selected end-user applications Selected end-user data

Why use APPX/Net?

APPX/Net allows you to transparently share APPX application design files and data files, across LAN and WAN connections. Sharing across WAN connections is not necessarily recommended at this time due to performance constraints, but does work, albeit more slowly than sharing across a LAN.

Some reasons you might want to use APPX/Net include:

Sharing APPX databases and applications among multiple APPX machines. APPX/Net can be used to share APPX data among multiple UNIX and/or Windows machines. Unlike OS-based file sharing solutions like NFS and Windows mapped drives, APPX/Net can translate among system-dependent record and data formats.
Accessing data stored on your main UNIX-based APPX server in AppxIO, via PC-based ODBC client programs like MS-Access. Prior to the introduction of AppxODBC and APPX/Net, if you wanted access to your UNIX-based APPX data from a PC program like MS-Access, it was necessary to store data in a third-party RDBMS such as Oracle which provided PC ODBC drivers. Now data stored in the AppxIO native format on UNIX machines is accessible to PC productivity software users in real-time, via a combination of APPX/Net and AppxODBC.
Converting data and application design files among different platforms. Without APPX/Net, a data conversion consists of exporting the data, transferring it from system to system, and re-importing the data on the target system. If you are going between a RISC machine and an Intel machine, export and import will consist of TWO steps each. In addition to taking time and needing extra disk space to hold the export files, this process is somewhat error prone due to the simple-sounding (but often troublesome in practice) "transfer" step. With APPX/Net, you can avoid these steps. [ Yes, we need instructions on how to do this. They are not yet written, howerver. ]

If you are used to putting APPX and your data on an NT or Novell server drive, sharing the drive, and just mapping to it on client workstations, you might be wondering, "Why do this instead? It sounds more complex!", there are a number of reasons:

APPX/Net is architecture-neutral, and thus is a more flexible solution. With the mapped-drive approach, you are limited to using PC servers, because no byte order translation is done by APPX in that configuration. In contrast, APPX/Net data sharing will properly convert data between multiple machine architectures, so that you could even use a UNIX machine as your application data server, if you wish.
APPX/Net does not use OS cacheing for data, and is thus a more robust solution than OS-based file sharing. In the past, sites using the mapped-drive approach occasionally ran into file corruption issues due to problems in Windows network file sharing code. Although there is a Microsoft patch that minimizes the chances of this occurring, the possibility still exists, and we at APPX Software (not knowing what the Microsoft Windows source code looks like) can only take Microsoft's word that the exposure is minimal.
APPX/Net may be more network-efficient than a mapped drive approach (this depends on application-specific characteristics). APPX/Net performs network I/O on a data record basis rather than on a disk block basis (which is what mapped drives use). This translates to less information being moved across the network when doing database processing.
APPX/Net provides additional data security. When using mapped drives, it is possible for end users to (for example) open an APPX data file in notepad, then re-save it, viewing and possibly corrupting data he or she may not have application rights to view. With APPX/Net, you do not need to share drives and directories at the OS level. DIrect access to APPX data files by non-APPX programs like notepad, hex viewer utilities, and the like is not available, thus preventing data from modification by tools outside of the APPX application environment.

Caveats to keep in mind when using APPX/Net:

Any time you want to access a particular file via APPX/Net, you must define the entire database in which the file is located, AND you must also define the application which contains the database's data dictionary. Both of these must be set up with an FMS Group type of '7' (APPX/Net). If these tasks are new to you, keep reading. We explain each one later in this document.
Because of the possibility for intermediate files to get out of sync, Application Design activities should not be done across APPX/Net. That means that even though you've defined an Application to your APPX/Net client machine, and you can run processes in that application on your client machine, and APPX will let you make changes to that application via Application Design on your APPX/Net client, DON'T DO IT! You should not make any changes to that application (in either processes or the data dictionary) from any machine EXCEPT the one on which the application is locally stored.

Getting started with APPX/Net

The best way to get started with APPX/Net is to set up Configuration #1 on your network. This consists of installing the APPX Presentation Server component on the machine you want to use as your APPX/Net data server, then configuring the client appropriately. Once you have successfully accessed remote data via Configuration #1, you can experiment with the other APPX/Net configurations. Assuming that the machine containing the data you want to share is already running APPX, there are just four things you need to do, to access its data from another machine -- and you may have already done some of them!

Quick APPX/Net Initial Configuration Steps
Install/configure APPX Presentation Server on APPX/Net server machine
Install APPX on APPX/Net client machine
Configure APPX on the client machine to acces data via APPX/Net
Test APPX/Net data access

Install and configure APPX Presentation Server on your APPX/Net data server machine

If you have already done this, and have GUI client login working properly, you can skip this step!
Otherwise, please refer to the APPX/Server Installation documentation for instructions on how to properly install and configure this server-side component of the APPX environment.

Please test that you can accomplish a GUI client login after installing the APPX Presentation Server, before moving on to the next step. If you plan to use a PC as your APPX/Net client (for example, to gateway between AppxODBC and data on a UNIX machine), it is best to test that you can login via GUI client from THE EXACT MACHINE you are configuring for APPX/Net, rather than "another machine on my network".

Note for use with APPX Releases up to and including 4.1.9: You must have a "GCS" (GUI client services) license listed in your APPX/Net Server's Registration information, to be able to test that GUI client login works successfully. If you do not have a "GCS" license, contact APPX Software for a temporary license containing "GCS" before attempting a login via the GUI client.
Install APPX on your APPX/Net client machine

If you plan to use an "all data and design files on the network" configuration, you can get by with copying JUST the APPX engine ("appx" in the UNIX world, "appx.exe" in the PC world) to your client system.

However, if you anticipate ultimately using one of the higher-performance options, please follow the standard APPX installation instructions for your client platform, to install a full copy of APPX on the client. For PCs, this typically means running the appropriate SETUP.EXE obtained from an APPX CD or a protected download area on the APPX Software, Inc. web site. For other machines, this means istallation of the required set of .tgz's for your machine. Be warned that if you just copy the engine right now, and later decide to try one of the more advanced APPX/Net configurations, you will still have to install a full copy of APPX on your APPX/Net client machine later.

Configure APPX on the client to access data with APPX/Net

The simplest APPX/Net configuration can be implemented in a matter of seconds by setting two environment variables on the client which tell APPX/Net the machine on which remote data is located, and how to login.

The variables that must be set on the client machine are:

Variable	Description
APPX_DATA_SERVER	Location and port number of the APPX Presentation Server this APPX/Net client will connect to, in the format hostname:port (the default port number we recommend is 8060, but if you have configured your APPX Presentation Server to run on a different port, please use that new port number here)
APPX_UID	Server (OS-level) login ID and password, which must be defined in your Presentation Server system's standard user database (User Manager for NT, /etc/passwd for UNIX), in the format loginID:password

HOW TO SET THESE VARIABLES FOR A UNIX APPX/Net CLIENT

You can set these environment variables anywhere you would normally set environment variables for APPX under UNIX. One place you could set them would be the appx.env file associated with that engine. If you do that, be aware that ALL USERS RUNNING THAT ENGINE will run as APPX/Net clients. (If you have an existing, working, APPX application on your APPX/Net client system today, you DO NOT want to set these variables in appx.env, because the settings in appx.env will override ALL OTHER settings.) You could also set them in a specific user's, or the system-wide profile, and they would be in effect for a user, the next time that user logged in. You could also create a script that sets them and runs APPX, for test purposes. The latter might be specifically useful if you have an existing APPX system running on the machine you want to use as an APPX/Net client, and you don't want to do anything which might affect your running configuration! It is also useful to do if you anticipate running this machine in one of the more advanced APPX/Net client configurations, and are just "going through the motions" of Configuration #1 as part of the setup process. For instance, you could create a script called "netclient" which sets them, then invokes APPX, like:

APPX_DATA_SERVER=myserver.appx.com:8060 export APPX_DATA_SERVER APPX_UID=myuserid:mypass export APPX_UID /usr/appx40/appx $*There are some interesting things to notice about this script. First, we use the full path to the APPX/Net client engine. This ensures that even if we have multiple versions of APPX installed on the system, and people's PATH settings are different, anyone running "netclient" will get the same version of APPX. Also, we use "$*" to pass along to the invocation of APPX any other command-line arguments you've specified. For example, if you call this script "netclient", then "netclient -k -m=cli" would let you enter a keymap called "cli". Remember to "chmod 755 netclient" so that the script is executable, before you run it.

HOW TO SET THESE VARIABLES FOR A WINDOWS APPXNET CLIENT

You can set these environment variables anywhere you would normally set environment variables for APPX under UNIX. You could set them in a specific user's, or the system User Environment settings (in NT) or in the autoexec.bat (in Windows 9x), and they would be in effect after the next reboot. You could also create a batch file that sets them and runs APPX. The latter might be specifically useful if you have an existing APPX system running on the machine you want to use as an APPX/Net client, and you don't want to do anything which might affect your running configuration! It is also useful to do if you anticipate running this machine in one of the more advanced APPX/Net client configurations, and are just "going through the motions" of Configuration #1 as part of the setup process. You probably DO NOT want to set these in appx.env, as some versions of APPX/Net don't seem to check that properly. For instance, you could create a script called "netclient.bat" which sets them, then invokes APPX, like:

set APPX_DATA_SERVER=myserver.appx.com:8060 set APPX_UID=myuserid:mypass c:\appx25\appx %1 %2 %3 %4 %5 %6 %7 %8 %9Be aware that using a script like this is only useful if you will always be invoking APPX from a Windows Shortcut or from the command line. It will not be useful if you are using AppxODBC.

For actual production deployment on NT, you would probably want to set the APPX_DATA_SERVER variable in the "System" environment variables area. Depending on whether you wanted the same APPX_UID information for all users, or different APPX_UID information for each user, you would set APPX_UID in either the "System" or "User" environment variable area in NT's control panel. For production deployment on Win 9x, you would probably set both of these in each user's AUTOEXEC.BAT.

There are some interesting things to notice about the above batch file. First, we use the full path to the APPX/Net client engine. This ensures that even if we have multiple versions of APPX installed on the system, and people's PATH settings are different, anyone running "netclient" will get the same version of APPX. Also, we use "%1 %2" etc. to pass along to APPX any other information entered on the batch file command line. For example, if you call this batch file "netclient.bat", then "netclient -k -m=cli" would let you enter a keymap called "cli".

Note that unlike when using full local copies of APPX to access data stored on a shared network drive, you do not have to put the password into the APPX FMS Group definition or the User file record for the user.

Test APPX/Net data access

You are now ready to test your new APPX/Net client. If you created a script or batch file in step 3, run it now. Otherwise, just invoke "appx". (Check your path to make sure that the correct engine will be invoked when you do this.) PC users who like to click a shortcut to start APPX need to be careful here -- if you click on a shortcut, MAKE SURE you've set your environment variables and rebooted, and MAKE SURE that shortcut is defined WITHOUT THE "-c" command line option! If your shortcut specifies the "-c", APPX will start up a regular GUI client session, not an APPX/Net session. (Check this by right-clicking on the shortcut, choosing Properties, and clicking the Shortcut tab.)

You should at this point see whatever main APPX screen is normally displayed for this user if they login directly to the APPX data server system, without going through APPX/Net. If you see it, CONGRATULATIONS, you have successfully configured APPX/Net! Be prepared to wait a while if you are attempting this process across a dial-up Internet link connecting your client with your APPX_DATA_SERVER, because a lot of data must move back and forth across the network when using the simplest APPX/Net configuration. Watch the dial-up networking status in your task bar -- as long as the send/receive lights are blinking periodically, APPX is doing something.

If you don't see the expected main screen, try making sure that the machine name, port number, user ID and password specified in the environment variables can be used to start a GUI client session. Seriously, please test that you can bring up the GUI client with the EXACT SAME user ID and password information specified in APPX_UID. Testing a different ID you believe to be set up identically is NOT an adequate test. We've seen it succeed with one ID and fail with another that "seemed" identically set up more than once. Also, check the spelling of everything in your script or batch file, or system environment variable settings again. Make sure case is correct as well. Once you can login with the GUI client, there's not much that can go wrong to keep APPX/Net from working in this simple configuration. Check and doublecheck your login parameters.

The Simple Stuff Works ...
Now What About Advanced Configurations?

If you've made it this far, you've successfully seen the main APPX screen, or a user's main application screen, from across the network. And you want more.

You did anticipate this, and install a full copy of APPX on your APPX/Net client system, right? If not, please do so now, before continuing. Yes, this means installing the large SETUP.EXE file if you are on a PC, or the set of .tgz files if you are on UNIX. Then test it again to make sure it still works. If you set the APPX/Net variables in appx.env, make a backup of that file before installing a full copy of APPX, then copy it back in after the install. Otherwise, you risk it being overwritten.

At this point, your configuration looks like:

APPX installed on the APPX/Net data server
APPX Presentation Server installed on the APPX/Net data server
APPX installed on the APPX/Net client
2 environment variables set for testing Configuration #1, unless you used the batch file / script approach

Using APPX/Net with Remote Applications

If you are reading this section, presumably you have done everything listed above, and made sure that you could get APPX/Net to work on your network, in the simplest configuration. If you decided, "I don't need to do that!", and skipped ahead to this section, "OK, but don't say we didn't warn you." Login failures and server-side configuration errors are MUCH easier to diagnose via the GUI client than via APPX/Net, and if you call Support to say that you can't make this APPX/Net configuration function on your system, the first things we're likely to ask you are:

A. Did you test to make sure you can you login to your server via a GUI client?
B. Could you make APPX/Net work by setting APPX_DATA_SERVER and APPX_UID?
C. Do you have a full copy of APPX installed on your APPX/Net client system?

If your answer to these questions is not yes, please go back and do these things. They'll provide more data Support can use to solve your issue more quickly.

Caveats now out of the way, let's get to it. This configuration is useful when you want a slight performance edge over the simple "100% APPX/Net" approach in exchange for the trade-off of increased client disk requirements, or when you will need to access both local (to the client) and remote (via APPX/Net) applications on your APPX/Net client system.

In both the "Remote Applications" and "Mixed Local and Remote Applications" configurations, the APPX 0apps system run-time applications will be accessed locally. Any other user-provided applications may be installed directly on the client machine ("locally") or accessed via APPX/Net ("remotely"). "Local" applications are installed the same way you'd normally install any APPX application -- by adding the application and database, and copying any needed files into the appropriate Data or Portdata directories, and doing Import steps if necessary. "Remote" applications are installed by adding each Application and Database via System Administration, then setting "FMS Group" properties for them to point to the APPX/Net server on which the "master" copies of these applications exist.

An important thing to remember when accessing data from a remote APPX file is that in addition to having the Database in which the file exists, defined as an APPX/Net FMS type, you must ALSO have the File's Application defined as an APPX/Net FMS type. This is true even if you *NEVER plan to touch Application Design for that application, on the client machine. Making a copy of the server's Application Design files on the client in an attempt to reduce network traffic or save time entering FMS information is very, very strongly NOT advised. In addition, it is unsupported and likely to cause you all sorts of trouble due to application data files getting out-of-sync with their data dictionary definitions.*

Assuming that you have been following along with this entire document, the steps to implement either a "Remote Applications" or "Mixed Local and Remote Applications" APPX/Net configuration are as follows:

Un-set the environment variables APPX_UID and APPX_DATA_SERVER, if you set them.

Reboot after un-setting them (if on a PC) or logout and log back in again (if on UNIX).
Choose whether you are implementing a "Remote Applications" or "Mixed Local and Remote Applications" configuration.

You must now decide which data on the APPX/Net data server you would like to access from the APPX/Net client. (Actually, you hopefully thought about this before ever sitting down to install APPX/Net!).

If:
- you are setting up this APPX/Net client for the express purpose of making UNIX-based APPX data available to programs like Access or Excel via AppxODBC

...then you will probably choose to access ALL applications and data across the network. This architecture would be an example of the "Remote Applications" configuration.

On the other hand, if:

- you are developing a relatively standalone APPX-based application to run on your client machine,
- and that application just needs access to two files in a database on the APPX/Net server,
- and that application does not need to share any of its local data with that other system

...you will probably choose to install/run the existing Application and Database via APPX/Net but the new application and data (which are only needed on this machine, not by the APPX/Net server) locally, This architecture would be an example of the "Mixed Local and Remote Applications" configuration.

Follow "Steps to Define an APPX/Net FMS Group" to define an FMS group which points to the remote system on which the database files are stored.

This consists of adding an FMS Group of type 7 (APPX/Net network file service) specifying the desired user name, password, host name and port number for access to your APPX/Net server machine.

Note that if you have a single APPX/Net client PC with which you wish to access multiple APPX/Net servers on different ports or even different machines, you are free to define multiple FMS Group entries of type 7, and point different applications and databases to different FMS Groups. It is anticipated that few sites will need to do this, but if you're one of them, the capability is there.
Follow "Steps to Define an APPX Application with APPX/Net" to define remote Applications.

Repeat this for each Application you want to access via APPX/Net. This should be done for every application which contains Data Dictionary information for a Database you want to access via APPX/Net.
Follow "Steps to Define an APPX Database with APPX/Net" to define remote Databases.

Repeat this for each Database you want to access via APPX/Net. This should be done for every database you want to access from your APPX/Net client machine.

It bears repeating: Remember, if you define a Database as an APPX/Net FMS type, you must also define the corresponding Application for that Database as an APPX/Net FMS type.

Steps to Define an APPX/Net FMS Group

Navigate to System Administration -> Configuration -> File System Groups.
Press ADD, to add a new File System Group, and enter the following:
- In the "FMS Group" column, enter the name of your new APPX/Net FMS Group. You can use any name you like, as long as no other FMS Group of type 7 currently has that name. You'll be typing it a lot later, so you might want to keep it reasonably short. As a hint, LEAVING IT BLANK is a perfectly valid FMS group name, believe it or not! This reduces the typing you'll need to do later, at what your faithful narrator here believes is a loss of clarity. Because I like to name my FMS Group rather than taking the blank "default", I will call the new sample APPX/Net FMS Group garthfiles.
- In the "FMS" column, enter 7.
- In the "Path" column, enter a string of the form userid:password@hostname:port,which lists the user and password needed to login to the APPX/Net server, as well as the APPX/Net server's name, and port on which it is running appxd or WinAppxD. Be warned that the user specified here MUST be a valid system login user on the APPX/Net server, and the password listed here must be the valid, non-expired password for the account. For example, if we wanted to login to our APPX/Net server as system user ID "andrew", whose password is "mypass", our APPX/Net server was named "garth.appx.com", and it was running appxd on port "8060, we would enter andrew:mypass@garth.appx.com:8060

You do not need to enter information in any other columns. Just hit return to finish adding the new FMS Group record.

Hit F8 or your usual End key to exit out of File System Group maintenance, and keep End'ing to exit out of APPX.

Steps to Define an APPX Application with APPX/Net

Quick APPX/Net Application Definition Steps (all on CLIENT machine)
Add the Application, specifying the FMS Group name you created for APPX/Net data access.
Set File Specifications for all Design Files in that application, to FMS 7 and FMS Group whatever-group-you-created.
Run Create Files for that Application's Design Files
Exit APPX, then run APPX again, and check to see if a list of the INPUT processes in that application is visible from the APPX/Net client machine

WALKTHROUGH - DEFINING AN APPX/Net APPLICATION

The following steps will walk you through setting up remote access to the application "ZOE", which resides on an APPX Server called garth.appx.com, a UNIX or NT machine which runs appxd (or WinAppxD) on port 8060. While you have the choice of letting each user on the client machine use a separate login account on the main APPX/Net server, this sample process takes the approach of all accesses to APPX/Net server data being done through a single login account, no matter which client user is accessing the data. (If you wish to configure APPX/Net with separate login/password information per user, please contact APPX Software for assistance until that information is incorporated in this document.) Note that ALL of these steps are performed on your APPX/Net client machine, not the APPX/Net server. Please make the following substitutions, as appropriate, in the instructions below:

Example text	You substitute...
ZOE 51	The name of the application you are defining on the client. This should be the same name and version of an application which exists on the APPX/Net server machine.
TST	The name of the database you are definining on the client. This should be the same name as a database which exists on the APPX/Net server machine.
garthfiles	The name of the FMS Group you created for APPX/Net.

Note: Make sure before beginning this step that you have defined on your client machine the APPX/Net FMS Group you want to use, or you will be unable to complete all the steps in this process.

Run "appx" (not "appx -c") on the APPX/Net client machine (for example, your desktop PC). Note that the rest of this example assumes that the user you login as now, has APPX System Administrator rights.
Add the Application to the system and your APPX/Net FMS Group, as follows:
1. Navigate to System Administration->Database/Applications->Applications
2. Press ADD, to add a new Application record.
3. Enter the Application and version, followed by a description, and the name of the database, then hit ENTER. For example, for our application, we will enter "ZOE 51" and database "TST.
4. In the "FMS Group" section of the pop-up box which appears now, enter the name of the FMS Group you defined for APPX/Net earlier in this process. In our example, we created a group called garthdata, so the data entered here would specify that name.
5. Hit ENTER to make the pop-up box disappear
Set ALL of that application's design files to be in your APPX/Net FMS Group, as follows:
1. If you are not already at System Administration->Database/Applications->Applications, navigate there now.
2. Select the Application you want to access via APPX/Net, which in our case would be "ZOE 51".
3. Choose "Design File Management". You should be presented with a screen telling you "35 of 35 files selected".
4. Choose "File Specifications". For each file listed (all 35 of them), enter 7 in the FMS column, and the name of the FMS Group you created, in the "FMS Group" column, then hit ENTER. For example, with our FMS Group garthdata, we might have a row containing:
  
  BITMAP 100 7 garthdata
5. Once finished with that, hit F8 or your usual End key to exit back to the Design File Management menu.
6. Choose "Create Files". It should create 35 files.
7. Again, hit F8 or your usual End key to exit back to the Design File Management menu.

The application "ZOE 51" should now be accessible over the net. If you want to verify at this time that you can see the contents of the design files for "ZOE 51", exit completely out of APPX, run APPX again, navigate to Application Design -> ZOE 51 -> Process Management ->Input, and verify that you can see a list of the INPUT processes in Application "ZOE 51".

Steps to Define an APPX Database with APPX/Net

Quick APPX/Net Database Definition Steps (all on CLIENT machine)
Add the Database, specifying the FMS Group name you created for APPX/Net data access.
Set File Specifications for all files in that database, to FMS 7 and FMS Group whatever-group-you-created.
Run Create Files for that Database's Files.
Exit APPX, then run APPX again, and check to see if you can run an application process that accesses data in the remote database.

WALKTHROUGH - DEFINING AN APPX/Net DATABASE

The following steps will walk you through setting up remote access to the database "TST"", which resides on an APPX Server called garth.appx.com, a UNIX or NT machine which runs appxd (or WinAppxD) on port 8060. While you have the choice of letting each user on the client machine use a separate login account on the main APPX/Net server, this sample process takes the approach of all accesses to APPX/Net server data being done through a single login account, no matter which client user is accessing the data. (If you wish to configure APPX/Net with separate login/password information per user, please contact APPX Software for assistance until that information is incorporated in this document.) Note that ALL of these steps are performed on your APPX/Net client machine, not the APPX/Net server. Please make the following substitutions, as appropriate, in the instructions below:

Example text	You substitute...
ZOE 51	The name of the application you are defining on the client. This should be the same name and version of an application which exists on the APPX/Net server machine.
TST	The name of the database you are definining on the client. This should be the same name as a database which exists on the APPX/Net server machine.
garthfiles	The name of the FMS Group you created for APPX/Net.

Note: Make sure before beginning this step that you have defined on your client machine both the APPX/Net FMS Group you want to use, and the Application corresponding to this Database, or you will be unable to complete all the steps in this process.

Run "appx" (not "appx -c") on the APPX/Net client machine (for example, your desktop PC). Note that the rest of this example assumes that the user you login as now, has APPX System Administrator rights.
Add the Database to the system and your APPX/Net FMS Group, as follows:
1. Navigate to System Administration->Database/Applications->Databases/Applications
2. Press ADD, to add a new Database record
3. Enter the Database ID (in our example, it's TST), and a description, then press Enter.
4. In the "Startup ID Ver" columns, enter the Application and Version number of the corresponding Application. For our example, that would be "ZOE 51". When we've finished this, the line would look like:
  
  TST Our testing db ZOE 51 ZOE application on garth
5. In the Pop-up box that appears, cursor down to "FMS Group" and enter the name of the APPX/Net FMS Group you created in a prior step. In our example, we would enter garthdata.
6. Hit return to make the pop-up box disappear.
Set ALL of that Database's data files to be in your APPX/Net FMS Group, as follows:
1. From the main APPX menu, navigate to Application Design -> "ZOE 51" -> Database Management -> Physical File Management.
2. Make sure that the correct database and application are displayed, then hit return to select all files in the database.
3. Choose "File Specifications". For each file listed (all 35 of them), enter 7 in the FMS column, and the name of the FMS Group you created, in the "FMS Group" column. You do not need to enter information ni the other columns. For example, with our FMS Group garthdata, we might have a row containing:
  
  ORDITEM 100 7 garthdata
4. Once finished with that, hit F8 or your usual End key to exit back to the Physical File Management menu.
5. Choose "Create Files". It should create all the files..
6. Again, hit F8 or your usual End key to exit back to the Physical File Management menu.

The database "TST" should now be accessible across the net. If you're brave (well, actually, at this point you don't really have a choice), run one of your "ZOE 51" application processes which accesses "TST" data, and see if it works.

See also ECR #4681. Also, release 4.1 will change UserID/Password specification with the 'Identity' file.

Comments:

Read what other users have said about this page or add your own comments.

-- ChrisBrower - 2011-06-08

Topic revision: r3 - 2012-03-13 - ChrisBrower