December 17, 2014
Hot Topics:

Connecting to IBM FileNet 4.0 Outside of a Java Application Server

  • December 29, 2008
  • By Anthony Lee
  • Send Email »
  • More Articles »

FileNet P8 4.0 takes advantage of a combination of the J2EE application server, JAAS, and directory services to establish authentication. Because PE resolves its authentication through the CE, Directory Services only need to be configured once for the CE. Authorization is provided on many levels and can be as broad as an LDAP group or as specific as a particular user. This concept applies to both CE and PE elements.

When IBM released FileNet P8 4.0, it introduced major architectural changes from previous versions. By incorporating more J2EE standards, it allowed FileNet P8 4.0 to be run on operating systems other than Windows as long as it is installed on a J2EE Application Server. Old FileNet API code is still compatible with FileNet P8 4.0, but it is highly recommended to switch to the 4.0 APIs.

One of the key changes was the transport methods for connecting to CE and PE. Previously, the communication used Content Engine Web Service (CEWS) transport based on the SOAP protocol. This has been upgraded with the capability to use an EJB protocol along with added benefits such as using JAAS for security.

Uses of FileNet Outside of an Application Server

FileNet Workplace is the out-of-the-box Web-based application that is usually deployed along with FileNet CE and PE. It allows users to organize documents, create workflows, and lots more. However, there may be cases where unique requirements aren't solved in Workplace or FileNet may need to be integrated seamlessly into an existing application. This is where the flexibility of the FileNet API comes into play. It enables you to do pretty much everything that Workplace can while allowing you to add in your own custom logic and functionality. This is an easy way to create robust custom applications that are backed by enterprise-level content and business process management.

These custom applications can be online or offline applications and be built in .NET or Java. In any case, the ability to test custom code using the FileNet API is crucial to fast development and a quality product. To do this, you'll want to be able to connect to FileNet outside of an application server. However, there are some things that need to be set up first to connect to FileNet through the API. An example is CE is deployed as a J2EE application and some libraries from the application server that CE is deployed on will need to be included. The rest of the article will serve as a tutorial for getting started using the FileNet API and connecting to a FileNet environment.

Setting Up the Environment

A working FileNet 4.0 environment needs to be configured before running the sample code presented in this article. Because my FileNet environment runs on a WebSphere 6.1 application server and uses Java 1.5, this is the base that I will be using throughout the article. If you are running FileNet on a different platform, minor changes in the VM Arguments and JAR files are needed to match the application server you are using. These differences are talked about later in the article.

I'll be using the EJB transport protocol along with JAAS for authentication. Before the sample code is run, it is necessary to configure the CE and PE elements to retrieve in your sample code. This includes but is not limited to Domain, Object Store, Document Classes, Isolated Region, Roster, and Queues. Refer to your FileNet documentation for more information on configuring these items.

Setup Tasks

For the sample code to use the correct JAAS stanza, the line shown in Listing 1 needs to be included in the JAAS configuration file:

Listing 1: JAAS Stanza

FileNetP8 {
   com.ibm.ws.security.common.auth.module.WSLoginModuleImpl
      required;
};

If you aren't using JAAS currently, you can create a blank text file containing the stanza and save it to your application configuration folder.

There are a couple WebSphere specific files that are used as well. To establish a connection to CE residing on WebSphere, the proper Secure Association Service (SAS) file must be configured. This file resides in this folder:

{WebSphere Root}\IBM\WebSphere\AppServer\profiles\
   {Profile Name}\properties

Copy the sas.client.props file to the configuration folder. If SSL is also needed, copy the ssl.client.props file as well.

The following lines need to be modified in the sas.client.props file you just copied:

Listing 2: sas.client.props File Changes

...
com.ibm.CORBA.securityServerHost={CE Server DNS or IP}
com.ibm.CORBA.securityServerPort={CE Server Port}
...
com.ibm.CORBA.loginSource=none
...

If you are using SSL, nothing needs to be changed in the ssl.client.props file you copied over.

The following FileNet-specific JARs must be added to run the sample code. They can be found in the lib directory within the Workplace application.

  • Jace.jar (Contains the CE API)
  • pe.jar (Contains the PE API)

The following WebSphere 6.1-specific JARs also need be added to run the sample code:

  • com.ibm.ws.admin.client_6.1.0.jar ({WebSphere Root}\IBM\WebSphere\AppServer\runtimes)
  • j2ee.jar ({WebSphere Root}\IBM\WebSphere\AppServer\lib)

Additionally, these libraries need to be added as well:

  • Log4j 4.x
  • JUnit 4.x

Tags: API



Page 2 of 5



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel