Wednesday, September 28, 2011

WebCache 11g. Name based balance


We used to use WebCache as load balancer for SOA 10/11g cluster from the first prototypes. I have to notice that it's the only one component that has no issues for ages.

SoŠ± for some reasons we should to reconfigure OiD/OIDDAS server and change the access url for sso and oiddas services. I decided to configure WebCache as a proxy to pass user's request to identity server and vice versa. I've created additional server definitions for ports 80 and 443. Network admins, changed for us DNS and allowed Webcache access identity system by application ports (they are defaults 7777 and 4443).
Site definitions
Then, I've created site to server mappings, and voila, the system is ready to manage requests soa11 for a cluster and ldap for user management.  After a while, SOA applications admin noticed me that they couldn't see some services, so the process couldn't receive callbacks. 
The results of the short investigation  was - If some process calls web service by the server name for example - http://soa11.telecom/osb/someService  - it works fine, if it uses IP address it fails.

Gosh, when they start using names instead of addresses! By the way, I have to manage this situation; because even developers immediately redeploy the new versions, there are still be callback messages with direct IP.

So the problem is on the top, before reconfiguration, WebCache sent any request with any name to only one destination (actually balance to the two HTTP servers) and now it has to decide who will be receiver for the message. The solution is quite easy; I’ve added aliases to the SOA site definitions, so the final site definitions table is
Final Site definitions table
In the last column you can see couple aliases for the site definition. Apply configuration, restart WebCache and now it definitely works.


Wednesday, September 21, 2011

OSB 11g - Siebel communication

Introduction

For a last five years I'm involved in a huge SOA project in a telco company.
So there were a quite interesting case.

We are migrating some helper processes from BPEL 10g to OSB 11g.
The main purpose for these utilities to mediate between Siebel services and BPEL process and composites.

So during process migration and tests we've got Business Service exception :
Error Code: 10944629 Error Message: Error: Missing body length in response to SWE request!
Metalink has a note ID 1301243.1the main idea of this document that SOAP message is sending to the Siebel service with  parameter Transfer-Encoding: chunked, so you should change the way of message delivery.

Solution
Oracle Service Bus  has a wide range of parameters, and you able to control almost any aspect of communication between business service and service provider. To do it, i just remove mark in Advanced section of HTTP Transport configuration.
Nothing interesting in there, but there are findings, that could be useful for you, my guests. I had to be sure, that we are the source of the issues, and fully realize that.

Utility
The OSB 11g Cluster runs on two OEL 64bit boxes, on the customer site and I don't want to install JDeveloper or any other IDE only for SOAP over HTTP check.
The second point is that I don't want to harvest TCP/IP messages in a log files.
Googling for tcp tunnel for Linux points me to Apache's utility TcpTunnelGui
Gotcha !! Another small investigation and I know where to find it on my server, and on your's too. I've found classes org.apache.soap.util.net.TcpTunnel & org.apache.soap.util.net.TcpTunnelGui in the library $FMW_HOME/osb/harvester/soap-2.2.jar


Proof

1. Create a clones of original proxy and business services
2. Point the Business Service to host with Apache's utility and one of free ports. Let's assume it as 8080.
3. Modify proxy clone, to route on the new business serivce.
4. Run the tunneler :
    $ . $DOMAIN_HOME/bin/setDomainEnv.sh
   $ java -classpath $FMW_HOME/osb/harvester/lib/soap-2.2.jar  org.apache.soap.util.net.TcpTunnelGui 8080 10.6.4.26 80

To run tunneler we should pass three parameters
- port to listen (8080)
- origin host (10.6.4.26)
- origin port (80)
5. Test cloned service.

We easily can see the transport information and SOAP messages.

Regards,