Setting Up a Thin Client Application Development Environment Using EJB Transport

For IBM WebSphere Application Server:

1. Create and deploy a custom EAR or WAR file in which the WAR\WEB-INF\lib folder contains the JAR files that are listed under "Required for a Content Engine Java™ API EJB transport client" in the Required Java Archive (JAR) Files topic.
   Note: If your development environment is co-located with Content Engine (a local development environment), you can copy the required JAR files from Content Engine. If your development environment is not co-located with Content Engine (a remote development environment), then the JAR files that are required for Content Engine are available from the Content Engine client installer (P8CE-CLIENT-version-WIN.EXE, where version is the release, such as 4.5.1).
2. On the WebSphere administrative console, set the EAR or WAR class loader order to load classes from the local class path first and from the parent application server class path last.

   For WebSphere Version 7.0: Navigate to applicationPage, then select Class loading and update detection and PARENT_LAST.

3. Set up the LTPA settings to create trust relationships between your client application server and the Content Engine application server when they are on different WebSphere application servers.

   On the Content Engine WebSphere Application Server:

   1. On the WebSphere administrative console of the Content Engine application server, navigate to the LTPA settings page.
   2. For WebSphere Version 7.0, navigate to Security > Global security, and then select LTPA.
   3. Enter an LTPA timeout value and then save the changes.
      Tip: Using the default value of 120 minutes is sufficient, if it is not less than the Security Cache timeout value.
   4. Type a password into the Cross-cell single sign-on > LTPA password field. (See your WebSphere documentation for password restrictions.)
   5. In the Key File Name field, enter the fully qualified path in which the key file is stored. For Example, non-Windows: /opt/LTPA/ltpa_key_name; Windows: c:\LTPA\ltpa_key_name.
   6. Click Export keys and confirm that you get a message that indicates success. If the step was unsuccessful, review the procedure and correct any errors. Otherwise, click Save changes directly to the master configuration.
   7. Stop and then restart WebSphere Application Server.
   8. Copy the key file from the Content Engine server location you specified in step e to a directory on the application server that is servicing your custom client application.

      On the client application WebSphere Application Server:

   9. On the WebSphere administrative console of the client application server, navigate to the LTPA settings page.
   10. For WebSphere Application Server 7.0, navigate to Security > Global security, and then select LTPA.
   11. Enter an LTPA timeout value and then save the changes.
       Tip: Using the default value of 120 minutes is sufficient, if it is not less than the Security Cache timeout value.
   12. In the Cross-cell single sign-on box, type in the LTPA password that you created for the Content Engine in step d.
   13. Specify the path for the key file that you copied to the client application WebSphere Application Server in step i.
   14. Click Import keys and confirm that you get a message that indicates success. If the step was unsuccessful, review the procedure and correct any errors. Otherwise, go to the next step.
   15. Click Save changes directly to the master configuration.
4. If your client application server and Content Engine are hosted on different WebSphere application servers, configure stand-alone LDAP settings for communications between WebSphere Application Server and the Content Engine. If they are deployed on the same application server, LDAP settings are already set up for Content Engine.
   Important: If you have a multiple domain environment, configure LDAP settings for federated repositories. Any unique settings for that environment are noted in the following steps. Also, be aware that if you are using federated repositories, your WebSphere administrative console user cannot have the same user name or ID as a user in the LDAP directory.
   1. On the client WebSphere Application Server administrative console, for WebSphere Version 7.0, navigate to Security > Global security.
   2. Temporarily disable (clear) the following security flag settings:
      • Enable administrative security
      • Enable application security
      • Java2 security
   3. From the Available realm definitions drop-down list, select Standalone LDAP registry and then click Configure. For federated repository configuration, select Federated Repositories instead and then click Configure.
   4. Configure the LDAP provider to exactly match the corresponding settings on the Content Engine application server.
      Tip: Open the WebSphere administrative console for Content Engine to the same windows and copy all settings. You can find the settings on the Configuration tab under General Properties.
   5. Configure the LDAP user registry settings to exactly match the corresponding settings on the Content Engine application server.
      Tip: Open the WebSphere administrative console for Content Engine to the same windows and copy all settings. You can find the settings on the Configuration tab under Additional Properties. Click the link for Advanced LDAP User registry settings and copy the values that you find under General Properties.
   6. Save all changes.
   7. Confirm that Standalone LDAP registry is still selected and if so, click Set as current. For federated repositories configuration, confirm that Federated Repositories is still selected before you click Set as current.
   8. Reset the security flags that you disabled in step b as follows:
      • Enable (select) Enable Administrative Security.
      • Enable (select) Enable application security.
      • Make sure that Java2 security is disabled (that is, not selected).
        Important: The IBM FileNet P8 Platform does not support Java 2 security. Enabled Java 2 security causes unexpected behavior.
   9. Click Save changes directly to the master configuration.
   10. Test the connection on the Standalone LDAP registry page. For federated repositories configuration, test the connection on the Federated repositories page.

       If the test fails, correct the error before proceeding. If the test succeeds, click OK to return to the previous page.

       You can ignore messages that indicate that the ID does not exist in the user repository.

   11. Stop and restart the application server.

If you are using the Content Engine Java API, no additional steps are required. However, if you are using the IBM FileNet P8 Compatibility Layer, which is a client-side API that allows you to upgrade and maintain applications that are written by using the 3.5.x Content Java API, then you must perform the two extra steps that are documented in the Modifying WcmApiConfig.properties for the IBM FileNet P8 Compatibility Layer topic.

For Oracle WebLogic Application Server:

