I have ONE VFP/VFE app using a native VFP database engine (call it myapp). I have multiple companies/installations using myapp. Multiple instances of myapp are running on a single cloud server, so: c:\company1\myapp is home dir c:\company1\myapp\data is data dir for company1's installation of myapp c:\company2\myapp is home dir c:\company2\myapp\data is data dir for company2's installation of myapp etc Each instance of myapp is completely independent of another i.e. Company1's myapp does not know that Company2's myapp exists.

I have developed a website (nothing to do with FoxPro) that needs to pull data from and post data to, Company1's and/or Company2's system. The website will make calls to a WC REST service to accomplish that.

I am developing the WC REST service. Somewhere in the WC REST service I will need to point to Company1's system or Company2's system. I am trying to determine the appropriate place to do that.

wwServer has: OnInit() server specific configuration OnLoad() app specific configuration

wwProcess has: OnProcessInit() runs just prior to each endpoint's method in wwProcess

Assuming the website can provide some piece of information that will tell me which company's system it needs access to, it sounds like I would point to the appropriate company's system in the wwProcess::OnProcessInit() method. When I say "point to", basically I mean set the VFP data path.

Does that sound correct?

Thanks, John

There are a few ways that you can handle this:

• Use explicit, parameterized paths for everything customer specific
• SET PATH for each request (tricky)

Explicit Paths

The first can be a lot of work, if you don't use business objects, but otherwise you should be able to set the path at the business object (or framework) level for subsequent data access. If you do it explcitly, you just have to prefix any files referenced explicitly:

lcFolder = lcCustomerSpecificPath && from whereever you get this
lcCustTable = ADDBS(lcFolder,"CustomerData")

select * from (lcCustTable)  

*** or
USE (lcCustTable) in 0

Make sure you parameterize your paths in some way that is consistent - you don't want to hard code anything and have easy access to the path since you'll need it a lot!

SET PATH

You can also SET PATH on every request that comes. Essentially in OnProcessInit() you can re-write the entire FoxPro path to the 'default path' the application expects plus your custom path.

It's important you put your complete path handling into that code in case a request fails to reset it - better to make sure you have the correct path at the beginning of each request (in OnProcessInit()).

FUNCTION OnProcessInit()

*** Base path. Best to parameterize
SET PATH TO (this.oServer.cAppBasePath)

*** Or hard coded
* SET PATH TO "\myAppFolder;\globalData;\wconnect\classes;\wconnect"

lcTenant = "customerId"  && however you figure out your customer's tenant

*** Add tenant specific path
SET PATH TO "\data\" + lcTenant ADDITIVE

ENDFUNC

+++Rick ---

Thanks Rick. OK, I believe I understand the best place to set pathing.

I am going to ask a question that may not make any sense at all but here goes:

Years ago, I made my Soap based ASP.Net Web Service (the VFP part), a VFE project. It gets compiled into a MTDLL. IIS runs ITFWebService.asmx which if I understand correctly, calls the methods in ITFWeb.DLL. Those methods are OLE PUBLIC because the VFE application object is marked OLE PUBLIC.

For my WC REST service, can you tell me exactly what IIS is running?

Thanks, John

Trying to make progress on my WC Rest service. Looking at Rick's document for the Publishing example, where Rick says: "go to the deploy folder and launch your main EXE - Publishing.exe in this case. This starts the file based Web Server". OK, I get that so at this point publishing.exe is running and waiting on requests. When a request comes in, something, meaning some program or something, calls the publishingmain.prg passing values for lcAction, lvParm1, lvParm2.

1. I am creating a VFExpress application to mimic the publishing.pjx With a VFE app, the application object is set as MAIN in the VFE project so the application object is the project's starting point. I will likely be putting the code from publishingmain.prg in my application object's startup methods.

2. I do not have any option to change the parameters accepted by my application object.

So how do I receive the 3 parameters that publishingmain.prg accepts into my VFE application object?

Thanks, John

OK, I don't think I need that last question answered. I believe I can either do the configuration manually or can figure out a way to make the configuration a COM object (so a OLEPUBLIC method) inside my COM server and thus run it from the VFP IDE.

I do have a question. This is probably something most everyone except me would assume, but I am not much on assuming anything.

When running my COM server in FILE mode, I see the screen that lets you see the requests. That screen would NOT appear if running in COM mode. Is that correct?

Thanks, John

Rick, I am repeating this because when replying to my own threads, I am guessing you never get notified that I am asking you a question.

OK, I don't think I need that last question answered. I believe I can either do the configuration manually or can figure out a way to make the configuration a COM object (so a OLEPUBLIC method) inside my COM server and thus run it from the VFP IDE.

I do have a question. This is probably something most everyone except me would assume, but I am not much on assuming anything.

When running my COM server in FILE mode, I see the screen that lets you see the requests. That screen would NOT appear if running in COM mode. Is that correct?

Adding to this. I am reading everything I can find on the net. The above question has to do with my lack of understanding some basic things about VFP. I live a very "sheltered" foxpro life because the day I started using Visual Foxpro is the day I also started using the visual foxexpress framework. In 40 years of foxpro I have never issued a read events. Anyway, I found where you stated

COM objects and file based servers are managed completely differently. COM Servers are instantiated as COM objects - they don't have a startup program with a READ EVENTS loop, and there's no way to 'Close' a COM server. You can't even call QUIT from within a COM server to kill it. QUIT has no effect inside of a COM server.

So why is there a read events in main.prg which is what gets compiled into my COM server?

Thanks, John