How to Trace Http Post calls

, , ,
1

Hello wM experts,

We are using webMethods 9.8 IS, were we have develop critical payment integration flow service. Please find the high level flow for service.

[inbound] Source system → soap call → wM [outbound] —> http post → F5 load balancer → Target external system

In idea scenario, when one request trigger from source app then only one request must received at target app but as this is critical payment integration flow as said earlier, so we are facing very rarely occurs issue in our production system which we have to identity and resolve it.

In wM outbound flow service while making call via http request to target (external) system, request failed and we have received http response code back so on failure http response we have logic written in our wM service flow to retries (3) attempts to external system and wM servers made (3) attempts but issue start when external system/app team told they didn’t received any requests from wM

So ask here is,

  1. How to trouble shoot http call request when wM makes to external system?
  2. What are steps or checks we need to do from wM side to verify issue?
  3. Is there any ways how to trace http request when request move out from wM server?
  4. Do you feel design flow is not correct as this is payment flow services, and we are making 3 reties attempts to external system?
  5. Please provide trouble shooting steps to trace http call?
  6. Any kind of scripts which helps to capture http calls/logs or any other suggestions on wM [outbound] flow side?
  7. Do I need to add any logic to capture http logs in server level?
  8. Any flow service or server level setting/configuration need to reverify?
  9. Wat are steps/pointers I can suggest to external system team so that can capture/trace logs or verify etc. at their end?

Kindly let me know if any additional information is require.

Thanks
RJ

2

You can increase the logging level of the IS logs to Debug/Trace which then captures transport-level logs as well for investigation.

Having said that, here are my initial thoughts -

  1. If IS logs indicate that the request and retries were unsuccessful, then the IS has certainly attempted the HTTP requests
  2. What is the actual error message as seen on the IS?
  3. Since you have an F5 layer between the IS and target app, investigate if requests were received and sent out by the F5

It seems likely that there was either a network issue between IS and F5, or the F5 had issues reaching the target application. Get into a working session with F5, network and target application support teams, and track where the drop occurs.

Tip - Retries help when there are frequent transient errors, due to an unstable network/bandwidth, but remember that IS consumes additional resources than usual, especially if it’s constantly tracking and performing retries.

Consider going async (correlation and reconciliation will be additional activities, if you do), if this constantly happens and cannot be resolved in the near future.

KM

1 Like
3

Hi,

in addition to Kasi´s answer:

Can you provide an outline of your flow service showing the general logic (i.e. try-catch construct and how the retries are checked)?

Can you share the error messages from server.log?
Are there any timeouts or data related messages being observerd?

Regards,
Holger

4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.