.png)
Oracle Retail Integration Guide
Connect Oracle Retail applications with enterprise systems through REST APIs, product-specific events, messaging, SOAP services, batch processing, and secure workflows.
Oracle Retail integration options at a glance
Oracle Retail is a portfolio rather than a single application, so integration options depend on the product, release, and deployment model. REST APIs are the principal mechanism for many Oracle Retail Cloud applications, while selected products may provide SOAP services, Oracle Retail Integration Bus messaging, batch or asynchronous processing, and file exchanges. Event-oriented integration can use product-specific messages or incremental API queries; universal HTTP webhooks should not be assumed. Martini can consume these endpoints, authenticate with OAuth 2.0, Basic Authentication, service accounts, or certificates where supported, and orchestrate mappings, validation, retries, reconciliation, and downstream API or messaging calls.
| Integration point | Supported by Oracle Retail? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | REST is the principal integration mechanism for many Oracle Retail Cloud applications and can expose Items, Locations, Suppliers, Purchase Orders, Inventory, Transfers, Sales transactions, and configuration resources. Coverage varies by product and release. | Martini can consume Oracle Retail REST APIs, handle authentication and pagination, transform payloads, apply business rules, and expose REST APIs for downstream or intermediary systems. |
| RIB and messaging | Limited | Oracle Retail Integration Bus exchanges business messages between Oracle Retail applications and external systems. Deployments may use JMS, Oracle AQ, or related middleware. | Martini can participate when the deployed architecture exposes a supported messaging, middleware, or API endpoint. RIB should not be treated as a generic HTTP webhook service. |
| Bulk, async, and batch APIs | Limited | Selected Oracle Retail products provide batch jobs or asynchronous processing for large item, inventory, or transaction workloads. Job models and status operations are product-specific. | Martini can start documented jobs, poll status endpoints, process result files or responses, and orchestrate controlled retries and reconciliation workflows. |
| SOAP APIs | Limited | Some Oracle Retail products and older releases expose SOAP or other enterprise web services. Availability must be verified for the exact application and release. | Martini can consume a documented SOAP endpoint using its WSDL, map XML request and response structures, and apply endpoint-specific error handling. |
| Webhooks and outbound callbacks | Limited | Selected products may provide event or callback mechanisms, but Oracle Retail does not establish universal HTTP webhook coverage for every object. | Martini can receive HTTP callbacks where the specific application documents them, then retrieve the current resource and process the event idempotently. |
| File exchange | Limited | Batch and file-based exchanges are used in some implementations for high-volume or operationally decoupled workloads. Formats and transports vary by product and deployment. | Martini can orchestrate file-oriented workflows where the approved transport and format are exposed, then parse, validate, transform, and route the contents. |
| Authentication | Yes | Oracle Retail integrations may use OAuth 2.0, Basic Authentication, service accounts, Oracle identity services, roles, certificates, or mutual TLS depending on the application and environment. | Martini can store credentials, tokens, client secrets, and certificates in environment secrets and apply the endpoint-specific authentication configuration. |
| Database access | Not confirmed | Oracle Database may underpin Oracle Retail deployments, but direct application-schema access is not a generally confirmed public integration interface. | Martini can connect to approved databases where an explicit supported interface exists, but should not bypass documented Oracle Retail APIs or services without architecture and support approval. |
How Oracle Retail exposes data and business events
Oracle Retail REST APIs
REST APIs are the principal standards-based mechanism for many Oracle Retail Cloud applications. They commonly expose resources such as Items, Locations, Suppliers, Purchase Orders, Inventory, Transfers, and Sales transactions, although resource coverage varies by product and release.
Martini implementation pattern
Martini implementation pattern: Martini authenticates to the documented Oracle Retail endpoint, retrieves pages or incremental changes, maps the product-specific response into a canonical model, and calls downstream APIs or exposes a controlled Martini API. Product and release-specific fields remain isolated in the mapping layer.
Implementation sequence
RIB and messaging
Oracle Retail Integration Bus is a message-oriented framework used by Oracle Retail applications and external systems. Depending on deployment, RIB may involve JMS, Oracle AQ, or related middleware rather than HTTP callbacks.
Martini implementation pattern
Martini implementation pattern: Martini connects to the supported messaging or intermediary endpoint actually exposed by the deployment. It consumes or publishes approved messages, translates RIB payloads into the target contract, and preserves correlation and delivery information for operational handling.
Implementation sequence
Oracle Retail SOAP services
Selected Oracle Retail products and older releases may expose SOAP or other enterprise web services. SOAP availability is product-specific and should be verified against the exact WSDL, endpoint, and release.
Martini implementation pattern
Martini implementation pattern: Martini consumes the documented WSDL-based service, constructs XML requests from canonical data, parses SOAP responses and faults, and separates transport failures from business validation errors.
Implementation sequence
Batch and asynchronous processing
Parts of the Oracle Retail portfolio support batch jobs or asynchronous processing for large item, inventory, or transaction workloads. The operation, payload, limits, and status model depend on the application.
Martini implementation pattern
Martini implementation pattern: Martini starts the documented batch or asynchronous operation, stores the job identifier, polls status at a controlled interval, and processes the resulting payload or file only after the job reaches a terminal state.
Implementation sequence
File exchange
Some Oracle Retail implementations use structured files, object storage, managed file transfer, or middleware-managed exchanges for high-volume or decoupled processing. The format and transport must be confirmed for the specific product.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves an approved file, validates its structure and business content, transforms rows into target requests, and records file-level and row-level outcomes for replay and reconciliation.
Implementation sequence
Common Oracle Retail integration patterns
Pattern 1: Synchronize items and locations to commerce
When to use this pattern
Use this pattern when Oracle Retail merchandising and location data must be reflected in a digital commerce platform. A scheduled incremental workflow is appropriate when the exact product does not expose a documented event or callback for every relevant change.
Integration direction
Example Mapping
| Oracle Retail Field | Canonical Field | Target Field |
|---|---|---|
| itemId | product.externalId | productId |
| itemDescription | product.name | name |
| locationId | site.externalId | locationId |
| lastUpdated | source.updatedAt | updatedAt |
Martini implementation pattern
A Martini scheduler starts the workflow, which retrieves paginated Items and Locations using documented incremental filters where available. It validates required identifiers, maps product-specific structures into a commerce model, applies publication and status rules, and performs idempotent upserts. The workflow stores a checkpoint and sends transient failures through bounded retry while routing malformed records to reconciliation.
Martini capabilities used
- workflows
- scheduling
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Synchronize inventory availability
When to use this pattern
Use this pattern to keep commerce, order-management, warehouse, or marketplace availability aligned with Oracle Retail Inventory. It supports polling, supported product events, or reconciliation when an event is missed.
Integration direction
Example Mapping
| Oracle Retail Field | Canonical Field | Target Field |
|---|---|---|
| itemId | inventory.productId | inventoryItem |
| locationId | inventory.locationId | location |
| availableToSell | inventory.availableQuantity | available |
| inventoryTimestamp | inventory.observedAt | updatedAt |
Martini implementation pattern
Martini receives supported event messages or polls Inventory incrementally, then orders changes using timestamps or sequence values when available. It converts location-level quantities into the target availability model, rejects stale updates, and uses target upserts or a processing record to prevent duplicates. A scheduled reconciliation workflow compares recent inventory and repairs missed updates.
Martini capabilities used
- event processing
- API consumption
- data transformation
- business rules
- reconciliation
- retry handling
Pattern 3: Process purchase orders and suppliers
When to use this pattern
Use this pattern when retail procurement data must be exchanged with Oracle Fusion Cloud ERP, a supplier portal, or another procurement process. It supports outbound Purchase Orders and inbound acknowledgments where the Oracle Retail product exposes the required resources.
Integration direction
Example Mapping
| Oracle Retail Field | Canonical Field | Target Field |
|---|---|---|
| purchaseOrderNumber | purchaseOrder.externalId | purchaseOrderNumber |
| supplierId | supplier.externalId | supplierNumber |
| orderLines | purchaseOrder.lines | lines |
| status | purchaseOrder.status | documentStatus |
Martini implementation pattern
A Martini workflow retrieves Purchase Orders and related Suppliers, validates supplier and location references, maps headers and lines to the ERP contract, and applies status-transition rules. It uses the purchase-order number as an idempotency key, records acknowledgments, retries temporary API failures, and routes authorization or validation errors to an operational queue.
Martini capabilities used
- workflows
- API consumption
- mapping
- validation
- business rules
- error handling
Pattern 4: Post sales transactions through a batch workflow
When to use this pattern
Use this pattern for high-volume Sales transactions that must be normalized and sent to finance or ERP systems. When the relevant Oracle Retail application documents batch or asynchronous processing, it is preferable to unbounded individual REST calls.
Integration direction
Example Mapping
| Oracle Retail Field | Canonical Field | Target Field |
|---|---|---|
| transactionId | salesTransaction.externalId | sourceTransactionId |
| transactionDate | salesTransaction.occurredAt | transactionDate |
| locationId | salesTransaction.storeId | store |
| totalAmount | salesTransaction.total | amount |
Martini implementation pattern
Martini starts or retrieves the documented batch, tracks its job status, and processes completed transaction results in controlled chunks. It validates totals and required financial dimensions, aggregates or normalizes records as agreed, sends them to the ERP API, and preserves source identifiers for replay-safe retry and reconciliation.
Martini capabilities used
- scheduled workflows
- batch orchestration
- API consumption
- JSON and XML transformation
- validation
- monitoring
Applications commonly integrated with Oracle Retail
Oracle Retail implementations commonly participate in broader Oracle, commerce, supply-chain, customer-experience, and enterprise operations landscapes. The exact direction and object coverage depend on the Oracle Retail product and release, but Martini can coordinate these exchanges through documented APIs, messages, files, and scheduled workflows.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Oracle Fusion Cloud ERP | Exchange purchasing, supplier, inventory, sales, and financial information between retail operations and corporate finance processes. | Oracle Retail → Martini → Oracle Fusion Cloud ERP | Use scheduled or event-driven workflows to retrieve Oracle Retail Purchase Orders, Suppliers, Inventory, and Sales transactions, normalize them into an ERP-facing model, apply validation and accounting rules, and call the relevant ERP APIs. Route rejected records to an operational exception flow. |
| Oracle Commerce | Synchronize catalog, item availability, pricing, and order-related information between retail merchandising and digital commerce operations. | Oracle Retail → Martini → Oracle Commerce | Poll changed Items, Locations, and Inventory resources or consume supported product events, map them to the commerce model, and publish updates through APIs. Use checkpoints, idempotent keys, and reconciliation for missed or duplicate changes. |
| Oracle Warehouse Management | Coordinate inventory, receiving, fulfillment, shipping, and warehouse execution with retail inventory and order processes. | Oracle Retail → Martini → Oracle Warehouse Management | Orchestrate bidirectional API or message flows for Inventory, Transfers, and fulfillment-related data. Apply location and quantity transformations, preserve event timestamps, and retry transient endpoint or messaging failures without duplicating warehouse updates. |
| Oracle Transportation Management | Exchange shipment, delivery, carrier, and transportation-planning information with retail supply-chain processes. | Oracle Retail → Martini → Oracle Transportation Management | Retrieve or receive shipment-related changes through the documented Oracle Retail product interface, map locations and order references, and send normalized requests to transportation services. Track acknowledgments and quarantine records with missing carrier or location data. |
| Salesforce | Synchronize customer, service, loyalty, commerce, or retail transaction information where Salesforce participates in the enterprise customer landscape. | Oracle Retail → Martini → Salesforce | Expose or consume REST APIs as appropriate, map Oracle Retail identifiers into Salesforce keys, apply field-level validation and business rules, and use durable checkpoints or target-side upserts to prevent duplicate customer or transaction updates. |
| Shopify | Publish products and inventory to a commerce channel and return orders or sales information to retail systems. | Oracle Retail → Martini → Shopify | Schedule incremental Item and Inventory synchronization to Shopify, transform location-level availability into channel quantities, and process order information in the reverse direction where the Oracle Retail application supports the required resources. Use throttling and reconciliation for channel API limits. |
| ServiceNow | Create incidents or service requests for store, integration, infrastructure, or data-quality exceptions and return status updates when required. | Oracle Retail → Martini → ServiceNow | Route classified Oracle Retail or workflow failures to ServiceNow through its API, include correlation identifiers and diagnostic context, and optionally consume status changes to close or update the originating operational record. |
| Workday | Exchange workforce, organization, or cost-center information when retail HR and finance processes require coordinated reference data. | Workday → Martini → Oracle Retail | Run a scheduled workflow that retrieves approved reference data, validates organizational mappings, transforms it into the Oracle Retail product schema, and records rejected rows separately from successful updates. |
How to build a Oracle Retail integration in Martini
Objective
Identify the exact Oracle Retail product, release, endpoint, and deployment model, then configure the required authentication and network controls.
Instructions in Martini
- Confirm the Oracle Retail application, release, API base URL, and supported integration mechanism.
- Create a dedicated service account with the minimum required roles.
- Store OAuth credentials, Basic Authentication values, certificates, and endpoint configuration in Martini environment secrets.
- Verify allow lists, private connectivity, VPN, or mutual TLS requirements where applicable.
Objective
Select the trigger that matches the confirmed Oracle Retail capability and workload profile.
Instructions in Martini
- Use a documented Oracle Retail event, RIB message, or callback when available.
- Use a scheduler for polling, incremental synchronization, reconciliation, or batch jobs.
- Use an API trigger when an intermediary or Oracle Retail system needs to invoke Martini.
- Do not assume universal HTTP webhook support across Oracle Retail products.
Objective
Receive or retrieve Oracle Retail data reliably while preserving pagination, incremental state, and batch status.
Instructions in Martini
- Call the documented REST or SOAP resource, messaging endpoint, or approved file exchange.
- Handle product-specific pagination and stop conditions rather than assuming a common response shape.
- Persist last-updated checkpoints, event identifiers, job identifiers, or file names.
- Retrieve complete resources when an event contains only a notification or reference.
Objective
Coordinate calls, messages, transformations, validations, and downstream writes in a maintainable Martini workflow.
Instructions in Martini
- Separate product-specific acquisition logic from common canonical processing.
- Use conditional routing for object types, status values, and error classes.
- Use controlled concurrency for Oracle service quotas and downstream capacity.
- Preserve Oracle correlation identifiers and source references through the workflow.
Objective
Convert Oracle Retail product-specific payloads into stable canonical and target-system models.
Instructions in Martini
- Map actual Oracle Retail objects such as Items, Locations, Inventory, Purchase Orders, and Sales transactions.
- Transform JSON, XML, or approved file structures into the target contract.
- Normalize identifiers, timestamps, quantities, currencies, statuses, and location codes.
- Version mappings when Oracle Retail products or releases expose different schemas.
Objective
Validate data and enforce retail processing rules before writing to downstream systems.
Instructions in Martini
- Validate required identifiers, supplier references, location relationships, quantities, and financial dimensions.
- Reject stale inventory or transaction updates when ordering metadata is available.
- Apply idempotency using business keys, upsert operations, or a Martini-side processing record.
- Separate permanent validation and authorization failures from transient errors.
Common Oracle Retail data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Items | Products, item hierarchies, attributes, and item-location relationships used for catalog and inventory synchronization. | Oracle Commerce, Shopify, Salesforce, Oracle Fusion Cloud ERP, marketplaces | Martini retrieves changed Items through documented APIs or batch mechanisms, handles pagination and version-specific fields, maps them to a canonical product model, and upserts target records. |
| Locations | Stores, warehouses, virtual locations, and other retail sites used to contextualize inventory and transactions. | Oracle Commerce, Oracle Warehouse Management, Oracle Transportation Management, ERP systems | Martini validates location identifiers and types, maps them to target site codes, and preserves the relationship between Locations and inventory or transaction data. |
| Suppliers | Vendor identities and supplier-related commercial information used in procurement and finance flows. | Oracle Fusion Cloud ERP, procurement applications, supplier portals | Martini normalizes supplier identifiers and status, applies required-field validation, and routes invalid or unmatched suppliers to an exception workflow. |
| Purchase Orders | Supplier orders containing lines, quantities, references, and status changes. | Oracle Fusion Cloud ERP, supplier portals, warehouse systems | Martini maps headers and lines, enforces idempotency using purchase-order identifiers, tracks acknowledgments, and retries transient downstream failures. |
| Transfers | Inventory movements between retail locations, warehouses, or other sites. | Oracle Warehouse Management, Oracle Transportation Management, inventory platforms | Martini transforms source and destination Locations, quantities, statuses, and timestamps while detecting stale or duplicate updates. |
| Inventory | Stock positions, availability, adjustments, and inventory movements at location level. | Oracle Commerce, Shopify, order-management systems, marketplaces, warehouses | Martini applies incremental filters or event messages where available, calculates or maps availability according to the agreed model, and runs reconciliation for missed changes. |
Authentication and security considerations
Product-specific authentication
Oracle Retail authentication depends on the application, release, and environment. Supported approaches may include OAuth 2.0, Basic Authentication, Oracle identity services, service accounts, roles, certificates, or mutual TLS.
Least privilege and secrets
Use dedicated integration users with only the roles and data permissions required for the workflow. Store credentials, tokens, client secrets, and certificates in Martini environment secrets rather than in workflow definitions.
Network and data protection
- Confirm allow lists, private connectivity, VPN, and certificate requirements before deployment.
- Do not log authorization headers, tokens, or sensitive customer and payment data.
- Use HTTPS and retain Oracle request or correlation identifiers for controlled troubleshooting.
Operational considerations for Oracle Retail integrations
API variation and pagination
Oracle Retail is a portfolio, so resource names, fields, pagination, limits, and authentication requirements vary by product and release. Confirm the exact contract and version before implementing mappings.
Rate limits and retries
Use controlled concurrency, bounded retries, and backoff for throttling, timeouts, and temporary server errors. Respect Retry-After headers when present and avoid retrying malformed payloads or authorization failures.
Idempotency and ordering
Use identifiers such as item, location, purchase order, transfer, and sales transaction numbers for deduplication. Preserve timestamps, versions, or sequence values where available and reject stale inventory or transaction updates.
Batch and database boundaries
Prefer documented asynchronous or batch operations for high-volume loads. Do not treat the underlying Oracle Database as a supported integration interface unless direct access is explicitly approved for the deployment.
Testing and change management
Test representative payloads, empty pages, partial failures, duplicate messages, throttling, authorization errors, and schema differences across environments. Version product-specific mappings and monitor workflow logs and reconciliation results after release changes.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than one API call
Oracle Retail integrations often combine APIs, messaging, batch jobs, files, and downstream enterprise systems. Martini workflows coordinate these steps with scheduling, conditional routing, asynchronous processing, and reusable integration logic.
Keep transformations maintainable
Martini separates product-specific Oracle Retail mappings from canonical and target models. This makes it easier to handle differences between Oracle Retail products and releases without duplicating point-to-point scripts.
Build operational controls in
Retries, validation, idempotency, checkpoints, reconciliation, and structured error handling can be designed into the workflow rather than added after failures occur.
Expose controlled APIs
Martini can expose REST APIs for Oracle Retail or intermediary systems, allowing enterprise teams to standardize access, apply security policies, and reuse integration assets across applications.
Frequently asked questions
Oracle Retail can be integrated through REST APIs, product-specific event or RIB messaging, selected SOAP services, batch and asynchronous processing, and file exchanges where supported by the specific application and release. Scheduled incremental API queries and reconciliation workflows are also common.
Yes. Martini can consume Oracle Retail REST APIs, consume documented SOAP services, orchestrate scheduled and batch workflows, and participate in supported messaging or intermediary architectures. Exact implementation depends on the Oracle Retail product, release, deployment, and exposed endpoints.
No. A dedicated Oracle Retail connector is not required. Martini can use Oracle Retail's documented REST or SOAP APIs, supported RIB or messaging architecture, approved file exchanges, callbacks where explicitly available, and configured authentication methods.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Oracle Retail. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Oracle, cloud infrastructure, messaging, middleware, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs are the primary standards-based choice for many Oracle Retail Cloud applications. Use documented bulk or asynchronous mechanisms for large workloads, RIB or approved messaging for message-oriented flows, and SOAP only when the exact product and release require or document it. GraphQL is not confirmed as a general Oracle Retail API.
Oracle Retail supports selected event-oriented mechanisms, including RIB and product-specific integration services. This does not establish universal HTTP webhook support for every object. Use callbacks only when the exact Oracle Retail application documents them; otherwise use messaging, incremental queries, batch extracts, or scheduled reconciliation.
Martini can use last-updated filters, product-specific event messages, RIB messages, batch exports, or scheduled polling where available. Workflows preserve pagination and checkpoints, map objects such as Items, Inventory, Purchase Orders, and Sales transactions, and use idempotency and reconciliation to address duplicates or missed changes.
Martini can distinguish transient throttling, timeout, and server failures from permanent validation or authorization errors. Workflows can apply bounded retries and backoff, preserve correlation identifiers, use business keys or upserts for idempotency, quarantine invalid records, and route unresolved failures to operational or reconciliation workflows.
Related Martini documentation
APIs
Build a maintainable Oracle Retail integration
Use Martini to connect Oracle Retail APIs, messages, batch processes, and approved file exchanges with the systems that support your retail operation.