SOAP invocation failed: java.security.PrivilegedActionException: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed

Not Yet Reviewed

First off - I'm far from a SOAP expert so apologies if I state things incorrectly or use the wrong verbiage.

We use CA Process Automation Manager (PAM) to maintain out users. On one of the processes when we are looking to see if a user can be inactivated, we occasionally get this error.

SOAP invocation failed: java.security.PrivilegedActionException: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed

The method being called is QueryUser. I can drop that exact soap package in SoapUI and it works just fine. The only commonality I see on the failed soap call is they all return a "User Unknown" when I run it in SoapUI. If they return a user it appears the call doesn't fail.

The SOAP schema we are using is http://www.xmatters.com/webservices/schema#5.0

Any thoughts?

0

Comments

5 comments
Date Votes

Please sign in to leave a comment.

  • Hey Neil. That is a fun error message! I especially love it when those kinds of errors show up randomly.
    So, just to clarify the architecture, PAM is making the SOAP requests to xMatters and is spitting this error out from time to time? Based on the schema you're using this is on premise? What patch are you running (printed in the first few lines of the xMHOME/logs/AlarmPoint.txt file)?
    I ran that error through our ticketing system and there are some very diverse root causes.

    0
  • Hey Travis - guess I forgot to mention we're using OnDemand SaaS solution. That version is at Version: 5.5.82(r3654).

    I also need to note that at first I thought this is isolated to just the QueryUser - but after digging through the PAM erred process it does appear to happen on other methods too - not just UserQuery. And like you said - "randomly"

    0
  • hmmm, there is an issue with our wsdl. When you pull the wsdl into the client system, the endpoint binding is incorrect and uses "http" instead of "https". In one of the tickets I found in our system this may have been the culprit. Although that should be more systemic rather than random.

    0
  • Travis, what would you suggest as the next step?

    0
  • Hey Neil. The best thing to do is isolate it in anyway you can. It sounds like you can capture the SOAP message from PAM. Have you tried sending that soap message to xM from the same box that PAM is on? When you look at the raw http entries in SOAP ui, do you see any differences in the endpoint address? Are you using the same user in both cases?
    It seems like this "User Unknown" is a key. You mention it works fine in SOAP UI, does it work fine when a "User Unknown" is returned? Seems like pulling on that thread might be a good idea.

    0

Didn't find what you were looking for?

New post