3 Replies Latest reply: May 27, 2014 10:41 AM by Todd Little-Oracle RSS

    GWWS Server and Instance ID

    Mats Ulvedal

      Hi all,

       

      Is it possible to get hold of the "GWInstance id" given in both the CLOPT and the deployment file from GWWS Plugin code?

      I guess I can use the MIB, but was is the class name and what service name should I call? .TMIB??

      I think this is the field I'm looking for TA_WS_GWWSID, but how to access it?

       

      I tried to find any MIB info in the documention but nothing so far.

       

      Best Regards

      Mats

        • 1. Re: GWWS Server and Instance ID
          Todd Little-Oracle

          Hi Mats,

           

          There isn't a MIB for SALT just yet, although we are working on it.  The only ways I can think of getting this would be to get your process ID with getpid(), then make a .TMIB call to get the GWWS server with that PID command line CLOPT and then parse the CLOPT.  I know, ewwwwww...  If you are on Linux, you could also just read the file /proc/self/cmdline and get the command  line that way.  Can I ask why you want GWInstance ID in your plug-in?  Another possibility would be to put the GWInstance ID in an ENVFILE for the GWWS, but then you'd have to keep that in sync with any changes to your configuration.

           

          Regards,

          Todd Little

          Oracle Tuxedo Chief Architect

          • 2. Re: GWWS Server and Instance ID
            Mats Ulvedal

            Hi Todd,

            I suspected that after some test.

            I will look into the way you suggest. It's a few more lines of code, but it's fun to code so...........

            To put it in system environment I agree with you, I thought of that but I skip that with the same reason you mentioned above.

             

            First, we are using MP configuration, in that we have two machines who publish our WebServices, but the business logic is in other domains.

            So you can say that "this" SALT domains only acts as an integration gateway.

             

            The reason for doing this is that we will soon start with an Apache server as a front for all our's "SALT application" who will terminate the SSL.

            So in the Apache server we "ProxyPass" to our WSDL URL we have for different system (BASINFO, NAVET, etc.) to a localhost:port.

            The thing is that we also have bigIP(used as failover only) in front of the Apache who control where to send the call.

             

            And bigIP can't check an URL to a localhost, so we need a "status (ON | DOWN)" file for each system (which also lay in a own GWWS group).

             

            The ID we have for each GWWS server are we using when we generate all the needed config files. And since we (I) put the code who update's status

            in the Plugin's (actually a shared libb), so if the GWWS server is shutdown down it write DOWN then bigIP close that URL and send the call to the other machine in the domain(active/active).

            And ofcourse viceversa when it start again.

             

            And to wrap this up, if it's possible I would like to use the same name for all of the needed file for each system. Makes it a lot eaiser when maintaning and look for errors.

            That's why.

             

            I hope I could describe it well enough.

             

            Regards

            Mats

            • 3. Re: GWWS Server and Instance ID
              Todd Little-Oracle

              Hi Mats,

               

              Wow, sorry for the delay in responding!  A lot of activity getting 12.1.3 out the door.

               

              In any case, how is your plug-in doing this?  My recollection of the plug-in API is that it doesn't get lifecycle events.  It would seem TSAM Plus is a better alternative as it can know the state of all the servers (SALT gateways and actual backend business servers) and you can define rules in OEM to create/update the availability files for the bigIP.  Thoughts?

               

              Regards,

              Todd Little

              Oracle Tuxedo Chief Architect