|
|
WebLogic Portal's Virtual Content Repository allows you to connect to non-BEA repositories. When third-party repositories are connected to the Virtual Content Repository, their content can be accessed by portal tools such as content placeholders, content selectors, and so on.
Some third-party content management vendors have built integrations (Content Service Provider Implementations or SPIs) that allow you to connect third-party repositories to the Virtual Content Repository. Contact your third-party repository vendor to find out the details about their implementation.
If the third-party repository you are using is JSR 170 compliant, you can connect to it via BEA's JSR 170 Connector, you can use BEA's JSR 170 Connector, see Working with a JSR 170-Compatible Repository. For more information about JSR170, see the JSR 170 website.
If you are using a third-party repository from a vender that has not written an implementation for WebLogic Portal's Virtual Content Repository, you can write your own using BEA's Service Provider Interface (SPI).
This chapter includes the following sections:
Configuring a third-party repository to use with WebLogic Portal involves the following three steps:
The SPI implementation runs inside a WebLogic Portal enterprise application. Different implementations may affect scalability and performance for WebLogic Portal.
The following section gives a brief overview of some interfaces a SPI implementation for accessing a third-party repository must implement, and some of the classes the SPI implementation can use. See the Content SPI JavaDoc for detailed information.
The SPI includes two types of interfaces:
The SPI also includes classes that allow you to use error messages (repository exceptions) to indicate if operations are not allowed in the repository. For example, the SPI allows for content to be added to folders, if the repository does not allow that behavior then it must throw a RepositoryException stating so.
If a method is not implemented at all, then a UnsupportedRepositoryOperationException can be thrown.
This section includes the following topics:
Repository Connection Interfaces include the interfaces listed in Table 8-1. In order for a client of the SPI to connect to the services, the repository connection interfaces must be implemented. These interfaces allow an SPI implementation to be plugged into the BEA content management framework.
For more information about these repository connection interfaces, see the WebLogic Portal JavaDoc for the com.bea.content.spi package.
ExtendedTicket enables repository services that are available in WebLogic 9.2. For example, content workflows can be used. For more information about content workflows, see Using Content Workflows in Your BEA Repository.
|
|
Service Interfaces are used to perform the primary content management tasks within your repository such as adding content, updating it and deleting it.
Service interfaces are expected to be transactional (where necessary), threadsafe and scalable. There can be one implementation for all interfaces, or a separate implementation for each service interface. All service methods throw a general com.bea.content.RepositoryException. The SPI also includes a few standard exceptions that extend the RepositoryException.
Table 8-2 lists the service interfaces available with the content SPI. For more information about these service interfaces, see the WebLogic Portal JavaDoc for the com.bea.content.spi package.
ExtendedObjectClassOps provides access to newer features for objectClasses (content types) that are included in WebLogic Portal 9.2 See Using Content Types in Your BEA Repository for more information.
|
|
Listing 8-1 is an example of a repository implementation is that is called by the Virtual ContentManager.
public class RepositoryImpl implements Repository
{
Properties properties;
String name;
public Ticket connect(Credentials credentials)
{
return new TicketImpl(credentials, properties);
}
public Ticket connect(String userName, String password)
{
Subject subject = com.bea.p13n.security.Authentication.
getCurrentSubject();
Credentials credentials = new Credentials(subject);
return new TicketImpl(credentials, properties);
}
public Properties getProperties()
{
return properties;
}
public void setProperties(Properties properties)
{
this.properties = properties;
}
public String getName()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
}
Once you have an SPI implementation, you need to connect the third-party repository to the Virtual Content Repository using the Portal Administration Console. After you have connected a third-party repository to the Virtual Content Repository, you can use that repository's content within your portal. If the third-party repository implementation includes write capabilities, you can also use the Portal Administration Console to modify content within the repository.
An SPI can be deployed multiple times with different configuration parameters. From the application's perspective, this appears as multiple repositories.
| Note: | BEA's library services are not supported for use with SPI implementations. |
When you connect to a third-party repository, you may need to configure additional properties that match your third-party repository's configuration. Consult your third-party documentation to verify the properties you need to configure and the connection class you should use.
To connect a repository to the Virtual Content Repository:
WebLogic Portal provides a connector to repositories which implement the JSR 170 Specification such as Day Software's CRX. If you want to access a repository via its JSR 170 interface, you do not need to write a custom SPI implementation.
This section assumes you have already installed and configured a JSR 170 repository. For additional documentation about installing and using Day Software's CRX JSR 170 repository, see the WebLogic JSR 170 Adaptor Developer's Guide and the WebLogic JSR 170 Supported Configurations Guide.
This section discusses the following topics:
When a repository is connected to the Virtual Content Repository, both content contributors and developers can search for content within the repository. However not all metadata provided by the Virtual Content Repository (system properties, MIME types, and so on) are supported by the JSR 170 specification, so some searches may be invalid.
The following system properties cannot be used when searching JSR 170 repositories:
The following search operators cannot be used:
To connect to a JSR 170 repository, do the following:
|
Repeat the following steps for each property you want to add:
|
