How it works
Three of these layers are fixed, because they are yours. The fourth is the part that's open to discussion.
Browser
|
web tier ← your choice
|
stored procedure ← integration boundary
|
RPG service pgm ← business boundary
|
Db2 for i
The distinction that matters as the system grows
The stored procedure is the integration boundary: how the web tier talks to IBM i.
The RPG service program is the business boundary: where the rules live.
Keeping them apart is what stops the integration layer quietly accumulating business logic of its own. It matters more the bigger the system gets, and it's very hard to retrofit later.
Your existing programs are not modified.
We add RPG service programs that expose business functions, and stored-procedure wrappers over them. The green screen keeps working exactly as it does today, on the same data, at the same time.
That means no cutover, no parallel run, no big bang. Old and new coexist indefinitely. And if you stop after Phase 1, nothing is left broken behind you.
Usually the fastest win
Most IBM i shops have hundreds of spool files, Query/400 outputs and hand-distributed CSVs. Those become screens: filter, sort, search, paginate, export to Excel or PDF.
The calculation logic stays exactly where it is. We change how the output is consumed, not how it is produced, which is why it's the lowest-risk work with the most visible result, and often where customers want to start.
What comes as standard
- SSO via Entra ID or equivalent, with MFA where the green screen can't offer it
- Role-based access control, default-deny on unknown roles
- Full audit logging: who did what, and when
- TLS throughout; on the on-box model, Db2 access is local and never touches a network
- Hardened against the OWASP Top 10, built to ASVS Level 2