Academy / Week 2 / Sync Mechanics Deep Dive / Debugging On-Prem PMS with RPCs

Debugging On-Prem PMS with RPCs

Lesson 7.3 ⏱ ~3 min Week 2

💡 Why This Matters

On-prem PMS integrations introduce a debugging surface that differs fundamentally from cloud-based sync apps — you can't rely solely on Kubernetes tooling. Knowing how to send RPC commands directly to a running SyncApp, whether on-prem or cloud, lets you verify writeback logic and simulate full flows without triggering costly end-to-end test runs. This skill directly reduces time-to-resolution on writeback bugs in production offices.

🎯 What You'll Learn

  • How to verify connectivity to both on-prem and cloud SyncApp instances using the ping RPC command
  • How to use WAM's 'send command' feature to dispatch RPC calls to a running SyncApp
  • How to retrieve system-level host and OS information from a SyncApp via RPC
  • How to simulate a writeback by sending a targeted RPC payload instead of running the full NWX flow
  • How on-prem logs differ from cloud logs and where to access each
  • How RPC controllers are wired in source code to route writeback logic into the PMS database

▶ Watch Video

Open in Google Drive 💡 Open in Drive for AI-powered transcript search and summaries

📋 Lesson Summary

The lesson demonstrates debugging on-prem PMS integrations using two SyncApp instances as examples: Eaglesoft 18 running on-prem inside a VM, and NXT running in the cloud. Connectivity for both is verified via a ping button in WAM, which logs the result as a received RPC message. WAM's 'send command' feature dispatches RPC calls to either instance — a basic system-level command returns hostname and OS details directly in the logs. A real-world Eaglesoft writeback bug is used as the core example: the issue prevented a patient's birth date from being updated in the PMS when the existing PMS value was null or zero, even when a valid birth date existed in Weave. After fixing the handling logic and rebuilding the SyncApp, the fix was validated by sending a writeback RPC payload targeting Patient ID 191 with a birth date of 1960 — bypassing the full NWX flow entirely. The PMS confirmed the update after reopening the patient card. In source code, these RPC calls route through exposed RPC controllers that execute writeback logic directly against the Eaglesoft database. On-prem logs are tailed live in the VM terminal, while cloud SyncApp logs are accessed via kubectl in a local terminal.

🏷 Key Concepts

RPC (Remote Procedure Call)WAM send commandOn-prem SyncApp debuggingWrite-back simulation via RPCEaglesoft writeback bugOn-prem vs cloud log accesskubectl log tailingRPC controllers in source codePing connectivity verificationSyncApp on-prem VM terminalUseful RPC Commands reference docPMS database update validation

⭐ Key Takeaways

01Always verify SyncApp connectivity first using the ping RPC command before investigating deeper writeback or sync failures
02Use WAM's 'send command' to dispatch RPC calls to both on-prem and cloud SyncApp instances without needing direct code changes
03Never run the full NWX flow just to test a writeback fix — send a targeted RPC payload directly to simulate and confirm the update
04Check on-prem SyncApp logs in the VM terminal directly; use kubectl to tail logs for cloud-based SyncApp instances
05Handle null or zero PMS field values explicitly in writeback logic — do not assume a missing value means no update is needed
06Reference the 'Useful RPC Commands' document when constructing payloads to ensure correct command structure and available methods

🔗 References & Resources

📎 Additional Materials