# Oracle Fusion Cloud Applications

> Connect Oracle Fusion Cloud Applications (ERP, HCM, SCM) to LightHouse: a JWT assertion with your certificate for a read-only integration user, where the credential is held, and what is indexed.

The engine reads the REST resources you name in Fusion ERP, HCM and SCM into a knowledge base.

Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. The records are not transmitted, and LightHouse does not open the credential.

## The way to connect

| Way                                                | What you do                                                                                                                                                                                                                                                   |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Connect by JWT assertion with your certificate** | Upload your certificate in the Security Console under **API Authentication** as an inbound certificate with a trusted issuer name. Make an integration user with the view duties of the resources named. Paste the PEM of the private key and its certificate |

## Connect in LightHouse

You need the **Client administrator** (`client_admin`) role, signed in as a person, and a deployment whose engine reads this connector ([compatibility reference](/concepts/telemetry-contract/#compatibility-reference)) and keeps credentials in your own store.

1. Go to **Setup and admin → Connectors**, find **Oracle Fusion Cloud Applications** (search for it, or filter by its family), and choose **Connect**.
2. Fill in `pod_url` (`https://<pod>.fa.<region>.oraclecloud.com`), `issuer`, `username` and `resources`.
3. The connection is **Read only**: this connector offers no other level.
4. Paste the PEM of the private key and its certificate. Your browser seals it to your deployment; LightHouse never sees it.
5. Your deployment keeps it and checks it at the provider. The card shows the result.

## Connect in code

```yaml
- id: oracle-fusion-knowledge
  purpose: Read Oracle Fusion Cloud Applications into the knowledge base.
  executor: python
  target: aal_engine.ingest.connector:run_card
  overseer: ops-lead@example.com
  budget_usd: 0
  effect: internal
  source:
    kind: oracle-fusion
    resources:
      - path: fscmRestApi/resources/11.13.18.05/invoices
        key: InvoiceId
        updated: LastUpdateDate        # the default
        title: InvoiceNumber           # optional
        fields: [InvoiceNumber, Supplier, InvoiceAmount, InvoiceCurrency, Description]
    label: internal
    credential_secret: <connection id>
    requires:
      reads: [oracle-fusion:payables invoices]
      reason: the finance agents answer from the invoice history
```

## Permissions

- **Read only, always**: the integration user’s view duties for the resources named. Read and write is not offered.
- **The assertion is the bearer token**: Fusion’s inbound JWT authentication takes the signed assertion itself, valid ten minutes and signed again before it lapses. No password, no client secret, no token exchange.
- **The health check**: your deployment reads one record. Fusion does not state a user’s roles to it, so the card says the check read one resource and the roles were not stated.
- **One host**: your pod, sealed with the credential. A resource path is held to `fscmRestApi`, `hcmRestApi` or `crmRestApi`.

## Where the credential is held

LightHouse never opens this credential. It is sealed in your browser, or by `lighthouse-ai connect oracle-fusion --credential-stdin`, to your deployment’s own key, and your deployment keeps it in your own secrets store under `lighthouse/connectors/oracle-fusion/<connection id>`. A request that sends it to LightHouse unsealed is refused with `422 sealing_required`. LightHouse keeps the connection’s fingerprint, the access level, the scopes the provider states and when it was checked: never the credential, and never what it reads.

See [Where every credential is held](/connect/#where-every-credential-is-held).

## What is indexed

- **Records** of the resources named, with the fields named.
- **How often, and what is read each time**: on the card’s schedule. Each pull reads records whose `LastUpdateDate` (or the field named) is after the cursor, in order, paged while Fusion says there is more.
- **Deletions**: every six hours the keys are listed and a record that has gone is removed.
- **Rate limits**: requests are paced; a `429` waits as long as Fusion asks.
- **Never read**: resources you do not name, and attachments.

## Check it worked

- The source’s run note in your deployment: `written N, unchanged N, quarantined N, removed N`.
- **Agents → Knowledge**: documents from `oracle-fusion`.
- Content is read in place, in your deployment. LightHouse receives ids, hashes and counts only; the records are not transmitted.

## Removing it

On the card, choose **Disconnect**. Your deployment deletes the credential from your store. Delete the inbound certificate in the Security Console, and make the integration user inactive. Documents already written stay in the corpus until you delete them.

Source: https://docs.atlanticagenticlabs.com/connect/oracle-fusion/