13 Extending the Domain to Include Inbound Refinery

You need to perform certain tasks in order to extend the enterprise deployment domain to include Inbound Refinery software.

• Extending the Domain for Inbound Refinery
  The instructions for extending the existing enterprise deployment domain with the Inbound Refinery software are detailed in this section.
• Completing Postconfiguration and Verification Tasks for Inbound Refinery
  After extending the domain with the Inbound Refinery software, consider the following post-configuration and verification tasks.
• Configuring the Inbound Refinery Managed Servers
  To initialize the configuration of an Inbound Refinery Managed Server, you need to access it only once through HTTP. You can do this directly at the Managed Server's listen address. An Inbound Refinery instance should not be placed behind an HTTP server.
• Validating the Configuration of the Inbound Refinery Managed Servers
  To ensure that the Inbound Refinery Managed Servers you have created are properly configured, validate the configuration by logging in to Content Server and verifying that a file with an extension recognized as valid for conversion is correctly converted.

13.1 Extending the Domain for Inbound Refinery

The instructions for extending the existing enterprise deployment domain with the Inbound Refinery software are detailed in this section.

• Starting the Configuration Wizard
  
• Navigating the Configuration Wizard Screens to Extend the Domain
  

13.1.1 Starting the Configuration Wizard

To start the Configuration Wizard:

1. From the WebLogic Server Console, stop any managed servers that will be modified by this domain extension. Managed Servers that are not effected can remain on-line.
2. For any managed servers to be modified, verify the managed server shutdown has completed.
3. Stop the Administration Server once all managed servers are in a steady state.
4. Navigate to the following directory and start the WebLogic Server Configuration Wizard.

   cd ORACLE_HOME/oracle_common/common/bin
   ./config.sh
   

13.1.2 Navigating the Configuration Wizard Screens to Extend the Domain

Follow the instructions in this section to update and configure the domain for the topology.

Note:

You can use the same procedure described in this section to extend an existing domain. If your needs do not match the instructions given in the procedure, be sure to make your selections accordingly, or refer to the supporting documentation for additional details.

Domain creation and configuration includes the following tasks:

Task 1   Selecting the Domain Type and Domain Home Location

On the Configuration Type screen, select Update an existing domain.

In the Domain Location field, select the value of the ASERVER_HOME variable, which represents the complete path to the initial Administration Server domain home you created.

For more information about the directory location variables, see File System and Directory Variables Used in This Guide.

Tip:

More information about the other options on this screen can be found in Configuration Type in Creating WebLogic Domains Using the Configuration Wizard.

Task 2   Selecting the Configuration Template

On the Templates screen, make sure Update Domain Using Product Templates is selected, then select the following templates:

• Oracle Universal Content Management - Inbound Refinery - 12.2.1.2.0 [wccontent]

  The Infrastructure templates, WebCenter Portal templates, and WebCenter Content templates should already be selected, because they were used to create and update the initial domain.

Tip:

More information about the options on this screen can be found in Templates in Creating WebLogic Domains Using the Configuration Wizard.

Task 3   Providing the GridLink Oracle RAC Database Connection Details

On the GridLink Oracle RAC Component Schema screen, click Next.

Task 4   Testing the JDBC Connections

Click Next to continue.

Task 5   Selecting Advanced Configuration

To complete domain configuration for the topology, select the following option on the Advanced Configuration screen:

Topology

Task 6   Configuring Managed Servers

On the Managed Servers screen, a new Managed Server appears in the list of servers.

Perform the following tasks to modify the default Managed Server and create a second Managed Server:

1. Rename the default Managed Server to WLS_IBR1.

2. Click Add to create a new Managed Server and name it WLS_IBR2.

   Tip:

   The server names recommended here will be used throughout this document. If you choose different names be sure to replace them as needed.

3. Use the information in the following table to fill in the rest of the columns for each Managed Server.

Table 13-1 Values Required for Each Oracle Inbound Refinery Server

Server Name	Listen Address	Listen Port	Enable SSL	SSL Listen Port	Server Group
WLS_IBR1	WCCHOST1	16250	No	Disabled	IBR-MGD-SVR
WLS_IBR2	WCCHOST2	16250	No	Disabled	IBR-MGD-SVR

Tip:

More information about the options on the Managed Server screen can be found in Managed Servers in Creating WebLogic Domains Using the Configuration Wizard.

Task 7   Configuring a Cluster

In this task, you create a cluster of Managed Servers to which you can target the Oracle Inbound Refinery software.

Use the Clusters screen to create a new cluster:

1. Click the Add button.

2. Specify IBR_Servers in the Cluster Name field.

3. From the Dynamic Server Groups drop-down list, select Unspecified.

4. Click Next to proceed to the next screen.

Note:

By default, server instances in a cluster communicate with one another using unicast. If you want to change your cluster communications to use multicast, refer to "Considerations for Choosing Unicast or Multicast" in Administering Clusters for Oracle WebLogic Server.

Tip:

More information about the options on this screen can be found in Clusters in Creating WebLogic Domains Using the Configuration Wizard.

Task 8   Assigning Server Templates

Click Next to proceed to the next screen.

Task 9   Configuring Dynamic Servers

Verify that all dynamic server options are disabled for clusters that are to remain as static clusters.

1. Confirm that the Dynamic Cluster, Calculated Listen Port, and Calculated Machine Names checkboxes on this screen are unchecked.

2. Confirm the Server Template selection is Unspecified.

3. Click Next.

Task 10   Assigning Managed Servers to the Cluster

Use the Assign Servers to Clusters screen to assign WLS_IBR1 and WLS_IBR2 to the new cluster IBR_Servers:

1. In the Clusters pane, select the cluster to which you want to assign the servers; in this case, IBR_Servers.

2. In the Servers pane, assign WLS_IBR1 to IBR_Servers by doing one of the following:

   • Click once on WLS_IBR1 Managed Server to select it, then click on the right arrow to move it beneath the selected cluster in the Clusters pane.

   • Double-click WLS_IBR1 to move it beneath the selected cluster in the clusters pane.

3. Repeat to assign WLS_IBR2 to IBR_Servers.

Tip:

More information about the options on this screen can be found in Assign Servers to Clusters in Creating WebLogic Domains Using the Configuration Wizard.

Task 11   Configuring Coherence Clusters

Use the Coherence Clusters screen to configure the Coherence cluster that is automatically added to the domain. Leave the port number value at 9991, as it was defined during the initial Infrastructure domain creation.

Note:

For Coherence licensing information, refer to Oracle Coherence in Oracle Fusion Middleware Licensing Information.

Task 12   Verifying the Existing Machines

Under the Unix Machine tab, verify the names of the machines you created when creating the initial Infrastructure domain.

Click Next to proceed.

Task 13   Assigning Servers to Machines

Use the Assign Servers to Machines screen to assign the Oracle Inbound Refinery Managed Servers you just created to the corresponding machines in the domain.

Assign WLS_IBR1 to WCCHOST1, and assign WLS_IBR2 to WCCHOST2.

Tip:

More information about the options on this screen can be found in Assign Servers to Machines in Creating WebLogic Domains Using the Configuration Wizard.

Task 14   Reviewing Virtual Targets

Click Next to proceed to the next screen.

Task 15   Reviewing Partitions

Click Next to proceed to the next screen.

Task 16   Reviewing Your Configuration Specifications and Configuring the Domain

The Configuration Summary screen contains the detailed configuration information for the domain. Review the details of each item on the screen and verify that the information is correct.

You can go back to any previous screen if you need to make any changes, either by using the Back button or by selecting the screen in the navigation pane.

Click Update to execute the domain extension.

Tip:

More information about the options on this screen can be found in Configuration Summary in Creating WebLogic Domains Using the Configuration Wizard.

Task 17   Writing Down Your Domain Home and Administration Server URL

The Configuration Success screen will show the following items about the domain you just configured:

• Domain Location

• Administration Server URL

You must make a note of both items as you will need them later; the domain location is needed to access the scripts used to start the Node Manager and Administration Server, and the URL is needed to access the Administration Server.

Click Finish to dismiss the Configuration Wizard.

Task 18   Start the Administration Server

Start the Administration Server to ensure the changes you have made to the domain have been applied.

