After installing the Tibco SAP R3 Adapter, you might get an exception as follows if you’re using the Unicode version of the adapter;

ADR3_Unicode_Error

The reason for this is as the error message suggests using non-Unicode palette. The trick is in modifying the designer.tra as follows to enable usage of the Unicode palette.

First of all ensure you’re using the correct version of the adapter by checking it via adr3u.exe --version command.

Following this edit the properties as follows:


tibco.env.CUSTOM_CP_EXT
C:/tibco/adapter/adr3/version_number/lib/palettesu

tibco.env.CUSTOM_PALETTE_PATH
C:/tibco/adapter/adr3/version_number/lib/palettesu

tibco.env.CUSTOM_LIB_PATH
C:/tibco/adapter/adr3/version_number/lib/palettesu

This example assumes c:/tibco as installation directory. Also, you must ensure that these entries precede all entries.



I have recently experienced a problem where the asynchronous invocation in a BPEL instance was waiting indefinitely for a reply – even though the response was apparently returned!! In my case, we have a BPEL process which invokes a Mediator in an asynch fashion. The mediator makes a synch call to a backend. Apparently it is possible under such a setup (asynch to synch mediation) that the returned response is not correlated. One can see symptoms in the log files as;


[2012-09-18T15:14:09.618+02:00] [SOANode1] [WARNING] [] [oracle.soa.mediator.service] [tid: Workmanager: , Version: 0, Scheduled=false, Started=false, Wait time: 0 ms\n] [userId: <anonymous>] [ecid: f4fb487b2ff4258e:-740461df:139d51913e7:-8000-000000000014529d,1:24039] [APP: soa-infra] [composite_name: ServiceBroker] [component_name: TaskRouter][component_instance_id: B49DF541019211E2BFE1EF3BDA6AAB34] [composite_instance_id: 2670199] No callback info for instance id :B49DF541019211E2BFE1EF3BDA6AAB34
[2012-09-18T15:14:09.618+02:00] [SOANode1] [WARNING] [] [oracle.soa.mediator.service] [tid: Workmanager: , Version: 0, Scheduled=false, Started=false, Wait time: 0 ms\n] [userId: <anonymous>] [ecid: f4fb487b2ff4258e:-740461df:139d51913e7:-8000-000000000014529d,1:24039] [APP: soa-infra] [composite_name: ServiceBroker] [component_name: TaskRouter][component_instance_id: B49DF541019211E2BFE1EF3BDA6AAB34] [composite_instance_id: 2670199] No callback instance found. So no one to send the callback dropping it.

DISCLAIMER: Everything you will read below is my deduction of how things work. I haven’t been able to find any documentation on this so please let me know your experience, an official document with explanation, etc. if you have it.

The way asynch calls work with Mediator is, whenever an asynch call is received a row is inserted into the MEDIATOR_CALLBACK table. When the response is ready to be returned, this inserted row is selected using the instance id. On the other hand, everything is done in a transaction so no use in looking for the row in the table until the response is returned, after which the transaction is committed. Somehow, SOA Suite can’t seem to find this inserted row resulting in the log statements above.

But this is not all to the story. It appears, how the rule is executed -sequential vs parallel- is also important. When the rule is parallel, SOA Suite seems to insert  a row into the MEDIATOR_DEFERRED_MESSAGE table and commits the transaction. Therefore, the row is already there before the response is returned if you look for it. Next another thread that monitors this table picks it up and executed the call in a new transaction.

When such a mediation is happening (asynch to synch), it seems it is better to  use the parallel execution. This does have other implications, but works better.

Note: After some more research I came across an Oracle documentation (20.2.2.4 How to Configure Response Messages) stating the same. Unfortunately, There is no reasoning behind it.

“Typically, the caller receives the callback after waiting for 100 milliseconds. However, if you have a bridge Oracle Mediator with a sequential routing rule and a connection to a synchronous interface service, then due to the complex flow of the program with all sequential routing rules, the caller may take longer to get ready to receive the callback. You can work around this issue by changing the routing rule of the bridge Oracle Mediator to parallel.”

Environment: Oracle SOA Suite 11g, 11.1.1.6 on Red Hat Enterprise Linux Server release 5.8



I haven’t found a resource explaining this in a straight forward manner, so adding it here.

If you are using MDS (which you should) for managing your artifacts, you need it available in your project. To make it available, you need to configure the adf-config.xml file in Application Resources. MDS can be based on files or DB. In order to make a DB based MDS available to your project, add the following element under <metadata-store-usages>;

<metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property value="<username>" name="jdbc-userid"/>
<property value="<password>" name="jdbc-password"/>
<property value="<JDBC_URL>" name="jdbc-url"/>
<property value="<partition_name>" name="partition-name"/>
</metadata-store>
</metadata-store-usage>



Just came across this today. In version 11.1.1.5 of JDeveloper, the WSDL generated for the Rules service has a typo in it. It usually manifests itself with the error;


