This content has been marked as final. Show 6 replies
You can do as you say, but you will still need to make modifications on the Tuxedo system unless you already have the domain gateway on the Tuxedo system configured and configured to allow access from the WLS system. If not, then changes will need to be made in the configuration of the Tuxedo system. If you are going to make changes to the external system, SALT may be a better option as it performs better and you have one less system in the middle.
In any case, load balancing can be performed between WLS/WTC and Tuxedo. In fact your solution is essentially what we told customers to do before we developed SALT. Transactionality shouldn't be a problem either as both WLS web services and WTC support distributed transactions, so as long as Siebel can support WS-AtomicTransaction, you should be good there as well.
Oracle Tuxedo Chief Architect
Thanks Todd for quick reply on this.
For sample tuxedo service we used following configurations so that tuxedo service understands web service domain.
TDOM1 NWADDR="//<ip address of tuxedo machine>:1234"
TDOM2 NWADDR="//<ip address of web service machine>:7001"
I understand that external interface will need to make configuration changes as the requests are coming from different machine and domain. Apart from domain changes are there any other configuration changes required.
We will not be able to make any changes in their system as it is handled by different group. We can although request few changes but no architectural change will be accepted.
Edited by: NeelimaK on Jul 5, 2012 1:59 AM
Hi Neelima,1 person found this helpful
Yes, you will need to have them modify their domain configuration to allow your external system access. Typically this just means adding a new remote domain definition, a new TDOMAIN definition, and if they are concerned about what services you access then services defined in the export section.
Oracle Tuxedo Chief Architect
Thanks for your inputs earlier. It helped us to finalize the design.
Now while we are actually working on one of the module we are facing below issue:
On Tuxedo end
084341.rnmdev1!GWTDOMAIN.8389.1.0: ERROR: msgsnd err:(LIBTUX_CAT:669: ERROR: Message operation failed because of the invalid
message queue identifier) errno=22,qid=32223,buf=413984,bytes=297,flag=2048
084341.rnmdev1!GWTDOMAIN.8389.1.0: LIBGW_CAT:1030: ERROR: Reply message not sent due to gateway error 402006
on weblogic side we are getting this value
[Tue 10/16] Amit(6:44:30 PM): The iterator value came as :: fldid=167781184; occurrence=0;=BA_N
The iterator value came as :: fldid=167781163; occurrence=0;=No Error
The iterator value came as :: fldid=167781193; occurrence=1;=01/01/2002
The iterator value came as :: fldid=167781190; occurrence=0;=
The iterator value came as :: fldid=167780185; occurrence=0;=
Here we are having a existing tuxedo client simulator which was communicating to our tuxedo server - rmTTIRecieve. Now this tuxedo server is getting replaced by EJB based webserver and using WTC.
Below are config details:
TDOM1 NWADDR="//<tuxedo - local>:1234"
RNM_TTI_UAT NWADDR="//<WTC ip - remote server>:38771"
#ident "@(#) apps/simpapp/ubbsimple $Revision: 1.3 $"
#Skeleton UBBCONFIG file for the TUXEDO Simple Application.
#Replace the <bracketed> items with the appropriate values.
LMID=simple GRPNO=1 OPENINFO=NONE
LMID=simple GRPNO=2 OPENINFO=NONE
WSL SRVGRP="GROUP1" SRVID=1000 RESTART=Y GRACE=0
CLOPT="-A -- -n //<tuxedo mcahine ip>:port -d /dev/tcp -K both"
DMADM SRVGRP=GROUP2 SRVID=1
GWADM SRVGRP=GROUP2 SRVID=2
GWTDOMAIN SRVGRP=GROUP2 SRVID=3
# name number type flags comments
IVR_Version_TxId 8001 string - -
IVR_CERkey_TxId 8002 string - -
IVR_Transaction_TxId 8003 string - -
IVR_ReturnService_TxId 8004 string - -
IVR_RequestingSys_TxId 8005 string - -
IVR_ClientData_TxId 8006 string - -
IVR_TroubleGroupId_TxId 8020 string - -
IVR_TroubleTypeId_TxId 8021 string - -
IVR_CBR_TxId 8022 string - -
IVR_ANI_TxId 8023 string - -
IVR_TroubleGroup_TxId 8024 string - -
IVR_TroubleType_TxId 8025 string - -
RM_MLTRequired_TxId 8050 string - -
RM_ResponseCode_TxId 8051 string - -
RM_ErrorDesc_TxId 8052 string - -
We have generated java file using this fld file and provided this in resource of WTC.
Weblogic side WTC configuration:
<nw-addr>//<WTC server ip-local>:port</nw-addr>
Please let me know if any more information is needed. We are looking for solution on urgent basis now. :(
Apart from this I still have doubt on why do we need to set up remote access point on weblogic as we do not utilise tuxedo server written on tuxedo machine.
Ideally we should only provide bdmconfig to tuxedo client so that it can operate with WTC server.
Please correct my understanding.
OK, I'm a little confused (so what's new!)
Where is the client of this service running? I'm guessing on Tuxedo since you are posting some ULOG entries from GWTDOMAIN, but I'm not certain based upon your comment "Apart from this I still have doubt on why do we need to set up remote access point on weblogic as we do not utilise tuxedo server written on tuxedo machine."
Assuming that the client is a Tuxedo client (or a server making a request to the service, thus acting as a client), then you not only need to configure the Tuxedo domain gateway configuration (BDMCONFIG), but also the remote domain that offers the service, which if I understand correctly is an EJB running on WLS. In the case of WTC, you need to configure any exported services so WTC knows which EJB is to be invoked for an incoming request.
The error message you are seeing from the Tuxedo domain gateway I believe is caused by the caller of the service exiting before receiving the reply.
Is there more information in either the ULOG or the WLS log file that might be related to this problem?
Oracle Tuxedo Chief Architect
Thanks for your reply. Meanwhile we found two issues which can contribute to this error:
1. The ReplyToService that we were setting in request from TuxClient, was not capable of reciving FML buffer. We are now trying to set up a relevant service.
2. While sending request it was considering two differnt field tables, however on EJB server side only one field table was considered while coding. We are in process to include those details.
I will let you know if any further issues.