Choosing the proper path from VFP to the web

[cfsjohn]

Hello All, It has been since June of 2016. I moved my first client to RemoteApp (with a lot of help from tek-tips). I am not sure but I believe I have the ONLY VFP/Visual Fox Express framework app running via RemoteApp. It has been rough but the dust is settled. I need more advice:

I am sooooo lost.

I have a VFP/VFE app. Basically this is an accounting app. For simplicity let’s say banks use this app to manage their customer accounts and to balance the bank’s books.

Each bank is a complete and separate installation. The app uses a VFP database. Each site has a database server and the users access the database from personal workstations.

Recent installations are on a cloud server. Users access the app via RemoteApp.

This app has 130 tables and about 1500 views.

Whether a local server or a cloud server is utilized, there is a program running on each database server 24/7. This VFP program performs things like interfacing with other apps. For example, a routine runs every few minutes that FTP’s a list of the bank’s customers to vendors, a routine that retrieves lists of deposits from vendor’s FTP sites and deposits those funds to the bank’s customer accounts and a routine that accesses vendor’s web services to post debits to the customer accounts.

There is a web service (also written in VFP) that runs on the database server (local or cloud) that accepts deposits and debits from vendors and posts those credits and debits to the bank’s customer accounts.

The app has hundreds of system level settings so that each bank can tailor how the app’s bells and whistles are run for their particular site.

Speed has always been a challenge. It is a constant task to optimize. With the advent of RemoteApp this has been much improved as all users access the data locally (on the server). Printing to local printers has not been an issue. Use of USB devices like barcode scanners, magstripe readers and touchscreens (there are POS screens built into the app) have not been an issue as they are all in “keyboard emulation” mode so RDP has handled that wonderfully.

I should mention, setting aside the cost of licensing ($35.00 per user per month), moving all sites to use RemoteApp and cloud servers, is the current plan. I am in the process of making that happen.

At the same time, I am trying to think about what is next. Should I become a web app? If I can become a web app, my understanding is the licensing cost go away or are at least drastically reduced. I feel I should finally move to an MSSQL database and last but certainly not least, you don’t even want to tell perspective new customers that this is a FoxPro application.

This app has provided good income for many years but I am the sole developer and support. I am getting old. I am trying to make the app outlive me. I would really like to turn my company into a business that will maintain this app after I am gone. I have the app in good shape. Support is getting easier every day. I currently have 20 customer sites. I am ready to take on customers at a faster rate (there are potentially thousands). I believe the part I am missing is converting the app into something a company can maintain.

What should I do? What path should I take? These are very complex questions. Ask anything you like. I am seeking a path.

John

 

[Mike Lewis]

Hi John,

The first thing that strikes me is that this is really two quite separate questions.

First, you are seeking technical advice about whether to migrate the app to the web, which database to choose, and so on. These are good questions, and this is a good place to ask them.

Your other question is not a technical one, but rather a business one: how to go about bringing your product to a wider market, possibly in face of your withdrawal from the business. Although there are probably people here who will chip in with advice on this point, I think you would do better to find a business-oriented forum where you will find people with experience of this problems (which is not an unusual one). You wouldn't need to discuss the technical issues with them. In fact, doing so would just be a distraction.

It's not just a question of where you post your problem. More importantly, you need to separate out these issues in your own mind so that you can think clearly about each of them.

I hope this helps. I won't try to answer your technical points myself, as there are people here who can do so much better than me.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[cfsjohn]

Hi Mike,

Thank you for the very expert advice. "separating these issues in my own mind", now there is a real challenge. I do need to spend some real quality time trying to do that so when someone does offer advice I am better equipped to discuss it. I will be trying to do that...

Thanks again,
John

 

[JRB-Bldr]

I'll make an attempt to throw in my 2 cents worth...

Each site has a database server and the users access the database from personal workstations.

Renting separate server space for each individual client on a Cloud server provider would be quite expensive and your having to maintain the various servers for your separate client/customers could be a nightmare. And the database server software licenses for each separate one might add up to a considerable sum.

I might be wrong, but I think that once before I advised you to consider modifying your application architecture so that all clients worked off of a single database server.
Within that single database server you could, for privacy reasons, separate the clients data into their own set of data tables.

If this is financial information for your clients, you might want to take Security into consideration.

If that should be Important to you and/or your customers, you might want to consider using something like Micro$oft's SQL Server as your data 'backend' since it offers more security than VFP data tables.

Users access the app via RemoteApp

I would quite strongly suggest that for multiple clients, you get rid of RemoteApp access to your application. It too is a time intensive maintenance approach when multiple clients are involved.

