Oracle Fusion Technical: Reports, Data, Integrations and Extensions · Module 10 · REST and SOAP: calling Fusion, and being called
Authentication and the service account
Lesson 100 of 177 · 2 min
The service account's ROLES decide what the integration can do, and that single fact explains the failure this lesson is named for. Authentication proves who is calling — basic auth or OAuth. Authorisation decides what they may do, and it is the same role model as a human user. An integration is a user: it holds job roles, it passes through data security, and it sees exactly what those grants allow. WHY INTEGRATIONS FAIL ON A MONDAY AFTER A ROLE CHANGE NOBODY CONNECTED TO THEM. Somebody tidies the role assignments, removes a role from an account that "is not a person", and an interface that has run nightly for a year starts returning empty or refusing. Nothing in the role screen says the account is an integration, and nothing in the integration says which roles it depends on. Three habits fix it. Name the account so it is obviously an…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Fusion Technical: Reports, Data, Integrations and Extensions, with a certificate on completion and a fourteen-day refund window.
In this module: Module 10 · REST and SOAP: calling Fusion, and being called
- 1What Fusion exposes, and what it does not
- 2REST vs SOAP: choosing without arguingFree preview
- 3Authentication and the service account
- 4Reading the REST API catalogue
- 5Your first call, and its error
- 6Payloads, child resources and partial updates
- 7Bulk operations and rate limits
- 8Fusion calling out: business events
- 9Idempotency and retries
- 10Versioning and surviving a quarterly update
- 11What breaks: five integration failures
- 12Lab briefing · Read, write and break an integration