Oracle ERP Cloud Sandbox Limitations for Integration Testing

TL;DR

• Bottom line: Oracle Fusion Cloud ERP has three testing levels — sandboxes (config isolation), test pods (separate environments), and ATEs. Sandbox changes are invisible to integrations until published.
• Key limit: Max 20 open sandboxes per environment. Sandboxes only isolate configuration — not data or API endpoints.
• Watch out for: Sandbox changes are invisible to REST APIs, FBDI, and batch processes until published to mainline.
• Best for: Teams planning testing strategies for Oracle Cloud ERP customizations and integrations.
• Authentication: Same credentials for sandbox and mainline within an environment. Test pod requires separate credentials.

System Profile

Oracle Fusion Cloud ERP provides sandboxes (configuration isolation within environments), test pods (separate non-production environments), and ATEs (Additional Test Environments). Standard subscription: 1 production + 1 test environment.

API Surfaces & Capabilities

Rate Limits & Quotas

Sandbox vs Test Pod Capabilities

Constraints

• Sandbox changes invisible to REST APIs, FBDI, batch processes until published.
• Max 20 sandboxes — more degrades performance. Keep under 10.
• Environment refresh requires version parity (source = target version).
• Production cannot be refreshed/overwritten — one-way: prod to test only.
• Test pod may have lower rate limits than production.
• Standard subscription: 1 production + 1 test. Extra environments cost extra.

Integration Pattern Decision Tree

START — Need to test Oracle ERP Cloud integration
├── Config changes (flexfields, Page Composer)?
│   ├── Develop in sandbox → publish → test on test pod
│   └── Cannot test integrations IN sandbox
├── REST API testing? → Test pod (separate URL)
├── FBDI testing? → Test pod with refreshed data
├── Quarterly update regression? → Test pod (~2 weeks before prod)
├── Performance testing? → Request dedicated environment
└── Need production data? → Refresh test pod from production
    └── Must match Fusion version before refresh

Quick Reference

Step-by-Step Integration Guide

1. Set Up Test Pod

Verify access and representative data. [src3]

2. Refresh Test Pod from Production

Clone production data. Requires version parity. [src2]

3. Configure Integration Endpoints

Point integrations to test pod URL with separate credentials. [src4]

ENV_CONFIG = {
    "production": {"url": "https://prod.fa.us2.oraclecloud.com"},
    "test": {"url": "https://test.fa.us2.oraclecloud.com"},
}
config = ENV_CONFIG[os.environ.get("ORACLE_ENV", "test")]

Code Examples

Python: Environment-Aware Client

# Input:  Environment name (production/test)
# Output: Configured API client

class OracleERPClient:
    def __init__(self, env="test"):
        self.config = ENV_CONFIG[env]
        self.token = None

    def get(self, endpoint, params=None):
        if not self.token: self.get_token()
        return requests.get(f"{self.config['url']}{endpoint}",
            headers={"Authorization": f"Bearer {self.token}"}, params=params)

client = OracleERPClient(env="test")
pos = client.get("/fscmRestApi/resources/11.13.18.05/purchaseOrders", {"limit": 5})

cURL: Test Pod Health Check

# Check test pod API access
curl -s -o /dev/null -w "HTTP %{http_code}\n" \
  "https://your-test.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=1" \
  -H "Authorization: Bearer $TEST_TOKEN"

# Check data freshness
curl -s "https://your-test.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=1&orderBy=CreationDate:desc" \
  -H "Authorization: Bearer $TEST_TOKEN" | python -m json.tool

Error Handling & Failure Points

Common Errors

Failure Points

• Testing integrations in sandbox: Fields invisible to API. Fix: Publish sandbox, test on test pod. [src1]
• Credentials reset after refresh: Service accounts fail with 401. Fix: Reset passwords post-refresh. [src2]
• Version mismatch blocks refresh: During quarterly update window. Fix: Refresh before update window. [src2]

Anti-Patterns

Wrong: Testing Integrations in Sandbox

// ❌ BAD — REST API cannot see sandbox-only changes
// Developer configures flexfield in sandbox, API returns nothing
// Hours wasted debugging non-existent API bug

Correct: Publish Sandbox, Test on Test Pod

// ✅ GOOD — Sandbox for config dev, test pod for integration testing
// 1. Configure in sandbox (visual) → 2. Publish → 3. Test on test pod

Wrong: Same Credentials for All Environments

# ❌ BAD — Risk of hitting production accidentally
client_id = "SHARED_CLIENT_ID"

Correct: Separate Credentials Per Environment

# ✅ GOOD — Environment-specific credentials
client_id = os.environ[f"{env.upper()}_CLIENT_ID"]

Common Pitfalls

• Confusing sandbox with test environment: Sandboxes isolate config only. Fix: Use test pod for integration testing. [src1]
• Stale test pod data: Missing production data. Fix: Refresh before major testing. [src2]
• Assuming test = production performance: Test pod may have lower limits. Fix: Request dedicated performance environment. [src4]
• Too many sandboxes: >10 degrades performance. Fix: Close after publishing. [src1]

Diagnostic Commands

# Check test pod accessibility
curl -s -o /dev/null -w "HTTP %{http_code}\n" \
  "https://your-test.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=1" \
  -H "Authorization: Bearer $TEST_TOKEN"

# Compare record counts
echo "Prod:" && curl -s "$PROD_URL?limit=0&totalResults=true" -H "Authorization: Bearer $PROD_TOKEN" | python -c "import sys,json; print(json.load(sys.stdin).get('totalResults','N/A'))"
echo "Test:" && curl -s "$TEST_URL?limit=0&totalResults=true" -H "Authorization: Bearer $TEST_TOKEN" | python -c "import sys,json; print(json.load(sys.stdin).get('totalResults','N/A'))"

Version History & Compatibility

When to Use / When Not to Use

Important Caveats

• Sandboxes isolate configuration only — not data, not API endpoints, not integrations.
• Test pod performance may not match production.
• Environment refresh requires version parity and causes target downtime.
• After refresh, verify all credentials, SSO, and UCM permissions.
• Standard subscription: 1 test environment. Multiple teams may need ATEs.