There are ways to mix-and-match various software languages to get the job done.
One client of mine has a VB.Net 'front-end' for the users to use when accessing the application and, at the same time, there are VFP routines which are running stand-alone EXE's which are launched by Windows Scheduled Tasks to run the periodic background tasks such as FTPing data files, etc.

Regardless, if you put your application on the web you can work with VFP data tables or a full-blown database server like M$ SQL Server.

It sounds as though you might want to get your client's perspective (or that of your potential client's) on their need for Data Security and ease of access to the application. Once you have that it will help you make up your mind on the variety of issues under consideration.

Good Luck
JRB-Bldr

 

[cfsjohn]

JRB-Bldr,

Thanks for the awesome input. I started a much longer reply but went back and read your reply several times and realized that what you are trying to tell me about "application architecture" changes make a lot of sense and would probably be necessary to becoming a web based app or at least to maintaining one.

It has become obvious to me that I am not yet ready to have this conversation. I need to think about those architectural changes first.

I would appreciate your opinion on the following statement:
You mentioned "Data Security" and how MS-SQL Server is more secure. I understand that, but I believe (and please correct me), that is no longer an issue because my users can not get to the data folders when using RemoteApp. If my app is exited the user is taken back to their workstation. They have no means to access anything outside my app on the cloud server. There are no places in my app where a user gets to "point" to a server location like to save a report, etc where they may damage or overwrite or delete tables, etc.

As for the rest of this, let me do some more homework and I will be back...

Thank You,
John

 

[JRB-Bldr]

I believe (and please correct me), [Security] is no longer an issue because my users can not get to the data folders when using RemoteApp. If my app is exited the user is taken back to their workstation.

Yes it is true that your application limits what data any single user can see and/or access, but what if YOU (Your Data Server(s)) get hacked? The Hacker could 'vacuum up' ALL of your client's data.

Now would using something like M$ SQL Server prevent that? Not really. But their ability to 'read' the data would be a good bit more difficult than it would be if you were using VFP data tables.
Now for some forms of data this might be a "Who Cares", but for financial data it might be more important -- although the Personally Identifiable Information (PII) standards have broadened the Importance for some clients.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

I don't know the details of RemoteApp, but just browsing through

https://technet.microsoft.com/de-de/library/cc755055(v=ws.11).aspx

I see RemoteApp is based on an RDP file.

Once you have an RDP connection I think you can do more than the direct link to the remote application offers; you could use RDP command line tools to send all kinds of commands. Very simply speaking it compares to having an FTP link including login credentials to a specific file, then you can also use that connection to list directory and retrieve other files. Sinde the remote app can access them, so can the RDP session and user and so there is no barrier to access.

In regard of an SQL Server connection, the same applies, though, once you have a connection and granted rights to read/write data you can do so via this connection not only within an application limiting what you can do.

For that reason, it's a good choice to let each bank have its separate terminal server in the current state of your system.

Letting this grow into one cloud space you rent as Azure, AWS or google cloud space is enabling to scale up with less than a linear growth of costs and your customers, you or both may profit from that. The customers still can have separate VMs they run in, the goal should perhaps not be to have a single database anyway. Of course, the fewer resources and the less separation you use within a cloud space, the lower the costs for that, too, but there sure are pro/con arguments. A single database on a single instance, for example, can still have many schemas and logins each only seeing one schema. But you share the resource of the single server, and it won't scale up for any number of banks.

Bye, Olaf.

 

[cfsjohn]

JR-Bldr,

As for getting hacked and vacuuming up data, my app really has no data of the type hackers would be interested in. Yes, it is financial information but no credit card numbers or personal information. That is not completely true but it's close. Having said that I would not want that to occur. The cloud server hosting company is responsible for the server's security. Having said that I am always ultimately responsible. As for a move to MS-SQL server, it appears that one will have to wait. At this point it appears my path (really big picture) will be to access a VFP database, per each instance of my app. I have arrived at that conclusion from the information I am getting on this forum. It is subject to change.

Olaf, When my users are connected to the server I suppose there are ways to access the server's folders, etc. I am unsure how they would do that. I will pose that question to the cloud server hosting company and let you know what I learn.

