In this chapter, IBM WebSphere is used to reference both IBM WebSphere Application Server (AS) and IBM WebSphere Application Server Network Deployment (ND). The specific product names are used when appropriate.

When you install Oracle SOA Suite with IBM WebSphere, an internal LDAP server is not automatically configured with SOA users and groups. You must manually perform these configuration tasks in an external LDAP server, such as Oracle Internet Directory, after installation.

The following provides an overview of the tasks to perform when configuring your supported LDAP server for use with Oracle SOA Suite:

Use your LDAP management tool to create two groups (Operator group and Monitor group) and two users (Operator user and Monitor user).

Note that the management tool you use to create the users and groups will vary, depending up on the LDAP server you are using. For example, if you are using Oracle Internet Directory, refer to information about using the Oracle Directory Services Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

In the IBM WebSphere Administrative Console, create the following mappings:

User roles for operator and monitor

Group roles for operator and monitor

For example, the following page shows the Administrative user roles section with the monitor user ashish (second check box) and the operator user opuser (fourth check box) available for selection. You perform similar mappings for group roles on a separate page.

Log in to Oracle JDeveloper and navigate to New, then to Connections, then to Application Server Connections.

Create an application server connection and enter the necessary information. To do this:

Navigate to File, then New, then Connections, then Application Server Connection. This starts a Create Application Server Connection wizard. Enter the connection name and for the connection type choose WebSphere Server 7.x. Click Next.

Specify the username; the default is wasadmin. Specify the password; the default is welcome1. Click Next.

There should be no spaces in the path to wsadmin.sh/bat. If you are on Windows, use the DOS equivalent path; for example, instead of C:\Program Files\ use C:\Progra~1\.

If you have an IBM WebSphere server installed locally, then enter the path to wsadmin.bat file in the "Wsadmin Script File location"; otherwise, specify the location to this file from the IBM WebSphere client installation.

If you have an IBM WebSphere server installed locally, then enter the path to wsadmin.bat file in the "Wsadmin Script File location"; otherwise, specify the location to this file from the IBM WebSphere client installation.

Click Next.

You might see the SSL Signer Exchange Prompt. If so, click Y to continue. This dialog appears only once for each host and server.

Test your connection and make sure that all tests are successful. To do this, on the Test tab click Test Connection. All tests should pass as follows:

4.2.2.2 How to Configure the WebSphere Application Client for Use with Oracle JDeveloper on Different Computers

This section describes how to configure the WebSphere Application Client for use with Oracle JDeveloper when the two are on different computers. Once the WebSphere Application Client is properly configured, Oracle JDeveloper can remotely connect to an IBM WebSphere Server. This enables you to perform actions such as the following in Oracle JDeveloper:

set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%USER_INSTALL_
ROOT%\properties\soap.client.props
set CLIENTSAS=-Dcom.ibm.CORBA.ConfigURL=file:%USER_INSTALL_
ROOT%\properties\sas.client.props
set CLIENTSSL=-Dcom.ibm.SSL.ConfigURL=file:%USER_INSTALL_
ROOT%\properties\ssl.client.props
set CLIENTIPC=-Dcom.ibm.IPC.ConfigURL=file:%USER_INSTALL_
ROOT%\properties\ipc.client.props

Remove all trailing white space characters from the entire file.

4.2.2.2.3 Running wsadmin.sh or wsadmin.bat from the Command Line

Ensure that the script works by running wsadmin.sh or wsadmin.bat from the command line. Note the following:

You may need to enter the user name and password at the login prompt.

You may need to accept the server certificate by clicking Y at the signer exchange prompt.

4.2.4 Creating an Application Server Connection

You must create a connection to the IBM WebSphere Server to which to deploy a SOA composite application. During application server connection creation, you are prompted for configuration information on several wizard pages. Table 4-2 describes where to find this information on IBM WebSphere Administrative Console for which you are prompted. The locations differ based on the type of IBM WebSphere Server you are using, and the server where the application is being deployed.

If you are using IBM WebSphere ND as the server type and you are deploying the application to the deployment manager server, then use the second column in the table to locate the configuration information you need.

In the Username field, enter the user authorized for access to the application server.

In the Password field, enter the password for this user.

Click Next.

The Configuration page appears. If you are not sure about the information to enter on this page, see Table 4-2.

