As-Is Architecture

Topology

• Client: a 32-bit PowerBuilder application (originally PB 11, migrated to Appeon PowerBuilder 2022 R2 per homer.xml), deployed as homer.exe plus one .pbd per library. All business logic runs on the client.
• Database: Oracle, connected via native driver with AutoCommit=1 and DisableBind=1 (literal SQL). Connection profiles live in HOMER.INI ([ORACLE PRODUCTION], [ORACLE TEST], …); credentials are entered at login.
• No middle tier. The database is the only shared state; a handful of stored procedures exist (e.g. sp_aetna_enrollment, sp_rule_defs, sp_rule_contingency_defs), otherwise all SQL is issued from the client.

Application framework

• Built on the PFC (PowerBuilder Foundation Class) framework — the pfc*/pfe* libraries — providing MDI frame services, DataWindow services (sort, filter, row management), error handling, and transaction management. These 8 libraries are infrastructure, not business logic, and do not need functional migration.
• base extends PFC with HOMER's own ancestors: w_sheet (standard MDI sheet), w_maint_selection/w_header_detail_maint (standard maintenance-screen patterns), u_homer_dw (standard DataWindow control), w_homer_wizard (wizard pattern). Most of the 546 windows inherit from these, so screens share consistent behavior: select-then-edit flows, save/cancel semantics, row-level validation on save.
• The application object (homer/homer.sra) instantiates n_cst_sfpiappmanager (homersys), which handles login, INI reading, connection, and opens the MDI frame w_sfpi_frame.

Navigation model (important for migration)

Navigation is data-driven: the system_menu table stores the function tree (captions, window names, parameters). w_system_menu reads it, filters by the user's security class, and opens sheets via OpenSheet/OpenSheetWithParm on the window name stored in the row. Menu bars on individual sheets are mostly local actions (save, close, print), not global navigation.

Consequence: the definitive list of user-reachable functions lives in database data, not code. The migration must export system_menu (and the security tables that filter it) to enumerate the production navigation tree. Until then, the Traceability Matrix enumerates every window and what it touches, which is a superset of what any user can reach.

Configuration

HOMER.INI sections observed:

• [SETTINGS] — logo/help paths, DB profile selection, SQL spy log, archive dir
• [APP PREFERENCES] — behavioral flags (e.g. directtomember, memberidletter), export paths for PBM/enrollment/withholding file exchange, client segment=SFPI
• [ORACLE *] — named connection profiles
• [Paths] — Melissa Data address-data locations and license key
• [ErrorLog] — client-side error log path

External integration points

Integration	Mechanism	Evidence
PBM — PCS/Caremark	File/table exchange of eligibility & drug claim transactions	drug_covr_pcs_*, caremark_edi_table, pcs_path/exp_path INI entries
Outbound claim EDI	Staging tables written per claim/line/provider/patient	outbound_edi_* tables (claim, line, provider, patient, ub92, dental)
Aetna enrollment	Stored procedure	sp_aetna_enrollment
Address validation	Melissa Data COM/DLL objects, local data files	mdAddr.dll, AddrObj.dll, [Paths] in INI
Check printing & 1099s	Printed forms from DataWindows; print_1099s table	funding/reprint libraries, 1099-NEC form images in app dir
Withholding export	File drop to accounting share	witholding= INI path

Known technical debt / migration-relevant constraints

• Client-side 2-phase logic with AutoCommit=1 means multi-statement operations rely on application sequencing, not transactions — behavior to examine per workflow during migration.
• DisableBind=1 (literal SQL) implies the schema tolerates implicit conversions; exact server-side types must come from DDL.
• Heavy use of Oracle-specific SQL (outer-join (+) syntax, dual, sequences) inside DataWindows.
• Local file-system dependencies (INI, network shares, Melissa Data files) are per-workstation state.