I have created an SR on the same subject, but I would like to have specialist point of view of this question :
we are using an http gateway (formerly “reverse invoke”), in front of our B2B system.
Punctually, are loosing some documents :
we can see the corresponding activity in our firewall (so the document is arriving)
the training partner got an HTTP 200 return code (so the document is fully transmitted and accepted)
but we can’t see anything in TN.
So my question is : which is the component sending the HTTP return code ?
I have understood the http gateway is totally transparent on this process, so I need to know if this return code is issued by the IS hosting TN or if it’s the gateway generating this code before forwarding the document to TN.
Which service it is getting invoked? Partner IB docs are getting routed yo DMZ and internally to tn:receive or direct invoking receive itself.If custom svc then for debugging you can try with pub.flow:getTransportInfo service and SavePiplelineToFile right after and trace it.
Yes internally IS transport handler will return http resp codes (success or failure).
Code is certainly from internal IS, beacuse recently i faced some issues in Reverse gateway setup where connectivity was getting lost between Reverse proxy IS and internal IS, RIP IS was listening to all the requests from IS but client applicaiton was not getting any response infact it goes hung till the time … internal IS comes back and process the pending requests.
– SAG resolved this connectivity issues with some fixes, but functionality is still the same
Consider an RI x InternalIS that is configured propertly. I mean, most of the times if one hits on the RI external port with a service invokation that exists at the InternalIS and both parts plus the network and the database are in a good hair day everything works perfectly. However, if RI is up and running with the external gateway port enabled, but the Internal IS is down, and one hits on the RI external gateway port with a good invoke request via an IE browser like:
[URL=“http://localhost:3333/invoke/PIE9287/debugLog”]http://localhost:3333/invoke/PIE9287/debugLog[/font][/URL][FONT=Tahoma][COLOR=#002060], this browser instance never times out or replies until the Internal IS is started, and while RI cannot get an communicate with this IS it would write on the RI server.log lines like:[/color] 2010-06-10 17:02:02 EDT [ISC.0064.0027C] 1 Requests waiting for a registration connection Once the InternalIS got started it would listen to the RI, the RI would send the request, IS would hear it, produce and answer, this would reach RI and then the Browser. However, what you really wanted is: RI would not be waiting on InternalIS forever, but return some kind of error to the Browser indicating that the InternalIS could not really be reached, and drop the request that could not be processed.