In the Host Name field, enter the host on which the IBM WebSphere Server is installed. If no name is entered, the name defaults to localhost.

In the SOAP Connector Port field, enter the port number of the server on which IBM WebSphere Server is installed. The default SOAP connector port is 8879.

In the Server Name field, enter the name assigned to the target application server for this application.

In the Target Node field, enter the name of the target node for this connection. A node is a grouping of managed servers (for example, hostNode01, where host is the name of the host on which the node resides).

In the Target Cell field, enter the name of the target cell for this connection. A cell is a group of processes that host runtime components (for example, hostNode01Cell, where host is the name of the host on which the node resides).

In the Wsadmin script location field, enter or browse for the location of the wsadmin script file to use for defining the system login configuration for this application server connection (for example, WAS_HOME\bin\wsadmin.bat for Windows or WAS_HOME/bin/wsadmin.sh for Unix).

Note:

Do not enter spaces in the path to the wsadmin.sh or wsadmin.bat file. For example, if on Windows, use the DOS equivalent path of C:\Progra~1\ instead of C:\Program Files\.

Click Next.

The JMX page appears.

If you want to browse the SOA Infrastructure and deploy over JMX, select Enable JMX for this connection.

In the RMI Port field, enter the port number for the IBM WebSphere Server's RMI connector port. If you are not sure about the information to enter on this page, see Table 4-2.

In the WebSphere Properties Location (for secure MBean access) field, enter or browse for the location of the file that contains the properties for the security configuration and MBeans that are enabled (for example, WAS_HOME/profiles/profile_name/properties). This field is optional (for some Oracle JDeveloper use cases), but is required for SOA browsing and deployment. The location you specify must contain the sas.client.props file. Details about the contents of the sas.client.props file are as follows:

Authentication:

The sas.client.props file is required for authentication, and must be edited as follows:

If you require SSL for JMX, do not configure ssl.client.props. Instead, you must append the necessary SSL configuration details to sas.client.props for Sun JRE clients, since Oracle JDeveloper runs in the Sun JRE.

Upon the first invocation of JMX (typically when you click Test Connection on the Test page of this wizard), the SSL Signer Exchange dialog can appear. Click y to accept the server certificate. Note that a ThreadDeath error is displayed that can safely be ignored.

Provide the keystore location through the system properties in either of the following ways:

Note:

When configuring the truststore location through the system properties on Windows operating systems, you must enter a forward slash (/) in the path. For example, c:/to/path/truststore.

Since one sas.client.props file is required for each application server connection, Oracle recommends that you create a directory for each application server, copy sas.client.props to that directory, and edit the file as necessary.

Click Next.

Click Test Connection to test your server connection.

If the connection is successful, click Finish. Otherwise, click Back to make corrections in the previous dialogs. Even if the connection test is unsuccessful, a connection is created.

4.2.5 Deploying SOA Composite Applications

The only exception is the appearance of the Deploy using SSL check box on the SOA Servers page of the deployment wizard. This differs from Oracle WebLogic Server, where the Deploy using SSL check box instead appears on the Configuration page of the Create Application Server Connection wizard page.

Table 4-3 describes what occurs when you select this check box during IBM WebSphere Server deployment.

Table 4-3 Deployment to HTTPS and HTTP Servers

If This Checkbox Is...

Then...

Selected

An HTTPS server URL must exist to deploy the composite with SSL. Otherwise, deployment fails.

If the server has only an HTTP URL, deployment also fails. This enables you to ensure that SSL deployment must not go through a non-SSL HTTP URL, and must only go through an HTTPS URL

Not selected

An HTTP server URL must exist to deploy to a non-SSL environment. Otherwise, deployment fails.

If the server has both HTTPS and HTTP URLs, deployment occurs through a non-SSL connection. This enables you to force a non-SSL deployment from Oracle JDeveloper, even though the server is SSL-enabled.

4.2.6 Using the Diagnostic Framework

Be aware of the following issues when using the Diagnostic Framework on IBM WebSphere.

The port number is the SOAP_CONNECTOR_ADDRESS of the host used to connect to the server for deployment. In the IBM Administrative Console, navigate to the Ports table via Deployment Manager > Ports to locate the value.

