Undetected Unsupported Features

PowerServer supports nearly 100% of PowerBuilder features, because it runs PowerScript natively (just as desktop apps). However, in certain scenarios, PowerBuilder code may not function correctly in PowerServer, and 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

In PowerServer, 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

Runtime Performance

The runtime performance in PowerServer will not be as fast as in a traditional PowerBuilder 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: API Authentication

Error handling and debugging

In PowerServer's n-tier architecture, errors may occur in different layers and require different diagnostic approaches.

In a traditional PowerBuilder application, the client typically communicates directly with the database. In PowerServer, the execution path involves multiple layers, including the client, network, Web API layer, and database. As a result, issues may originate from any of these layers and can occur at different project stages such as build, deployment, installation, and runtime.

Understanding common error patterns can help quickly identify where the issue comes from and find solutions faster.

To facilitate error-handling at different lifecycle phase, refer to the following resources: