SOA FAQ: Compare Weblogic and Oracle Application Server

Migrating from Oracle Application Server to WebLogic for the Oracle SOA Suite is not rather complicated, the concept is still the same. The major difference is the look and feel of the WebLogic Administration console and all the option you can choose. Furthermore the whole directory structre and filenames are different. This article gives you a quick reference on the difference

How to install Oracle SOA Suite on WebLogic?

Currently Oracle SOA Suite 10.1.3.3 is certified against Weblogic 9.2. The near future Oracle SOA Suite 10.1.3.4 will be certified against 9.2.

• Install Oracle SOA Suite 10.1.3.x in seperate home.
• Install Oracle SOASuite 10.1.3.4 patch.
• Upgrade SOA Schemas
• Apply Opatch for Bug 7337034
  
• Download SOA Suite for WebLogic 10.1.3.4 via OTN (WL_SOA10134_Installables).
• Install Weblogic 9.2
• Unzip WL_SOA10134_Installables
• Apply changes in SOADomain.properties (create new domain)
• Install SOA Suite for WebLogic 10.1.3.4

How to start WebLogic with Oracle SOA Suite installed?

WebLogic is using a node manger to control the environment. This can be compared with the Oracle process manager (OPMN). Start the node manager as follows:

$WEBLOGIC_HOME/server/bin/startNodeManager.sh

WebLogic has the concepts of domains. This is NOT the sames as the domains in the the SOA Suite. In a Domain one or more application servers are running. At least one is configured, this is the mananged server, it is comparable with the OC4J instance 'home'. You can start this server as follows:

$WEBLOGIC_DOMAINHOME/<yourSOADomain>/bin/startWebLogic.sh

Within the installtion of Oracle SOA Suite on top of Weblogic, a addtional server is created. This can be compared with the 'oc4j_soa' container .

Where is the data-sources.xml file located?

Each connection is has his own config file instead of one single file.
$WEBLOGIC_DOMAINHOME/<yourSOADomain>/config/jdbc

Where are the adapter config files, such as oc4j-ra.xml?

$WEBLOGIC_HOME/apps/soaApps/<adapter>/META-INF/ra.xml
$WEBLOGIC_HOME/apps/soaApps/<adapter>/META-INF/weblogic-ra.xml

Every change made in the Weblogic Admin Console comes in to a deployment plan file (Plan.xml).

Where can I find my log files, the standard out for example?

$WEBLOGIC_DOMAINHOME/<yourSOADomain>/servers/<yourSOAServer>/logs
OracleSOAServer.log
OracleSOAServer.out

How do I edit the adapter config files?

Just edit the weblogic-ra.xml file. From the console you can not edit empty properties (wls 9.2)

$WEBLOGIC_HOME/apps/soaApps/<adapter>/META-INF/weblogic-ra.xml

Oracle SOA Build System: updated

An updated version of Oracle SOA Build System can be download here. This version should work against Oracle SOA Suite release 10.1.3.4.

A next version of this tool will work against Oracle Weblogic Server.

Featured plan:

• Migrate OSBS tool for Oracle Weblogic server (10.1.3.4)
• Migrate OSBS tool for Oracle Weblogic server (10.1.3.5)
• Migrate OSBS tool for Oracle Weblogic server (11.x)

Regards,

Marc

Install Oracle WebLogic Server / Oracle Application Server on linux 64 bit

Not all Oracle products are directly available on Linux 64 bit. This results, that you can not use the product or trust the 32 bit version.

To use the 32 bit products on a 64 bits operating system, you must have installed the 32 bit packages. With tools such as YAST or another package managers, you can easily add these packages:

• linux32
• compat-32bit
• gcc-32bit
• glib-32bit
• glibc-32bit
• and other dependencies
  

To install the 32 bits code on the 64bits O/S you first start the 32 bits shell.

$ linux32 bash


Then start your scripts, for example:

./runInstaller

./startNodeManager.sh

./server923_linux32.bin

Applying Oracle Patches on WLS

While I'm now working on Oracle Web Logic server; WLS 9.2, Oracle SOA Suite and Oracle Service Bus. I run into a common issue when applying patches on your Operating system.

I love to play with Linux, my version is Suse 11.1. I known it is running on the edge, but thats live.

When applying patches you some times get errors like:

OPatch detects your platform as 46 while this patch 7337034 supports platforms:
0 (Generic Platform)

IMHO the patch should just install, while the patch is generic.

A simple solution is available.

Open the file etc/config/inventory from your install directory.

Add your platform into this file and apply the patch again.

Orginal:

<os_platforms>
<platform name="Generic Platform" id="0">
</os_platforms>

Add your platform:

<os_platforms>
<platform name="Generic Platform" id="46">
<platform name="Generic Platform" id="0">
</os_platforms>

Domain Value Mapping (DVM) example

Here are some examples how to use domain-value-mapes in XSLT transformations.

Domain value maps are used to map code-values from one into another one. Commonly used in SOA patterns and in canonical datamodels.

For example in Oracle AIA, DVM are used to map statuses farom Siebel to AIA canonical data format and then to Oracle BRM format.

Example call to DVM lookup

<xsl:variable name="Salutation" select="orcl:lookup-dvm('CONTACT_SALUTATION','SEBL_01','Miss.','PMDM_01','')">
<xsl:if test="$Salutation!=''">
  <xsl:value-of select="$Salutation">
</xsl:if>

In more general terms:

<xsl:variable name="RESULT" select="orcl:lookup-dvm(DVM_NAME,$SOURCE_SYSTEM,$KEY,$TARGET_SYSTEM,'')">
<xsl:choose>
  <xsl:when test="$ RESULT!=''">
    <xsl:value-of select="$ RESULT ">
  </xsl:when>
  <xsl:otherwise>DEFAULT</xsl:otherwise>
</xsl:choose>

‘SOURCE_SYSTEM’ variable either retrieved from EBM Header and lookup in AIA registry OR hard-coded to ‘COMMON’ (when message from AIA to application

‘TARGET_SYSTEM ‘ would be a target system either retrieved from EBM Header and lookup in AIA registry or hard-coded to ‘COMMON’ (when message from application to AIA’

Lookup in AIA registry example:

<xsl:variable name="TargetSystemID">
  <xsl:choose>
      <xsl:when test="boolean(/telcocustmr:CreateCustomerPartyEBM/corecom:EBMHeader/corecom:Target/corecom:ID/text())">
          <xsl:value-of select="/telcocustmr:CreateCustomerPartyEBM/corecom:EBMHeader/corecom:Target/corecom:ID">
      </xsl:when>
      <xsl:otherwise>
          <xsl:value-of select="aia:getServiceProperty('{http://xmlns.oracle.com/ABCSImpl/Portal/Industry/Telco/CreateCustomerPartyPortalProvABCSImpl/V1}CreateCustomerPartyPortalProvABCSImpl','BRMCUSTService.Routing.Target.Default.SystemID',true())">
      </xsl:otherwise>
  </xsl:choose>
</xsl:variable>

<xsl:variable name=" SOURCE_SYSTEM " select="$TargetSystemID">

Note the way the identification of the system is used BRMCUSTService. If your application is not (yet) registered in AIA, like PMDM, a hardcoded system identification would be more appropriate, example:

<xsl:variable name="TargetSystemID">
  <xsl:choose>
      <xsl:when test="boolean(/telcocustmr:CreateCustomerPartyEBM/corecom:EBMHeader/corecom:Target/corecom:ID/text())">
          <xsl:value-of select="/telcocustmr:CreateCustomerPartyEBM/corecom:EBMHeader/corecom:Target/corecom:ID">
      </xsl:when>
      <xsl:otherwise>PMDM_01</xsl:otherwise>
  </xsl:choose>
</xsl:variable>

<xsl:variable name=" SOURCE_SYSTEM " select="$TargetSystemID">