You also need to set the maximum connections value of AQAdapter J2C connection factories to a higher value than the default of 10. You can find this entry in the WebSphere Application Server J2C connection factories -> <Name of AQAdapter> -> Connection pools panel.

4.2.9 JMS Technology Adapter on WebSphere 7.0

If you are developing composite applications to run on WebSphere 7.0, you need to use the Third Party option when modelling the JMS adapter with the Default Messaging JMS provider. You can specify that the adapter uses a third-party JMS Provider, by supplying a value to the FactoryProperties parameter in the weblogic-ra.xml file. Specifically, you can provide the ThirdPartyJMSProvider value to the FactoryProperties parameter.

When deployed on WebSphere 7.0, the JMS Adapter will not work with an AQJMS provider, unless you use the Adapter Configuration Wizard to set defaultConnectionTypeOverride as unshared for both the adapter connection factory pool and for the queue/topic connection factory pool. See the following screen shot.

You also need to set the maximum connections value of JMS Adapter J2C factories to a higher value than the default of 10. You can find this entry in the WebSphere Application Server J2C connection factories >Name of JMS Adapter> Connection pools panel.

4.2.9.1 Avoiding JMS Adapter Connection Leaks

While running JMS Adapter use cases on WebSphere 7.0, you might encounter the following error from a connection leak:.

java.lang.IllegalStateException: ConnectionManager is null

To avoid connection leaks, update the maximum and minimum connection value for the JMS Adapter to the same value at Queue connection factories >Connection_factory_name> Connection pools and J2C connection factories >J2C_Connection_Factoryname> Connection Point.

4.2.10 Oracle Database Adapter on WebSphere 7.0

For the Oracle Database Adapter to work properly, you need to the set the maximum connections value of the DB adapter J2C connection factories, using the WebSphere Admin Server. This value needs to be set to a higher value than the default of 10. You can find this entry under J2C connection factories >Name of DB-Adapter> Connection pools. The preferred value is 100.

When configuring Oracle SOA Suite in an IBM WebSphere high availability environment, ensure that you stop and restart the Deployment Manager before configuration of the second node. If you do not perform these steps, the Deployment Manager does not detect the remote node agent.

Run the Configuration Wizard on host1:

MW_HOME/ORACLE_HOME/common/bin/was_config.sh

Create and configure an IBM WebSphere cell.

Install Oracle SOA Suite components into the cell.

Start the Deployment Manager by navigating to the following directory in the IBM WebSphere home and entering the following command:

If you do not perform Steps 5 and 6, after you finish configuration of host2 and restart node agent2, when you go to the IBM WebSphere Administrative Console, the node agent on host2 (remote node) is shown as down when it is actually running. This is because the Deployment Manager fails to detect the remote node agent.

Run the Configuration Wizard on host2 (remote host), as described in Step 1.

To log in to IBM WebSphere, you must go directly to the WebSphere Administrative Console.

4.3.4 DefaultToDo Task Flow is Configured to Use HTTPS

Oracle SOA Suite on IBM WebSphere is configured to use HTTPS. This means the DefaultToDo task flow also uses HTTPS because the DefaultToDo task flow host name, port, and protocol are based on the SOA Server URL.

If a valid certificate is not available on the server, then DefaultToDo would not be accessible in Microsoft Internet Explorer and Google Chrome, while Mozilla Firefox would issue a warning and then allow the user to proceed. If necessary, use Oracle Enterprise Manager Fusion Middleware Control to change the SOA Server URL.

4.3.5 Configuring the current-dateTime Function to Display Output in Seconds

The current-dateTime function returns the current datetime value in the ISO format of CCYY-MM-DDThh:mm:ss.sTZD (where s denotes the time in milliseconds). If you want to display the output in seconds, perform the following steps:

Log in to the IBM WebSphere Administrative Console.

Click Servers > Server Types > WebSphere application servers.

Click the name of the server on which you want this function to display output in seconds (for example, server1).

Pass the following system properties while running the Facade API client. In the following segment of code, "${full_path}" points to the directory location in which sas.client.props and ssl.client.props are present.

These files are present in the IBM WebSphere installation directory in the following location. However, before passing them as the above system properties, you must modify them as follows:

Copy the following files to an appropriate directory, which is represented as ${full_path}.

If you skip or incorrectly run any of Steps 1 through 5, the above-mentioned code that uses the Facade API such as loc.getCompositeInstances(filter); does not work and can throw the following exception:

