Tips for Installing Oracle BPM Suite 11g FP4

Edited on October 20, 2011 regarding the location of OPatch (due to progressive insight, and some comments).

When installing Oracle BPM Suite 11g FP4 I ran into a couple of things, of which I thought I better write that down for some next time. If you are a SOA Suite install crack, don't bother to read on, as I probably have nothing new to tell you. In case you are new to it or do installations only occasionally, you might find this saving you considerable time. It would have done so in my case.

You typically install the SOA/BPM Suite on top of WebLogic. The MW_HOME is the (middleware) folder containing the wlserver_10.3 folder (among others). The Common Oracle Home will be [MW_HOME]\oracle_common, while the SOA_ORACLE_HOME will be [MW_HOME]\Oracle_SOA1. In the readme for the PS4 installation ORACLE_HOME refers to both, so read the instructions carefully.

The first instruction is to make sure you have the latest OPatch. When you download it, you will find that the instructions of OPatch itself say you can find OPatch in ORACLE_HOME. There actually is one in both ORACLE_HOMES. Probably the same one, I did not bother to find out and copied the download OPatch to both folders.

The instructions are particularly written for Unix, so needs some "translation" to make it applicable for Windows:

• Where it reads "$ORACLE_HOME" you should replace that by "%ORACLE_HOME%" (duh!)
• To patch the Oracle Common Home it tells you to use the following command:
  
  $ORACLE_HOME/OPatch/opatch napply -invPtrLoc $ORACLE_HOME/oraInst.loc
  
  It took me some time to find out that the invPtrLoc only applies to Unix only, and that for Windows you can simply leave it out. On Windows the inventory information is located in the registry instead of the oraInst.loc file. So the command for Windows is simply:
  
  %ORACLE_HOME%\OPatch\opatch napply
  

PSA stands for Patch Set Assistant. I skipped the backup of the database, because as a developer I can simply recreate the SOA INFRA any time without loosing any valuable information.

The instructions will tell you to run PSA from the ORACLE_HOME\bin folder. Now that's a bit confusing as there is a psa.bat in the bin folder of both ORACLE_HOME's. But if you read the PSA instructions carefully, you will find it refers to SOA_ORACLE_HOME ([MW_HOME]\Oracle_SOA1. An educated guess already made me already think so.

If you are using OTN you may not be referred to the proper post-installation guide. The one it currently points to, is the post-installation steps for Oracle SOA Suite for Healthcare Integration. If you need that do that first, but then you still have to do the BPM post-installation instructions.

BTW, this guide discusses the commands for Unix as well as Windows, and specifically uses SOA_ORACLE_HOME. But that's for weenies, and not us developers, as we like finding out the hard way, right?

While I'm at it I might as well past the command I used for updating the policy store, as it may just fit your environment as well:

wlst.cmd %soa_oracle_home%\bin\bpm-ps4fp-upgrade.py --username weblogic --password welcome1 --wlsHost localhost --adminServerListenPort 7001

The post-installation instructions tell you to delete the DOMAIN_HOME\servers\...\tmp. Many of us developer probably choose to deploy the SOA Suite on the Admin Server, so the only servers\tmp folder you then have is DOMAIN_HOME\servers\...\AdminServer\tmp. According to the documentation about domain configuration files, you can simply delete the contents of that folder, so that is what I did. Have some patience, as that folder contains GB's of files.

If you followed my example, the next post-installation instruction may make you start cursing, as it will tell you to copy some library into a sub-folder of the tmp you just deleted. I, on the contrary, kept my usual cool, and just started the server. I still kept my cool when looking at several exceptions, not recalling if those were new, of whether I've seen those before. So I bounced the server and found that the exceptions disappeared. Also the WebLogic Console and the Enterprise Manager appear to function normally (pfew!).

I stopped the server, and continued with task 3, regarding copying the jar file adflibSOAMgmt.jar. And bounced the server again.

Finally, the readme on OTN mentions that you should have a soa-jdev-extension.zip. The one I have also mentions a bpm-jdev-extension.zip. Both instructions do not mentions to actually install them. I did both in the usual way (JDeveloper -> Help -> etc.).

That's when I was ready.

Oracle BPM FP4 Is Out!

Finally, it's there, the long awaited Feature Pack 4 for the Oracle Business Process Modeling Suite.

Instructions for Customers to get this are as follows:

1. This is available as a patch under the following bug id: Patch 12413651: SOA PS4 BPM FEATURES PACK


2. The patch is password protected and is available to those BPM customers that request it from support by filing an SR


3. It is intended for use by BPM customers only. SOA Suite customers should check with Support and Product Management before requesting it.

Information on PS4FP will be blogged at http://blogs.oracle.com/bpm soon.

Documentation is available at http://www.oracle.com/technetwork/middleware/soasuite/documentation/11gr1ps4featurepackdoc-462677.html

OBPM 11g: Showing More Detailed Log Info

One of those too stupid to be discussed items is how you can make the SOA Suite show detailed information about the payload for activities like a script activities, or what is going on inside a business rule. After all, every SOA/BPM developer is assumed to know how to set log levels, right?

Well every developer is also assumed to know what they say about assumptions, and how frustrating it is to loose valuable time on finding out how to do simple things. So bare with me while I state the obvious.

Showing Detailed Payload Information

When the audit level is set to Production (which seems to be the default), only data associations for asynchronous activities are logged. You can see which level you are using, e.g. in the Audit Trail page, as shown below.



Because I have set the log level to Development, I do not only see detailed information about the payload that left the Handle Time-out sub-process, but also of the instance system fault.

This log level can be set in the Enterprise manager, but (as the pop-up with the information indicates) not in the Log Configuration, but in the SOA Infrastructure Common Properties. You can find it as shown below.





Show What's Going on in Business Rules

Another one of those "too obvious" things is showing detailed information about what is going on inside a business rule.

When you ask you always get an answer like: "You can turn on debug tracing in the Rules SE by setting the log level for oracle.soa.services.rules to TRACE:32 to get more detailed logging of what is happening." Absolutely a valid answer, but when you have not had to much exposure to setting log levels, this can take you some time to find out how to do.

This is done by changing the Log Configuration, as follows: