Client Server

More advanced topics discussed.

Moderators: Susan Smith, admin, Gabriel

gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Client Server

Post by gtisdale »

I am trying to get Client Server running. I've never used it in the past and am not completely clear on how to do this.

My plan is to install it on my development machine, a stand alone Vista 32 machine. Then install on my office 2003 Back Office SERVER, AND FINALLY INSTALL ON MY uBUNTU lINUX ftp server to allow clients limited access to their data.

One step at a time. First the development machine (Vista 32):

I have placed a copy of brlistener430-2011-02-18.exe in my C:\Windows\system32 directory and named it brlistener.exe

I have created a brlistener.conf file named brlistener.conf in the same c:\windows\system32 directory

The brlistener.conf file contents are:

logfile=C:\programs\wb\log\brerror.log
loglevel=10
[
LABEL=PC
STARTDIR=C:\programs\wb\br430
EXECUTABLE=C:\programs\wb\br430\brserver.exe
CONFIG=C:\programs\wb\br430\brconfig.loc
STDERR=C:\programs\wb\br430\log\brstderr.log
]

All of the directroies referred to exist, but the c:\programs\wb\br430\log directory is completely empty.

I have run brlistenerinstaller.exe. It is located in my c:\programs\wb\br430 directory.

I have rebooted the machine.

When I run task manager BRLISTENER.exe is listed as a service, but it is stopped. If I try to start it I receive a message that access is denied and the service will not start.

Can anyone suggest what is missing or wrong? I will then move on to getting the client running.

Thank you.

FNGeorge
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

I think you need to put brlistener.conf in the c:\windows directory, not the system32 directory.
bluesfannoz
Posts: 291
Joined: Fri Jun 19, 2009 9:01 am
Location: Lawrence, Kansas
Contact:

Post by bluesfannoz »

Yes I was just getting ready to post the same thing! Good catch Gabe!
Gabriel wrote:I think you need to put brlistener.conf in the c:\windows directory, not the system32 directory.
Steve Koger
Computer Specialist
SEKESC-MACS Division
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

OK I moved BRLISTENER.CONF to c:\windows and removed it from c:\windows\system32.

After a reboot the BRLISTENER is now running as a service.

Thanks.

Now on to getting the client installed an running.

FNGeorge
bluesfannoz
Posts: 291
Joined: Fri Jun 19, 2009 9:01 am
Location: Lawrence, Kansas
Contact:

Post by bluesfannoz »

Good news! Just for information purposes. You can just go into Services and STOP and the START the BRLISTENER service to have it re-read changes to the brlistener.conf file without having to reboot.
Steve Koger
Computer Specialist
SEKESC-MACS Division
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

Thanks. It did not restart before , that's why I rebooted. Maybe becasue I had had the CONF in the wrong location...
Anyway, listener is now running.

I put CLIENT in the BR430 directory mentioned and added a BR_PARAm.txt file.

Got the following error(s) (see attached file).
Attachments
Screen Shot
Screen Shot
err9953.jpg (36.62 KiB) Viewed 19286 times
bluesfannoz
Posts: 291
Joined: Fri Jun 19, 2009 9:01 am
Location: Lawrence, Kansas
Contact:

Post by bluesfannoz »

He has been making some changes to the brlistener in 4.3. I would verify that you are using the listener that corresponds to the version of BR your running. Once they stop making changes to the listener. It will then be cross version.
gtisdale wrote:Thanks. It did not restart before , that's why I rebooted. Maybe becasue I had had the CONF in the wrong location...
Anyway, listener is now running.

I put CLIENT in the BR430 directory mentioned and added a BR_PARAm.txt file.

Got the following error(s) (see attached file).
Steve Koger
Computer Specialist
SEKESC-MACS Division
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

Thanks. I was running the same release date, but I had mixed the debug and non-debug versions.

I had installed the debug version of the server and the non-debug version of the client. I switched the client to debug version and all works now.

