Client Server Technologies

Size: px

Start display at page:

Download "Client Server Technologies"

Samuel Wright
5 years ago
Views:

1 Client Server Technologies Presented by: Gord Davey Copyright 2005 Best Software Canada Ltd. All rights reserved. No part of this publication may be reproduced, or transmitted in any form or by any means, electronic, mechanical, photocopied, recorded or other, without prior written consent of Best Software Canada Ltd. 1

2 Presentation Overview Application Server Enhancements JavX Enhancements Client/Server Efficient Coding AutoUpdater 2

3 Application Server Enhancements NT Service Support Enhanced Logging Enhanced Start-In and INI Improved User Switching Terminate/Break and Log Clearing Commands are now sent to the Server Fatal Error Log pvx.appserv.log Speed Increase 6% to 10% and more 3

Application Server Enhancements NT Service Support Simple Install/Un-Install/Start/Stop NT Service Support Requires ProvideX V7 with a V7 activation key.

4 Application Server Enhancements NT Service Support Simple Install/Un-Install/Start/Stop NT Service Support Requires ProvideX V7 with a V7 activation key. Each server daemon will be run as a separate service. This can cause difficulties with ProvideX User Count licensing. If you have more than one daemon running, and they are set to interact with the desktop, then they will share the total user license count. However, if they do not interact with the desktop, then they will not be able to share the user count. Example: Server daemons A and B, and 5 workstations, 1,2,3,4 and 5. If all 5 connect to Daemon A, you will use 6 user slots - one for the daemon and one for each of the WindX workstations 1 through 5. If all 5 of those workstations also connect to server B, and each runs one session, then you will use another 6 user slots - one for the B server daemon and one for each of the 5 workstations. This means you will have used 12 user slots in total. However, if you set both daemons A and B to interact with the desktop, and each of the 5 workstations connect one session to both server A and server B, then you will only use a total of 6 user slots, rather than a total of 12. Continued 4

5 Application Server Enhancements NT Service Support (continued) Name: A unique service name. This is generated automatically. Display Name and Description: These items are what users will see displayed in the NT Services Listing Start Type: May be set to Automatic, Manual or Disabled Domain, User Name and Password: If you wish to run the service as a user other than Local System then you may set those properties here. Interact With Desktop: This is only valid when running as the Local System account (not when running as another user) Install / Un-Install: Adds or Removes the service from Windows. Start / Stop: To Start or Stop the service, use the Start/Stop buttons on the Server Tab. If the service is not installed, then selecting Start will start it on the Desktop. Note: Changing any NT Service properties when the App Server daemon is running will require the daemon to be stopped, un-installed, re-installed and re-started. 5

Application Server Enhancements Logging Enhancements Clear All and Log Rotation Server PID Logging Enhancements Logging commands are now sent to the server daemon.

6 Application Server Enhancements Logging Enhancements Clear All and Log Rotation Server PID Logging Enhancements Logging commands are now sent to the server daemon. Clear, Clear All and Rotate will all be processed by the daemon when it is running, or by the configuration screen if it is not running. This allows logs to be cleared, etc., while the daemon is running. Previously they could not be cleared unless the daemon was stopped. Clear All (new button) Clears all the current logs that exist for the currently-named server. It will not clear any rotated logs. Rotate (new button) This will cause the logs to be renamed with the following format: file.log becomes YYYYMMDD.HHMMSS.file.log within the currently-named server directory (*appserv/servername/*.log). If the server is running, it will complete and close the existing logs, rotate them, initialize/re-create the current log files and reopen any required logs to provide the requested logging. 6

Application Server Enhancements Start-In and INI for spawned tasks enhanced Enhanced INI and Start-In INI and Start-In are used for spawned tasks, and not just for starting the application server

7 Application Server Enhancements Start-In and INI for spawned tasks enhanced Enhanced INI and Start-In INI and Start-In are used for spawned tasks, and not just for starting the application server daemon. The order for determining the INI and Start-In Directory for spawned tasks has been enhanced. Previously, the Server s INI and the Start-In Directory were used only if the application server daemon was started from within the Configuration Screen. If the daemon was started outside of the configuration, these two items would not be used. Continued 7

8 Enhanced INI and Start-In (continued) New INI Behavior If starting the application server daemon from within the configuration screen, then the old rules apply - the server daemon will be started with this INI. If the server daemon is started outside of the configuration screen, then the INI given on the command line is used, and the INI specified in the server tab is ignored. Any sessions spawned by the daemon will now use the following, in order: #1 - INI from the *client icon, if given, and if the application named on the icon allows for INI overrides (see the Apps Tab, Detail of App). #2 INI from the application detail screen, if given (See Apps Tab, Detail of App). #3 (New) The INI specified on the Server tab. #4 The INI used by the server daemon, either from the daemon s command line (if started externally) or the Server s INI if given on the Server Tab. Note: INI s are only valid in a Windows environment. New Start-In Directory Behavior For starting the server daemon there is no change. The Start-In Directory on the server tab is valid only if the configuration screen is used to start the daemon. If the daemon is started externally, then the Start-In Directory will be set based on that external launch. The new behavior affects the sessions which are spawned from within the daemon. The rules are applied in the following order: #1 Start-In from the *client icon, if given, and if the application named on the icon allows for Start-In overrides (see the Apps Tab, Detail of App). #2 Start-In from the application detail screen, if given (See Apps Tab, Detail of App). #3 (New) The Start-In Directory specified on the Server tab. #4 The Start-In used by the server daemon, either from the daemon s command line (if started externally) or the Start-In Directory if given on the Server Tab. Continued 8

9 Application Server Enhancements Improved User Switching Uses DEF UID if available rather than su Terminate/Break and Log Clearing Commands are now sent to the Server Config may run as a different user from daemon Fatal Error Log pvx.appserv.log To /tmp (*nix) or current directory (windows) Miscellaneous: New Menu Item: Shutdown All Servers Server PID for each daemon displayed Speed Increase 6% to 10% Miscellaneous Improved User Switching Valid for UNIX and Linux platforms only. Wherever the ProvideX DEF UID command is available, it will be used to allow newly-spawned sessions to be started as a particular user. If the DEF UID command fails for any reason, then an su will be attempted. By using DEF UID it will eliminate the su events from the typical su log file for the OS in question. For DEF UID or su to be effective, the server daemon must be running as root. When not running as root, the behavior has been enhanced so that the spawned applications will not attempt a DEF UID or an su, and will simply launch as whatever user the server daemon is currently running as. Commands Now Sent to Server The Terminate and Interrupt commands from the Sessions tab, as well as the Clear, Clear All and Rotate commands from the Logging tab are all now sent to the server daemon for processing, provided the server daemon is currently running. The net effect of this is that these commands will successfully execute because they are now executed by the same user that the daemon is running as. If the daemon is running as an NT Service these commands will occur within the context of the NT Service. This also allows the Configuration screen to be run as a different user to the server daemon (provided the daemon was started outside of the configuration. Continued 9

10 Miscellaneous (continued) Fatal Error Log (New) An additional log has been created where, if there is a fatal error or warning that needs to be given during the start-up of a server daemon, those errors and warnings will be posted to the fatal error log. This log is named pvx.appserv.log and will be placed in the /tmp directory for UNIX or Linux, or in the app server s current Start-In directory under MS Windows. This will help diagnosis should the server daemon not start or fail prior to opening any of its normal configured log files. New warning s are now written to this file when: A) the server daemon is not run as root B) the server daemon is not using a UMASK of 0. Shutdown All Servers (New) A new command to shutdown all currently-running application server daemons has been added to the File drop down menu. Server PID The Process ID of the server daemon is now shown in the Configuration s status box for the currently selected application server. Speed Improvement A tightening of the code in the application server daemon has basically reduced line numbers and built more compound statements. Also, the switching to large arrays for buffer management has shown an overall speed increase within the server daemon, averaging 6% to 10% faster execution. Due to the use of very large dimensions arrays, and the use of DEF UID, the minimum version of ProvideX that this edition of the Application Server will run on is now V6.10. A ProvideX Version 7 activation key is required to use the NT Service abilities of the Application Server. 10

11 JavX Enhancements JavX V2.5 now comes in 3 editions JavX SE Swing Edition Closest to ProvideX in terms of GUI Controls Includes: Grid, Formatted List Boxes, Tree View, List View, Report View, Full Button characteristics JavX AE AWT Edition Lightweight GUI Interface Includes: list box, buttons, check boxes, radio buttons, etc., all in simplified form Excludes: Grid, Formatted List Boxes, Tree View, List View, Report View, Full Button characteristics JavX LE Lite Edition Has no character mode or graphical mode user interface. Direct to Java Object Interface 11

12 JavX Enhancements JavX SE Swing Edition Full range of GUI controls supported with virtually all options Requires Java 2 SE (Standard Edition) Runtime (version 1.42) or higher Equivalent to prior releases of JavX Most feature rich JavX Enhancements JavX SE runs with: Java 2 SE (Standard Edition) Runtime, version 1.42 or higher Java 2 EE (Enterprise Edition) Runtime, version 1.42 or higher 12

13 JavX Enhancements JavX AE AWT Edition Limited range of simplified GUI controls available Requires Java 2 ME CDC PP (Micro Edition, Constrained Device Context, Personal Profile) Runtime (any version) or higher Intended for PDAs (Pocket PC, Windows CE Devices), Embedded Devices and Desktop PCs JavX Enhancements JavX AE runs with: Java 2 ME CDC PP (Micro Edition, Constrained Device, Personal Profile) Device with limited user interface (PDA) Java 2 SE (Standard Edition) Runtime, version 1.42 or higher Java 2 EE (Enterprise Edition) Runtime, version 1.42 or higher 13

14 JavX Enhancements JavX LE Lite Edition Has no character or graphical user interface at all Requires Java 2 ME CDC FP (Micro Edition, Constrained Device Context, Foundation Profile) Runtime (any version) or higher Intended for Java devices that do not have a user interface (routers, gateways, printers) JavX Enhancements JavX LE runs with: Java 2 ME CDC FP (Micro Edition, Constrained Device, Foundation Profile) Device with no user interface (gateway, router) Java 2 ME CDC PBP (Micro Edition, Constrained Device, Personal Basis Profile) Device with extremely limited user interface (printer, automotive telemetrics) Java 2 ME CDC PP (Micro Edition, Constrained Device, Personal Profile) Device with limited user interface (PDA) Java 2 SE (Standard Edition) Runtime, version 1.42 or higher Java 2 EE (Enterprise Edition) Runtime, version 1.42 or higher 14

15 JavX Enhancements Direct to Java Object Interface Uses ProvideX DEF OBJECT syntax DEF OBJECT [wdx]javax.swing.jslider DEF OBJECT X, [wdx]jdbcdriver Instantiate and utilize Java Classes directly, manipulating properties, executing methods, listening for events and more. Allows for the use of the Java BeanShell class, which can take Java source code directly. JavX Enhancements Direct to Java Object Interface Note: Using will embed the Java component into the ProvideX window. 0010! 0012! This program creates an AWT FRAME and Button 0014! and places it on a Frame. This demonstrates the flexibility of the OCX 0015! interface in JavX 0020! 0030 def object AWTWINDOW,"[wdx]java.awt.Frame" 0040 def object AWTBUTTON,"[wdx]java.awt.Button" 0050 def object EXITBUTTON,"[wdx]java.awt.Button" 0080 def object AWTMULTI_LINE,"[wdx]java.awt.TextArea" 0090! 15

16 Direct to Java Object Interface (Continued) 0100! PRINT awtwindow'* 0110 AWTWINDOW'SETSIZE(260,320) 0120 AWTWINDOW'SHOW() 0130 AWTBUTTON'SETBOUNDS(30,246,80,40) 0140 EXITBUTTON'SETBOUNDS(140,246,80,40) 0150 AWTBUTTON'SETLABEL("Hit Me!") 0160 EXITBUTTON'SETLABEL("Exit") 0170 AWTMULTI_LINE'SETBOUNDS(25,45,200,200) 0180! add events 0190 execute "[wdx]on event java.awt.event.actionlistener from "+str(awtbutton)+" preinput 10" 0191 execute "[wdx]on event java.awt.event.actionlistener from "+str(exitbutton)+" preinput 20" 0200! 0210 AWTWINDOW'SETLAYOUT(*-1) 0220 AWTWINDOW'ADD(*AWTBUTTON) 0230 AWTWINDOW'ADD(*EXITBUTTON) 0240! 0250 EXITBUTTON'LINE= EXITBUTTON'COL= EXITBUTTON'LINES= EXITBUTTON'COLS=9 0290! 0300 AWTWINDOW'ADD(*AWTMULTI_LINE) 0310 AWTWINDOW'VALIDATE() 0320 AWTWINDOW'REPAINT() 0330 obtain A$ 0340 EVT=ctl 0350 if EVT=10 then { 0360! 0370 LOADTEXT$="Ctl :"+str(evt) 0380 CURTEXT$=AWTMULTI_LINE'GETTEXT$() 0390 AWTMULTI_LINE'SETTEXT(CURTEXT$+" "+LOADTEXT$) 0400 goto } 0411 if EVT=20 then { 0412 goto CLEAN_UP 0420 } else { 0421 goto } 0440! Continued 16

17 Direct to Java Object Interface (Continued) 0460! clean up 0470 CLEAN_UP: 0480 AWTWINDOW'REMOVE(*AWTBUTTON) 0490 AWTWINDOW'REMOVE(*AWTMULTI_LINE) 0500 AWTWINDOW'HIDE() 0510 AWTWINDOW'DISPOSE() 0520 delete object AWTWINDOW 0530 delete object AWTBUTTON 0540 delete object AWTMULTI_LINE 0550 end 17

18 Client/Server Efficient Coding Minimize Data Send only enough data to get the job done Analyze your screens Perhaps there is a different approach that might require less object loading (list box, drop box, grid) Make use of special features to minimize loading: Load-on-Demand feature for listboxes Query object, which reads records one page at a time 18

19 Client/Server Efficient Coding Minimize Data Be careful of CALL A CALL [WDX]SomeProg,X$ will send the current contents of X$ to the client and will receive it back. If X$ was 20,000 X s on the way up, and it was not modified on the client, then 20,000 X s will come back In these cases, get the program on the WindX side to clear the unneeded variables before the CALL completes 19

20 Client/Server Efficient Coding Minimize Send/Receive Occurrences Items such as FID( ), FIB( ), FIN( ), OBJ( ), MSE( ), etc., must be retrieved from the workstation Avoid code that asks for these types of items repeatedly Consider: for x=1 to 10000; y=fin(chan, numrec );a*=5; next; y=fin(chan, numrec ) y=fin(chan, numrec );for x=1 to 10000;a*=5; next; y=fin(chan, numrec ) packet requests versus 2 packet requests 20

21 Client/Server Efficient Coding Minimize Send/Receive Occurrences Any variable or function that requires data from WindX will cause the system to pause until it has an answer For example, when using TXW( ) and TXH( ) to determine the sizes of text at various point sizes: It is better to put the code in a CALL and make one CALL across a WindX connection, than it is to repeatedly call TXW( ) and TXH( ) Note: This is true for any function, not just for TXW( ) and TXH( ) 21

22 Client/Server Efficient Coding Minimize Send/Receive Occurrences When dealing with Objects and their Dynamic Properties, try to use the newer _PropList$ and _PropValues$ to retrieve or set multiple properties at once When dealing with properties, try to organize your code so that sets and gets are grouped together Don t do a property get, then a set, then a get, then a set, then a get 22

23 AutoUpdater Features Server-Side Setup Server-Side Directory Structure Server-Side Configuration 23

24 AutoUpdater Features Automated software updating for Client/Server environments WindX Stand-Alone (Version 4.11 and higher) WindX Plug-in (Version 4.11 and higher) ProvideX with WindX (Version 5.10 and higher) Repository based system Software to be pushed resides on the Server No client software installation required Customizable to include your software requirements Requires V7 ProvideX on Server, with a V7 activation key Will perform Upgrades, Downgrades or Repairs Intelligent restart capability if session is severed 24

25 AutoUpdater Features Assigns Show updates of the Add or Remove Programs dialogue in Windows Configurable User Interaction Automated COM and DLL registration Will detect and shutdown other client sessions currently invoked on Workstation that are using same executable No client reboot required after an upgrade, downgrade, or repair Windows 9X, NT, 2000, XP, Server 2003 compliant Has logging capability 25

26 AutoUpdater Server-Side Setup Download the required.zip (Windows) or.taz (UNIX or Linux) file for the version you wish to auto upgrade or downgrade from our Web Site or ftp.pvx.com Unzip/untar the file into the Server s /lib/_repository directory Turn on the AutoUpdater in its configuration file...that s it - you re done! 26

27 AutoUpdater Server-Side Directory Structure When installing ProvideX Version 7, a new directory will be created: \lib\_updater\ cinfo (software that is moved to clients machine to obtain all the client s information; i.e., version, startup information, libraries, etc.) windx.upd (main control program for WindX update) autoupdate.pvc (AutoUpdate engine that performs all required functions for the product update; i.e., windx.upd) Contains the autoupdate.conf (default configuration setup file) 27

28 AutoUpdater Server-Side Directory Structure Once you download and unzip/untar the required repository file, the _repository directory will contain Software to be deployed to the client workstations \lib\_repository\<prefix><version X.XX.XXXX>\ manifest.conf (holds information about the product version on each file and deployment type; i.e., WindX Standalone, Plug-in, or ProvideX) 28

29 AutoUpdater Server-Side Configuration Text based configuration file Copy the autoupdate.conf, default config file to autoupdatecustom.conf to customize your configuration Configuration file contains identification tags [Defaults] All settings defined under this tag are the defaults You may add user-specific settings by adding tags for each user [<IP Address>] i.e. [ ] [<IP Address>+ : +<MachineName>] i.e. [ :MyBox] [<UserID>] i.e. [Tom] Settings Broken up into 3 parts Defaults, Debug, and Products Settings may be placed in both Defaults or Product sections Specific order: Defaults, Products, User-Defined 29

30 AutoUpdater Server-Side Configuration AllowUpgrade=Y or N (if null then default is N) Indicates whether an upgrade should take place if client s workstation version ID is lower than version in autoupdate.conf AllowDownGrade=Y or N (if null then default is N) Indicates whether a downgrade should take place if client s workstation version is higher than version in autoupdate.conf 30

31 AutoUpdater Server-Side Configuration AllowCompare=Y or N (if null then default is N) Indicates whether repair should take place if client s workstation version is same as version in autoupdate.conf CompareFrequency=D or W or M or 2Tuesday D = Once Daily W = Once Weekly M = Once Monthly 2Tuesday = Every Second Tuesday of the month Format is Number+Day (Fri or Friday) 31

32 AutoUpdater Server-Side Configuration Interactive=Silent or Prompted (if not set, the default is Prompted) 32

33 AutoUpdater Server-Side Configuration CurrentVersion= This is the value that all client sessions will be compared against to identify whether an update is to proceed RepositoryPrefix=pvx Windx.upd will take this value + CurrentVersion and look in this directory within the repository directory to get manifest information on what files to move i.e., CurrentVersion = RepositoryPrefix=PVX Directory to look in will be \lib\_repository\pvx

34 AutoUpdater Server-Side Configuration LogLevel=0 -> 9 (if null then default is 0) KillProcessMsg=Y or N (if null then default is N) Indicates if the user will receive a message box advising them that a session running with the same executable is going to be terminated 34

35 AutoUpdater Server-Side Configuration AllowClientInitiation=Y or N (if null then default is N) Displays dialogue advising user on what will happen 35

36 AutoUpdater Server-Side Configuration AllowClientCancellation=Y or N (if null then default is N) Indicates if all the user dialogues contain a Close or Cancel button LookandFeel= 4,3,2 2 (Windows 3.1 style) 3 (Windows 95 style) 4(XP style) 36

37 AutoUpdater Example autoupdate.conf file [DEFAULTS] INTERACTIVE= SILENT ALLOWUPGRADE=Y ALLOWDOWNGRADE=Y ALLOWCOMPARE=Y COMPAREFREQUENCY=M LOOKANDFEEL=4 [DEBUG] LOGLEVEL=0 [PRODUCTS] 1=ProvideX 2=WindX Standalone 3=WindX Plugin 4=JavX [PRODUCT:ProvideX] IDENTIFIER=PVX CURRENTVERSION= REPOSITORYPREFIX=pvx [PRODUCT:WindX Standalone] IDENTIFIER=WXS CURRENTVERSION= REPOSITORYPREFIX=pvx [PRODUCT:WindX Plugin] IDENTIFIER=WXP CURRENTVERSION= REPOSITORYPREFIX=pvx [ ] ALLOWUPGRADE=N How the autoupdate.conf file is read The entire file is read into a *memory file: All default information All Debug information Product list Product information pertinent to the software the Client is connecting with Any user-defined information In this example all updates will be taken from the directory \lib\_repository\pvx All users will be upgraded except Continued 37

38 Auto Updater Example autoupdate.conf File (continued) [DEFAULTS] INTERACTIVE= SILENT ALLOWUPGRADE=Y ALLOWDOWNGRADE=Y ALLOWCOMPARE=Y COMPAREFREQUENCY=M LOOKANDFEEL=4 [DEBUG] LOGLEVEL=0 [PRODUCTS] 1=ProvideX 2=WindX Standalone 3=WindX Plugin 4=JavX [PRODUCT:ProvideX] IDENTIFIER=PVX CURRENTVERSION= REPOSITORYPREFIX=pvx [PRODUCT:WindX Standalone] IDENTIFIER=WXS CURRENTVERSION= REPOSITORYPREFIX=pvx [PRODUCT:WindX Plugin] IDENTIFIER=WXP CURRENTVERSION= REPOSITORYPREFIX=pvx [ ] ALLOWUPGRADE=N 38

39 AutoUpdater Example manifest.conf file # Manifest.conf - For ProvideX and WindX Version # issued: July 2005 pvxcom.exe ;Ver= ;ASCII;ID=WXS,PVX;Reg=9;RegInstall=pvxcom.exe /unregserver;reguninstall= /unregserver Pvxwin32.exe ;Ver= # This is a remark Manifest.conf Ver = Current Version of the specified file ASCII/BINARY = File transfer type (Default is BINARY) ID = Is the value determined by cinfo to identify which product is on the work station WXS = WindX Standalone WXP = WindX Plugin PVX = ProvideX with WindX within REG = Windows registering options 0 = Register and unregister the file with regsvr32 9 = Custom expression where you supply the command to be issued 39

40 Auto Updater Example Manifest.conf File (continued) # Manifest.conf - For ProvideX and WindX Version # issued: July 2005 pvxcom.exe ;Ver= ;ASCII;ID=WXS,PVX;Reg=9;RegInstall=pvxcom.exe /unregserver;reguninstall=/unregserver Pvxwin32.exe ;Ver= # This is a remark 40

41 End of Presentation THANK YOU! 41

42 42

ProvideXVERSION 7. AutoUpdater

ProvideXVERSION 7. AutoUpdater ProvideXVERSION 7 AutoUpdater Introduction 1 AutoUpdater Configuration 3 How it all Works 9 The Repository File 12 Customizing the AutoUpdater 13 Trouble Shooting 14 ProvideX is a trademark of Sage Software