.Net weirdness - Forum - OpenEdge Development - Progress Community

.Net weirdness

  • Hi all,

    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
       at Progress.SupportClass.UdpClientSupport.Receive(UdpClientSupport
    tempClient, PacketSupport packet)
       at Progress.NameServer.Client.NameServerClient.receiveResponse(Int32
    responseCount, String applicationService) (8230)
       at OEproxyLib.OEproxyObject..ctor()
       at OEproxy.ASConnection.Connect(String appServerURL, String userId,
    String passWord)

    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.