Integration
Never rip-and-replace again Multiply what you already own
OAN is built to extend the ERP, identity, content, and AI stack you already run, not replace it. You start with the capability you need most today, adopt the rest as your process matures, and every new piece of OAN adds more return to the investment you have already made.
- No rip-and-replace
- Progressive adoption
- Built on Oracle
- Open standards
We know what IT leadership is worried about
Every new platform starts with the lock-in question
Procurement asks it. Architecture asks it. Your own team asks it after one too many integration projects that never ended. OAN is designed so the answer is short and obvious.
Every platform wants a ten-year bet, and we have learned not to make it.
Each new tool keeps its own copy of our data and identities.
Our ERP and identity systems are live, so anything new must fit around them.
Every new connection is custom code my team maintains forever.
Integration philosophy
Three rules for how OAN integrates
Every integration category on this page follows these three rules. If a connector breaks one of them, we do not ship it.
Oracle at the core
OAN is built on Oracle APEX, Oracle Database, and Oracle REST Data Services. Oracle customers get the deepest, most native fit because OAN runs on the same stack your ERP, identity, and content platform already use.
Open at every edge
Non-Oracle systems are first-class integration targets, not afterthoughts. ERPs, identity providers, AI models, content stores, and custom applications all plug in through standards-based connectors, not proprietary ones.
Standards over proprietary
SAML, OIDC, REST, OpenAPI, OAuth 2.0, SQL, SFTP. Every integration uses an open standard, so nothing about OAN locks you into OAN. If you ever walk away, your data, your audit log, and your identity graph walk with you.
Integration points
Six places OAN plugs into your stack
The ERP you run, the documents you capture, the models you use for AI, the identity provider that governs access, the content store that holds your records, and the APIs that let your other applications talk to OAN.
ERP integration
Runs on top of the ERP you already have
Oracle customers get deep, metadata-driven integration with Oracle E-Business Suite and Oracle Fusion Cloud ERP. The same OAN platform also integrates with non-Oracle ERPs and custom applications through pre-built bidirectional connectors, so you are never locked into a single ERP vendor.
- Oracle E-Business Suite
- Oracle Fusion Cloud ERP
- Oracle PeopleSoft
- Oracle JD Edwards
- SAP S/4HANA and ECC
- Microsoft Dynamics 365
- NetSuite
- Custom applications
Capture
Ingest documents from wherever they come from
OAN Capture pulls documents into your process from any channel your business actually uses. Email inboxes, scan devices, web uploads, SFTP drops, and API pushes all land in the right OAN product with classification and metadata extraction applied automatically.
AI extraction engine
Plug any AI model into the extraction engine
OAN's AI extraction engine is model-neutral by design. Use your Oracle Cloud Generative AI tenancy, your Azure OpenAI contract, OpenAI direct, Anthropic Claude, or self-hosted open-source models. You can route different document types to different models based on cost, accuracy, or compliance, and swap providers whenever the market shifts.
Identity & access
Federates with the identity provider you already run
OAN authenticates users against your existing identity provider via SAML 2.0 and OIDC. Oracle Identity and Access Management for Oracle customers, Microsoft Entra ID, Okta, and any LDAP-compatible directory are all first-class. OAN does not run its own password store or user database.
Content & storage
Store documents where you already store them
OAN integrates with Oracle WebCenter Content as the enterprise content platform for documents that need records management, retention, and governance. For high-volume binary storage, OAN reads from and writes to Oracle Cloud Infrastructure Object Storage. Your content stays in the store your team already governs.
Open REST APIs via ORDS
Every OAN product exposes standards-based REST APIs
OAN is built on Oracle APEX and Oracle REST Data Services (ORDS), so every product automatically exposes REST APIs your other applications can call. Custom apps, mobile clients, downstream SaaS, and your own integration platforms can query OAN data or trigger OAN workflows through documented endpoints, secured by OAuth 2.0.
Oracle-native does not mean Oracle-only
OAN is built on Oracle APEX, Oracle Database, and Oracle REST Data Services because the Oracle stack gives us the most direct, most proven, most secure path for Oracle EBS and Fusion customers. When you run OAN next to your Oracle ERP, there is no separate middleware, no parallel data store, and no custom integration layer to maintain. But being built on Oracle is not the same as being locked to Oracle. Every integration point on this page (ERPs, identity, AI models, content, APIs) treats non-Oracle systems as first-class. Your SAP instance, your Azure OpenAI contract, your Okta tenant, and your custom application are all supported through open standards, not proprietary ones. You get the depth of Oracle-native integration where it helps, and the freedom to plug in anything else where it does not.
- No separate middleware
- No parallel data store
- No custom integration layer to maintain
- Non-Oracle systems as first-class
- Open standards, not proprietary ones
FAQ
Frequently asked questions
The questions we hear most often from IT leadership and architecture reviews.
We already run Oracle EBS or Fusion. What does “native integration” actually mean?
OAN is built on the same Oracle stack your ERP runs on: Oracle Database, Oracle APEX, and Oracle REST Data Services. OAN reads and writes to the same Oracle Database your ERP uses (in separate, access-controlled schemas), uses ORDS as the integration backbone, and does not require a separate middleware layer, ETL pipeline, or message broker. For Oracle EBS and Fusion customers, integration is metadata-driven and largely pre-built.
We run SAP, PeopleSoft, JD Edwards, Dynamics, or NetSuite. Can we still use OAN?
Yes. OAN treats non-Oracle ERPs and custom applications as first-class integration targets. We use pre-built bidirectional connectors instead of Oracle-native pipelines, but you get the same OAN platform, the same products, and the same maturity. The platform itself does not depend on a specific ERP underneath.
If we adopt OAN and later switch ERPs, what happens?
The OAN platform and your business logic do not depend on a specific ERP. Integration sits in a connector layer. If you move from one ERP to another, OAN changes which connector it uses, but your OAN configuration, your workflows, your policies, and your data stay in place. You are not re-implementing AP, Cash Application, or Vendor Management on a new platform just because the ERP changed.
Can we use our existing identity provider? We do not want to manage another user database.
Yes. OAN uses federated identity via SAML 2.0 or OIDC. Your users authenticate against your existing Oracle IAM, Microsoft Entra ID, Okta, or any LDAP-compatible directory. OAN does not run its own password store, and OAN role assignments flow from your identity provider group mappings. Deprovisioning a user in your IdP deprovisions them in OAN.
The AI extraction engine uses LLMs. Which AI provider do we have to commit to?
None. The AI extraction engine is model-neutral. Plug it into Oracle Cloud Generative AI, Azure OpenAI, OpenAI, Anthropic Claude, or self-hosted open-source models. You can even route different document types or different tenants to different providers based on cost, accuracy, or compliance requirements, and swap providers when the market shifts.
What about documents and content? We already use Oracle WebCenter or other stores.
OAN integrates natively with Oracle WebCenter Content as the enterprise content platform for governed documents, and with Oracle Cloud Infrastructure Object Storage for high-volume binary storage. Network file shares are supported for legacy workflows. Documents stay in the store your team already governs and already audits.
Can our other applications pull data out of OAN, or trigger OAN workflows?
Yes. Every OAN product exposes REST APIs via Oracle REST Data Services (ORDS). Downstream applications, custom or SaaS, can query OAN data or trigger OAN workflows through documented endpoints secured by OAuth 2.0. Webhooks let OAN push events to your downstream systems in near real time, so you can wire OAN into your existing integration platform or event bus.
Are we locked in to OAN long-term?
Technically no. OAN runs on Oracle Database, in your own tenancy or in an OAN-managed environment you have full visibility into. Your data, your audit log, and your configuration are accessible through standards-based APIs at all times. If you ever stop using OAN, your data is still yours, still in Oracle, and still in formats your team already understands.
More ROI from what you already run.
Measure what OAN adds to what you already own
A 60-minute working session with your IT, finance, and architecture leads. Bring the ERP, identity, content, and AI stack you run today. We walk through exactly where OAN adds value on top, where it extends what you already own, and what that means for the return on your existing investment.
No commitment. An ROI walkthrough with your team.
