SOA Suite Olite

There are times that you may need to connect to the database that is used by Oracle SOA Suite to perform post-patch processing.  I have included the following as a reminder of how to connect to the associated Olite database.

Mobile SQL Client ($ORACLE_HOME\Mobile\Sdk\BIN\msql.exe) is used to connect to an Olite database. The version distributed with SOA Suite is 10.2.0.2. Here is a typical connection string:

msql system/manager@jdbc:polite:

For the SOA Suite there are three databases: orabpel, oraesb, orawsm. Connecting to the schema that is used by the Oracle BPEL Process Manager is:

  msql system/manager@jdbc:polite:orabpel

Additional:  One thing to keep in mind is that the oraesb password is "any" as opposed to "manager".

ASO_QUOTE_PUB.Update_Quote API Error

I have been writing code to utilize the Oracle Quoting API.  While I've run into a number of little road blocks or could I say potholes, I have been able to quickly figure out the problem and continue.  But I came across a problem that vexed me.  When I executed the update_quote call, I would always get the error "Record has been updated".  I tried a lot of variations and did a lot of searching on OTN and Metalink until I came across this the comment below on Metalink.  When you are executing the update_quote, you need to pass the last_update_date along with the quote_header_id or you will always get the error.

Error running the ASO_QUOTE_PUB.Update_Quote API

Problem:	Receiving the following error running the ASO_QUOTE_PUB.Update_Quote API. Record has been updated. Please requery to see change. (INFO=quote)
Cause:	Error message ASO_API_RECORD_CHANGED is returned If (l_last_update_date <> p_qte_header_rec.last_update_date)
Solution:	Whenever making a call to update quote, query the last_update_date from the database and pass it to p_qte_header_rec. Update quote will throw this warning if p_qte_header_rec.last_update_date doesn't match the last update date in the database.

Transaction Timeout - ** The secret File **

Well, let me just say that I've spent a lot of time researching the topic of transaction timeout's.  I currently have a BPEL process that calls a database procedure which runs for about four minutes.  I have been having all kinds of trouble with this process because the server transaction time's out after about 60 seconds.  If you do any searches on OTN or Metalink you will discover that the two important areas to adjust are the JTA transaction-timeout parameter and the syncMaxWaitTime parameter.  I had made these changes, but was still having all kinds of problems with timeout.  I ended up creating a pl/sql script to see exactly how long a db operation can last before the transaction would timeout.  Here is the code for the procedure:

create or replace procedure wbr_sleep (p_time IN number) as
begin
dbms_lock.sleep(p_time);
end;
/

I finally have come across the solution to this transaction timeout problem. First of all, here is the link to the documentation:

Oracle BPEL Troubleshooting Guide

Here is the file I was missing:

<your SOA_Oracle_Home>\j2ee\<your oc4j instance name>\application-deployments\orabpel\ejb_ob_engine\orion-ejb-jar.xml

In this file you will find a number of transaction-timeout attributes. The values assigned to these attributes should be greater than your syncMaxWaitTime but less than the value of your JTA transaction-timeout value.  Once I made this change, I have been able to execute long running db calls.  Here is what my environment settings are currently:

   1: JTA Transaction timeout = 7200

   2: orion-ejb-jar.xml (all timeout parameters) = 3600

   3: syncMaxWaitTime = 330

Variable Reuse Temptation

When you have a partner link that gets executed multiple times throughout your BPEL process, there is a temptation to invoke that service with the same input and output variables that you used before.  While this can work, you should be aware of some of the pitfalls in doing this:

1. If you don't explicitly set each input parameter each time you execute the partner link, you will be using a value from the last time that values where copied to the variable.
2. If you are executing the same partner link in a parallel branch, do not use the same input and output variables.  You WILL have a conflict.
3. If you reuse input and output variables, it makes it a little more challenging to determine assignment problem throughout your process.
4. One advantage of reusing an input and output variable is that in a large BPEL process reuse produces less assignment clutter.  You can generically name the variable and use it throughout your process.
5. If your assign is copying namespace info, you can end up having exceptions due to different or unrecognized ns assignments.

So to wrap this up.  As a general rule, when you are reusing a partner link.  Always create a new set of input and output variables for each invocation.  This will spare you a lot of debugging problems down the road.

If you have any additional advantages or disadvantages about variable reuse, please comment.

Animator vs. Animation

Animator vs. Animation by *alanbecker on deviantART

 

How to longer the BPEL waiting timeout ...

I've been having timeout issues with a long running database call.  I have been doing research on how to increase these timeout limits.  I came across a post on the BPEL Forum in which Peter Hanusiak gave some good advice on not only looking at the syncMaxWaitTime but also checking the OC4J JTA timeout.

Just setting syncMaxWaitTime may not solve the timeout. It is internal parameter of BPEL. But BPEL engine uses OC4J JTA, so if your JTA timeout is less than syncMaxWaitTime it will not work as you expect and the whole execution will be rollbacked by OC4J. You have to change in server.xml for OC4J transaction timeout in way that syncMaxWaitTime < OC4J JTA timeout

How to longer the BPEL waiting timeout ...

Future of Oracle Forms and Reports?

If you are interested in knowing what the future holds for Oracle Forms and Reports, ToolsSOD.pdf (application/pdf Object) is a must read.  According to this document, while J2EE is the preferred method of future development, Oracle Forms and Oracle Reports are not going away in the foreseeable future. 

Oracle JDeveloper 10g with ADF is the tool of choice for Forms, Reports and Designer customers because it carries over a similar development model.  However, given the architecture difference between J2EE and Forms or Reports, Oracle has no plans to offer a complete migration solution that would attempt to migrate applications built with these tools to J2EE.

(HT: iAdvice)