13.2 Completing Postconfiguration and Verification Tasks for Inbound Refinery

After extending the domain with the Inbound Refinery software, consider the following post-configuration and verification tasks.

• Propagate the Domain Configuration Updates for Inbound Refinery
  
• Updating the NodeManager Configuration After Unpacking the Domain
  When extending a domain, the nodemanager.properties file in MSERVER_HOME may be overwritten with some values from the nodemanager.properties file for ASERVER_HOME. Specifically, the ListenAddress and/or CustomIdentityAlias values can be reset.
• Restarting and Validating Pre-existing Managed Servers
  
• Modifying the Upload and Stage Directories to an Absolute Path
  After configuring the domain and unpacking it to the Managed Server domain directories on all the hosts, verify and update the upload and stage directories for Managed Servers in the new clusters.
• Starting the Inbound Refinery Managed Servers
  

13.2.1 Propagate the Domain Configuration Updates for Inbound Refinery

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the Managed Server domain directory. To propagate the domain configuration to the Inbound Refinery Managed Servers:

1. Create a backup copy of the Managed Server domain directory and the Managed Server applications directory.
2. Run the following pack command on WCCHOST1 to create a template pack:

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true 
             -domain=ASERVER_HOME 
             -template=/full_path/edgdomaintemplateExtIBR.jar 
             -template_name=edgdomain_templateIBR
   

   In this example:

   • Replace ASERVER_HOME with the actual path to the domain directory you created on the shared storage device.

   • Replace full_path with the complete path to the location where you want to create the domain template jar file. You will need to reference this location when you copy or unpack the domain template jar file. It is recommended to choose a shared volume other than ORACLE_HOME, or write to /tmp/ and copy the files manually between servers.

     You must specify a full path for the template jar file as part of the -template argument to the pack command:

     SHARED_CONFIG_DIR/domains/template_filename.jar
     

   • edgdomaintemplateExtIBR.jar is a sample name for the JAR file you are creating, which will contain the domain configuration files, including the configuration files for the Oracle HTTP Server instances.

   • edgdomain_templateIBR is the name assigned to the domain template file.

3. Run the following unpack command on WCPHOST1 to propagate the template created in the preceding step to the MSERVER_HOME directory:

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=MSERVER_HOME 
               -template=/full_path/edgdomaintemplateExtIBR.jar 
               -app_dir=APPLICATION_HOME 
               -overwrite_domain=true
   

   In this example:

   • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain will be unpacked.

   • edgdomaintemplateIBR.jaris the directory path and name of the template you created when you ran the pack command to pack up the domain on the shared storage device.

   • The -overwrite_domain=true argument is necessary when you are unpacking a managed server template into an existing domain and existing applications directories.

     For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory, they must be restored after this unpack operation.

   • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on local storage.

   Tip:

   For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.

4. If the full path to the packed jar file is on a shared volume available to the other servers, skip this step, otherwise, run the following command on WCCHOST1 to copy the template pack created in step 1 to WCCHOST2:

   scp /full_path/edgdomaintemplateExtIBR.jar oracle@WCCHOST2:/full_path/
   

   Replace full_path with the complete path to the directory where you want to copy the template jar file.

5. Run the following unpack command on each of the remote hosts to deploy the domain template copied in the preceding step to the MSERVER_HOME directory:

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=MSERVER_HOME 
               -template=/full_path/edgdomaintemplateExtIBR.jar 
               -app_dir=APPLICATION_HOME 
               -overwrite_domain=true
   

   In this example:

   • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain will be unpacked.

   • edgdomaintemplateIBR.jaris the directory path and name of the template you created when you ran the pack command to pack up the domain on the shared storage device.

   • The -overwrite_domain=true argument is necessary when you are unpacking a managed server template into an existing domain and existing applications directories.

     For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory, they must be restored after this unpack operation.

   • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on local storage.

   Tip:

   For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.

13.2.2 Updating the NodeManager Configuration After Unpacking the Domain

When extending a domain, the nodemanager.properties file in MSERVER_HOME may be overwritten with some values from the nodemanager.properties file for ASERVER_HOME. Specifically, the ListenAddress and/or CustomIdentityAlias values can be reset.