1. Create and deploy a custom EAR or WAR file in which the WAR\WEB-INF\lib folder contains the JAR files that are listed under "Required for a Content Engine Java API EJB transport client" in the Required Java Archive (JAR) Files topic.
   Note: If your development environment is co-located with Content Engine (a local development environment), you can copy the required JAR files from Content Engine. If your development environment is not co-located with Content Engine (a remote development environment), then the JAR files that are required for Content Engine are available from the Content Engine client installer (P8CE-CLIENT-version-WIN.EXE, where version is the release, such as 4.5.1).
2. Edit the weblogic.xml file to set the EAR and WAR class loader policy as follows:

   <container-descriptor>
         <prefer-web-inf-classes>true</prefer-web-inf-classes>
    </container-descriptor> 
    

   This change causes the class loader to load classes from the local class path first and from the parent application server class path last.
3. Set up the trust relationships between your client application server and the Content Engine application server when they are in different WebLogic domains.
   1. On the WebLogic administrative console of the Content Engine application server, navigate to the advanced security settings page.
   2. Enter a password for the domain.
   3. Save and activate your changes.
   4. Restart the Content Engine application server if needed.
   5. On the WebLogic administrative console of the client application server, navigate to the advanced security settings page for your domain, and enter the same password as you used for the Content Engine application server in step b.
   6. Restart the client application server if needed.
4. Configure LDAP settings for communications between WebLogic and Content Engine.
   Important: You can create these settings with an Authentication Provider in WebLogic Server. Refer to your Content Engine installation worksheet and the WebLogic Server Administration Console settings for Compatibility Security > Realms for Authentication Provider, users, and groups.
   1. On the client WebLogic application server's administrative console, create a new Authentication Provider of the same type as the LDAP Authentication Provider on the Content Engine.
   2. Configure the new Authentication Provider to have the same provider-specific LDAP settings as the Authentication Provider on the Content Engine.
      Tip: Open the Content Engine application server administrative console to the same windows and copy all settings.
   3. For both the default and the new Authentication provider, ensure that DefaultAuthenticator > Control Flag in Common Settings is set to SUFFICIENT.
   4. Save your changes.
   5. Restart the application server.

If you are using the Content Engine Java API, no additional steps are required. However, if you are using the IBM FileNet P8 Compatibility Layer, which is a client-side API that allows you to upgrade and maintain applications that are written by using the 3.5.x Content Java API, then you must perform the two additional steps that are documented in the Modifying WcmApiConfig.properties for the IBM FileNet P8 Compatibility Layer topic.

For JBoss Application Server:

1. Create and deploy a custom EAR or WAR file in which the WAR\WEB-INF\lib folder contains the JAR files that are listed under "Required for a Content Engine Java API EJB transport client" in the Required Java Archive (JAR) Files topic.
   Note: If your development environment is co-located with Content Engine (a local development environment), you can copy the required JAR files from Content Engine. If your development environment is not co-located with Content Engine (a remote development environment), then the JAR files that are required for Content Engine are available from the Content Engine client installer (P8CE-CLIENT-version-WIN.EXE, where version is the release, such as 4.5.1).
2. Configure LDAP settings for communications between JBoss and Content Engine.
   1. On the client application JBoss Application Server, create a backup copy of the JBoss_home/server/server_name/conf/login-config.xml file, replacing JBoss_home and server_name in the path with your own JBoss home location and server name.
   2. Open the login-config.xml file with a text editor, and just before the final </policy> line of the file, add an entry <application-policy name="FileNet"> that exactly matches the corresponding entry in the login-config.xml file on the Content Engine server.

      You can copy this entry from the Content Engine login-config.xml file. If you have no custom entries in the file on your client application server, you can replace the login-config.xml file on the client application server with a copy of the same file from the Content Engine server.

   3. Make a backup copy of JBoss_home/server/server_name/deploy/ear-deployer.xml. Edit the file to change the CallByValue attribute from false to true.
   4. Execute the appropriate file for your environment to restart the JBoss Application Server and verify your configuration changes:
      • non-Windows: ./run.sh
      • Windows: run.bat

If you are using the Content Engine Java API, no additional steps are required. However, if you are using the IBM FileNet P8 Compatibility Layer, which is a client-side API that allows you to upgrade and maintain applications that are written by using the 3.5.x Content Java API, then you must perform additional steps as documented in the Modifying WcmApiConfig.properties for the IBM FileNet P8 Compatibility Layer topic.

Modifying WcmApiConfig.properties for the IBM FileNet P8 Compatibility Layer

If you are using the IBM FileNet P8 Compatibility Layer, which is a client-side API that allows you to upgrade and maintain applications that are written by using the 3.5.x Content Java API, then you must perform the following steps in addition to the previous procedure that is applicable to your application server environment. The additional steps are listed as follows:

1. Open the WcmApiConfig.properties file with a text editor. This file is in the install_path\WEB-INF\classes directory.
2. Modify WcmApiConfig.properties with the following entries (unless your application sets them programmatically):

   RemoteServerUrl=jnp://ceServer:port/FileNet/Engine
   RemoteServerUploadUrl=jnp://ceServer:port/FileNet/Engine
   RemoteServerDownloadUrl=jnp://ceServer:port/FileNet/Engine

   The previous example entries reflect the protocol (jnp:) for a JBoss Application Server environment, but you must substitute the protocol type that you are using (such as http, jnp, iiop, t3).

   ceServer is your Content Engine server. port is the port that you are using.

   For sample URLs based on application server type and protocol type, see Enabling SSL for Content Engine.

3. Modify WcmApiConfig.properties to point jaasConfigurationName to FileNetP8.