If you're standing up an integration flow in Oracle Integration Cloud (OIC) that needs to push a document into Oracle WebCenter Content (WCC) — an invoice image, a signed PDF, a scanned form — you have a decision to make about how the two talk. WCC exposes its full IdcService surface over a native SOAP layer, and OIC has a first-class SOAP adapter. Wire those two together correctly and you get a clean, supported, credential-secured path to check content in and out of the repository from any integration you build.
The reason this is worth writing down is that the SOAP path has a few sharp edges that aren't obvious from the OIC side. The security policy has to match on both ends, the WSDL you point OIC at is a specific one (not the WCC console URL), and the response you get back is not a tidy typed object — it's an IdcService result document you have to read on its own terms. I've done this on a real WCC-to-OIC check-in for a US home-services company, and below is the runbook: the setup, the WSDL shape, and the exact request and response you should expect.
The shape of the integration
The goal in the reference project was simple to state: check a document into WebCenter Content from an OIC integration. OIC receives (or builds) the file and its metadata, and hands it to WCC's CHECKIN_UNIVERSAL service. WCC creates the content item, assigns it a dID and dDocName, and returns a status.
Three things have to be in place before that call will succeed:
- Web service security configured through WSM policies — matched on the OIC request and the WCC service.
- A key map holding the credential OIC uses to authenticate to WCC.
- The correct CheckIn WSDL registered in OIC as the SOAP connection's target.
Get those three right and the actual invoke is straightforward. Get any one of them wrong and you'll spend an afternoon reading SOAP faults that don't say what's actually wrong.
Step 1: security through Oracle WSM policies
WebCenter Content secures its SOAP endpoints with Oracle Web Services Manager (OWSM) policies, and the policy you attach on the OIC side has to be compatible with the one WCC enforces. WCC supports two classes of policy for these endpoints — username-token and SAML — and in practice you'll assign one of the following service-side policies:
oracle/wss11_username_token_with_message_protection_service_policyoracle/wss11_saml_token_with_message_protection_service_policy
For the check-in integration the default working configuration was the no-MTOM policy — oracle/no_mtom_policy — on the message path, paired with a username-token policy for authentication. MTOM (the SOAP attachment optimization mechanism) is worth calling out explicitly: if your OIC connection and the WCC endpoint disagree about whether MTOM is in play, the file payload will not deserialize on the WCC side, and the failure surfaces as a generic fault rather than an attachment error. Pin the MTOM behavior deliberately on both ends rather than leaving it to defaults.
The rule of thumb: the client policy in OIC and the service policy in WCC are a matched pair. wss11_username_token_with_message_protection on the service expects the corresponding _client policy on the caller. A mismatch here is the single most common reason a first invoke fails with an authentication or policy-enforcement fault — and it's a mismatch that reads as a generic policy-enforcement fault, not as "your client policy doesn't match," so the fault text points you at the symptom rather than the cause. Which policy class actually fits — username-token versus SAML, message protection on or off — is a call about your environment's trust model, not a default the wizard picks correctly for you.
Step 2: the key map — where the credential lives
OIC doesn't put a raw username and password into the SOAP header itself; it references a key in a credential map, and that key resolves to the WCC service account at runtime. So the second setup task is to create a key map for the credential used by this integration.
This is the right pattern for two reasons. First, the credential is stored once and referenced by name, so rotating the WCC service-account password is a one-place change rather than a hunt through every integration. Second, it keeps the secret out of the integration's design-time metadata. Provision a dedicated WCC service account for the integration — with exactly the security-group and account rights the check-in needs, and no more — and map its credential under a stable key you reference from the connection.
Step 3: point OIC at the CheckIn WSDL
This is the step people get wrong. You do not point the OIC SOAP connection at the WCC web console or the generic IdcService URL. You point it at the CheckIn service WSDL — the WSDL that describes the check-in and check-out operations as SOAP operations with typed messages.
That WSDL defines a CheckInSoap port type with the operations you'd expect for a content lifecycle:
CheckInUniversal— create a new content item from a file plus metadataCheckOut/CheckOutByName— check out bydIDor bydDocNameUndoCheckOut/UndoCheckOutByNameUpdateDocInfo— update metadata on an existing revisionCheckInList— enumerate items pending check-in
The CheckInUniversal request type is the one you'll bind to in OIC. Its shape is the WCC content model expressed as XML — the standard d-prefixed system fields plus a slot for custom metadata and the file itself:
<s:element name="CheckInUniversal">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" name="dDocName" type="s:string"/>
<s:element minOccurs="0" name="dDocTitle" type="s:string"/>
<s:element minOccurs="0" name="dDocType" type="s:string"/>
<s:element minOccurs="0" name="dDocAuthor" type="s:string"/>
<s:element minOccurs="0" name="dSecurityGroup" type="s:string"/>
<s:element minOccurs="0" name="dDocAccount" type="s:string"/>
<s:element minOccurs="0" name="CustomDocMetaData" type="s0:IdcPropertyList"/>
<s:element minOccurs="0" name="primaryFile" type="s0:IdcFile"/>
<s:element minOccurs="0" name="alternateFile" type="s0:IdcFile"/>
<s:element minOccurs="0" name="extraProps" type="s0:IdcPropertyList"/>
</s:sequence>
</s:complexType>
</s:element>
Two of those complex types are the ones that make WCC's model work over SOAP. IdcFile is fileName plus fileContent as base64Binary — so a file rides inside the SOAP body as base64 (this is exactly why the MTOM decision above matters). IdcPropertyList is a repeating list of name/value IdcProperty pairs — that's your escape hatch for custom metadata fields (xInvoiceNumber, xReceivedDate, whatever your content type carries) without needing them declared in the WSDL. You pass them as properties in CustomDocMetaData.
One historical detail worth knowing so it doesn't surprise you: the CheckIn WSDL's target namespace is http://www.stellent.com/CheckIn/. Stellent is the pre-Oracle lineage of the product, and that namespace persists in the contract. It's not a typo and it's not deprecated — bind to it as-is.
The request you actually send
The service-level SOAP body wraps an IdcService element naming the service as CHECKIN_UNIVERSAL, with a document carrying the metadata attributes and a file reference. The reference project's working request looked like this (metadata values illustrative):
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="CHECKIN_UNIVERSAL">
<idc:document dDocName="OICSoapUpload1"
dDocAuthor="sysadmin"
dDocTitle="OICSoapUpload1 Document"
dDocType="Document"
dSecurityGroup="Public"
dDocAccount=""
xReceivedDate="">
<idc:file name="primaryFile" href="C:/tmp/soaptest.doc"/>
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Notice the custom fields (xReceivedDate and friends) sit right alongside the system d-fields as attributes on document. That's the IdcService convention: x-prefixed attributes are your content type's custom metadata, and they flow through the same call. In an OIC integration you'll typically map incoming flow variables into these attributes and stream the file bytes into the file element rather than referencing a server path.
The response — read it as an IdcService document, not a typed object
Here's the part that trips people up coming from a normal typed-SOAP mindset. The response is not a compact CheckInUniversalResult with three fields. It's a full IdcService result document — the same envelope structure, echoing back the entire content item as attributes on document, plus a long list of field elements. The ones that matter for a successful check-in:
<idc:document dDocName="OICSoapUpload1" dID="12" dDocID="24"
dRevisionID="1" dRevLabel="1" dStatus="DONE" ...>
<idc:field name="StatusCode">0</idc:field>
<idc:field name="StatusMessage">
Successfully checked in content item 'OICSoapUpload1'.
</idc:field>
<idc:field name="dConversion">PASSTHRU</idc:field>
...
</idc:document>
So in your OIC mapping, the two things you assert on are StatusCode and StatusMessage. StatusCode of 0 means the check-in succeeded; a negative value means it did not, and StatusMessage carries the human-readable reason. The dID, dDocName, and dRevLabel on the document are what you capture downstream — that's the repository's identity for the item you just created, and you'll want to persist or return it so the rest of the flow can reference the content.
Don't try to bind the response to a rigid schema and fail the invoke when a field you didn't expect shows up — the field list is long and varies by content type. Parse for StatusCode/StatusMessage first, capture the identity fields you need, and ignore the rest.
What this pattern buys you
Once the SOAP connection, the WSM policy pair, and the key map are in place, CHECKIN_UNIVERSAL is just the first of many. The same connection and the same security give you CheckOut, UpdateDocInfo, and the rest of the CheckIn port type — and the broader IdcService surface behind them — from any OIC integration. That turns WebCenter Content into a first-class participant in your integration fabric: an AP flow can file an invoice image and stamp its metadata in the same orchestration that posts the payable, and a records flow can update document info as a case moves through its lifecycle.
The judgment calls — which security policy class fits your environment, whether MTOM belongs in the picture, how tightly to scope the service account, how to stream file bytes efficiently through OIC rather than base64-bloating every message — are where a working integration diverges from a fragile one. That's the part the adapter wizard won't decide for you.
If you're integrating WebCenter Content with OIC (or with any orchestration layer) and want a second set of eyes on the security model or the check-in flow before it goes to production, that's a conversation we're happy to have.