I have decided to break this issue of dealing with "application architecture" into smaller pieces. The first item is one you guys probably understand much better than I. I have been coding FoxPro since 2.6 but still, and probably because I work in a somewhat sheltered environment by using a VFE Framework, have a difficult time with some of the basics, in this case "pathing". First, I believe this is an issue that needs to be resolved and I believe it has been raised because I want to move to a web app. History: My app started like most, run using a mapped drive from a workstation where the executable and database were on the server. At some point I figured out moving the executable to the workstations made it run faster (and I believe there were other benefits) so that was implemented. I finally did away with the drive mappings and began using UNC pathing. At some point it became necessary to run multiple instances of my app from any given workstation so user Joe could run ITF-Instance1 and ITF-Instance2 simultaneously. Each instance is completely separate with it's own directory structure, database, everything. I simply rename ITF.EXE to ITF-Instance1.EXE and ITF-Instance2.EXE. My users can only run any particular instance of my app once, so Joe can run ITF-Instance1 and ITF-Instance2 simultaneously, but Joe can only run either one once. I could not exactly put into words why I have that limitation but it is not a limitation my users have any issue with and I am not needing to change that. In case you are wondering, everything is coded for multi-user the best I know how.

As I think about moving to a web app, I am questioning the whole idea of multiple EXE's (like ITF-Instance1.EXE and ITF-Instance2.EXE). I am wondering if finding a way to only have a single ITF.EXE is preferable. I guess I am thinking if I had 20 instances of my app residing on one cloud server, it would be nice to only have one exe to upgrade. More than what would be "nice", I am wondering if that isn't required when I become a web app. I have very little comprehension of "web apps" but it just seems there would only be the one exe. It also seems there would only be one directory structure even if there is a separate "DATA" folder per instance of my app.

Once I start thinking about one exe and one directory structure, I start thinking about pathing, meaning understanding it completely and what would need to be done to my app so multiple instances of my app all use the same exe but (and I believe better for now) each instance with it's own database.

Before I go any further and get into questions about exactly what to do to my app with regard to pathing to make this work, I should probably stop and ask if you guys think I am headed in the right general direction.

Thanks,
John

 

[foxincloud]

I have very little comprehension of "web apps" but it just seems there would only be the one exe.

John,
A web app runs behind a Web Server (eg. IIS, Apache, etc.).

When the Web Server receives a request (through the http protocol),
[ul]
[li]if an executable module is mapped to this request (generally based on the URL's extension; eg. in

http://domain.com/page.ext,

'.ext' is mapped to an executable module), the Web server passes the request to this module[/li]
[li]else it looks for a file named like the request and delivers it,[/li]
[li]else it sends a 404 error back.[/li]
[/ul]

Web server and executable module communicate through CGI (Unix) or ISAPI (Windows).

The executable module processes the request using a program and sends back a http response according to a certain MIME type: [tt]text/html, text/xml, text/json, text/plain, excel/application[/tt], etc.

The program can be written in any language that can deliver a MIME type that the client (browser) can understand; most MIME types being just text, VFP is a good candidate to deliver an http response.

As a Web Application provider, VFP can work in 2 modes: file-based or automation (COM/COM+).
[ol]
[li]In file-based mode, the ISAPI module (see above) writes a file in a pre-defined location polled by one or several VFP .exe running with a timer. The first VFP exe finding a request processes it and writes the response in the same location; the ISAPI module sends this response back to the browser through the Web Server.[/li]
[li]In COM (.exe) or COM+ (mtdll) mode, the ISAPI module (see above) holds a set of VFP objects based on an 'OLEPUBLIC' class and passes the request to the first free object for a request-response process similar to what 1. describes.[/li]
[/ol]

Given the way this works, you have no control over which 'program' (exe or COM) processes a request from a given user.

Here comes (one of) the main constraint and challenge of Web Applications -- maintain user's state:
[ul]
[li]Each request must provide an identifier for a user; generally through a cookie linked to the site[/li]
[li]Based on this identifier, the Web Application (whatever language it is written in) must 'remind' whatever previous action of this user that can influence the current action[/li]
[li]After the request is completed, the application must store the user's action in some history[/li]
[/ul]

For example, it the user clicks a button and the action behind this button depends on a set of radio buttons, the program must know which choice the user has previously made on these radio button to choose the proper process.
Running one instance of program per user, a desktop application naturally persists the user's state in properties of the form and form members, or whatever other dedicated storage such as cursor, public variables, _screen.properties, etc. It's a bit more complex for Web Applications.

I understand you use multiple programs (exe) on the client workstation to address several sets of data. On a Web application you could either:
[ol]
[li]keep this strategy through several Sites / URLs ([tt]

http://app1.company.com/,

http://app2.company.com/,

etc.[/tt])[/li]
[li]merge your databases into a single one addressed by a single application; users could open several instance of the same form in different browser tabs or windows (with a .Init() parameter to query/filter the proper data set)[/li]
[/ol]

In strategy (1), each application instance is installed in a separate folder with the same sub-folders and its own database; relative pathing works the same for each instance: [tt].\data, .\images, etc.[/tt]

HTH,