6 Integrating Oracle UCM with Enterprise Applications

This chapter describes how to integrate Oracle Universal Content Management (Oracle UCM) with enterprise applications.

This chapter includes the following sections:

6.1 Overview of Integration Methods

Several easy, flexible methods are available for integrating Oracle Content Server with enterprise applications such as application servers, catalog solutions, personalization applications, and enterprise portals, and client-side software.

Oracle Content Server not only serves as a content management solution for content-centric web sites, but also provides a scalable content management infrastructure that supports multiple enterprise applications in many diverse environments and platforms. The integration solutions enable other enterprise applications to access content managed by the content management system and provides these applications with critical content management capabilities such as full-text and metadata searching, library services, workflow, subscription notifications and content conversion capabilities through a wide array of integration methods.

In general, these integration methodologies serve to translate or pass methods and associated parameters with the goal of executing Oracle Content Server services. The various Oracle Content Server services are the "window" for accessing the content and content management functions within Oracle Universal Content Management. For example, one simple integration option is to reference content that is managed within Oracle UCM by persistent URL. Other integration options are to use the Java API, the Microsoft Component Object Model (COM) interface, or the ActiveX control.

The focus of this chapter is to present the available integration options, suggest an approach, (like IdcCommand X, or persistent URL, or SOAP), and provide information about where to get the detailed documentation on that approach. Specifically, this chapter provides basic conceptual information about the integration of Oracle Universal Content Management within network system environments using various protocols, interfaces, and mapping services.

For information about using the IdcCommand utility to access Oracle Content Server services from other applications, see Chapter 7, "Using the IdcCommand Utility to Access Services."

For information about the COM interface, see Chapter 8, "Using the COM API for Integration."

For information about Remote Intradoc Client (RIDC) integration, see Chapter 9, "Using Remote Intradoc Client (RIDC)."

6.2 JSP Integration

You can access the Oracle Content Server core functionality from JavaServer Pages (JSP) to deliver forms and custom pages using any of these methods:

The following subsections describe JSP integration with Oracle Content Server:

6.2.1 JSP Execution

The JSP Execution functionality uses the built-in Apache Jakarta Tomcat Servlet/JSP Server to access the content and content management functions within Oracle Content Server.

The Apache Jakarta Tomcat Server is a free, open-source server of Java Servlet and JavaServer Pages that is run inside of Oracle Content Server when the feature is enabled. The integration of Tomcat Server with Oracle UCM provides the benefit of increased performance for content delivery.

Using JSP Execution functionality enables developers to access and modify Oracle Content Server content, ResultSets, personalization and security definitions, and predefined variables and configuration settings through JavaServer Pages rather than through standard component architecture. Services and Idoc Script functions can also be executed from JSP pages which reside as executable content in Oracle Content Server.

Important:

JSP pages can execute Idoc Script functions only when the JSP page is being served on Oracle Content Server as part of the JSP Execution functionality. JSP pages served on a separate JSP server do not have this functionality. In those cases, checking in a JSP page to Oracle Content Server provides revision control but does not provide dynamic execution of Idoc Script functions on the presentation tier (JSP server).

6.2.2 Tomcat

The capability for JSP to call services is provided by integrating the Tomcat 5.025 server with the Oracle Content Server core functionality.

  • Tomcat is a free, open-source server of Java Server and JavaServer Pages; version 5.025 complies with Servlet 2.4 and JSP 2.0 specifications.

  • The main benefit of integrating Tomcat into Oracle Content Server is the increase in performance of delivering content. The direct integration eliminates the need for a socket-based interface and enables the use of all Oracle Content Server core capabilities.

  • Although Tomcat is embedded in Oracle Content Server, you can use server.xml as the configuration file to modify the internal Tomcat engine to suit your needs.

    Note:

    This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

6.2.3 Features

With JSP support enabled, custom components can include JSP pages of type jsp and jspx.

  • The DomainHome/ucm/cs/weblayout/jsp directory is able to host JSP pages by default.

  • The Oracle Enterprise Content Management Suite distribution media also includes the current Java EE SDK.

6.2.4 Configuring JSP Support