java.lang.RuntimeException: Caller doesn't have enough permission
to call this method.

When updating property values in the IBM WebSphere Administrative Console, click the property to open a page, enter the values as needed, and click OK. To commit the changes, click Save. Then restart Oracle SOA Server.

In the Resource Adapter summary table, you click the Oracle BAM Adapter resource name to configure the properties (for example, OracleBAMAdapter or BAM ADC Adapter as shown Figure 4-3. The name varies depending on how it was deployed).

On the Configuration page, you click Custom properties in the Additional Properties section on the right (Figure 4-4) to display all the properties you can configure for the selected Oracle BAM Adapter, as shown in Figure 4-5.

4.4.1.2 Configuring Oracle BAM Connection Factories

Before deploying applications that use Oracle BAM Adapter, a connection factory to Oracle BAM Server must be configured. You can configure both Remote Method Invocation (RMI) and Simple Object Access Protocol (SOAP) connection factories.

After clicking an Oracle BAM Adapter resource name as shown in Figure 4-3, on the Configuration page, you click J2C connection factories in the Additional Properties section on the right (Figure 4-6) to display a list of configured connection factories that you can use with the resource adapter.

If there are no connection factories listed on the J2C Connection Factories page, click New to create and configure an Oracle BAM connection factory to Oracle BAM Server (Figure 4-7). You can create connection factories for RMI-based calls and SOAP-based calls.

To configure the properties for a connection factory, click the connection factory name (for example, bamrmi or bamsoap), then on the Configuration page click Custom properties on the right. Figure 4-11 and Figure 4-12 show the custom properties you can configure for a RMI-based connection factory and a SOAP-based connection factory, respectively. Note that with RMI-based connection factories, InstanceName is the connection name for Oracle BAM Adapter (for example, ADCAdapter1), and PortNumber is the BOOTSTRAP_ADDRESS of the Oracle BAM Server. With SOAP-base connection factories, PortNumber is the WC_defaulthost of Oracle BAM Server.

Figure 4-12 also shows a SOAP-based connection factory configured for HTTP. To configure an HTTPS SOAP-based connection factory, create a new connection factory and specify the IsHTTPSEnabledWebService property value as true.

4.4.1.3 Configuring Trusted Domains

When using the RMI connection between a SOA composite application and Oracle BAM Server, that is when they are deployed in different cells, trusted domain configuration must be done in the IBM WebLogic Administrative Console. For more information, see Section 4.4.5, "Configuring Trusted Domains."

If you already have an installation of Oracle Data Integrator 10g working with an older version of Oracle BAM, you must have another installation of Oracle Data Integrator 10g to work with the current release of Oracle BAM. You cannot use the same Oracle Data Integrator 10g installation to work with multiple versions of Oracle BAM.

Apache Ant is required to run the installation script. Set the environment variable ANT_HOME to the location where ANT is installed before you run the bam_odi_configuration.sh (bam_odi_configuration.bat) script.

Set the following environment variables before you run the installation script:

JAVA_HOME: Root directory of the supported version of Java Development Kit (see the Oracle BAM support matrix on Oracle Technology Network web site for supported JDK versions).

WAS_CLIENT_PROPS: Directory where the sas.client.props file that the user wants to use resides.

Before you run the installation script, make sure login security values in sas.client.props and the server port value in BAMICommandConfig.xml are configured properly. For information, see Section 4.4.3, "Using ICommand."

After running the installation script and before using Oracle Data Integrator with Oracle BAM Server running on IBM WebSphere, make sure the server port value in BAMODIConfig.xml is configured to the same server port value as in step 4 above. To change the value, locate BAMODIConfig.xml in $ODI_HOME/oracledi/lib/config, then uncomment the line for the server port value.

4.4.3 Using ICommand

When a standalone Oracle BAM client (such as ICommand, Oracle Data Integrator, and Oracle BAM Data Control) connects to Oracle BAM Server, the configuration file (for example BAMICommandConfig.xml), which is read when the Oracle BAM client code is invoked, must point to the server on which the Oracle BAM Server instance is running.

In addition, login security must be configured before standalone Oracle BAM clients can connect to Oracle BAM Server.

4.4.3.1 Configuring Oracle BAM Server Port

