Calling WebCenter Content from OIC over SOAP: a field runbook

An integration in Oracle Integration Cloud that needs to push a document into WebCenter Content (an invoice image, a signed PDF, a scanned form) has to decide how the two systems talk. WCC exposes its full IdcService surface over a native SOAP layer, and OIC ships a SOAP adapter. Wired correctly, that is a supported, credential-secured path to check content in and out of the repository from any flow you build. Wired loosely, it is an afternoon of SOAP faults that do not say what is wrong.

We built this on a WCC-to-OIC check-in for a national home-services company, and this is the runbook: the three things that must be in place, the WSDL shape, and the exact request and response to expect.

The shape of the integration

OIC receives or assembles the file and its metadata and hands both to WCC's CHECKIN_UNIVERSAL service. WCC creates the content item, assigns a dID and dDocName, and returns a status. Before that call can succeed:

1. Web service security is configured through Oracle Web Services Manager (OWSM) policies, matched on the OIC request and the WCC service.
2. A key map holds the credential OIC uses to authenticate to WCC.
3. The correct CheckIn WSDL is registered in OIC as the SOAP connection's target.

Step 1: the OWSM policy pair

WCC secures its SOAP endpoints with OWSM policies, and the client policy attached on the OIC side has to be compatible with the one WCC enforces. WCC supports username-token and SAML classes for these endpoints; in practice the service side carries one of:

• oracle/wss11_username_token_with_message_protection_service_policy
• oracle/wss11_saml_token_with_message_protection_service_policy

On the reference integration the working configuration was oracle/no_mtom_policy on the message path, paired with a username-token policy for authentication. MTOM deserves explicit attention: if the 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 MTOM on both ends on purpose.

The rule: the client policy in OIC and the service policy in WCC are a matched pair. A wss11_username_token_with_message_protection service policy expects the corresponding _client policy on the caller. A mismatch is the most common reason a first invoke fails, and it reads as a generic policy-enforcement fault that points at the symptom rather than the cause. Which class fits (username-token or SAML, message protection on or off) is a decision about your environment's trust model, not something the adapter wizard picks correctly on its own.

Step 2: the key map

OIC does not put a raw username and password in the SOAP header. It references a key in a credential map, and the key resolves to the WCC service account at runtime. Create the key map for this integration's credential before you build the connection.

Two reasons this is the right pattern. The credential is stored once and referenced by name, so rotating the WCC service-account password is a one-place change. And the secret stays out of the integration's design-time metadata. Provision a dedicated WCC service account with exactly the security-group and account rights the check-in needs, and map it under a stable key.

Step 3: the CheckIn WSDL

This is the step that goes wrong most often. The OIC SOAP connection does not point at the WCC web console or the generic IdcService URL. It points at the CheckIn service WSDL, which describes check-in and check-out as typed SOAP operations on a CheckInSoap port type:

• CheckInUniversal creates a new content item from a file plus metadata
• CheckOut and CheckOutByName check out by dID or dDocName
• UndoCheckOut and UndoCheckOutByName
• UpdateDocInfo updates metadata on an existing revision
• CheckInList enumerates items pending check-in

The CheckInUniversal request type is the WCC content model expressed as XML: the d-prefixed system fields, 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 complex types carry the model. IdcFile is fileName plus fileContent as base64Binary, so the file rides inside the SOAP body as base64, which is exactly why the MTOM decision above matters. IdcPropertyList is a repeating list of name/value IdcProperty pairs: the way to pass custom metadata (xInvoiceNumber, xReceivedDate, whatever the content type carries) in CustomDocMetaData without declaring it in the WSDL.

One detail so it does not surprise you: the WSDL's target namespace is http://www.stellent.com/CheckIn/. Stellent is the product's pre-Oracle lineage and the namespace persists in the contract. Bind to it as-is.

The request

The SOAP body wraps an IdcService element naming CHECKIN_UNIVERSAL, with a document carrying the metadata as attributes and a file reference. The working request, with illustrative values:

<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>

The custom x-prefixed fields sit alongside the system d-fields as attributes on document; that is the IdcService convention. In a real OIC integration you map flow variables into those attributes and stream the file bytes into the file element rather than referencing a server path.

The response

This is where a typed-SOAP mindset trips. The response is not a compact result with three fields. It is a full IdcService result document: the same envelope structure, the entire content item echoed back as attributes on document, and a long list of field elements. For a successful check-in the ones that matter are:

<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>

In the OIC mapping, assert on StatusCode and StatusMessage. Zero means the check-in succeeded; a negative value means it did not, and StatusMessage says why. dID, dDocName and dRevLabel on the document are the repository's identity for the item; persist or return them so the rest of the flow can reference the content. Do not bind the response to a rigid schema and fail the invoke when an unexpected field appears; the list is long and varies by content type. Parse for status first, capture the identity fields, ignore the rest.

What the pattern buys you

With the SOAP connection, the policy pair and the key map in place, CHECKIN_UNIVERSAL is only the first call. The same connection gives you CheckOut, UpdateDocInfo and the rest of the CheckIn port type, and the wider IdcService surface behind them, from any OIC integration. WCC becomes a first-class participant in the 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 policy class fits the trust model, whether MTOM belongs, how tightly to scope the service account, how to stream file bytes through OIC without base64-bloating every message, are where a working integration diverges from a fragile one. The adapter wizard does not make them for you. And on the 12c-to-14c timeline this is one of the integrations to re-test explicitly after the WebCenter 14c upgrade, because the endpoint, the policy store and the service account all move with the domain.