Build a New Content Connector

To build a new content connector as a Restful service, a developer needs to implement the Restful interfaces provided by the connector framework.

The Oracle Content and Experience connector framework has the following interfaces.

  • APIResource Interface: This interface is the starting point of the content connector. You simply return the version that's supported.

  • ServerResource Interface: When a developer or administrator registers a content connector in the Oracle Content and Experience server, Oracle Content and Experience calls this service to get the basic details about the connector server, such as these:

    • Authorization type:

      • OAUTH: If the remote cloud store supports 3-legged OAuth authentication
      • BASIC_AUTH: If the remote cloud store supports Basic authentication


        Oracle no longer supports Basic authentication for general consumption.
      • NO_AUTH: If the remote store doesn’t require any authentication
    • Picker type: Oracle Content and Experience supports the Oracle Content and Experience generic picker to list the file system. If the content connector supports the native picker, then the content connector implementer can implement JavaScript APIs to integrate that picker with the Oracle Content and Experience UI. The picker type can be one of three values:

      1. COMMON, using the common UI
      2. CUSTOM, using a custom UI
      3. NATIVE, using a native UI like Google Drive or Microsoft OneDrive
    • Also use this Interface to define custom fields for the content connector. Custom properties are connector specific, so the connector framework can’t provide such a properties list by itself. Every content connector has its own requirement to connect to a remote store; for example, one content connector might need just ClientID and ClientSecret, while another might require ClientID, ClientSecret, AppID, and so on. Each content connector can provide a custom properties list to the Oracle Content and Experience server by ServerResource. If any of these properties need to be filled in by a developer or administrator during configuration, the connector framework will surface them in the administration UI.

    This service will be called only once, at the time of registration.

  • AuthorizationResource Interface: Used to complete the authorization before content from the remote store can be copied to the Oracle Content and Experience repository. This interface has support for both OAuth and Basic authentication protocols.

    • 3-legged OAuth authentication
      • In the OAuth flow, the Oracle Content and Experience UI, based on the custom property value provided by the content connector, supports OAuth authentication. It triggers an OAuth flow by calling the connector framework, which in turn calls the /authorization/authorization URLs service on the content connector to get the authorization URL.

      • The Oracle Content and Experience UI renders the authorization URL in a browser, where the user authorizes the application and gives Oracle Content and Experience permission to access the token for further communication. To complete the authorization and get the OAuth token, the Oracle Content and Experience server will call the /authorization/completedAuthorizations service on the content connector. To complete 3-legged OAuth, the Oracle Content and Experience server also provides the redirect callback servlet, which the remote store will call to complete the authorization process.

    • Basic authentication: In case the content connector supports Basic authentication, the Oracle Content and Experience UI will prompt the user to enter a user name and password, which it will pass to the Oracle Content and Experience server (connector framework). The connector framework will call the /authorization/ basicAuthorization service to pass the credentials and will expect the content connector to validate with the remote store if the credentials are correct.
  • FileSystemResource Interface: The connector framework supports the generic file picker, which can be used by content connectors to render the file-system information for a user to browse the files. But, the content connector needs to implement the /filesystem service to use this functionality. Highlights of this service follow:

    • The user can browse the file system like any other file picker; for example, the Google Drive or Microsoft OneDrive picker.

    • This supports pagination.

    • The user can also specify the search criteria to get the filtered result.

  • ContentResource Interface: The connector framework uses the service /content to get the actual content (the bytes of the files) stored in the cloud store.

    This service returns as a response, and the response entity is the content of the file. The response should include the following headers:

    • Content-Length: Set to the entity length, or -1 if unknown.

    • Content-Type: Set to the content type, or application/octet-stream if a more accurate type is not possible.

    • Content-Disposition: Set to the disposition type of attachment, and includes a filename parameter (for example, Content-Disposition: attachment; filename="meeting agenda.doc"). Note that file names with spaces must be in quotation marks. See RFC 6266 for details about the format and encoding of the header.

Each of these interfaces is described in more detail, with examples of REST payloads, in the following sections: