OSB vs BPEL

One of the fundamental concepts of SOA is service reuse. There are significant cost benefits to reuse. This involves discipline and governance in defining the interfaces of the services to be reused. However it is not reasonable to re engineer all your existing applications to be reusable. What is required is service virtualization by a layer in front, which has the architected controlled reusable interfaces. This interface needs to be governed through an enterprise repository and discovered for reuse through a service registry.

Another problem is that application interfaces change over time as business requirements change and evolve. However in a successful SOA practice, these applications are heavily reused with lots of clients. The change to the interface has a ripple effect across all the clients who need to absorb the change. What is required is agility in the IT systems to minimize the impact of such changes so such changes can be done quickly and easily. This not only has cost benefits but also business benefits due to agility to meet new business requirements. To achieve this, we need a virtualization layer in front that the many clients talk to, which can be the point of absorption of most such changes.

Oracle Service Bus (OSB) is a high performance stateless enterprise service bus that provides this virtualization layer that facilitates reuse. OSB deals not only with XML interfaces but also binary, text, java(future) and structured binary (example SWIFT) interfaces. All these data types can be natively stored in OSB variables.

What are the types of changes OSB can absorb? OSB can largely absorb all of the following changes. As one of many examples, you do not want to constantly modify a BPEL process for all these changes but rather abstract out these changes to OSB in front of or behind the bpel process.

- Changes to the document format, say due to xml schema changes or even changes to the version of structured binary data. Transformation can be done by java code, XSLT, Xquery, or MFL to convert between structured binary and XML. OSB supports any to any bridging between formats.
- Changes to packaging say from soap 1.1 to soap 1.2 or even from REST to soap.
- Changes to where the messages need to be routed or load balanced.
- Changes to the location of a service (change in address).
- Changes to the security scheme, say from HTTP basic auth to web services security username token.
- Changes to the transport, say from HTTP to JMS. OSB supports a large number of transports and you can also seamlessly plug in new transports. OSB supports any to any bridging between transports.
- Changes to the invocation style say from one-way to request/response. OSB supports any to any bridging between supported invocation styles.
- Changes to what data the message is enriched with. OSB has a variety of ways to lookup data. You can lookup data in a databases or invoke web services or java code to do lookups.
- Split of a service or operation into multiple services or operations that need to be invoked in sequence or in parallel or a mix of the two. Alternatively merge of a set of services or operations into a single service or operation.
- Changes to the routing rules.
- As service reuse increases, the service gets overloaded and needs to be throttled.

Even if there are no difference initially between the OSB interface and the enterprise services it virtualize it is good to architect in OSB as an intermediary for more easily handle future changes.

BPEL on the other hand is focused on orchestration of long running or short running processes. The core of a process logic is implemented as a BPEL process.
The focus is very different. You would NOT put process logic in OSB.

Coherence Installation and QuickStart

1. Download Oracle Coherence 3.5 for Java Version from http://www.oracle.com/technology/software/products/ias/htdocs/coherence.html
2. Unzip the download into D:\ directory
3. Rename the coherence-java-v3.5b459 to coherence
4. Open Command Window [window1] and and navigate to the coherence directory (renamed above)
5. Type, cd coherence
6. Type, java -cp lib\coherence.jar com.tangosol.net.CacheFactory
7. Open another command window [window 2] and follow setps 4-6
8. On window1, type “cache MyCache”
9. On window1, type put 1 HelloWorld!
10. On window2, type “cache MyCache”
11. On window2, type get 1
12. It should return HelloWorld!
13. Now read the document at http://coherence.oracle.com/display/COH33UG/Creating+and+Using+Coherence+Caches and follow the section “Setting up your test environment”

OUI version not compatible error

I was trying to install the MLR#8 on BPEL 10.1.3.4 and as a prerequisite, I extracted the latest oPatch in SOA Oracle home but it fails when I apply the patch using opatch command. I also ran Prereq to check the OUI version compatibility but got the error,

Prereq "checkOUIVersionCompatible" failed

The details are: Required version of OUI is not present.The available version is 10.1.0.6.0

Solution:

Under Oracle SOA home:
1. Rename /oui directory to /oui.original

2. Copy the oui directory under the Oracle DB home to Oracle SOA home:
/oui to

3. Run OPatch update again

This issue occurs because the Oracle Universal Installer version in Oracle SOA suite is not updated to the latest one - and is not compatible with the latest OPatch version.

HTH

AIA (2.4) Installation Steps

1. Install Database:

- Oracle 10g:
Install Oracle 10.2.0.3
Install 10.2.0.1
Install patch 10.2.0.3

OR

- Oracle XE

2. Install SOA Suite 10.1.3.1: This is the base software installation of SOA Suite 10g.Every subsequent step will be a patch applied to this base software install. Perform the advanced SOA install

3. Patch SOA Suite – 10.1.3.4
This patch brings the 10.1.3.1 base installation up to version 10.1.3.4.

4. Download Oracle Patch (OPatch) update
This is a patch for the Oracle Patch utility for SOA Suite and must be applied to the SOA Suite home. This is required for MLR #8 listed below.

5. Install Merge Label Request (MLR) #8 Patch number: 8372150: MLR patches are accumulations of bug fixes that have not yet made it into a point release but will be included when such a release is public. One can think of MLRs as a service pack or patch cluster between point releases of the product.

6. Install Oracle Services Registry (Optional for AIA 2.4 installation)
Service registry provides a central place to catalog and categorize all of the services created. The SOA Suite installer does not install the Oracle Service Registry.

7. Install AIA Media Pack Latest version: 2.4

- Product: Oracle Application Integration Architecture
- Pack: Oracle Application Integration Architecture Release 2.4 Media Pack for Microsoft Windows (32-bit)
- Part: V16434-01

Note:

1. Select a new Oracle home for AIA installation

2. Are you using the right version of JDK?.
Each version of Foundation pack is certified with a different version of JDK. Verify the installation guide and metalink notes to check for the most recent version. The last version of Foundation pack was certified on JDK 1.5 update 16

3. Does the DB user have DBA privileges?
The DB user entered during interview screens should have privileges to create a db schema. ‘sys’ user usually has all the required privileges.

4. Is directory browsing enabled on the server?
Check the install guide for information on how to enable directory browsing on your server.

5. Is your ESB working properly?
- Ensure ESB design time and runtime are accessing the following urls.
http://host:port/esb/dtStatus.jsp
http://host:port/esb/rtStatus.jsp
both the pages should return a true.
- Deploy a sample ESB process from ESB Console and execute it to check the results.
- Create a sample ‘system’ from ESB Console.
- Ensure virtual host and port of BPELSystem and DefaultSystem are set appropriately in ESBConsole.

6. Is your BPEL PM working properly?
- Deploy a sample BPEL process and verify the flow eg: LoanFlow demo.
- Verify if you are able to login to BPELConsole and navigate across various pages


Links for troubleshooting:

- Download the latest version of this Installation and Upgrade guide from Metalink Note 809490.1

How to change the JAVA version used to run a specific OC4J instance

1. Using Application Server Control Web Interface

Overview
--------
(a) Ensure the Application Server Control web application is running
and accessible from a browser.
(b) Access the Application Server Control application, drill down to
the configuration pages for the desired OC4J instance and enter
the path of the desired java executable as the "Java Executable"
value under "Command Line Options".
(d) Reload opmn using "opmnctl reload" so that it can pick up the
configuration changes.
(e) Start/Restart the desired OC4J instance with the new java executable
in place.

Detailed Approach
-----------------
(a) Ensure the Application Server Control web application is running
and accessible from a browser.

Identify the correct Application Server Control port (typically 1810).
The port can be determined by inspecting the file:

${ORACLE_HOME}/install/portlist.ini

which contains an entry similar to:

[Ports]
Oracle HTTP Server port = 7777
:
:
Application Server Control port = 1810

Access the appropriate URL for the Application Server Control:

http://yourHost.your.domain:1810/

and login as the ias_admin user with the ias_admin password provided
at installation time.

(b) Using Application Server Control application, drill down to
the configuration pages for the desired OC4J instance and enter
the path of the desired java executable as the "Java Executable"
value under "Command Line Options".

Under the "Home" tab of the main page, identify the desired OC4J
instance in the "System Components" list and click on the hyperlink
assosciated with it's name.

On the OC4J instance page, click on the "Administration" tab and on
the resulting page under the "Instance Properties" section, click on
the "Server Properties" link.

On the next page:

- scroll down to the "Command Line Options" section
- enter the full path to the "java" binary as the value provided
for the "Java Executable" field
- click on the "Apply" button

The validity of the provided path can be confirmed by running the same
path at a command prompt window with a "-version" flag. For example,
assuming "Java Executable" field value of /usr/j2sdk1.4.2_10/bin/java,
run:

% /usr/j2sdk1.4.2_10/bin/java -version

and confirm that this produces output similar to the following:

java version "1.4.2_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode

(d) Reload opmn using "opmnctl reload" so that it can pick up the
configuration changes.

Though Application Server Control will have automatically updated
the centralized copy of the opmn.xml file, it is still necessary togate
restart or reload opmn so that it re-reads it's updated configuration file:

% opmnctl reload
opmnctl: reconfiguring opmn...
opmnctl: opmn reloaded successfully...

(e) Start/Restart the desired OC4J instance with the new java executable
in place.

Finally, it will be necessary to stop any current running instance of the
desired OC4J instance so that opmn can be used to start a new instance
with the modified java executable.

You can navigate back to the top OC4J instance page under Application
Server Control and press the "Start" or "Restart" buttons.


2. Manually applying configuration file changes

Overview
--------
(a) Backup the current OPMN configuration file.
(b) Edit "opmn.xml" and set "java-bin" attribute within the opmn XML entries
for the desired OC4J instance to point to the desired "java" executable.
(c) Propagate the changes in this configuration file to the
configuration repository using "dcmctl updateConfig -ct opmn -v -d".
(d) Reload opmn using "opmnctl reload" so that it can pick up the
configuration changes.

Detailed Approach
-----------------
(a) Backup the current OPMN configuration file.

Make an additional copy of $ORACLE_HOME/opmn/conf/opmn.xml, so
that it can be referenced later or restored to it's original
condition:

% cd $ORACLE_HOME/opmn/conf
% cp opmn.xml opmn.xml.orig

(b) Edit "opmn.xml" file and locate the start of the XML entries
relating to the desired OC4J instance, for example:

<process-type id="myOc4J" module-id="OC4J">
<module-data>
<category id="start-parameters">

Check if the child elements for the "start-parameters" tag
contains a "java-bin" entry as shown below:

<category id="start-parameters">
<data id="java-options" value="-server -Djava.security.policy=
/as9/app/oracle/product/mid90420a/j2ee/myOc4j/config/java2.policy
-Djava.awt.headless=true"/>
<data id="oc4j-options" value="-properties"/>
<data id="java-bin" value="/path/to/java_home/bin/java"/>
</category>

If a java-bin entry does not exist, create one after the "oc4j-options"
entry as shown above.

Ensure that the "value" attribute is an absolute path to a "java" exutable
located in the "bin" sub-directory of a java installation. Confirm that
the value is appropriate by executing that path using the "-version"
argument.

For example, for a J2SDK installed at the location:

/usr/j2sdk1.4.2_10

The XML entries would look similar to the following:

<category id="start-parameters">
<data id="java-options" value="....."/>
<data id="oc4j-options" value="......"/>
<data id="java-bin" value="/usr/j2sdk1.4.2_10/bin/java"/>
</category>

Confirm the validity of value provided as the "java-bin" by executing
at the command prompt:

% /usr/j2sdk1.4.2_10/bin/java -version
java version "1.4.2_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)

(c) For Application Server 9.0.4.x and 10.1.2.x versions only, propagate
the changes in this configuration file to the configuration repository
using "dcmctl updateConfig -ct opmn -v -d"

After making any manual change to a configuration file it is
necessary to run an appropriate "dcmctl updateConfig" command to
propagate the change to the configuration repository.

In this case where changes have only been made to "opmn.xml", these
can be propagated by running:

% dcmctl updateConfig -ct opmn -v -d

(d) Reload opmn using "opmnctl reload" so that it can pick up the
configuration changes

If the OPMN process is not running, the configuration changes will
take effect the next time opmn is started using:

% opmnctl start
opmnctl: opmn started

If opmn is already running, reload it using the following command,
which will force it to reload it's configuration file:

% opmnctl reload
opmnctl: reconfiguring opmn...
opmnctl: opmn reloaded successfully...

(e) Start/Restart the desired OC4J instance with the new java executable
in place.

Finally, it will be necessary to stop any current running instance of the
desired OC4J instance so that opmn can be used to start a new instance
with the modified java executable.

From the command line, use the following "opmnctl" commands which
illustrate how to stop/start an OC4J instance named "myOC4J":

% opmnctl stopproc process-type=myOC4J
% opmnctl startproc process-type=myOC4J

Oracle Bpel Process Manager 10.1.3.4 - New Features

The latest release of SOA Suite and BPA Suite 10.1.3.4 has been released for a while now, so you're probably wondering, what's in it for us ...

Well let's have a look at the new features in Oracle Bpel Process Manager 10.1.3.4:

- Ability to represent real load, to represent the engine behaviour and to know what's actually going on. Go to the administration-tab in your bpel control and drill down into pools to have message details => a dynamic page for threading, updated in real-time

- Statistics are now displayed on process map level and aggregated per process instance => Go to the Analytics-tab in Bpel Control Page
- To miminize XML Coding errors you now have the 'Validate XML'-tab in your BPEL Console

- What about those lost instances, you've instantiated a process but you can't find the instance anymore => Audit trail persistence is moved to a separate thread which will prevent losing all data for a given thread when rollback occurs

- You want to open up a Service Request for an issue you're running into, but you need all diagnostics to be able to log the problem properly => Go to the 'diagnostics'-tab in your BPEL Console to collect support information

- When you've defined your Bpel process and your going through release-management you had to manually update wsdl's, configuration files, etc. to be able to point to the different environments (development, test, qa, production, etc.) => using a deployment plan you can now deploy your bpel process to any environment without the hastle of manually having to change your process parameters => Take a BPEL Suitcase and go to the deployment plan, in this manner you will define a deployment plan for each environment.

Those are big improvements for as well developers, as administrators and especially for troubleshooting.

Uninstalling Oracle Service Registry (OSR) 10.1.3

1. Go to J2EE container and un-deploy the registry application.
2. Stop the J2EE container
3. Login to registry database as sysdba and perform the following,
- Drop the UDDIUSER:
"drop user uddiuser cascade;"
- Delete the UDDINODE tablespace:
"drop tablespace uddinode including contents and datafiles;"
4. Delete the registry installation directory and registry application directory from the deployed application folder on J2EE home
5. In Windows, delete the registry entries/folder with the name "Oracle Service Registry 10.3" and restart the machine
6. Restart the J2EE application container

Why BPEL process instances may appear on the Manual Recovery List

Messages appearing on the Recovery Console happen for a number of reasons, namely;

BPEL has a Delivery Service that intercepts the incoming messages. Once it intercepts an incoming message, the delivery service does two things: 1) Put a very short JMS message to the in-memory queue . The small JMS message will trigger work further downstream of the process. 2) Save the BPEL message to tables at the dehydration store.

In the same thread the BPEL engine instantiate or continue the BPEL instance. By the time the engine finishes processing this message (i.e. hits the end of the process, or hits the first dehydration point) the engine will update the message tables to mark the message as "HANDLED".

The Recovery page shows those invoke or callback messages that are NOT in the HANDLED state. If you click fast enough, you will see messages come and go on the Recovery page. So seeing messages at the Recovery page does not necessarily mean there are problems, unless ...

Unless they stay there permanently. They stay there permanently because there are no more JMS messages to trigger the WorkerBean to process those un-handled BPEL messages in invoke_message or dlv_message tables. Derived from this, these are the scenarios that could cause the BPEL messages stay at UNRESOLVED states:

* The server shuts down or crash before it finish processing the BPEL message. When the server re-started again, the in-memory JMS message associated with the invoke or call back message is already is already gone.
* The engine could not finish processing the message before reaching the time-out as dictated by the transaction-time out specified in the server.xml. In such case it rolls back the message to the message table. But the JMS message associated with the invoke messages are already consumed.

In these cases, no more events (i.e. JMS messages) to trigger the engine to process the BPEL messages in invoke_message or dlv_message tables. Therefore a manual recovery is performed.

Hosting Schema, WSDL or any file on OC4J, Apache or Oracle ESB

1. Search for in the file $ORACLE_HOME\Apache\Apache\conf\httpd.conf and add the entry under other Alias entries,

Alias /xsd/ "$XSD_DIR/"

2. Restart Apache Server

3. Start Referencing the XSD as below,

http://hostname:port/xsd/$xsdfilename

Steps to Create WebDav Rules Repository

1. Create new WebDav repository:
   
   • Add following entry in /Apache/oradav/conf/moddav.conf
     <Location /dav_rules>DAV on</Location>
   • Create directory called dav_rules under /Apache/Apache/htdocs directory
     
   • Restart the Apache server and that’s all required for configuring custom repository.
     
2. Now login to ruleauthor web application
   
3. Click on "Repository" icon
   
4. Select "WebDAV" from "Repository Type" drop down menu
   
5. Provide URL as http://soa_host:soa_port/dav_rules and click connect
   
6. You should be seeing a confirmation box about the successful connection. If not please try browsing that URL and see if you are able to access it or not. Also if you have setup security on that, please provide username and password to connect.
   
7. Not you can create new WebDAV connection in JDeveloper by going to "connection tab" and right click on "WebDAV Server" icon and select "New WebDAV connection"
   
8. Provide URL you used in step 8 here and username and password if required.
   
9. Click on "Test Connection" button to see if it’s successful.

How to change your Eclipse JVM

As an example, I will update the Eclipse JVM to use JRockit:

edit %ECLIPSE_HOME%/eclipse.ini

Add the following:
-vm %BEA_HOME%\jrockit90_150_04\jre\bin\javaw.exe

Make sure you replace the %BEA_HOME% with an actual valid path such as "C:\BEA\" then restart.

Change your default JVM for workspace to the new JVM:

Once you bring up Eclipse goto – Windows -> Preferences -> Java -> Installed JRE and then on the UI that pops up choose - and add a new JRE and point to the following directory below "%BEA_HOME%\jrockit90_150_04\jre".

After adding the JRE, make it the default JRE for all projects, exit and restart and you're done.

Also make sure that the %PATH% has "C:\YOURBEAHOME\jrockit90_150_04\jre\bin;" reference before it refrences any other JDK.

And your JAVA_HOME is pointing to "C:\YOURBEAHOME\jrockit90_150_04\jre"

Scheduling Polling Frequency for Adapters in Oracle ESB

File Adapter will collect the files from specified folder at the polling frequency time parameter, such as every 1 second or 1 min. What about specified time, every 6pm or every morning? How?? The solution is to use the Quartz in conbination with Oracle ESB Client APIs.

Using the client APIs you can the status to enabled/disabled at the specified time.

Oracle ESB API can also be invoked via HTTP protocol. You can try this http://server:port/esbConfiguration/executeCommand?action=ExploreServices.

This URL will return an XML metadata where you can explore the services in ESB,
such as guid and status.

And this is how we create quartz to work with OC4J
http://radio.weblogs.com/0135826/2004/04/02.html

This is the example of how we communicate with Oracle ESB API Client

JAVA CODE

ConsoleClient client = ConsoleClientFactory.getConsoleClient(HOST, PORT, USER_NAME,PASSWORD);
client.perform(”UpdateServiceStatus”, requestProps);