HR application

Parity: 17 of 17 scenarios

Each scenario was recorded on the original and replayed against the migrated app. Three runs from a fresh database gave byte-identical diffs for every scenario; none has a defect. Open a scenario for its steps, screenshots of both apps, the golden record, the diff and its waivers.

• Match: the same value. Tolerated: different only within a written rule of the tolerance policy, here the signed APEX token, which changes on every click, and list-of-values rows the Forms client had not fetched yet.
• Waived: 2 waivers are proposed for the customer's decision; 2 of them cover 21 values here, where the migrated app deliberately does not copy the original (see waivers).
• Defect: a difference to repair. Unmapped: none; every recorded value has a counterpart in the migrated app.

The same app with an Angular front end: 17 of 17

The check does not depend on what the new interface is built with. This app has a second front end written in Angular on the same back end and API, and the same scenarios, mapping, tolerance policy and waivers check it: 17 of 17 scenarios at parity, 0 defects, three runs from a fresh database byte-identical, and every diff byte-identical to the default front end's.

The app is also rebuilt from native APEX components on its original Oracle schema, checked with the same scenarios: the APEX version.

Faithful to the original

The migrated app copies the original's behaviour, including what looks like a bug. These are the places a visitor will notice.

The interface is new; the behaviour is the original's, and the scenarios check it value by value. Some of that behaviour looks like a bug on a web page. It is kept on purpose, because the point of the demo is that nothing changed:

• Oracle message texts on a PostgreSQL app. FRM-40400: Transaction complete, FRM-40350: Query caused no records to be retrieved, FRM-40202: Field must be entered, FRM-40212: Invalid value for field and FRM-40505: ORACLE error are the original's messages, and the message line is part of the recorded behaviour.
• A search containing an apostrophe fails with FRM-40505: ORACLE error: unable to perform query. The original pastes the search text into its WHERE clause; the port reproduces the failure, not the injection.
• Search matches first name, last name and email anywhere in the text, ignoring case. An id such as 100 finds nothing.
• User names are case-sensitive: ALICE is refused, as in the original's login query.
• Create inserts the blank row below the current one and puts the cursor on its Details button, as the Forms CREATE_RECORD and the form's item order do.
• A list of values opens by itself when the cursor enters Dept. Id, Job Id or Manager Id, also when tabbing through a row. Its Find box matches the first column (the Id), as in Forms.
• Deleting an employee with job history is refused with "Cannot delete master record when matching detail records exist."
• Closing EMPLOYEES with unsaved changes asks "Do you want to save the changes you have made?" and the message line says "Press Tab to move between choices, Return to select."
• The record counter reads n/? until the list has been scrolled to its end, and it counts the block the cursor is in: on a toolbar button it shows Record: 1/1.
• Reload ends the session, as closing the Forms applet did. Log in again. The browser's Back closes EMPLOYEES while it is open, as its Back to console button does (the save question included); with only the console open, Back leaves the app.
• The APEX buttons (Home, Employees, Details) build a signed APEX link the way the original does and show it, token included, on the message line; the scenarios compare it with the original's URL. The link opens a stand-in page, not the original's APEX application (Forms + APEX). The original, on Forms 14.1.2, fails here with FRM-92022; the port opens the page instead (waiver H1).
• The Department tab of an employee without a department is empty. The original keeps showing the previous department's number there (waiver H2).

Deliberate differences that no scenario covers: Enter in the login and search fields presses Login and Search (Forms moves to the next field); the server requires a logged-in session for its data calls; the employee list scrolls with the mouse wheel and its own scrollbar.

Forms + APEX

The original HR app is a Forms + APEX hybrid. Its Home, Employees and row Details buttons compose a signed token (COMPOSE_URL, GENERATE_TOKEN) and open pages of a separate Oracle APEX application, hr_dev/hr-app, in a new tab. That APEX application is not part of the public source: the upstream repository at the pinned commit holds only the three Forms modules and the database code. It was therefore not migrated, and in the recorded original the buttons fail with FRM-92022 (waiver H1).

In this demo the buttons open stand-in pages under /hr/apex/ (/hr-ng/apex/ from the Angular front end). Each page says that it stands in for the APEX application, verifies the token as APEX would (signature, audience, five-minute expiry) and shows the data the APEX page would show. Migrating the APEX side would be its own scenario set, recorded on the APEX application.

Coverage of the original

Every trigger and program unit of the Forms modules, measured with Forms Runtime Diagnostics while the scenarios ran; database PL/SQL measured with DBMS_PLSQL_CODE_COVERAGE.

Decision branches: 32, of which 24 covered, 4 unreachable (retirement candidates) and 4 blocked. Database PL/SQL: 11 unit(s) in the coverage report, 13 of 13 blocks covered. Exit check: PASS.

Waivers

Source behaviour a customer would probably not replicate, proposed for the customer's decision. Each is pinned to the exact values it covers; the counts are values waived in the final diffs. File: waivers.yaml.

Waived: 2 waivers are proposed for the customer's decision; 2 of them cover 21 values here, where the migrated app deliberately does not copy the original (see waivers).