PowerServer Coexistence Architecture

Overview

PowerServer (by Appeon) enables the PowerSeller Desktop App to run as an "Integrated Cloud App" — users get the familiar PowerBuilder UX while the database moves to the cloud. This creates a coexistence path where the Desktop App and PSSaaS share the same database, allowing incremental migration without a rip-and-replace.

Architecture

How It Works

Today (Hosted on VMs)

Each Desktop App customer has their own VM in IBM Softlayer with a local SQL Server instance. The app runs directly on the VM and talks to SQL Server locally. This is expensive to maintain, hard to scale, and isolates each customer's data.

PowerServer Model (Target)

1. User downloads a stub launcher — a small Windows executable that connects to PowerServer
2. Stub fetches PowerBuilder binaries — the compiled PB application files needed to run the Desktop App locally
3. App runs on the user's PC — same UX, same windows, same keyboard shortcuts, same everything
4. All database calls go through PowerServer's Web API — instead of direct SQL Server connections, every COMMIT USING sqlca goes through an HTTP intermediary
5. PowerServer communicates with Azure SQL MI — the actual database lives in the cloud, not on the user's PC or a VM

PSSaaS Coexistence

Once a customer's data is in SQL MI, PSSaaS can access it:

• Same database, same tables — PSSaaS reads and writes the same pscat_/rmcat_/pxcat_ tables as the Desktop App
• Incremental module adoption — the customer starts using PSSaaS for Pipeline Management while continuing to use the Desktop App for trading and risk
• No data migration — the data is already in SQL MI; PSSaaS just connects to it
• Gradual UX transition — workflows move from Desktop App to PSSaaS one at a time, at the customer's pace

Migration Path

Phase	App	Database	Status
On-Premises	Desktop App (local)	Customer's SQL Server	Some customers today
Hosted (VM)	Desktop App (on VM)	SQL Server on VM	Most hosted customers today
PowerServer	Desktop App (local PC via stub)	Azure SQL MI	POC with MWFI
Coexistence	Desktop App + PSSaaS	Shared SQL MI database	Target architecture
Full SaaS	PSSaaS only	Azure SQL MI	End state

Key Benefits

For Customers

• No workflow disruption — they keep using the Desktop App they know until PSSaaS modules are ready
• Immediate cloud benefits — data in SQL MI means better backup, disaster recovery, and accessibility
• Gradual learning curve — adopt PSSaaS features at their own pace
• No double entry — both apps share the same data, no sync issues

For PowerSeller

• Eliminate VM hosting costs — no more IBM Softlayer VMs per customer
• Consolidate infrastructure — all customer databases on one SQL MI instance
• Prove PSSaaS incrementally — customers try one module at a time, not a big-bang migration
• Retain customers during transition — nobody is forced to switch until they're ready

For MWFI (Pilot Customer)

• Already on SQL MI — PS608 database exists, AVD proof-of-concept works
• First to get PSSaaS modules — Pipeline Management, then BestEx when agency delivery starts
• PSX integration — PSX trade execution flows directly into PSSaaS Pipeline
• Design partner — shapes the coexistence experience for future customers

Pre-PowerServer Integration: PSSaaS Connector Plugin

Customers who haven't migrated to PowerServer yet (Desktop App with local or hosted SQL Server) can still benefit from PSSaaS through a plugin that connects to the PSSaaS API over the internet.

How It Works

1. User clicks "Sync from PSSaaS" in the Desktop App menu
2. The plugin calls PSSaaS API endpoints over HTTPS (internet-accessible)
3. PSSaaS returns trade data, BestEx results, pipeline status as JSON
4. The plugin writes the data directly to the local psbid_loans, rmcat_bestex_analysis, or other tables
5. The user continues working in the Desktop App with the data already populated

Plugin Architecture

The Desktop App already has a plugin architecture — 26+ rate sheet plugins as separate PBLs. The PSSaaS Connector would follow the same pattern:

• PowerBuilder shell — menu integration, DataWindow display, user interaction
• C# component — HTTP client, JSON parsing, API authentication (Tom is comfortable with C# for plugins)
• Configuration — PSSaaS API URL, authentication credentials, sync preferences stored in pxcat_site_plugins

Integration Paths by Customer Location

Customer Location	Integration Path	Database Sharing
On-premises (own SQL)	Plugin → PSSaaS API (internet)	No — plugin writes to local DB
IBM Softlayer (hosted VM)	Plugin → PSSaaS API, or PSSaaS → hosted SQL directly (PowerSeller controls the network)	Optional — PSSaaS could write to hosted SQL
PowerServer + SQL MI	No plugin needed — shared database	Yes — both apps use SQL MI
Full PSSaaS	Desktop App retired	N/A

What the Plugin Enables

• PSX trade data flows into the Desktop App without manual import
• BestEx results pre-computed by PSSaaS appear in the Desktop App's BestEx worksheet
• Encompass sync status visible in the Desktop App (PSSaaS pushed to Encompass, plugin shows confirmation)
• Pipeline status from PSSaaS visible alongside Desktop App workflows

Build Considerations

• Tom can build this — it's a PB plugin with C# for the HTTP/JSON layer
• No changes to the Desktop App core — it's an add-on PBL
• Works for any customer regardless of database location (the API call is over the internet)
• Natural stepping stone — customers get PSSaaS value before committing to PowerServer or full SaaS migration

Open Questions

PowerServer Transaction Semantics

Status: Research needed (backlog item #9)

The Desktop App uses manual transaction management via n_cst_transobj with COMMIT USING sqlca and ROLLBACK USING sqlca. When these SQL calls go through PowerServer's Web API instead of a direct database connection:

• Are transactions preserved across multiple SQL statements in a single PB event?
• Is the isolation level maintained (READ COMMITTED by default in PB)?
• How does PowerServer handle transaction timeouts?
• Can PSSaaS and PowerServer write to the same tables simultaneously without deadlocks?

Tom's PowerServer evaluation work will answer these. This is not a blocker for the coexistence architecture, but it affects implementation details.

Concurrent Write Safety

When both the Desktop App (via PowerServer) and PSSaaS write to the same tables:

• Low risk tables — pscat_instruments, pscat_companies, pscat_trade_counterparties are configuration data that rarely changes. Concurrent reads are fine; concurrent writes are unlikely.
• Medium risk tables — loan, pscat_trades, pscat_pools are operational data. Both apps might update loan status or create trades. EF Core optimistic concurrency and SQL Server row-level locking mitigate this.
• High risk tables — rmcat_bestex_analysis, rmcat_todays_prices are analysis output. These should be owned by one app at a time. If PSSaaS runs BestEx, the Desktop App should not simultaneously run its BestEx for the same profile.

Ownership boundaries per module will be defined as PSSaaS modules are activated per customer.

PowerServer Licensing

PowerServer is licensed by Appeon. Costs, per-user licensing, and deployment requirements need to be evaluated by the CTO. This is a business decision, not a technical one.