1. Integrating and Extending Oracle Content Management
  2. Developing Oracle Content Management Extensions
  3. Develop Content Connectors
  4. Build a New Content Connector

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 Management 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 Management server, Oracle Content Management calls this service to get the basic details about the connector server, such as these:

    • Authorization type:

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

        Note:

        Oracle no longer supports Basic authentication for general consumption.
      • NO_AUTH: If the remote store doesn’t require any authentication

    • Picker type: Oracle Content Management supports the Oracle Content Management 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 Management 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 Management 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 Management repository. This interface has support for both OAuth and Basic authentication protocols.

    • Three-legged OAuth authentication

      • In the OAuth flow, the Oracle Content Management 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 Management UI renders the authorization URL in a browser, where the user authorizes the application and gives Oracle Content Management permission to access the token for further communication. To complete the authorization and get the OAuth token, the Oracle Content Management server will call the /authorization/completedAuthorizations service on the content connector. To complete the three-legged OAuth, the Oracle Content Management 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 Management UI will prompt the user to enter a user name and password, which it will pass to the Oracle Content Management (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 are the following:

    • 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 javax.ws.rs.core.Response 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: