OasisPro · IFS Cloud Integration · REST APIs · Projections · IFS Connect
IFS Cloud integration.
REST APIs, projections, and 5 patterns that actually work.
IFS Cloud integration is where migration projects from IFS Apps 9 and 10 hit their biggest technical surprise: the database-level integration patterns that grew over a decade of on-premise IFS are simply not available against IFS Cloud. Everything goes through the supported API surface now: OData projections, IFS Connect, and the event infrastructure. This guide covers how IFS Cloud integration actually works, the five patterns that hold up in production, and the mistakes that turn integration estates into upgrade blockers.
The shift is bigger than a technology swap. On-premise IFS tolerated direct table reads, custom PL/SQL, and database links because customers controlled the database.
IFS Cloud's evergreen model and managed deployment close that door deliberately.
Teams that embrace the API surface get integrations that survive every 6-monthly release. Teams that fight it get an estate that breaks with every service update.
Every IFS Cloud integration that survives release cycles is built on the same foundation: projections for synchronous APIs, IFS Connect for messages, events for outbound push. Everything else is technical debt with a countdown timer.
OasisPro's senior technical consultants have migrated integration estates from IFS Apps to IFS Cloud across manufacturing, aerospace, and energy clients. The patterns in this guide are the ones still standing after multiple release cycles in production environments.
The IFS Cloud integration surface: what you actually have to work with
IFS Cloud exposes three sanctioned integration mechanisms, and understanding what each is for prevents most architecture mistakes.
Projections are the API layer. Every projection exposes entities and actions as an OData REST service secured through IFS IAM with OAuth 2.0.
Critically, these are the same services the Aurena web client uses, which means they are first-class citizens that IFS maintains release over release.
IFS Connect is the message engine: routing rules, transformations, and connectors for file-based, queued, and asynchronous exchanges where a REST call-response model does not fit.
The event infrastructure pushes changes outward, letting external systems react to IFS Cloud business events rather than polling for changes.
The IFS Cloud technical documentation covers the full integration architecture in detail.
GET https://<env>.ifs.cloud/main/ifsapplications/projection/v1/
CustomerOrdersHandling.svc/CustomerOrderSet?
$filter=Objstate eq 'Released'&
$select=OrderNo,CustomerNo,WantedDeliveryDate&
$top=100
Authorization: Bearer <OAuth2 token from IFS IAM>
The 5 IFS Cloud integration patterns that work in production
Synchronous REST via standard projections
The default pattern for request-response integration: reading data, creating records, calling actions. Use standard projections wherever they cover the need, because IFS maintains them through every release. Best for real-time lookups, order creation from web portals, and system-to-system calls at moderate volume.
Custom projections for specific data shapes
Where standard projections force chatty multi-call patterns or expose the wrong granularity, a custom projection presents exactly the entities and actions the integration needs. The trade: custom projections are your responsibility to test at each release, so build them deliberately and sparingly.
IFS Connect for files and asynchronous messages
EDI flows, bank files, batch imports, and any exchange where the external party works in files or queues. IFS Connect's routing rules and transformations keep the message handling inside supported configuration rather than custom code hanging off the database.
Event-driven outbound push
When external systems need to know that something happened in IFS Cloud, events beat polling every time: lower load, lower latency, no missed changes between polls. Order status changes feeding a customer portal or warehouse system is the classic case.
Middleware-fronted compliance integrations
For regulatory surfaces that change on government timetables, eInvoicing mandates and ISO 20022 payments, the production-grade pattern puts maintained middleware between IFS Cloud and the external network. IFS Cloud talks to the middleware once. The middleware absorbs every mandate change. This is exactly how the OasisPro EU eInvoicing Gateway and ISOWorks connect to IFS Cloud.
The anti-pattern: recreating database access
Attempting to rebuild Apps-era direct data access through undocumented endpoints, scraping, or unsupported routes produces integrations that break unpredictably at service updates. If a requirement seems to demand it, the requirement needs redesigning around the supported surface, not the other way around.
The question for every IFS Cloud integration is not "can we build it?" It is "will it still work after the next two releases without emergency rework?"
Migrating an integration estate from IFS Apps 10 to IFS Cloud
For businesses moving from Apps 9 or 10, the integration estate is routinely the most underestimated migration workstream.
A decade of accumulated interfaces, many undocumented, built on database access that no longer exists.
The OasisPro approach: inventory every interface including the forgotten ones, classify each against the five patterns above, retire the interfaces nobody can justify, and rebuild the rest on the supported surface.
On most estates, a meaningful fraction of legacy interfaces are retired rather than migrated, which is a cost saving hiding inside the migration.
Integration discovery belongs at the start of an IFS Cloud migration, not the middle.
The interfaces that surface late in a migration are the ones that delay go-live. A structured integration inventory in the first weeks of the programme, including database jobs and scheduled scripts that nobody remembers owning, converts the biggest unknown in most IFS Cloud migrations into a planned workstream with a cost and a timeline.
OasisPro provides senior IFS Cloud integration consultants and ready-made compliance integrations.
Integration architecture, custom projection development, IFS Connect configuration, and full estate migration from Apps 9 and 10, delivered by consultants with 15 or more years of IFS technical experience. For eInvoicing and ISO 20022, the OasisPro EU eInvoicing Gateway and ISOWorks connect to IFS Cloud as maintained products rather than one-off builds.
IFS Cloud technical consultingIFS Cloud integration architecture, estate migration, or a specific interface that will not behave?
Talk to OasisPro. We will review your integration landscape, classify it against release-safe patterns, and give you a plan that survives the next release cycle and every one after it.
How do you integrate with IFS Cloud?
IFS Cloud integration is built on three supported mechanisms: OData REST APIs exposed through projections and secured with OAuth 2.0 via IFS IAM, IFS Connect for message-based and file-based exchanges with routing and transformation, and the event infrastructure for pushing IFS Cloud changes outward to external systems. The right mechanism depends on direction, volume, latency requirements, and the capabilities of the external system.
What are IFS Cloud projections?
Projections are the API layer of IFS Cloud. Each projection exposes a set of entities and actions as an OData REST service, and they are the same services the IFS Cloud Aurena client itself consumes, which makes them first-class supported interfaces maintained release over release. Integrations use standard projections where they fit and deliberately-built custom projections where a specific data shape or action set is needed.
Does IFS Cloud still support database-level integration?
No. Direct database access patterns from the IFS Apps era, direct table reads, custom PL/SQL interfaces, and database links, are not available against IFS Cloud in the managed deployment model. All integration goes through projections, IFS Connect, and the event infrastructure. Migrating the legacy database-level integration estate is typically the most underestimated workstream in an Apps 10 to IFS Cloud migration.
Can OasisPro help with IFS Cloud integration projects?
Yes. OasisPro provides senior IFS Cloud technical consultants covering integration architecture, custom projection development, IFS Connect configuration, event-driven design, and full integration estate migration from IFS Apps 9 and 10. For compliance surfaces, the OasisPro EU eInvoicing Gateway and ISOWorks connect to IFS Cloud as maintained middleware products, which removes the mandate-tracking burden from your integration team entirely.
IFS Cloud integration done right survives every release. Done wrong, it becomes the reason you dread them.
The IFS Cloud integration surface is genuinely good: consistent REST APIs, a capable message engine, and real event infrastructure.
The businesses that struggle are the ones recreating on-premise habits against a platform designed to prevent them.
Whether you are architecting new integrations, migrating an Apps 10 estate, or untangling something that breaks at every service update, OasisPro's senior technical consultants can help. Talk to us.