1. Jeff Kandt
  2. PowerBuilder
  3. Friday, 5 February 2021 21:32 PM UTC

PowerClient looks very exciting as a way to solve the perennial client/server problem of deploying code to clients! But I have questions about a couple of aspects that are making me think it’s not something we can use yet.

I haven't had any hand-on experience playing with PowerClient myself yet, so if I'm wrong -- great! Otherwise, I guess this boils down to a feature request post.

Roaming Profiles

In Chris Pollach’s Elevate session, we see that the App Shell is installed into the user’s \AppData\Local folder, but it appeared that the PB applications and runtime(s) were installed into \AppData\Roaming. For enterprises implementing Roaming Profiles, doesn’t this mean that all of that data is being pushed up to the profile server and then synchronized with the workstation on each login/logoff?

Our current deployed executable folder, which includes runtime dlls and exe/pbds, weighs in at almost 300 MB. Of that, more than 100MB is our application (exe + pdbs).

If each of our several hundred users are going to need to store that much data on the profile server, this is probably a non-starter for us, especially since we maintain multiple environments that correspond with code branches/releases, so some users (developers, QA, beta testers) will be running multiple versions of our app at the same time. (I presume we would need to publish those as separately named applications: AppName, AppName_QA, AppName_Beta, etc.)

When stored in the new deployment format (individual object files) can we expect the application footprint be larger or smaller on disk than current binaries?

Is there any way to configure that the deployed applications get installed into AppData\Local instead of AppData\Roaming?

Integration with automated build pipelines

I saw that PowerClient is not yet supported by the command-line PBC tool. Does that mean the ORCA interface doesn’t support it yet either? Until PowerClient deployments can be automated as part of a CI/CD pipeline (we use TFS and PowerGen), I’m having a hard time working out how this could fit into our process.

For auditability, the builds we hand off to QA, and that get certified for production, must be generated by the build server, to provide some assurance that all objects came directly from source control. As long as PowerClient deployments require a developer (or someone with a PB license) to manually build from local PBLs, that chain of custody from source control to production is broken.

Let me know if I’m missing something, but this also sounds like a show-stopper for us.

First launch experience

Chris showed that the first time the end user loads the application URL, the user is prompted to download and install the App Shell. I was disappointed that the installer didn’t immediately launch the PB app after that install completed. Chris had to go back to the browser and navigate to the URL again.

This one’s not a show-stopper by any means (in fact we would probably push the App Shell to clients separately in advance), just a suggestion: I think it would fit better with users’ expectations, and maintain the illusion of an application being “at” a URL, if the application always launched from the URL -- whether it’s the first time or not.


Thanks in advance for any clarification anyone can provide.

Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Friday, 5 February 2021 23:47 PM UTC
  2. PowerBuilder
  3. # 1

Hi Jeff,

Chris used a beta version of PB 2019 R3 to make that presentation.  We incorporated feedback from customers during the beta and the final version is polished, resolving all of your concerns except automated build with pipelines.  There was just not enough time to do this, and it is on our roadmap to definitely do this.

Roaming profiles

In the final release, you can configure where it is installed.  The default setting is the roaming folder.

The footprint would be very similar to what you normally get when you compile to p-code.  The additional thing is the Cloud App Launcher, but that is around 10MB.

First launch experience

You only need to launch the app the first time through the Web browser.  After first launch it will create desktop and start menu shortcuts (configurable), which you can use that every time from there on out.

There are two options for the launcher: to install with or without background service.  If you configure to install with a service, the app starts right away after the launcher is installed.  If you configure without a service, you need to click the "start" button in the HTML page to start the app the first time. 

Just to clarify, no matter with or without a service, it can create shortcuts and you can use the shortcuts always to start (including update the app).  It is not required to keep typing URL in the Web browser or clicking a hyperlink.

By default we do without a service so no admin rights are required on the machine.

Try PB 2019 R3

I encourage you to try the final release of PB 2019 R3 and send your feedback to our product management team at product@appeon.com so we can consider to further enhance this in PB 2021.

Best regards,

  1. Armeen Mazda @Appeon
  2. Monday, 8 February 2021 18:30 PM UTC
If you take a look at our roadmap page you will see this is planned for PB 2021: https://www.appeon.com/developers/roadmap#upcoming
  1. Helpful
  1. Jeff Kandt
  2. Monday, 8 February 2021 18:40 PM UTC
Armeen- Regarding fist launch experience -- which, again, isn't really an impediment for us -- I can foresee some use-cases where I wouldn't necessarily want to configure an app to install a shortcut. I'm intrigued by the idea of being able to launch someone into a PB app with merely a URL -- a hyperlink in an email or from another web page, as a substitute for a desktop shortcut rather than just a way to install one.

For instance, if I had a separate PowerClient deployment that's being built from a pre-release code branch, it might be useful to be able to send someone a hyperlink to get them in, temporarily, to preview and provide feedback on some new functionality, without cluttering their Start menu with a shortcut they may never need to use again. In this case it would be nicer if navigating to the URL for the first time installed and then launched so they didn't have to click it twice.

It's a pretty minor inconvenience, all things considered, just wanted to mention it.
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Monday, 8 February 2021 18:44 PM UTC
You can do that where you always launch through a URL/hyperlink... just uncheck the options to create shortcuts.

The same rules apply as I mentioned before. If the Cloud App Launcher is without a service the user will need to click a start button before the app starts. If the Cloud App Launcher is with a service the app will automatically start.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1

There are no replies made for this question yet.
However, you are not allowed to reply to this question.