Error: Load of wsdl "ExpiryDelayRules_ExpiryDelayRulesDecisionService.wsdl with Message part element undefined in wsdl [file:/FILENAME] part name = payload type = {http://xmlns.oracle.com/ExpiryDelayRules/ExpiryDelayRules_ExpiryDelayRulesDecisionService}callFunctionStateful" failed

The error is cryptic at best but the solution is easy. For some reason the schema import statement in the WSDL is prepended with “ice/”

Seems like a rookie mistake.



In Oracle Business Rules, when a decision function is about to return, it will look for a fact in the working memory whose type matches the type defined as the output of the decision function. If it finds multiple facts that match the type, it will throw an exception such as;

RLRuntimeException: The RL function getFactByType found more than one instance of the fact type, com.hospital.stmatthews.canonical.appointmentrequest.TypeOfAppointmentType.
at line 17 column 19 /Ruleset(com.stmatthews.rules.appointment.DeriveAppointmentType)/Function(DeriveAppointmentType_DecisionService_1)/Action[6]
at line 17 column 3 /Ruleset(com.stmatthews.rules.appointment.DeriveAppointmentType)/Function(DeriveAppointmentType_DecisionService_1)/Action[6]
at line 25 column 34 /Ruleset(com.stmatthews.rules.appointment.DeriveAppointmentType)/Function(Test_DeriveAppointmentType_DecisionFunction)/Action/Variable(v1_List)[5]
at line 25 column 129 /Ruleset(com.stmatthews.rules.appointment.DeriveAppointmentType)/Function(Test_DeriveAppointmentType_DecisionFunction)/Action/Variable(v1_List)[5]

There are two ways two solve this issue:

  1. Make sure when the decision function is about to return, there is only a single instance of the type in the working memory
  2. Turn the decision function output type into a list

If you are sure that there must be a single instance of the type in working memory, review your rules again. Especially if you are modifying a fact to make sure that a certain rule would not be fired, you might be wrong. Remember that Oracle does not give any strict guarantees regarding the firing order of the rules.  Therefore, it is quite possible that the modifying rule is actually fired after the rule which you do not expect to be fired. For example let’s look at a scenario where we modify a fact to accomplish a default rule.

Image

In this ruleset, in the first two rules we modify the AppointmentCodeType fact to make sure that the last rule is not fired. On the other hand, it is possible that the last rule is fired before the first two. In this case, we end up with two TypeOfAppointmentType facts in the working memory!!

In order to resolve this, you can modify the priority of the first two rules to make sure they are always fired before the first rule.

p.s. Example taken from Oracle SOA Suite 11g Handbook by Lucas Jellema

p.s.2. This error is catalogued by

RUL-00102: The RL function getFactByType found more than one instance of the fact type, {5}. {0} {1,choice,0#|0<at line {1,number,integer}} {2,choice,0#|0< column {2,number,integer}} {1,choice,0#|0< } {3,choice,0#|0<in {4}}

In the Oracle Fusion Middleware Error Messages Reference 11g Release 1 (11.1.1.6.0) documentation

Environment: Oracle SOA Suite 11g (11.1.1.5), JDeveloper 11.1.1.6 on Win 7



I ran into this problem when I changed definition of some Types in the Oracle DB. It seems Weblogic caches the statements at Data Source level. The documentation advises to set Statement Cache Size to 0 by modifiying Weblogic Server properties (See the link below).

http://docs.oracle.com/cd/E15523_01/doc.1111/e14770/adapter_tech.htm

I believe this is a bit misguiding, since this means forgoing the performance benefits of caching. It can be done on a DEV server but IMHO should not be done on PROD. Best option would be to reset the DataSource. You can reset the data source by going to;

Services/Data Sources/<DataSourceName>/Control

and choosing the deployed instance you want to reset. After that you can choose to Clear Statement Cache or Reset. Both should work.

Environment: Oracle SOA Suite 11g, JDeveloper 11g 11.1.1.6, Windows 7

Edit: Edwin Biemond has published a great article to do this via scripting. Thus, this can be added to deployment scripts.



I had spent some time on this issue this morning. It seems whenever the XSD for the target changes (even if it validates fine and tests fine) one needs to regenerate the XSL file with a new name. Some people have suggested on forums to switch from XSLT 1.0 to XSLT 2.0 which is not really a solution. On the other hand it gave me an idea;

1. The error contains the following line: XML-22036: (Error) Cannot convert result tree fragment to NodeSet.

2. XSLT 2.0 does not have RTFs (Result Tree Fragment) – when you declare a variable or param, it is a true NodeSet.

I had in my XSLT a parameter for the response variable from an early routing (initial.body). For some reason (possibly a bug) when  the target XSD changes, it seems this parameter is not (correctly) populated anymore. Therefore, when node-set() is invoked, it throws an exception.

Like I said earlier, regenerating the XSLT with a new name, seems to fix it.

Environment: Oracle SOA Suite 11g, JDeveloper 11g 11.1.1.6, Windows 7