Notes::

• The ListenAddress may typically get reset on the MSERVER_HOME nodemanager residing on the same host as the ASERVER_HOME nodemanager. In this topology, WCCHOST1.

• For domain extensions prior to Enabling SSL Communication Between the SOA Servers and the Hardware Load Balancer, steps 2 through 4 regarding the CustomIdentityAlias may not be applicable.

For the MSERVER_HOME/nodemanager/nodemanager.properties file on each host:

1. Verify the correct ListenAddress parameter value and reset it, if required.

   grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties
   

2. Confirm the list of configured Identity Aliases from the domain configuration file as a reference for the next command.

   grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq
   

3. Verify the current CustomIdentityAlias parameter value.

   grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties
   

4. Reset the CustomIdentityAlias parameter value to the correct alias string appropriate for the current host, if required.
5. Restart the nodemanager process:

   kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
   nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &
   

For more information, see Configuring Node Manager to Use the Custom Keystores.

13.2.3 Restarting and Validating Pre-existing Managed Servers

Restart the managed servers for the pre-existing components now that the domain has been extended and unpacked to the MSERVER_HOME directories on all of the servers.

1. From the WebLogic Server Console, first restart the WLS_WSMn Managed Servers.
2. From another browser window, verify the WSM-PM application is responding by successfully loading the URL:

   http://wcpinternal.example.com/wsm-pm/validator
   

3. Restart all other managed servers co-located in the unpacked MSERVER_HOME. This can be performed in a rolling fashion if necessary. Complete any server restarts and service validations needed before continuing to the next procedure.

13.2.4 Modifying the Upload and Stage Directories to an Absolute Path

After configuring the domain and unpacking it to the Managed Server domain directories on all the hosts, verify and update the upload and stage directories for Managed Servers in the new clusters.

This step is necessary to avoid potential issues when performing remote deployments and for deployments that require the stage mode.

To update these directory paths for all the Managed Servers in the Managed Server domain home directory:

1. Log in to the Oracle WebLogic Server Administration Console.

2. In the left navigation tree, expand Domain, and then Environment.

3. Click Lock & Edit.

4. Navigate to and edit the appropriate objects for your cluster type.

   1. For Static Clusters, navigate to Servers and click on the name of the Managed Server to be edited.

5. For each new Managed Server or Server Template to be edited:

   1. Click the Configuration tab, and then click the Deployment tab.

   2. Verify that the Staging Directory Name is set to the following:

      MSERVER_HOME/servers/server_or_template_name/stage
      

      Replace MSERVER_HOME with the directory path for the MSERVER_HOME directory; If using static clusters, update with the correct name of the Managed Server you are editing.

   3. Update the Upload Directory Name to the following value:

      ASERVER_HOME/servers/AdminServer/upload
      

      Replace ASERVER_HOME with the directory path for the ASERVER_HOME directory.

   4. Click Save.

   5. Return to the Summary of Servers or Summary of Server Templates screen as applicable.

6. When you have modified all of the appropriate objects, click Activate Changes.

7. Restart all Managed Servers effected by these change.

13.2.5 Starting the Inbound Refinery Managed Servers

To start the WLS_IBR1 Managed Server on WCCHOST1:

1. Log in to the Oracle WebLogic Server Administration Console as the weblogic_wcp user at:

   http://admin.example.com/console
   

2. Start the WLS_IBR1 Managed Server through the Administration Console, as follows:
   1. Expand the Environment node in the Domain Structure tree on the left.
   2. Click Servers.
   3. On the Summary of Servers page, click the Control tab.
   4. Select WLS_IBR1 from the Servers column of the table.
   5. Click Start.
3. Verify that the server status is reported as Running in the Administration Console.
   • If the server is shown as Starting or Resuming, wait for the server status to change to Started.
   • If another status is reported (such as Admin or Failed), check the server output log files for errors.
4. Repeat the preceding steps to start the WLS_IBR2 Managed Server on WCCHOST2.

13.3 Configuring the Inbound Refinery Managed Servers

To initialize the configuration of an Inbound Refinery Managed Server, you need to access it only once through HTTP. You can do this directly at the Managed Server's listen address. An Inbound Refinery instance should not be placed behind an HTTP server.