By default ICommand looks for Oracle BAM Server on port 2809. If the Oracle BAM Server port number is changed from the default during the setup and configuration of Oracle BAM on IBM WebSphere, then you must manually change the port number from 2809 to the new port number in the BAMICommandConfig.xml file.

You can set levels at any point in the package hierarchy right down to the individual class. This mechanism is analogous to modifying the logging.xml file.

Click Apply or OK, then click Save to the master configuration.

This saves the changes permanently so they are in effect even if you restart IBM WebSphere.

The log files are located at WAS_HOME/was_profiles/DefaultTopology/was_as/ServerName/logs/ServerName, (for example, ServerName-diagnostic.log), where ServerName is the name of the server that is hosting Oracle BAM.

Alternatively, you can execute wsadmin scripts to set the level for all the current descendants of a logger. For example:

4.4.5 Configuring Trusted Domains

When Oracle BAM Server components require a connection to a remote server, trusted domain configuration must be done in the IBM WebSphere Administrative Console. For example, when Enterprise Message Sources (EMS) in Oracle BAM needs to connect to a topic/queue on a JMS server that is installed on a different IBM WebSphere instance, you have to set up the domain trust between the IBM WebSphere instances.

To perform communication with another server, IBM WebSphere has to retrieve a signer certificate from a secure remote SSL port during the handshake. The signer exchange process for setting up SSL to external servers such as Lightweight Directory Access Protocol (LDAP) is greatly simplified on IBM WebSphere. Instead of manually obtaining the remote server's signer certificate and then importing it into the appropriate trust store each time, the signer certificate retrieved from the remote port can be stored in an existing local trust store. Oracle BAM Server components that require a connection to the remote server can then use the validated signer certificate from the keystore.

To configure a trusted domain by obtaining and validating a signer certificate from a remote port:

Log in to the IBM WebSphere Administrative Console.

In the navigation panel, expand Security, then click SSL certificate and key management.

Click Key stores and certificates.

The Keystore usages dropdown should show SSL keystores as the value.

Select a trust store (for example, NodeDefaultTrustStore).

Click Signer certificates, then click Retrieve from port.

This option opens an SSL connection to retrieve the certificate.

Enter the host name of the machine on which the signer resides.

Enter the SSL port on the host machine.

Enter an alias.

Click Retrieve signer information.

Verify the signer certificate information and the SHA digest of the certificate, which is used to ensure the information has not been modified in transit.

Click Apply or OK to add the signer certificate to the selected trust store.

4.4.6 Configuring Security

Login security must be configured before standalone Oracle BAM clients (such as Oracle Data Integrator, Oracle BAM Data Control and ICommand) can connect to Oracle BAM Server on IBM WebSphere.

Oracle BAM web applications by default use FORM as the authentication security method. To use the CLIENT_CERT authentication security method on IBM WebSphere, you must configure it manually.

To provide secure access to Oracle BAM web applications on IBM WebSphere, you must assign users to roles that provide the necessary permissions.

For standalone clients like Oracle Data Integrator, Oracle BAM Data Control and ICommand to connect to Oracle BAM Server on IBM WebSphere, certain property values must be set in the sas.client.props file, which is required for initial authentication of the standalone client by IBM WebSphere.

On IBM WebSphere, Oracle BAM web applications must use FORM as the authentication security method and Oracle BAM web services must use BASIC as the authentication security method. Unlike Oracle WebLogic Server, IBM WebSphere does not provide a fallback mechanism for authentication methods, which means you cannot specify more than one authentication method. If you wish to use the CLIENT_CERT authentication security method for Oracle BAM web applications, you must configure it manually by following these steps:

Extract the existing oracle-bam-was.ear, located in MW_HOME/Oracle_SOA1/bam/applications, for example.

Modify the deployment descriptor web.xml in bam-web.war by replacing "FORM" with "CLIENT_CERT". For example:

<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>

Repackage bam-web.war with the edited deployment descriptor.

Deploy the modified oracle-bam-was.ear.

4.4.6.3 Creating User/Group Mappings for Oracle BAM on IBM WebSphere

After installing Oracle BAM on IBM WebSphere AS or IBM WebSphere ND, you must specify the users and groups that are mapped to the security roles for Oracle BAM.

To create user/group mappings for Oracle BAM on IBM WebSphere:

Log in to the IBM WebSphere Administrative Console:

