Undetected Unsupported Features

In certain scenarios, PowerBuilder code may not function correctly in PowerServer, yet the compiler does not report any errors. This can lead to unexpected behavior during runtime. It is therefore essential to thoroughly review the Unsupported Features Guide and conduct comprehensive testing before deployment. The documentation provides valuable insights into potential compatibility issues between PB code and PowerServer's cloud-native architecture.

Reference: Unsupported Features & Workarounds

Database Connectivity

Database connectivity in PowerServer differs significantly from traditional client/server applications. In PowerServer, the architecture is cloud-native, and database interactions are handled by .NET rather than PowerScript. We have made great efforts to replicate most of the PowerBuilder concepts (e.g., transaction objects, LogID/LogPass), but there is one critical aspect you need to carefully evaluate is whether your application requires LongConnection to be enabled. By default, LongConnection is disabled. It is important to assess if enabling this feature is essential for your application to work properly.

Reference: Long Connection

PowerServer uses .NET data providers to connect with the database. Some DBParm properties such as DelimitIdentifier have different default values in .NET Core data providers vs. the native database drivers. If your application uses these DBParm properties, you would have to determine whether you need to adjust the default value for your application to work properly.

Reference: DBParm differences

Runtime Performance

The runtime performance in PowerServer will not be as fast as in a traditional PB client/server environment due to inherent differences in network architecture. This is a limitation of the cloud-native model rather than an aspect that can be significantly improved in future versions of PowerServer. However, with appropriate optimization, most users can achieve satisfactory performance.

To improve performance, implementing PowerServer Labels is a common approach. Labels help group server calls to optimize execution efficiency. For most applications, this will be sufficient. However, in some rare cases, additional performance tuning may be required.

Reference: Grouping Server Calls

Additional techniques for performance optimization: Performance Tuning

The only accurate way to evaluate the performance of your application is to deploy it with PowerServer and conduct real-world testing over an internet connection. Even if initial performance is acceptable, it is strongly recommended to implement PowerServer Labels for greater code efficiency.

Scalability

Scalability is closely related to runtime performance. PowerServer applications often exhibit performance issues in a server-based environment that may not be apparent during single-user testing. In multi-user environments, problems such as slow performance, blocked actions, or server crashes may arise.

The core issue stems from the way database-related code is handled. In a client/server setup, database code executes on each user's desktop. In contrast, PowerServer processes all database interactions on a central server, which may cause scalability issues if not optimized.

Common examples of database-related code include: DataWindow.retrieve, DataWindow.update, Embedded SQL.

To properly assess scalability, a beta rollout with real users is essential. Testing with a limited number of developers will not simulate realistic usage. Although load generation tools can simulate high user volumes, they may not fully replicate the diverse user scenarios your users will encounter.

Web API Security

Since PowerServer uses standard Web APIs, implementing user authentication in the Web API layer is critical. This requirement applies to both the PowerServer-generated Web APIs and any custom Web APIs you create. Without this authentication step, malicious users could potentially guess the Web API URL and gain unauthorized access to your users' data, posing significant security risks.

Before deploying your application to production, ensure that authentication is implemented correctly to protect the integrity of your users' data.

Reference: Authenticating Your Apps