No announcement yet.

Getting PrivilegedActionException when trying to send transaction

  • Filter
  • Time
  • Show
Clear All
new posts

  • Getting PrivilegedActionException when trying to send transaction

    I dont know if this belongs here or not. We are trying to do a secure webservices integration with Unisys. They sent us their certificates. We've imported them in to several keystores.

    From our sm.ini file:

    I'm not sure which of these should hold their certs, so I imported them in to all three in the RUN directory. Because we also have a "cacerts" file in the JAVA_HOME directory structure, I imported them there too. We also had our I-Net team import them into the cacerts on the webserver: /inet/apps/jdk64-1.6.0_18/jre/lib/security .

    When conditions are met, triggers on probsummary run a javascript that builds the XML, and does a doSOAPRequest to their URL. We continue to get the PrivilegedActionException error.

    The full error:
    Script <unknown script> line 0: ERROR uncaught exception: Error calling method: doSoapRequest in class: com/hp/ov/sm/server/utility/SoapClient Exception (com.
    sun.xml.messaging.saaj.SOAPExceptionImpl: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed) at char 1
    Error calling method: doSoapRequest in class: com/hp/ov/sm/server/utility/SoapClient Exception (com.sun.xml.messaging.saaj.SOAPExceptionImpl:
    vilegedActionException: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed)

    When they configure their end so we can just an unsecure (?) http port, everything works fine.

    Any ideas? How do I know what keystore is being used for this? Is it on the app server or the webserver? There is at least one more cacerts file on the webserver, but I dont have access. Is this maybe not even related to the certificates?

    One of the Unisys folks is saying we may need to change our sm.ini to have "ssl:1", but if I'm not mistaken that is for incoming client connections. We cant change that as it would affect every internal user who connects.

    Any advice would be appreciated.

  • #2
    You can always try to start a separate listener for this.

    in sm.cfg you can for example add this lines

    # SM dedicated servlet used for Web Services integration
    sm -debugnode -httpsPort:17280 -sslConnector:0 -ssl:1 -ssl_reqClientAuth:2 -log:../logs/sm_integration_webservices.log

    this way your web services would be separated from your normal user sessions. PS. adapt the settings on the line as needed.
    Kind regards,


    • #3
      thanks for the information. I'm going to do this in our test environment.

      The only thing is, tho, this is for outbound transactions. These transactions will be initiated on any ticket opened or updated in the desktop support assignment group: an xml request is being sent to a url provided by Unisys. any user of the system could be assigning a ticket to that group, so wouldnt the above only work for users connected to that port?

      Thanks again for the info.


      • #4
        You are right, I overlooked that. The listener is only for incoming requests. Your users will connect from their session to Unisys, so you will not solve it by adding an extra listener.
        Kind regards,


        • #5
          Issue Resolved!

          The error being generated by the script was kinda useless. While waiting to meet with Unisys again today, I decided to try the "wsdl to js" utility, if for nothing else, to see how SM would configure the script. Well, it failed, but it gave a better error message. The important part of the error was:

          29920(8886525) 10/02/2015 13:02:52 JRTE E Error in doHttpRequest() No subject alternative names matching IP address found

          This led the Unisys resources to realize that I cant connect using the IP, but needed to use the fully qualified name ( So, I had to update my /etc/hosts file. We did that, but it still didnt work. Doing an nslookup of the fully qualified name was reporting back the public name from the dns, not what we put in the hosts file. We then had to update our nsswitch.conf file to reverse the order of "hosts", so it would check "files" first, then DNS:

          hosts: files [NOTFOUND=continue UNAVAIL=continue] dns [NOTFOUND=return UNAVAIL=return]

          We made that change, and that fixed our issue. My script now successfully submits the XML transaction to Unisys without error.

          Thanks again for replying to my question. This forum has been very helpful to me.