Use the following procedure to enable and configure JSP support.

  1. In Oracle Content Server, create a new security group to be used for JSP pages (called jsp in the subsequent steps). This security group should be restricted to developers. This step is not required but it is recommended for developer convenience. Any security groups to be enabled for JSP must be specified in Step 5.

    1. Display the User Admin screen.

    2. From the Security menu, choose Permissions by Group.

    3. Click Add Group.

    4. Enter jsp as the group name, enter a description, and then click OK.

    5. Assign Admin permission to the admin role and any developer roles.

    6. Assign Read permission to all non-admin roles.

    7. Click Close.

  2. If you run on AIX, HP-UX, or Linux s390, the Java 2 SDK, which is required for the JSP integration, is not installed on your system automatically, nor is it provided on the distribution media. For the internal JSP engine to run on any of these operating systems, a 1.5 JDK must be present on the server, and the CLASSPATH value in the intradoc.cfg file must be modified to include the path to the tools.jar file. For example, for a default 1.5 install on AIX, this file should be in /usr/java15/lib.

  3. Click one of the following options:

    • On the Admin Server page, click General Configuration.

    • From the System Properties utility, click the Server tab.

  4. Enable the JSP prompt:

    • For the Admin Server: click Enable Java Server Page (JSP)

    • For System Properties: click Execute Java Server Page (JSP)

  5. Enter the security groups to be enabled for JSP (including the security group you created in Step 1).

  6. Save the settings, and restart Oracle Content Server.

6.2.5 Loading Example Pages

Use either of the following procedures to load example pages into Oracle Content Server:

  • Check in the .war file in the JSP security group. Make sure to check in other content to the JSP security group before checking in the war file.

  • Start the JSP Server Web App Admin from the Administration page.

6.3 Java 2 Enterprise Edition Integration (J2EE)

The J2EE integration for Oracle Content Server is available with Content Integration Suite, a separate product.

Content Integration Suite (CIS) enables communication with Oracle Content Server and is deployable on a number of J2EE application servers, in addition to working in non-J2EE environments. A supported version of Oracle Content Server is required.

For more information, see Chapter 10, "Using Content Integration Suite (CIS)."

6.4 Web Services

The following subsections provide an overview of web services, general information about WSDL files and the SOAP protocol, and several basic implementation architectures.

6.4.1 Web Services Framework

Web services reside as a layer on top of existing software systems such as application servers, .NET servers, and Oracle Content Server. Web services can be used as a bridge to dissimilar operating systems or programming languages.

Web services are adapted to the Internet as the model for communication and rely on the HyperText Transfer Protocol (HTTP) as the default network protocol. Thus, using web services, you can build applications using a combination of components.

Oracle Content Server provides some web services built into the core product. Oracle WebLogic Server provides SOAP capabilities, and Oracle Content Server supports several SOAP requests through Oracle WebLogic Server. Additionally, the WSDL Generator component is installed (enabled) by default with Oracle Content Server. For more information, see Chapter 12, "Using Oracle UCM Web Services."

The core enabling technologies for web services are XML, WSDL, SOAP, and UDDL:

  • �XML: Data: The eXtensible Markup Language (XML) is a bundle of specifications that provides the foundation of all web services technologies. Using the XML structure and syntax as the foundation allows for the exchange of data between differing programming languages, middleware, and database management systems.

  • �SOAP: Communication: The Simple Object Access Protocol (SOAP) provides the Oracle Content Server communication for web services interfaces to communicate to each other over a network. SOAP is an XML-based communication protocol used to access web services. Web services receive requests and return responses using SOAP packets encapsulated within an XML document.

  • �UDDI: Registry: The Universal Description Discovery and Integration (UDDI) service provides registry and repository services for storing and retrieving web services interfaces. UDDI is a public or private XML-based directory for registration and lookup of web services.

Public or private UDDI sources are not published. However this does not prevent users from integrating Oracle Content Server with other applications using web services.

The XML, WSDL, SOAP, and UDDI technologies work together as layers on the web services protocol stack. The web services protocol stack consists of these layers:

  • The service transport layer between applications (HTTP). While several protocols are available as a transport layer (for example, HTTP, SMTP, FTP, BEEP), the HTTP protocol is most commonly used. The WSDL Generator component relies on the HTTP protocol as the transport layer.

  • The messaging layer that provides a common communication method (XML and SOAP).

  • The service description layer that describes the public interface to a specific web service (WSDL).

  • The service discovery layer that provides registry and repository services for storing and retrieving web services interfaces (UDDI).

6.4.2 Virtual Folders and WebDAV Integration

