We are working on a WCF webservice that uses .Net open client to integrate mfg/pro with a cloud based CRM. Our setup is as follows:
* mfg/pro (and Progress) is running on Unix,
* WCF webservice (that communicates with CRM and mfg/pro) is hosted on IIS in a Windows box.
During development, the sample Progress database, OE Appserver and WCF webservice were all deployed on a single windows box, hence it wasn't a issue then.
Currently we've the OE Appserver running on the Windows machine. Is the Appserver suppose to run on the Windows machine or Unix box where mfg/pro is running?
|
Thanks Mike for your prompt reply, much appreciated.
If the Appserver is running on the Windows box, how should I configure it to connect to mfg/pro database on Unix? Can you please direct me to some resource that discusses this?
The issues here I guess are:
1) Since there are two different OSs involved, where is it preferable to put the Appserver (Windows vs. Unix)?
2) How should I configure the Appserver to connect to database on Unix (if I place it on the Windows box)?
The AppServer will have faster access to the database if it is on the same machine as the database.
True, if you've never experienced remote client/server database connectivity (-H -S) then that will be a very long learning process. It takes quite a bit of time to configure the database startup parameters ("SERV"ers) to support remote clients properly. And, on the development side of things, all your ABL runs quite a lot slower than it does with "shared memory".
There are also a number of management-related issues that you may be confronted with. For example, "shared memory" clients are auto-trimmed whenever the database is restarted, but your remote client/server processes may need to be restarted manually because they don't recover very well on their own.
If this is a new application, and you can afford the licenses, then you may want to look at investing in PASOE rather than "classic" appserver. PASOE has a lot of features that you might benefit from. The features may even allow you to bypass WCF in the scenarios where WCF is doing nothing more than working as a middle man. Personally I love WCF and would probably use it either way, unless it caused additional problems.