Layer7 API Management

Hi Stefan,

Earlier than that error, you should generally see a message something to the effect of "Processing request for <ServiceName>”, and it will likely share the thread number too. So in your example, you may see that with the same thread number of 1192. This should help point out which service was being called at the time of that error.

Ultimately though, that error means that a request was made to the service which calls on an operation or action that the WSDL of the SOAP service does not declare, so the request is then dropped at that point.

If you have customized your logging in any ways, you may need to report back with how you have it set up for the SSG log syslog and the log.levels cluster-wide property, as those may impact what shows up in your logs to help troubleshoot.

Hi Stefan,

I'm happy to hear you were able to narrow it down far enough to find the affected service.

In terms of that error you receive, here are my thoughts:

• It's not an actual error (I think I missed this part earlier myself too), you'll notice it has the level of "INFO", so it's simply an informational message for your own records so that you know the request incoming didn't match any supported operations in the WSDL for that SOAP service. From there, it doesn't drop the request (which is what I mistakenly said earlier because I had forgot about the possibility of the override for this which you are using), it will simply continue onwards and as it says in the INFO dialogue – it tries to match it using the document instead. The whole request I believe should still succeed unless it gets caught elsewhere in policy. It would be type "WARNING" or "ERROR", I believe, if you hadn't used that override of "Allow requests intended for operations not supported by the WSDL".

• I'd recommend keeping those entries just for completion sake, but if you are getting way too many of them or you do not find them useful at all, then absolutely you can look to hide them from being logged. However, this method would affect the Java class level rather than that very specific error message, so it may unintentionally hide more than you are wanting, so just keep this in mind. You can, for example, add "com.l7tech.xml.soap.SoapUtil.level = WARNING" to the log.levels cluster-wide property. At that point, it'll only log messages with "WARNING", "ERROR", or "SEVERE" that come from the com.l7tech.xml.soap.SoapUtil Java class.

• On a side note though, I'd start to investigate why this service is receiving requests for operations that aren't supported, then evaluate if they should be supported (i.e. a bug in the WSDL file that should be supporting it but isn't written in a way that supports it), or if your requestor needs some additional training on how they generate their requests to your SOAP service. That, at least in my humble opinion, would be the more solid option rather than hiding log entries. But of course, you can still always do both too.

Hi Stefan,

Glad to hear those pesky messages are gone for you. Audits and logs are treated a bit differently, and I'm not aware of a way to hide certain log entries the same way you would audits, because there aren't really any "codes” to them as there are in audits.

In my Gateway 9.2.00, for some reason I cannot seem to get the "Processing request for <ServiceName>” item, but it's my lab Gateway for reproducing customer issues so of course it gets a bit too customized after a while and I need to reset it before it's valid. However, with that said, I did notice the following as my SSG logs were set to a severity of "ALL” when I began testing:

2018-08-10T16:49:09.116-0700 FINE    25617 com.l7tech.server.SoapMessageProcessingServlet: HTTP request URI [/echo]

The above is a FINE level request, so your SSG log sink would need to be customized to show at least FINE level or deeper to show that kind of log entry. So if you find yourself running into those kind of issues where you need to know which service it went to, you can temporarily make that change too so that you can then determine the service the requests were directed to.

Can you please confirm what you mean by "PID”? I know there is a thread number before each log entry after the date and log level (such as "25617” from the example above), is that what you're referring to? If that's what you were referring to, that won't actually relate to a service but rather the thread itself, so there's no way to actually map that to a service name as they are not related.