After having developed with OpenEdge and Sonic the company has decided
to move away from Sonic (and towards Biztalk). As part of this project
and also to learn more about Biztalk I'm trying to do a call from .Net
to an appserver from within Biztalk. This to replace or to "simulate"
the native invocation from Sonic to an appserver. When I first tested
the call to an appserver from within a Console application it working
as expected. But I see some strange errors in my Eventlog if I use an
almost identical .Net class from within Biztalk (I write the
exceptions to the eventlog):
Exception Progress.Open4GL.Exceptions.Open4GLException :Connect
Failure: NameServer Communications Failure -
System.Net.Sockets.SocketException (0x80004005): An existing
connection was forcibly closed by the remote host
tempClient, PacketSupport packet)
responseCount, String applicationService) (8230)
at OEproxy.ASConnection.Connect(String appServerURL, String userId,
I first had to solve issues with strongnames and assamblies but I had
hoped those were all solved because the console application was
working. Why is the connection to the appserver failing if I try to do
the call from within Biztalk. One of the things that I could think off
(but the error does not point that way) is some sort relation to the
Global Assembly Cache where all DLL's need to reside for Biztalk. The
console app uses "private" DLL's.
I disabled the firewall and switched to AppserverDC in the mean time
but no succes. The Knowledgebase didn't help with pointers as well.
Anybody here any pointers?
Take a look in your appserver logs. I think this message is telling you that there was some problem in the server, and the server closed the connection.
Well that is the strangest about it. There is no movement whatsoever in the logs. I tested the appserver call from the same computer with a standalone .Net commandline application and it works there.
I would have asked about any intervening web servers and AIA, but you mentioned direct connect. I'd be sniffing the traffic at this point. You don't have to understand the protocol, you just need to ensure the TCP connection is being made to the server. You can turn up the broker and agent/server logging, and that will show whether connections are received.
I've managed to get a connection to the appserver. I'm using the OpenAPI protocoll. It is a little bit harder but I think it is related to the specific DLL generated by the proxygen. For now a nice solution since we are using a generic procedue already for Sonic. For now I guess this is a workable replacement for those flows.
If you are willing to provide a producible case for this, I would log it with Tech Support, so we can investigate whether it is a bug or not.