Application Built with USoft

An application built with USoft is made up of different components.

A USoft application is typically delivered to its Production environment in the form of a set of flat files, although it is also possible to run USoft applications from repository tables.

Typically, the core of each USoft application is a set of flatfiles containing at least a .CON file and a .JOB file.

In addition, a USoft client/server (Windows) application has an .ESI file containing window interface definitions.

In addition, a USoft Web Application has a set of .XML files containing web page interface definitions. Invariably, a web application also needs surrounding files, in particular, .CSS and .JS files.

Typically, you run USoft Authorizer in the production environment. This allows you to change data access rights on-the-fly (that is, without deploying a new version of the application from a development environment. See the USoft Authorizer Help for details.

If the application relies on third-party components such as a Java object layer, .NET components or ActiveX controls, these may need to be registered and installed on each production machine.

Access to application

In addition to server-side setup and authorization, you need to give end-users access to the application from their client machine.

For browser-based access, distribute correct URLs, usernames and passwords to runtime users.

For client/server access to UIs, distribute a USoft Binder file to each runtime user:

•Make sure that for all USoft Binder files in the production environment, you specify Project Type = "Production".

•In the (Read) From field in the Application Properties dialog, make sure you specify "Flat Files", NOT "Repository". You also need to specify the application name in this dialog.

•When specifying username, password and database string, you use the login and connection information of the team member, but in the Owner field you specify the application owner. If you don't, USoft Binder attempts to find the application tables in the end-user's own account.

For client/server access to scripted batch procedures and services, distribute correct scripts or embedded calls to each runtime user as appropriate.