host:port/ibm/console

On IBM WebSphere ND, navigate to the Console Preferences page in System administration. Select Synchronize changes with Nodes and click Apply.

This ensures that all changes saved to the master configuration are propagated across the nodes.

In the navigation panel, expand Applications > Application Types.

Select WebSphere enterprise applications, then select oracle-bam.

On the Configuration tab, Detail Properties section, select Security role to user/group mapping.

Select the bamuser checkbox, then click Map Users.

Click Search to display a list of available users.

Select cn=adminusername,dc=com and move it to the Selected list, then click OK twice.

Save the change and restart Oracle BAM Server.

Alternatively, you can use the wsadmin command-line utility to configure the mapping. For example:

For Enterprise Message Sources (EMS) on Oracle BAM Server to look up JMS resources hosted on a remote provider, you must first set up the trust between the local IBM WebSphere server (where Oracle BAM is deployed) and the remote IBM WebSphere server (where the JMS provider is configured). Then you set up the JMS resource on the remote server by creating a service integration bus, a JMS topic connection factory, and a JMS topic.

On the remote IBM WebSphere instance, log in to the IBM WebSphere Administrative Console.

To create a service integration bus, follow these steps:

In the navigator panel, expand Service integration. Click Buses, then click New.

Enter a name for your new bus (for example, MyBus).

Note that this name should be different from the bus name in your local IBM WebSphere instance.

Deselect Bus security.

Click Next, then click Finish.

On the Buses page, click the bus name you just created.

On the Configuration tab, Topology section, click Bus members then click Add.

Choose the server to add to the bus from the dropdown list (for example, JrfNode:JrfServer).

Click Next, accepting all default values until you get to the Summary page, then click Finish.

To create a JMS topic connection factory, follow these steps:

In the navigation panel, expand Resources > JMS.

Click Topic connection factories.

Expand Scope, then select the node and server as the scope from the dropdown list (for example, Node=JrfNode,Server=JrfServer).

The scope identifies the level to which the resource (JMS topic connection factory) is visible.

Click New, then select Default messaging provider as the provider that supports the topic connection factory instance, and click OK.

In the Administration section of the Configuration page, enter a display name for the resource (for example, myNewTopicCF) and the JNDI name for the resource (for example, jms/myNewTopicCF).In the Connection section, from the Bus name dropdown list, select the bus to connect to (for example, MyBus).

This is the service integration bus that the connection factory is used to create connections to.

Enter the name of the target that is used to determine the messaging engine (for example, JrfNode.JrfServer).

This is the bus member (server) you added in step 3g above.

Select Bus member name as the type from the Target Type dropdown list.

In the Provider endpoints box, enter <yourhostname>:7277: as the endpoint used to connect to a bootstrap server, then click OK.

To create a JMS topic, follow these steps:

In the navigator panel, expand Resources > JMS.

Click Topics.

Expand Scope, then select the node and server as the scope from the dropdown list (for example, Node=JrfNode,Server=JrfServer).

Click New, then select Default messaging provider as the provider that supports the topic destination instance, and click OK.

In the Administration section of the Configuration page, enter a display name for the resource (for example, myNewTopic) and the JNDI name for the resource (for example, jms/myNewTopic).In the Connection section, from the Bus name dropdown list, select the bus hosting the topic (for example, MyBus).

The topic space name you created should now be listed in the Topic space dropdown list.

Click OK.

Save to the master configuration. Restart the server.

In Oracle BAM Architect on the local IBM WebSphere instance, create a new EMS definition using the remote provider URL, the remote connection factory (for example, jms/myNewTopicCF) and the remote topic (for example, jms/MyNewTopic) you created.

When deploying an Oracle ADF application that uses Oracle BAM data controls, make sure you deploy the application to an IBM WebSphere application server where ADF shared libraries are available. Before deploying, the properties of the application server connection to IBM WebSphere created in JDeveloper must include the parameters as described in Section 4.4.9.2, "Application Server Connection Parameters."

4.4.9.1 Exceptions in JDeveloper

A few exceptions must be noted before using Oracle BAM data controls in JDeveloper. They are:

Copy the JAR files in Table 4-5 from IBM WebSphere to the following Oracle JDeveloper directory:

JDEV_HOME/jdeveloper/was

Table 4-5 IBM WebSphere JAR Files to Copy and their Locations

JAR File to Copy

Location of JAR File on IBM WebSphere

com.ibm.ws.admin.client_7.0.0.0.jar

WAS_HOME/runtimes

com.ibm.ws.ejb.thinclient_7.0.0.jar

WAS_HOME/runtimes

com.ibm.ws.jpa.thinclient_7.0.0.jar

WAS_HOME/runtimes

com.ibm.ws.orb_7.0.0.jar

WAS_HOME/runtimes

ejb3exceptions.jar

WAS_HOME/runtimes

ibmorb.jar

WAS_HOME/java/jre/lib

oracle.webservices.standalone.client.jar

MW_HOME/oracle_common/modules/oracle.webservices_11.1.1

tools.jar

WAS_HOME/java/lib

wsclient_extended.jar

MW_HOME/oracle_common/webservices

Add the BAMCommonConfig.xml file to JDEV_HOME/jdeveloper/jdev/extensions/oracle.bam.jar.

Note that oracle.bam.jar is available only after you have installed soa-jdev-extension.zip.

BAMCommonConfig.xml should be added to the config directory in the root directory of the JAR file.

4.4.9.2 Application Server Connection Parameters

At runtime, Oracle BAM data controls in an Oracle ADF application use the Oracle BAM connection to connect to Oracle BAM Server on IBM WebSphere. Deploying an Oracle ADF application to IBM WebSphere is largely the same as deploying an ADF application to Oracle WebLogic Server. Note, however, that you must deploy the application to an IBM WebSphere application server where ADF shared libraries are available (for example, OracleAdminServer on IBM WebSphere ND). To enable this, certain parameters must be correctly set in the JDeveloper deployment profile for the application.

When you create the application server connection to IBM WebSphere in JDeveloper, on the Configuration page of the Create Application Server Connection wizard, make sure the parameters are properly set as shown in Table 4-6.

Table 4-6 Configuration Parameters for Server Connection

Parameter

Description

SOAP Connector Port

Port number of the host used to connect to the server for deployment, as defined in <SOAP_CONNECTOR_ADDRESS> on the IBM WebSphere Administrative Console.

Server Name

Name of server (as defined in IBM WebSphere) where the application is deployed.

Target Node

Name of the node (as defined in IBM WebSphere) where the application is deployed.

Target Cell

Name of the cell (as defined in IBM WebSphere) where the application is deployed.

Then on the JMX page of the Create Application Server Connection wizard, make sure the RMI port parameter is properly set as shown in Table 4-7.

Table 4-7 JMX Parameters for Server Connection

Parameter

Description

RMI Port

Port number of the IBM WebSphere application server's RMI connector port, as defined in <BOOTSTRAP_ADDRESS> on the IBM WebSphere Administrative Console.

Note:

In the IBM WebSphere Administrative Console, the locations where you can find the values of <SOAP_CONNECTOR_ADDRESS> and <BOOTSTRAP_ADDRESS>, and the runtime node and cell names, differ based on the type of IBM WebSphere Server you are using and the server where the application is being deployed (for example, soa_server1 or the deployment manager server dmgr). For more information, see Table 4-2, "Location of Application Server Connection Configuration Details", which describes where to find the information in the IBM WebSphere Administrative Console.

4.4.10 Configuring the LTPA Timeout for Active Data Reports

On IBM WebSphere, the Lightweight Third Party Authentication (LTPA) timeout value specifies the period of time during which the server credentials from another server are valid. After the timeout period expires, the server credential from the other server must be revalidated.

The default LTPA timeout value is 120 minutes, which means the user is logged out after 120 minutes. The LTPA token and associated sessions are terminated and reauthentication is needed. This would affect, for example, users who have Oracle BAM applications and active data reports open in the browser for longer than 120 minutes.

To allow users to remain logged in for more than 120 minutes without having to log in again to reauthenticate credentials, set the LTPA timeout value to a higher number.

To change the LTPA timeout value:

Log in to the IBM WebSphere Administrative Console.

In the navigation panel, expand Security and click Global Security.

In the Authentication section on the right, click LTPA.

In the LTPA timeout field, enter a value in minutes.

For example, to allow users to remain logged in for two days, enter 2880 minutes.

Scripting on this page enhances content navigation, but does not change the content in any way.