The Folders/WebDAV component is available as an extra component for download from the support site. You can use the Folders component to set up an interface to Oracle Content Server in the form of virtual folders that enable you to create a multilevel folder structure and also use the WebDAV component to remotely author and manage your content using clients that support the WebDAV protocol.

  • The Folders component provides a hierarchical folder interface to content in Oracle Content Server. The component is required for WebDAV functionality, and the WebDAV Client product.

  • The WebDAV component enables WebDAV (Web-Based Distributed Authoring and Versioning) functionality to remotely author and manage your content using clients that support the WebDAV protocol. For example, you can use Microsoft Windows Explorer to check in, check out, and modify content in the repository rather than using a web browser interface.

The option to install the WebDAV component is provided during the Folders/WebDAV installation process. For more information, see the Oracle Fusion Middleware Application Administrator's Guide for Content Server.

6.4.2.1 Virtual Folders

The Folders component sets up an interface to Oracle Content Server in the form of virtual folders (also called hierarchical folders). Virtual folders enable you to create a multilevel folder structure.

Virtual folders provide two main benefits:

  • Users can find content by drilling down through a familiar folder-type interface.

  • Users can apply default metadata to content items by checking them in through a particular folder.

The following structure is used for the Folders component:

  • Each Oracle Content Server instance has a common set of virtual folders. Any change to the folders is applied systemwide.

  • There is one default system-level folder, called Contribution Folders. If you are using a custom folders interface, folders for these products may also appear at the system level of the Folders hierarchy.

  • The system administrator can change the name of a system-level folder, but cannot delete it or add a custom system-level folder except through changes to the database. (Deleting a system-level folder disables it, but does not remove it from the system.)

  • Each folder in the hierarchy contains content items that have the same numeric Folder value, which is assigned automatically upon creation of the folder. Changing the value of the Folder field for a content item places it in a different folder.

  • The number of folders and number of files in each folder can be limited by the system administrator so that virtual folder functions do not affect system performance.

6.4.2.2 WebDAV Integration

WebDAV (Web-Based Distributed Authoring and Versioning) provides a way to remotely author and manage your content using clients that support the WebDAV protocol. For example, you can use Microsoft Windows Explorer to check in, check out, and modify content in the repository rather than using a web browser interface.

WebDAV is an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. The WebDAV protocol is specified by RFC 2518.0.

For more information, see the WebDAV Resources web site at

http://www.webdav.org

WebDAV provides support for the following authoring and versioning functions:

  • Version management

  • Locking for overwrite protection

  • Web page properties

  • Collections of web resources

  • Name space management (copy/move pages on a web server)

  • Access control

When WebDAV is used with a content management system such as Oracle Content Server, the WebDAV client serves as an alternate user interface to the native files in the content repository. The same versioning and security controls apply, whether an author uses the Oracle Content Server web browser interface or a WebDAV client.

In Oracle Content Server, the WebDAV interface is based on the hierarchical Folders interface. For more information, see Section 6.4.2.1, "Virtual Folders."

6.4.2.2.1 WebDAV Clients

A WebDAV client is an application that can send requests and receive responses using a WebDAV protocol (for example, Microsoft Windows Explorer, Word, Excel, and PowerPoint). Check the current WebDAV client documentation for supported versions. The Oracle UCM WebDAV Client is a different product that enhances the WebDAV interface to Oracle Content Server.

You can use WebDAV virtual folders in Windows Explorer to manage files that were created in a non-WebDAV client, but you cannot use the native application to check content in to and out of the Oracle Content Server repository.

The Desktop software package also includes a WebDAV Client component and a Check Out and Open component.

6.4.2.2.2 WebDAV Servers

A WebDAV server is a server that can receive requests and send responses using WebDAV protocol and can provide authoring and versioning capabilities. Because WebDAV requests are sent over HTTP protocol, a WebDAV server typically is built as an add-on component to a standard web server. In Oracle Content Server, the WebDAV server is used only as an interpreter between clients and Oracle Content Server.

6.4.2.2.3 WebDAV Architecture

WebDAV is implemented in Oracle Content Server by the WebDAV component. The architecture of a WebDAV request follows these steps:

  1. The WebDAV client makes a request to Oracle Content Server.

  2. The message is processed by the web server (through a DLL in IIS).

  3. On Oracle Content Server, the WebDAV component performs these functions:

    • Recognizes the client request as WebDAV.

    • Maps the client request to the appropriate WebDAV service call on Oracle Content Server.

    • Converts the client request from a WebDAV request to the appropriate Oracle Content Server request.

    • Connects to the core Oracle Content Server and executes the Oracle Content Server request.

  4. The WebDAV component converts the Oracle Content Server response into a WebDAV response and returns it to the WebDAV client.