All topics
37 / 60
Integrationintermediate

SOAP Web Services in Oracle EBS Integration Repository

Explain how EBS exposes SOAP web services through the Integration Repository for external system integration

The Integration Repository is EBS's catalogue of every supported way in. Before REST and iPaaS, SOAP services generated from it were the standard integration mechanism.

SOAP web services via iRep are like a hotel's international phone operator service: guests (external systems) speaking a standardized protocol (SOAP/XML) can request services (business logic) through the operator without needing to know the hotel's internal room-to-room extension system (raw PL/SQL API calls).

Key Concepts

1
What it catalogues.
    PL/SQL public APIs
    open interface tables
    concurrent programs
    Business Service Objects -- APIs exposed as SOAP services
2
Its first value is discovery, not SOAP. It tells you which interfaces Oracle supports for integration and which are internal.
3
That answers the question that otherwise gets answered badly: "how do I create a supplier from outside EBS?" The repository names the supported API. Without it people trace what a form does and call whatever they find, which is unsupported and changes at the next patch.
4
A Business Service Object wraps a PL/SQL API in SOAP. Select the API, generate the service, and it is deployed with a WSDL.
5
    external system  --SOAP/XML-->  BSO  -->  PL/SQL API  -->  EBS
6
The caller needs no database connection, no Oracle client and no PL/SQL knowledge. Any SOAP-capable platform can invoke EBS business logic, and the API's validation still runs because the BSO is only a wrapper.
7
Synchronous, which is the design constraint. The caller waits for the response. That suits a lookup or a single creation, and not a bulk load — a thousand records is a thousand calls, each waiting.
8
Where this sits now. New integration uses REST, and orchestration uses OIC. SOAP BSOs remain in service in a great many EBS installations, because they work and replacing a functioning interface has no business case.
9
The comparison interviewers ask for.
    BSO directly     point to point. Simple, no middleware, and the
                     caller must handle retries, mapping and errors.
    via OIC / SOA    orchestration: mapping, routing, retry, fault
                     handling and monitoring in one place, with
                     several systems involved.
10
One consumer and a simple call: the BSO is proportionate. Several systems, transformation, or anything needing retries and monitoring: put it behind an integration layer.
11
The point that matters regardless of era. Whatever the transport, go through a published interface. The repository exists so that the supported entry points are findable, and direct table access remains wrong whether it is reached by SOAP, REST or a script.
12
What the interviewer is probing.1. "What does the Integration Repository give you?" Probing: the purpose. Stalls: "Documentation." Moves up: the catalogue of supported interfaces — PL/SQL APIs, business events, concurrent programs — many of which can be deployed as services.
13
2. "What is ISG?" Probing: the vocabulary. Stalls: "A server." Moves up: integrated SOA gateway, which generates and hosts the SOAP and later REST services from repository interfaces.
14
3. "How is security handled?" Probing: the practical angle. Stalls: "A password." *Moves up:* WS-Security with a username token or SAML, with the responsibility and org context passed in the SOA header.
15
4. "Why do people still fall back to interface tables?" Probing: honesty. Stalls: "Laziness." Moves up: volume and setup overhead — ISG needs configuration and deployment, where a file and import program is already understood by the team.
Use cases:soapirepbusiness-service-objectlegacy-integration