This appendix describes solutions to common problems that you might encounter when installing Oracle SOA Suite. It contains the following sections:
Section D.5, "Using Data Sources with an SSL-Enabled Database"
Section D.6, "Extending an Identity Management Domain with a SOA Installation"
Section D.7, "XA Configuration Required to Start the SOA Infrastructure on Microsoft SQL Server"
If you encounter an error during installation:
Read the Oracle Fusion Middleware Release Notes for the latest updates. The most current version of the release notes is available on Oracle Technology Network (http://www.oracle.com/technology/documentation).
Verify your system and configuration is certified. Refer to the Fusion Middleware Certification document:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Verify your system meets the minimum system requirements. Refer to the System Requirements and Specifications document:
http://www.oracle.com/technology/software/products/ias/files/fusion_requirements.htm
If you entered incorrect information on one of the installation screens, return to that screen by clicking Back until you see the screen.
If an error occurred while the installer is copying or linking files:
Note the error and review the installation log files.
Remove the failed installation by following the steps in Chapter 4, "Deinstalling Oracle SOA Suite and Oracle Business Process Management Suite".
Correct the issue that caused the error.
Restart the installation.
This section contains information about the log files that are created when running the Oracle SOA Suite installer and the Oracle Fusion Middleware Configuration Wizard. Log files contain information that can help you troubleshoot problems with your installation or configuration.
The installer writes logs files to the Oracle_Inventory_Location/log (on UNIX operating systems) or Oracle_Inventory_Location\logs (on Windows operating systems) directory. On UNIX operating systems, if you do not know the location of your Oracle Inventory directory, you can find it in the oraInst.loc file in the following directories (default locations):
Linux: /etc/oraInst.loc
HP-UX and Solaris: /var/opt/oracle/oraInst.loc
On Windows operating systems, the location for the inventory directory is C:\Program Files\Oracle\Inventory\logs. If you are using a 32-bit installer on a 64-bit Windows machine, the inventory directory is C:\Program Files (x86)\Oracle\Inventory\logs.
The following install log files are written to the log directory:
installdate-time-stamp.log
This is the main log file.
installdate-time-stamp.out
This log file contains the output and error streams during the installation.
installActionsdate-time-stamp.log
This file is used by the installer GUI to keep track of internal information.
installProfiledate-time-stamp.log
This log file contains the overall statistics like time taken to complete the installation, as well as configuration, memory and CPU details.
oraInstalldate-time-stamp.log
This log file contains the output stream of the copy session.
If you start the installer with the -printtime parameter, the timeTakendate-time-stamp.log and timedate-time-stamp.log files are created in the same directory:
timeTakendate-time-stamp.log
This file contains information for the amount of time taken to move between screens (applicable for GUI installations only).
timedate-time-stamp.log
This file contains time information for the copy session.
If you start the installer with the -printmemory parameter, the memorydate-time-stamp.log file is created. This file contains memory usage information for the copy session.
To create a log file of your configuration session, start the Configuration Wizard with the -log option, as shown below:
On UNIX operating systems:
./config.sh -log=log_filename -log_priority=log_level
On Windows operating systems:
config.cmd -log=log_filename -log_priority=log_level
See Table D-1 for more details about the -log and -log_priority options.
Table D-1 Configuration Wizard Log File Options
| Parameter | Description |
|---|---|
|
|
Specify the location of your log file. If you specify an absolute path with your Other values that can be specified with
|
|
|
Specify the level of detail you want included in your logs. The acceptable values are listed below, from most detailed to least detailed:
|
The JRE location used by the installer is stored in the SOA_ORACLE_HOME/oui/oraparam.ini (on UNIX operating systems) or SOA_ORACLE_HOME\oui\oraparam.ini (on Windows operating systems) file. This file is used by OPatch and Oracle Universal Installer (OUI) to determine the location of your preferred JRE.
It is possible to change the location of your JRE (for example, the JRE directory is moved out of the Middleware Home). If this happens, you will get an error message when trying to run OPatch or OUI since the JRE location can no longer be found. If this happens, you can do one of the following:
Edit the SOA_ORACLE_HOME/oui/oraparam.ini (on UNIX operating systems) or SOA_ORACLE_HOME\oui\oraparam.ini (on Windows operating systems) file to point to the new JRE location.
Use the -jreLoc command line option to point to the new JRE location. See Section 2.2.2, "Starting the Installer" for more information.
If Oracle WebLogic Server is configured to use custom trust key store, you must manually revise the setDomainEnv.cmd (on Windows operating systems) or setDomainEnv.sh (on UNIX operating systems) file so that the Djavax.net.ssl.trustStore parameter points to the custom trust keystore file. For example:
Djavax.net.ssl.trustStore=/myfolder/mystore/mytrustkeystore.jks
If you are using an SSL-enabled database, follow the instructions below so that your data sources will work with SSL connections:
Create a truststore and add the ./root/b64certificate.txt as a trusted certificate to the truststore using a keytool:
keytool -importcert -trustcacerts -alias dbroot -keystore ./truststore -storepass welcome1 -file ./b64certificate.txt
In the WebLogic Server console, navigate to the "Connection Pool" tab of the data source you are using. Modify the following properties accordingly:
Requires Authentication:
javax.net.ssl.keyStore=keystore_password javax.net.ssl.keyStoreType=JKS javax.net.ssl.keyStorePassword=keystore_password javax.net.ssl.trustStore=truststore_location javax.net.ssl.trustStoreType=JKS javax.net.ssl.trustStorePassword=truststore_password
Does Not Require Authentication:
javax.net.ssl.trustStore=truststore_location javax.net.ssl.trustStoreType=JKS javax.net.ssl.trustStorePassword=truststore_password
In the URL field, enter the following:
jdbc:oracle:thin:@( DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=database_host)(PORT=database_port))) (CONNECT_DATA=(SERVICE_NAME=service_name)) (SECURITY=(SSL_SERVER_CERT_DN="distinguished_name")) )
In the JDBC data source files, modify the <property> parameter as shown below:
<property>
<name>javax.net.ssl.trustStorePassword</name>
<value>truststore_password</value>
</property>
If you create a domain by installing Oracle Identity Management, then extend it by installing Oracle SOA Suite, the Oracle SOA installer changes the ORACLE_HOME environment variable. This breaks the Oracle Identity Federation (OIF) WebLogic Scripting Tool (WLST) environment, which relies on the value of ORACLE_HOME as set by the Identity Management installation.
To work around this issue, do the following:
Follow the instructions in "Setting up the WLST Environment" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
Copy all of the .py files in the OIF_ORACLE_HOME/fed/script (on UNIX operating systems) or OIF_ORACLE_HOME\fed\script (on Windows operating systems) directory to the WebLogic_Home/common/wlst (on UNIX operating systems) or WebLogic_Home\common\wlst (on Windows operating systems) directory.
Append the OIF_ORACLE_HOME/fed/script (on UNIX operating systems) or OIF_ORACLE_HOME\fed\script (on Windows operating systems) directory to the CLASSPATH environment variable on your system.
You must configure XA support in both the Microsoft SQL Server database and Microsoft operating system to test the SOA Infrastructure connection during domain creation and to successfully start the SOA Infrastructure.
For SQL 2005, 2008, 2008 R2, 2012, and 2012 SP1, do the following:
Install Oracle WebLogic Server.
Install Microsoft SQL Server JDBC XA procedures. These procedures enable you to use JDBC distributed transactions through JTA. This procedure must be repeated for each MS SQL Server installation to include in a distributed transaction.
Copy the .dll file appropriate for your platform and the instjdbc.sql file from the WebLogic_Home\server\bin directory to the directory appropriate to your version of SQL Server:
Note:
If you have an environment where you have previously configured XA support and have applied the latest Oracle SOA Suite patch set, you must perform this step using thesqljdbc.dll and instjdbc.sql files from the most recent WebLogic Server home directory.| Database | Copy This File... | To This Directory... |
|---|---|---|
| SQL Server 2005 | From the WebLogic_Home\server\bin directory, copy one of the following .dll files (find the one for your platform) along with the instjdbc.sql file:
|
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn |
| SQL Server 2008 and 2008 R2 | From the WebLogic_Home\server\bin directory, copy one of the following .dll files (find the one for your platform) along with the instjdbc.sql file:
|
C:\Program Files\Microsoft SQL
Server\MSSQL10.INSTANCE_NAME\MSSQL\Binn
|
| SQL Server 2012 and 2012 SP1 | From the WebLogic_Home\server\bin directory, copy one of the following .dll files (find the one for your platform) along with the instjdbc.sql file:
|
C:\Program Files\Microsoft SQL
Server\MSSQL11.INSTANCE_NAME\MSSQL\Binn
|
Notes:
If you are installing stored procedures on a database server with multiple Microsoft SQL Server instances, then each running SQL Server instance must be able to locate the appropriate .dll file. Therefore, the .dll file must be anywhere on the global PATH or on the application-specific PATH. For the application-specific PATH, place the .dll file into the drive:\Program Files\Microsoft SQL Server\MSSQL$Instance_1_Name\Binn directory for each instance.
If your Oracle WebLogic Server and Oracle SOA Suite installations are on a Linux host, the .dll file does not appear under the WebLogic_Home/server/lib directory. In these cases, you must copy this file from a host on which .dll file is installed.
From the database server, use the ISQL utility to run the instjdbc.sql script for your version of SQL Server. As a precaution, back up the master database before running instjdbc.sql.
For Microsoft SQL Server 2005, run:
C:\Program Files\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE -S "DB_HOST\INSTANCE_NAME" -U SA -P SA_PASSWORD -i instjdbc.sql -o LOG_FILE
For Microsoft SQL Server 2008, run:
C:\program files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE -S "DB_HOST\INSTANCE_NAME" -U SA -P SA_PASSWORD -i instjdbc.sql -o LOG_FILE
For Microsoft SQL Server 2012 and 2012 SP1, run:
C:\program files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.EXE -S "DB_HOST\INSTANCE_NAME" -U SA -P SA_PASSWORD -i instjdbc.sql -o LOG_FILE
For all commands, DB_HOST is the name of the host on which SQL Server is installed, INSTANCE_NAME is the name of the SQL Server instance, and SA_PASSWORD is the password of the system administrator.
The instjdbc.sql script generates many messages, including the following which can be safely ignored:
Msg 156, Level 15, State 1, Server STANA17-1\SQLSERVER123, Line 1 Incorrect syntax near the keyword 'tran'. Msg 319, Level 15, State 1, Server STANA17-1\SQLSERVER123, Line 1 Incorrect syntax near the keyword 'with'. If this statement is a common table expression, an xmlnamespaces clause or a change tracking context clause, the previous statement must be terminated with a semicolon.
You should scan the entire output for any messages that may indicate an execution error. The last message should indicate that instjdbc.sql ran successfully. The script fails when there is insufficient space available in the master database to store the JDBC XA procedures or to log changes to existing procedures.
On Microsoft Windows Server 2005, 2008, 2008 R2, 2012 and 2012 SP1, configure the Microsoft Distributed Transaction Coordinator (DTC) for the Microsoft operating system.
From the Start menu, select Control Panel, then Administrative Tools, then Component Services icon, then Component Services (in the navigator under Console Root), then Computers, and then My Computer.
On MS Windows Server 2005: Right-click My Computer and select Properties > MSDTC > Security Configuration.
On MS Windows Server 2008, 2008 R2, 2012 and 2012 SP1: From My Computer, select Distributed Transactions, and then Local DTC. Right-click on the properties of Local DTC. The Security Configuration dialog will appear.
If you are not able to find Distributed Transactions on MS Windows Server 2008 or 2008 R2, then follow the instructions for Installing Application Server Role in Step 4 and Installing DTC in Step 5.
In the Security Settings section, select the Network DTC Access checkbox.
In the Client and Administration section, select the Allow Remote Clients checkbox.
In the Transaction Manager Communication section, select the Allow Inbound, Allow Outbound, No Authentication Required. In SQL 2005 and 2008, enable Transaction Internet Protocol (TIP) Transactions checkboxes.
In the Security Settings section, select the Enable XA Transactions checkbox. For SQL 2008, 2008 R2, 2012 and SQL 2012 SP1, enable SNA LU 6.2 Transactions too.
Click OK in the Security Configuration dialog.
Click OK in the My Computer Properties dialog.
On SQL 2008 and 2008 R2, install the Application Server Role.
Click Start and then click Server Manager.
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
On the Action menu, click Add Roles.
The Add Roles Wizard appears. Click Next.
The Select Server Roles page appears. Select the Application Server check box, and then click Next.
Information about the Application Server role appears. Familiarize yourself with the information, and then click Next.
On the Select Role Services page, select the role services that are necessary to run your applications, and then click Next. Application Server Foundation, the default role service, is always installed as a part of the Application Server role.
Note that some role services require the installation of supporting features or role services from other roles. If this is the case, you have the option to either install or not install the required features or role services.
If the installation of a supporting feature or role service from another role is required, the next pages provide important information about the feature or set of features or role service. Click Next to go to the Confirm Installation Options page.
Click Install to begin installing the Application Server role with the options that appear on the page. The installation process can be lengthy, depending on the role services that you select. After the installation process starts, input by the operator is not necessary. When the installation process is finished, the status of the installation appears on the Installation Results page.
On Microsoft Windows 2008 and 2008 R2, install DTC.
To install DTC, open Control Panel and then Programs and Features. Select Turn Windows Features on or off.
The Server Manager opens and queries the system for the list of features and roles which are setup. Select Add Feature and then select Application Server from the feature list.
Click Next on the Welcome screen and the Application Server screen.
On the Local DTC Properties screen, select the services that you will install as part of this role. Select either Incoming Remote Transactions, or Outgoing Remote Transactions or both depending on your needs. If you want to use SOAP, select WS-Atomic Transactions. Click Next.
If you have selected WS-Atomic Transactions, a page to select an SSL cert displays. You can either select one of Create a Self Signed Cert, or request one later from a CA. Click Next and then click Install. If you have not selected WS-Atomic Transactions in the previous screen, the next screen will have the Summary and Install options. After the installation is complete, click Close.
Expand Roles from the left hand menu by clicking the plus (+) sign, and then go to Application Server, then Component Services, then Distributed Transaction Coordinator and then Local DTC.
Right click on Local DTC and select properties, then select the security tab.
Select the options you need to set the DTC up matching the other servers in your environment. Ensure that you enable Allow Remote Clients so that client machines can access the DTC on this machine. If you want to be able to remotely enable DTC from another machine, then select Allow Remote Administration.
Click OK and restart it. You can see the DTC events in the log by selecting the Application Server option from the menu on the left.
Reboot Microsoft SQL Server.
The XA driver will not successfully connect during domain configuration if your Microsoft SQL Server database is not rebooted.
If this appendix does not solve the problem you encountered, try looking for a solution on My Oracle Support (formerly OracleMetaLink):
https://support.oracle.com/
You can read Note 1292813.1 titled "Troubleshooting SOA Suite 11gR1 Installation for Versions 11.1.1.0 and higher" for additional Oracle SOA Suite troubleshooting information.
If you are unable to find a solution for your problem, open a service request.