Next on my agenda is to figure out the intracacies of client side vs server side directories, printing etc.

I'll be back asking more questions as this progresses.

Thank you again for the help.

FNGeorge
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

There was clearly a mismatch but you can mix & match the Server & Client Debug/Normal versions.
BLarry1T
Posts: 22
Joined: Thu Jul 14, 2011 9:14 am

Post by BLarry1T »

Great to see you found something to do on a rainy afternoon!

I would be interested in how the project works out. I have a client that could use this feature too!
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

My plan is to keep this thread going as I find the answers to my questions regarding files, printers etc. I know there are dealers that have made all of this work, but I need to understand for myself how and why it all works.

Perhaps as I discover this along the way others who have never used C/S can follow along and we can all get it running well for our own needs.

FNGeorge
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

I'm one of those who are following along too George. Thanks for keeping it all public on the forum. Each person will likely run into slightly different issues and questions, so it's really helpful to observe your progress.

Between Steve's excellent presentation on C/S at the last conference and your play-by-play, I think that a C/S tutorial is being birthed.

-- Susan
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

Our biggest problem was figuring out the client side drives and other information.

For discussion purposes, I use 3 different names for the same location C:\cs, X:\ and F:\

On the server, the application is installed in a folder called C:\CS.

The workstation has Mapped X: to C:\cs

BR refers to these drives as "F:".

Finally the workstation has a "TEMP" Folder, "@::C:\Users\siul\AppData\Local\Temp"

Within BR, none of these are really an issue, the Virtual File Names work just fine.

The problem happens when you "Shell to Dos/Windows". Server Side, you need to use "C:\CS", Client Side, you need to use "X:\", or sometimes "@::C:\users\..."

BR 4.20jg (I forget the exact version that introduced it), supports a 3rd paramater on the drive statement that works with the "SYNC" command

Drive F,C:\cs\,X:\,clsinc
Client_Current_Dir SYNC

When configured this way, "X:" will SYNC with the F: Drive. You can do this for any of the drives in your BRConfig.sys

We also used a simple command

EXECUTE "*sys -M CD > "&Cs_Textfile$

This command shells to dos, and sends the "Current Path" to CS_TEXTFILE$

Next, we used:

EXECUTE "*sys -M set > "&Cs_Textfile$

This command shells to dos, and sends all of the Environment Varialbes to CS_TEXTFILE$

We decided to add "CS_" before the "DOS" environment variable.

In particular we found the following to be useful

CS_COMPUTERNAME
CS_TEMP
CS_USERNAME

We also have several variables that we use
CS_Debug
CS_Developer
CS_WBstart

We use these variable to pass setting to the BR Session. Debug & Developer enable special modes of the software that include special messages or debug information.
As an example, CS_Debug will export all of the details for a particular report, or CS_Developer will prompt a message is we call a function wrong. (We really don't want that to happen in production).

CS_WBStart is critical because we perform different automation tasks based on the value.

Take this example:

Set WBStart=Claim:%1
Set CM_Dir_Run=F:\Dev\CLSInc\
start %CM_Dir_Run%\WBWin\BRClient.exe -%WSID% Run StartUp/WBWin

This batch file sets WBSTART to Claim: + the Primary Key.
Upon startup we check CS_Wbstart and if it's Claim:" we pull that claim up.
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

The syncing options for Client Server are useful for implementing Client Server in existing applications.

However, the way I do it is simpler conceptually, but would perhaps require more of a rewrite to some of your legacy applications.

Here are some tips I've learned about client server, especially as it relates to running command line programs.

"@:." symbolizes the current folder on the client, whereas "." is the current folder on the server.

Also, the -@ option on the execute "system" command will cause the shell call to execute on the client rather then the server.

For most everything, the server is the appropriate place for things to happen. Your data files will be on the server, and any command line program that does not have a user interface will likely run on the server. But in the cases where I need to run a command line program on the client, I copy the program over first.

My client server installations all make their own "resources" folder underneath wherever the Client is installed. In BR this is the "@:resources" folder. But if I need to pass the folder name to the OS, I use os_filename$("@:resources").

For example, I use a command line program called quickscan.exe that takes a few parameters, scans the document in an attached scanner, and saves the file as either a PDF or a JPG.

When the user clicks the "Scan Document" button in my application, here's what happens:

1) I check to see if the resources folder is there. if its not, I create it.
if Not Exists("@:resources") then execute "sy -M -@ mkdir resources"

2) I check to see if quickscan.exe is installed on the client. If its not, I install it, by copying it from the server to the client:
if not exists("@:resources\quickscan.exe") then execute "*copy quickscan.exe @:resources\quickscan.exe"

3) I execute quickscan on the client:
execute "system -C -M -@ quickscan showprogress prodname SageLive filename tempscan.pdf PDF resolution 150"

4) I loop until quickscan is finished scanning, checking for the existence of the output file. Its important to include a sleep command inside your loop, to keep BR from hogging all the systems resources while its just sitting there waiting.

do until exists("@:tempscan.pdf") ! Do until we're done scanning
sleep(.2)
loop until kstat$=hex$("6300") ! Loop until they press escape

5) Finally, I copy the finished file up to the server.

if exists("@:tempscan.pdf") then execute "copy @:tempscan.pdf reciepts\myscan.pdf"


This is paraphrased from my code, and I haven't tested it exactly the way it appears here. My actual function is a lot more complicated and handles lots of different options. It also displays a looping progress bar on the screen so the user knows the program is not frozen while it waits for the scan to complete. I just wanted to pull the important pieces out here, that relate to client server.

By putting all this in functions, its really quite simple to implement anywhere. I have an install function that checks to see if a given command line program exists on the client and if not, copies it from the server. I just call this function whenever I need to use something.

It helps me to conceptualize having separate folders on the client and the server, so I don't try to use the options that keep them in sync with each other.

The main advantage of doing it the way I do it, is my programs run fine over the internet. I find Client Server to be an excellent way to network between different physical locations with one piece of BR software. I have had people work for me from other countries sometimes.

But for me, the single biggest advantage of using Client Server like this, and not requiring access to any mapped network drives is that it enables me to travel without missing work.

And when technology allows us to incorporate real experiences into our lives, that's good technology.
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

I agree that ultimately it would be great to have 100% of everything run from the client side without the need for any mapped drives.

I would love to move the data,programs, etc. so that it was completely hidden from the user. That is the long term goal.

I actually have an FNEXE_CACHE library that copies the EXE to a local folder on the client, this way the program does not need to be used over the network or WAN each and every time. This can be quite a bit faster!

Some of my challenges lie, for example with my HELP, PDF or CHM files. I also need to make certain that the local "Cached Version" is up to date, just because my "EXE" exists on @:: doesn't mean it's the most current version.

Our help files are roughly 50MB. As it turns out, when you launch a "CHM file", it is much like a database in that it doesn't actually download the entire 50MB before displaying the "Start Page". If I copy the help file to the "@::" drive, it's like downloading 50MB, but if I simply launch it from the shared folder, it's virtually instant (Even in a slow VPN configuration).

Similarly, our customers import & export a lot of data. If I am going to create a 500MB export (it could easily be several gigs), I really don't want to create it at the client level.

The ultimate dream of having an application that runs right from the browser from any computer anywhere can't use the "SYNC" technology, it will have to depend 100% on the "@::" technology to interact with the workstation.

I can say that the performance and reliability improvements with client server are unreal. We see an average 15 times improvement in performance (1,500 % Improvement). The slower the client and network, the more improvement we see. In some instances we have seen 100 times faster (10,000 % Improvement). Users that had to index frequently now find that indexing is optional.
Post Reply