All subsequent access to the Inbound Refinery instance is through the socket listener. This listener is protected through the incoming socket connection address security filter configured in the next section.

Oracle recommends configuring each Content Server instance with all Inbound Refinery instances. The process for configuring Content Server is to add each Inbound Refinery instance as a provider. You also need to perform some post-installation steps with Inbound Refinery.

The following sections describe the procedures for post-installation configuration of each Inbound Refinery instance.

• Configuring Inbound Refinery Settings
  After starting the Inbound Refinery Managed Servers, configure the settings for each server on its post-installation configuration screen.
• Granting the WebCenter Content Administrative Roles via Credential Map
  
• Specifying the Font Path
  
• Setting Up Content Server to Send Jobs to Inbound Refinery for Conversion
  Before Oracle WebCenter Content Server can send jobs to Inbound Refinery for conversion, you need to perform the setup tasks described in the following sections for each Inbound Refinery Managed Server.

13.3.1 Configuring Inbound Refinery Settings

After starting the Inbound Refinery Managed Servers, configure the settings for each server on its post-installation configuration screen.

To configure the settings for each Inbound Refinery instance, complete the following steps:

1. Create the runtime cluster subdirectories required for the Oracle WebCenter Content Inbound Refinery shared folder configuration.

   The Oracle WebCenter Content Inbound Refinery configuration files are on a shared disk so that all members of the cluster can access them. The shared disk location of the Oracle WebCenter Content Inbound Refinery enterprise deployment is located at ORACLE_RUNTIME/domain_name/IBR_Servers/.

   Run the following commands to create the required subdirectories for every IBR managed server:

   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/vault 
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/weblayout 
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/data/users/profiles  
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/vault 
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/weblayout 
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/data/users/profiles
   

2. Access the Inbound Refinery post-installation configuration screen at the following URL, in which N is 1 or 2:

   http://WCCHOSTN:16250/ibr/
   

3. On the Configuration screen, you will see Inbound Refinery Instance Identifier: name. Set the configuration settings for this instance as follows. Each Inbound Refinery instance is independent of the other instances and local to each machine. Use local directories for the configuration directories of each instance.

   • Inbound Refinery Instance Folder: Set this to ORACLE_RUNTIME/domain_name/IBR_Servers/ibrN.

     For example: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1

   • Native File Repository Location: Set this to ORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/vault.

     For example: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/vault

   • WebLayout Folder: Set this to ORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/weblayout.

     For example: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/weblayout

   • User Profile Folders: Set this to ORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/data/users/profiles.

     For example: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/data/users/profiles

   • Incoming Socket Connection Address Security Filter: A pipe-delimited list of localhost and the server IP addresses:

     127.0.0.1|0:0:0:0:0:0:0:1|WCCHOST1-IP|WCCHOST2-IP|WEBHOST1-IP|WEBHOST2-IP

     This setting enables access from Content Server. The values for WCCHOST1-IP and WCCHOST2-IP should be the IP addresses of the machines with the Content Server instance or instances that will send jobs to Inbound Refinery, not necessarily the IP address of Inbound Refinery. (In the reference topology used in this enterprise deployment guide, however, these IP addresses are the same.)

     The Incoming Socket Connection Address Security Filter: field accepts wildcards in the value; for example, 192.0.2.*.

     You can change this value later by setting SocketHostAddressSecurityFilter in the/u02/oracle/runtime/wcpedg_domain/IBR_Servers/ibrN/config/config.cfg file and then restarting the Inbound Refinery Managed Server.

     Where N is 1 for http://WCCHOST1:16250/ibr/ and N is 2 for http://WCCHOST2:16250/ibr/

   • Server Socket Port: Enter an unused port number, such as 5555. This value is the number of the port for calling top-level services.

     Take note of the port number because you need it later for configuring Oracle WebCenter Content.

     Changing this field value changes the IntradocServerPort entry in /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibrN/config/config.cfg.

     Where N is 1 for http://WCCHOST1:16250/ibr/ and N is 2 for http://WCCHOST2:16250/ibr/

   • Server Instance Name: Specify a name for the Inbound Refinery server instance.

     You can accept the default value or change it to a name that is more useful to you. Take note of the server name because you will need it later for configuring Oracle WebCenter Content.

   You can leave all other fields on the configuration page as they are.

   Click Submit, and you should get the following message:

   Post-install configuration complete. Please restart this node.
