Hi Sean;

  This is where PB and PowerServer Web/Mobile come into picture. One App code-line maintained in the PB IDE but run-able across Windows, iOS and Android platforms.

Regards ... Chris

Yes, we have quite a few customers that are using a since PB code base to deploy both as a client/server on-premise app and a PowerServer Web app in the cloud.  Aside from the difference in DB connection there are some unsupported features.  Include the appeon_workarounds.pbl (usually located in C:\inetpub\wwwroot\appeon\developTempFile\appeon_workarounds) in your project and use the of_getclienttype() to run certain code if "WEB" or if "PB": https://www.appeon.com/support/documents/appeon_online_help/pb2017r3/workarounds_and_api_guide/ch01s03s01.html#of_getclienttype_function

i am doing a session at elevate this year that covers issues that i had to figure out in moving a commercial app to be able to run both as C/S and web from a single code base.

I saw afterwards that this was category "PowerServer WEB", my answer is about "PowerBuilder\IIS", sorry for that.

Hi,
yes we have done it, when we migrated our middle-tier from components in EAServer to web apps in IIS a couple of years ago.

A little history:
We had to switch all our requests in the old client from requests over Corba to requests over Soap, it was over 700 of them.
We made the decision to make an abstraction layer between the client and the server, something like this.
Client:
Client business object - wsclient ->
Server:
wsserver -> server business object

We refactored the server side code into about 25 web apps.
The wsserver object is a dispatcher to the real code and we started with only one exposed operation who could serve it all, but we extended it to 8 operations. The client will only call operations in the wsclient who is responsible for the actual request over Soap to the wsserver object.

So, to the point:
Then we made a C/S target too.
We included all our pbl's in the client target except for the wsclient component.
We included all the pbl's in the 25 web apps except for the wsserver component.
We made a new wsclient component that does a create on the wsserver component instead of doing a SOAP-request.
We made a new wsserver component that is the aggregate of the 25 in the web-apps.
Not so much extra coding to do, because most of the logic is inherited, but we opens the db-connection at client start up and closes it when the application shuts down, that's the main difference. This is done in the wsserver objects so it was easy to switch.

Why we did it.
It's very valuable when developing server side logic. We can develop in the C/S client and run it there, through the debugger if we want to. The time developing this client has been payed back many times over.

Of course we can't run code inside conditional compilation this way, eg. "IF DEFINED PBDOTNET", WinForms is not supported anymore. In the future, if we converts to the new C#-possibilities coming in PB2018, I think it's the end of this client.

A side note: We're not using the SoapConnection object in the client, but we made a COM-object ourselves to get compliant with TLSv1.2 at the time (PB12.6). And we're not going back because the SoapConnection object in the client, at the time, was very slow and our users were not happy.

Regards
Tor Ingvaldsen