6 Replies Latest reply on Oct 22, 2012 1:10 PM by 947421

    Siebel -> WTC ->Tuxedo


      I need to develop an application in Siebel 8.1 which can connet to tuxedo server. I have been reading through many posts and can find that SALT is one of the options. However in my case the tuxedo server is an external system. So without making any changes in external system I want to connect to their tuxedo environment from Siebel. In case of SALT tuxedo installations at external system needs to change, which is not desirable.
      Here is what we think could be a solution:
      1.     We know that Siebel can easily interact with web services.
      2.     There is a implementation provided by weblogic – as WTC – Weblogic Tuxedo Connector
      3.     By writing EJB based WTC enabled webservice we can communicate to external tuxedo system. This will ensure that external system still remains same.
      4.     We can then import this web service in Siebel and call it’s methods which inturns calls tuxedo functions.

      Siebel -> WTC ->Tuxedo

      We made a POC on this which is working fine. We made it both ways.
      I still want to seek expert opinion on this to understand if this approach would face any issue wrt performance, load balancing, missing transactions or availability. I want to understand if there will be any issue that we could expect before we finalize this design.

      Please suggest.

        • 1. Re: Siebel -> WTC ->Tuxedo
          Todd Little-Oracle
          Hi Neelima,

          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.

          Todd Little
          Oracle Tuxedo Chief Architect
          • 2. Re: Siebel -> WTC ->Tuxedo
            Thanks Todd for quick reply on this.

            For sample tuxedo service we used following configurations so that tuxedo service understands web service domain.

            TDOM1 GWGRP=GROUP2

            TDOM2 TYPE=TDOMAIN

            TDOM1 NWADDR="//<ip address of tuxedo machine>:1234"
            TDOM2 NWADDR="//<ip address of web service machine>:7001"

            TOLOWER RDOM="TDOM2"

            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
            • 3. Re: Siebel -> WTC ->Tuxedo
              Todd Little-Oracle
              Hi Neelima,

              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.

              Todd Little
              Oracle Tuxedo Chief Architect
              1 person found this helpful
              • 4. Re: Siebel -> WTC ->Tuxedo
                Hi Todd,
                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

                At Weblogic
                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:



                RNM_TTI_UAT TYPE=TDOMAIN

                TDOM1 NWADDR="//<tuxedo - local>:1234"
                RNM_TTI_UAT NWADDR="//<WTC ip - remote server>:38771"

                rmTTIReceive RDOM="RNM_TTI_UAT"



                #ident "@(#) apps/simpapp/ubbsimple $Revision: 1.3 $"

                #Skeleton UBBCONFIG file for the TUXEDO Simple Application.
                #Replace the <bracketed> items with the appropriate values.

                IPCKEY 123456
                PERM 0666
                DOMAINID simpapp
                MASTER simple
                MAXACCESSERS 20
                MAXSERVERS 5
                MAXSERVICES 20
                MODEL SHM
                LDBAL N
                NOTIFY SIGNAL
                USIGNAL SIGUSR2
                SCANUNIT 10
                SANITYSCAN 60
                BLOCKTIME 8

                # APPDIR="/home/me/simpapp"
                # TUXCONFIG="/home/me/simpapp/tuxconfig"
                # TUXDIR="/usr/tuxedo"

                rnmdev1 LMID=simple

                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


                FLD file

                # 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>
                <nw-addr>//<tuxedo ip-remote>: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.
                • 5. Re: Siebel -> WTC ->Tuxedo
                  Todd Little-Oracle
                  Hi Neelima,

                  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?

                  Todd Little
                  Oracle Tuxedo Chief Architect
                  • 6. Re: Siebel -> WTC ->Tuxedo
                    Hi Todd,

                    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.