Release copies twice and points PROD at a sandbox endpoint
A team promotes 14 integrations, 6 connections, 3 lookups and one mTLS certificate from DEV to PROD by exporting a .par from DEV, importing it into PROD, then activating. After the latest release: (a) the 02:00 nightly invoice job ran twice and 1,800 duplicate invoices were created; (b) a REST connection that pointed to prod.partner.com in PROD now calls sandbox.partner.com because the imported DEV connection overwrote it, and 1,800 sandbox calls were logged; (c) the archive contained the partner's client secret and sat on a shared drive. There is no CI/CD; one engineer releases at 23:00. PROD has no test tenant, the partner bills per API call, and two other PROD integrations still reference the old connection identifier.
1. Explain the double invoice run in terms of OIC behaviour, and give the corrected activation procedure.
Read the worked answer
Activating a new version does not implicitly retire the previous active version. For a schedule-triggered integration both versions hold a schedule, so both fire at 02:00 and each creates invoices; 1,800 duplicates is consistent with two runs of the same batch. Confirm by listing active versions and inspecting the scheduled integrations view for two entries.
Corrected procedure: deactivate the current version before activating the new one - or immediately after, in the same window - then verify exactly one active version and one next-fire time. Make that check a release gate, not a habit. Independently, the invoice write should be idempotent (upsert on invoice reference) so an accidental double activation degrades to a no-op instead of a financial correction exercise; duplicate active versions are a normal failure mode and the flow should survive it.
2. How should connections, endpoints and secrets be handled during promotion?
Read the worked answer
The import overwrote the PROD connection because the archive carried the DEV connection under the same identifier and import was allowed to replace it. Endpoints are environment data and must never travel in the archive.
Do this: maintain all six connections in PROD with PROD endpoints and credentials, and at import time select the existing PROD connections rather than importing DEV copies; where a connection must be new, create it manually first. Because the secret left the tenant, rotate it at the partner, revoke the old value, and review partner logs for unexpected callers. Remove secrets from exports and reference OCI Vault where the adapter supports it, otherwise re-enter credentials after import. Before activating, reconcile the 1,800 sandbox calls with the partner and use the connection's used-by view to confirm no integration still resolves to the wrong host - two other integrations still reference the old identifier, so changing it carelessly could break them.
3. Design a repeatable, low-risk promotion process for a team with no CI/CD and a billable API.
Read the worked answer
Replace the 23:00 heroics with a minimal scripted pipeline. Treat the .par as a build artifact tied to a source tag; promote in dependency order - lookups, then connections (created and verified, not imported), then integrations - using the OIC REST endpoints for import, activate and deactivate so every step is repeatable and logged.
Add post-deploy gates that would have caught all three incidents: exactly one active version per integration; host assertion that the partner connection resolves to prod.partner.com; a smoke order exercising trigger → mapping → callout; and zero pending faults in the first 15 minutes. Run outside the 02:00 schedule window.
Keep the previous .par and document rollback: deactivate the new version, reactivate the prior one, re-run the single-active check. Because PROD has no test tenant and calls are billable, the smoke test must use the partner's documented test mode or a single low-value record - never a replay of production volume. Record each change with who, what and when.