Oracle Service Bus, testing proxy services with Direct Calls

Today i stumbled on one of the features which is available on the testconsole page of a proxyservice.
I was testing some flows in the Oracle Service Bus which made use of a XAConnectionFactory.
The process made use of a proxyservice which gets a message out of a jmsqueue, routes it to an other businessservice, which eventually would put it back on some other queue.

When the process was getting triggered by some other eai component which puts a message in the queue the process would eventually fail.
But when i would try to replicate the problem and test the process from the beginning by using the testconsole on the proxyservice, the process would just complete without errors.

After a close look on the testconsole we see some extra options in the test configuration
testconsole

Direct Call and Include Tracing.

Direct Call

When we dive into the guides we will find the next information.

“Testing proxy services with the direct call option enabled bypasses some important security steps (authentication/authorization), including access control. Oracle recommends that you not use the test service in production systems.

A direct call is used to test a proxy service that is collocated in the Oracle Service Bus domain. Using the direct call option, messages are sent directly to the proxy service, bypassing the transport layer. When you employ the direct call option, tracing is turned on by default, allowing you to diagnose and troubleshoot a message flow in the test console. By default, testing of proxy services is done using the direct call option.

When you use the direct call option to test a proxy service, the configuration data you input to the test console must be that which is expected by the proxy service from the client that invokes it. In other words, the test console plays the role of the client invoking the proxy service. Also, when you do direct call testing, you bypass the monitoring framework for the message. “

directcall

This illustrates a direct call. Note that the message bypasses the transport layer it is delivered directly to the proxy service (P1).

In my case i was testing a proxyservice which made use of jms transport and xaconnectionfactories.
The direct call would skip the transport layer and would not force the xa transaction.
This XA transaction was eventually the problem for my situation. One of the contributers on the xa transaction (custom oracle aq adapter) was for some reason messing up the transaction.
Since i don’t want to change anything on this adapter, i just skip the enforcing of the xa on this message flow.

So be sure when testing the flow and you really want to replicate the original situation (so use the original designed transport mechanismes), to put off the ‘Direct Call’ option.

Resources

http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/transportsdk/developing.html (Co-Located Calls)
http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/testing.html (Testing Proxy Services)
Thread: OSB 10gR3: Handling response received from a proxy service

Original blog

Share this Post:
Digg Google Bookmarks reddit Mixx StumbleUpon Technorati Yahoo! Buzz DesignFloat Delicious BlinkList Furl

Leave a Reply:

Name (required):
Mail (will not be published) (required):
Website:
Comment (required):
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>