4. Restart the Inbound Refinery Managed Server, using the WebLogic Server Administration Console.
5. Repeat the preceding steps for each Inbound Refinery instance, using different names for the content folders.

13.3.2 Granting the WebCenter Content Administrative Roles via Credential Map

You must configure the Credential map to grant the Content Server administrative roles to the WCPAdministrators LDAP group.

The WCPAdministrators LDAP group is created in the Provisioning an Enterprise Deployment Administration User and Group section completed earlier. This configuration of credential map ensures consistent use of the LDAP administrative user for all configuration, administration, and maintenance tasks.

To configure a credential map and provide the necessary role grants to the LDAP-based WCPAdministrators group:

1. Log in to Inbound Refinery server on WCCHOST1 using the weblogic account.
2. Expand the Administration menu, select Credential Maps.
3. In the Map Identifier Field, enter a name for the new credential map: LDAPAdmins.
4. Add the following lines to map the LDAP group to the multiple administrative roles:

   # Assign full set of administration roles to the LDAP WCPAdministrators group
        WCPAdministrators, admin
        WCPAdministrators, sysmanager
        WCPAdministrators, refineryadmin
        WCPAdministrators, rmaadmin
        WCPAdministrators, pcmadmin
        WCPAdministrators, ermadmin
        #
        # Comment the following if you are not implementing Accounts in Content Server
        WCPAdministrators, @#all(RWDA)
        WCPAdministrators, @#none(RWDA)
   

   Note:

   If you are not implementing Accounts, comment out the last two lines of the previous example..
5. Click Update.
6. Navigate to Administration > Providers.
7. Click the info link for the existing JPS provider.
8. Make sure that the Credential Map parameter does not already have a map identifier listed.
9. Click the Edit button.
10. Enter the name of the Map Identifier from step 3 above as the Credential Map value.
11. Click Update.
12. Repeat this process for the Inbound Refinery server on WCCHOST2.
13. Restart the managed servers in the IBR_Servers cluster.
14. Log in to each Inbound Refinery server using the weblogic_wcp LDAP user and verify that the administrative menu options appear in the user interface.

13.3.3 Specifying the Font Path

For Inbound Refinery to work properly, you must specify the path to fonts used to generate font images. By default, the font path is set to the font directory in the JVM used by Inbound Refinery: MW_HOME/jdk160_version/jre/lib/fonts. However, the fonts included in the default directory are limited and may cause poor renditions. Also, in some cases if a non-standard JVM is used, then the JVM font path may be different than that specified as the default. If this is the case, an error message is displayed from both Inbound Refinery and Content Server. If this occurs, ensure that the font path is set to the directory containing the fonts necessary to properly render your conversions.

For more information, see Specifying the Font Path in Oracle Fusion Middleware Managing Oracle WebCenter Content.

13.3.4 Setting Up Content Server to Send Jobs to Inbound Refinery for Conversion

Before Oracle WebCenter Content Server can send jobs to Inbound Refinery for conversion, you need to perform the setup tasks described in the following sections for each Inbound Refinery Managed Server.

• Creating an Outgoing Provider
  Before Content Server can send files to Inbound Refinery for conversion, you must set up an outgoing provider from Content Server to each Inbound Refinery with the Handles Inbound Refinery Conversion Jobs option checked.
• Enabling Components for Inbound Refinery on Content Server
  Some conversion types require helper components to be enabled on Content Server. The InboundRefinerySupport component must always be enabled on any Content Server instance that uses Inbound Refinery for document conversion. It is enabled by default on a new Content Server installation.
• Selecting File Formats To Be Converted
  To tell Content Server which files to send to Inbound Refinery to be converted, you need to select file formats.

13.3.4.1 Creating an Outgoing Provider

Before Content Server can send files to Inbound Refinery for conversion, you must set up an outgoing provider from Content Server to each Inbound Refinery with the Handles Inbound Refinery Conversion Jobs option checked.

To create an outgoing provider for each Inbound Refinery instance:

1. Log in to Content Server at the following URL:

   http://WCCHOST1:16200/cs/
   

2. Open the Administration tray or menu, then choose Providers.
3. In the Create a New Provider table of the Providers page, click Add in the outgoing row.
4. Enter the following values for the fields:

   • Provider Name: Any short name with no spaces. It is a good idea to use the same value as the Instance Name value

   • Provider Description: Any text string.

   • Server Host Name: The name of the host machine where the Inbound Refinery instance is running: WCCHOST1.

   • HTTP Server Address: The address of the Inbound Refinery instance: WCCHOST1:16250.

   • Server Port: The value of the Server Socket Port field for the Inbound Refinery instance as specified in Configuring Inbound Refinery Settings; for example, 5555. This is the IntradocServerPort value in the Inbound Refineryconfig.cfg file.

   • Instance Name: The server instance name for Inbound Refinery as specified in Configuring Inbound Refinery Settings. This is the IDC_Name value in the Inbound Refinery config.cfg file.

   • Relative Web Root: The web root of the Inbound Refinery instance: /ibr/

5. Under Conversion Options, check Handles Inbound Refinery Conversion Jobs.

   Do not check Inbound Refinery Read Only Mode.

6. Click Add.
7. Restart the Inbound Refinery Managed Server and Oracle WebCenter Content Server (WebCenter Content Managed Server), using the WebLogic Server Administration Console.
8. Go back to the Providers page, and check that the Connection State value is good for the provider.

   If the value is not good, double-check that you entered all the preceding entries correctly, and check that the Content Server and Inbound Refinery instances can ping each other.

9. Complete steps 1 through 8 for the second IBR server.

For more information about setting up providers, see "Configuring Content Server and Refinery Communication" in Oracle Fusion Middleware Managing Oracle WebCenter Content.

13.3.4.2 Enabling Components for Inbound Refinery on Content Server

Some conversion types require helper components to be enabled on Content Server. The InboundRefinerySupport component must always be enabled on any Content Server instance that uses Inbound Refinery for document conversion. It is enabled by default on a new Content Server installation.

To enable Inbound Refinery components on Content Server:

1. Log in to Content Server at the following URL:

   https://wcp.example.com/cs
   

2. From the Administration tray or menu, choose Admin Server, then Component Manager.
3. On the Component Manager page, select Inbound Refinery, then select components that you want to enable under Inbound Refinery, such as XMLConverterSupport, and then click Update.
4. Restart both Content Servers by restarting the WebCenter Content Managed Servers, using the WebLogic Server Administration Console.

13.3.4.3 Selecting File Formats To Be Converted

To tell Content Server which files to send to Inbound Refinery to be converted, you need to select file formats.

To select file formats to be converted:

1. Log in to Content Server at the following URL:

   https://wcp.example.com/cs/
   

2. Open the Administration tray or menu, then choose Refinery Administration, and then File Formats Wizard to open the File Formats Wizard page.

   This page specifies what file formats will be sent to Inbound Refinery for conversion when they are checked into Content Server.

3. Select the formats you want converted, such as doc, dot, docx, and dotx for Microsoft Word documents.
4. Click Update.

You can also select file formats with the Configuration Manager, with more fine-grained control, including file formats that the wizard does not list. For more information, see "Managing File Types" in Oracle Fusion Middleware Managing Oracle WebCenter Content.

13.4 Validating the Configuration of the Inbound Refinery Managed Servers

To ensure that the Inbound Refinery Managed Servers you have created are properly configured, validate the configuration by logging in to Content Server and verifying that a file with an extension recognized as valid for conversion is correctly converted.

For example, if you selected docx as a format to be converted, you can convert a Microsoft Word document with a .docx extension to PDF format.

For information about the check-in and check-out procedures, see "Uploading Documents" and "Checking Out and Downloading Files" in Oracle Fusion Middleware Using Oracle WebCenter Content.

For information about the conversion process, see "Configuring Content Servers to Send Jobs to Refineries" in Oracle Fusion Middleware Managing Oracle WebCenter Content.