From open interfaces and Concurrent Manager to governed entities

Replace a staging-table and batch-import operating model with Data Management Framework packages, OData, business events and Azure services — and recontract each feed by business event rather than repointing it at a new endpoint.

What you will be able to do

• Map each EBS integration surface onto the correct target pattern
• Recontract feeds by business event and consumer rather than by endpoint name
• Eliminate direct-table assumptions from inbound and outbound designs
• Design the extraction approach for the migration itself, not just for run-state integration
• Replace custom reporting SQL with a governed analytics model

Introduction

An EBS estate's integration layer is coherent and well understood by the people who run it: open interface tables receive inbound data, concurrent programs validate and import it, Integrated SOA Gateway and XML Gateway handle service and message traffic, Web ADI covers controlled spreadsheet entry, and everybody who needs data reads the…

The surfaces and their targets

The named inbound interfaces in the source material are worth listing because they are the ones a client will recognise: GL_INTERFACE, AP_INVOICES_INTERFACE with AP_INVOICE_LINES_INTERFACE, RA_INTERFACE_LINES_ALL, PA_TRANSACTION_INTERFACE_ALL, and module-specific staging with concurrent imports alongside them.

Recontracting: the exercise that shrinks the estate

Start from the interface catalogue, then deliberately stop using it as the design input.

Inbound: from staging tables to governed entities

The EBS inbound pattern is consistent and comfortable: load rows into a staging table, run a concurrent program, read the status columns to find out what failed, fix and rerun.

Outbound: split by consumer

Outbound extracts produced by concurrent programs divide cleanly once the consumer is known.

The Concurrent Manager gap

The gap register rates the Concurrent Manager and open-interface operating model as a high-impact integration gap, and the wording is precise: batch, scheduling and staging conventions are operationally central but not portable.

Web ADI and controlled spreadsheet entry

Web ADI is rated a medium-impact gap with a fair characterisation: target tooling covers many scenarios but not all Web ADI control patterns.

Reporting SQL is not an integration contract

The customisation register's note on custom views is one of the sharpest instructions in the whole source package: do not treat custom SQL as a target-state integration contract by default.

Extraction for the migration itself

This is the separate problem, and it belongs here because it uses the same skills and the same access.

Knowledge check

Summary

The EBS integration layer — open interfaces, Concurrent Manager, SOA Gateway, XML Gateway, Web ADI and direct SQL — maps onto Data Management Framework packages, OData, custom services, business events, Azure integration and the analytics estate.