Modernizing the ADF non-PO coding form in WebCenter AP

Who this is for

The AP or ERP application owner whose WebCenter AP estate codes non-PO invoices through a custom ADF page, and who is tired of every coding-rule change becoming a JDeveloper project. Also the programme lead on an EBS-to-Fusion move who cannot yet say what happens to that page on the other side.

What the form actually is

In a typical WebCenter AP implementation the non-PO coding form is an Oracle Application Development Framework page: a JSF user interface built in JDeveloper, backed by ADF Business Components and task flows, deployed as an EAR to WebLogic Server beside WebCenter Imaging and the SOA stack. It is the screen an AP user opens when there is no purchase order to match against, to assign charge accounts, cost centres, projects, funds, departments, locations and whatever other dimensional posting the chart of accounts requires.

On most estates the page has been customised for years. Fund accounting rules, encumbrance logic, segment defaulting, validation hooks, lookup tables specific to the chart, and custom Java in the backing beans have accumulated one requirement at a time. Submission usually routes through SOA composites for approval and onward to the EBS Payables Open Interface or Fusion FBDI and OIC for posting, so the form's payload structure is part of a contract with those composites.

Why it is the piece that gets raised first

Four reinforcing reasons, heard in almost every conversation about a WebCenter AP estate.

• Every rule change is a development cycle. Adding a fund, changing a default cost centre, extending a validation: each one means opening JDeveloper, editing the page or a backing bean, rebuilding the EAR and redeploying to WebLogic. The AP team cannot self-serve.
• The change needs senior ADF hands. Working confidently across ADF Faces, ADF Business Components and task flows is a specialised skill set, and lining it up takes time. Small changes wait.
• The user experience shows its age. Pages designed in the early 2010s carry dense tables, limited keyboard support, browser compatibility quirks and no useful mobile story. AP teams who use modern tooling elsewhere feel it at the coding step.
• It is coupled to the SOA composites. The submit handler, the payload and the validations are woven into the composites that route the coded invoice forward. Touching the page without an SOA-aware review risks approval routing, encumbrance checks or posting.

A fifth reason arrives with the ERP programme: on an EBS-to-Fusion move, the ADF form is often the component nobody can confidently place on the far side, and the non-PO coding experience becomes the long pole.

What modernization means here

It does not mean a fresh coat of skin on the same backing beans. It means moving the coding rules out of compiled Java and into configuration an AP team can maintain, on a page that works in a current browser, while preserving the Oracle integration underneath: Payables Open Interface for EBS, FBDI and OIC REST for Fusion. The ERP stays the system of record. Vendor master, GL, payment and period close do not move. Audit detail — who coded, who approved, when it posted, the coding history — is preserved in full. Roles and the separation between coder and approver map onto the existing security model rather than replacing it.

What the rule inventory has to capture

Whatever the target, the inventory is the specification, and it is only useful if it is complete. From the page, its definitions and the backing beans we extract:

• Segment population. Which chart segments the form exposes, in what order, and which are derived rather than entered.
• Defaulting hierarchy. How each segment defaults — from the supplier, the invoice header, the requester's department, the previous line — and in what precedence.
• Validation and cross-validation. Field-level checks, cross-segment rules, fund and period-of-availability restrictions, encumbrance and budget checks, and which of those call out to EBS or Fusion in real time.
• Lookups and reference data. Every lookup table and value set the page reads, and where each is maintained today.
• Behavioural logic in Java. Anything in a backing bean that is neither defaulting nor validation: split rules, tax handling, tolerance handling, hidden fields that drive routing.
• The payload contract. The exact structure the submit handler passes to the SOA composite, field by field, because the approval routing downstream depends on it.
• Security and roles. Who can open the form, who can override a default, and how coder and approver are separated.

That list is what turns "modernise the coding form" from a slogan into a scoped project.

Four options for the target

Option 1 — Refactor on ADF 14c

ADF has a 14c release (14.1.2) on WebLogic 14c, so the page can move forward with the rest of the estate in the WebCenter 14c upgrade. The modernization work is then internal: pull the rules out of backing beans into externalised configuration (database-backed rule tables, ADF Business Components validators driven by data, or a Business Rules dictionary the SOA tier already uses), fix the browser-compatibility problems, and keep the payload contract with the composites intact. This is the lowest-disruption option and the right one when the estate is staying on EBS and WebCenter for the long run.

Option 2 — Rebuild the coding step on current Oracle tooling

Where the ADF page has more workaround than logic, a rebuild on Oracle's current application tooling — with the rules held in configuration from day one — can be cleaner than a refactor. The rebuilt page posts through the same Oracle-supported interfaces and hands off to the same SOA composites, or to a simplified routing layer. The rule inventory is the specification.

Option 3 — Fold the coding step into Fusion Payables

If the ERP is moving to Fusion Cloud, the non-PO coding step can live inside Fusion Payables itself — invoice entry, distribution sets and account rules, with Fusion's approval rules carrying the routing. This retires the ADF page and its SOA coupling entirely. The question is how much of the accumulated rule set Fusion configuration can express cleanly; the WebCenter AP to Fusion guide sets out how to decide.

Option 4 — A separate configurable AP layer

A separate AP platform — whichever the organisation selects — carries the coding screen, with the rules held in its configuration, and posts to EBS through the Payables Open Interface or to Fusion through FBDI and OIC REST. This suits estates that also want to consolidate capture, extraction and approval on one layer. It adds a platform to govern and an integration that must be designed against Oracle-supported interfaces only.

The engagement shape

1. Read the existing form. The ADF page, backing beans, Business Components, custom Java, and any Content Server or workflow hooks around it. Extract the coding rules, defaulting logic, validation behaviour and approval routing into a structured inventory the customer keeps regardless of the next step.
2. Classify every rule. Configuration, configurable hook, or retire. Rules that exist only to compensate for ADF limitations usually go away.
3. Choose the target against the inventory and the ERP direction.
4. Preserve the integration pattern. Same column conventions into the Payables Open Interface for EBS; FBDI and OIC REST for Fusion. No direct writes to base tables, no unsupported back channel.
5. Decide the approval hand-off. Keep the existing composite behind the same payload contract, or re-express routing in the new layer and simplify the SOA tier.
6. Parallel run through UAT. AP users code a sample set in both the old form and the new step; the resulting GL distribution lines are reconciled line by line. Cutover only after end-to-end posting validation.
7. Hand the configuration to the AP team. After cutover, adding a fund or changing a default is a maintained setting, not a redeploy.

How ECMWorks does this

We begin with a fixed-scope read of the running ADF form and the composites around it — page definitions, backing beans, Business Components, custom Java, and the SOA payload contract — and deliver the rule inventory with each rule classified. That document stands on its own. From there we deliver the chosen target: the ADF 14c refactor with externalised rules as part of a WebCenter 14c programme, the rebuilt coding step, or the Fusion-side configuration and hand-off design, through parallel run and cutover. For pages customised over many years, the reverse-engineering is the load-bearing phase and we size it as its own milestone before any build begins.