SymXchange and .net core can work together with a few tweaks.
SymXchange is the new web service replacement for interfacing with the Episys core system. Its predecessor, SymConnect, is a TCP socket based protocol, requiring special handling, request coordination, and everything else that comes with socket programming. The asynchronous nature of network requests makes it a challenge to pipe all those requests into a socket that can only handle one request at a time. The technology upgrade makes interfacing with Episys easier with modern development tools and infrastructure, and eliminates potential performance bottlenecks.
SymXchange and .net
SymXchange is a web service that uses WSDL documents to define the operations and data that are accessible through a given endpoint. Since WSDL documents are defined in XML, communication from your application to a SymXchange endpoint involves converting objects to and from XML documents, which are then transmitted across the network. Serializing objects to XML in .net involves serialization assemblies that are compiled during runtime by the JIT compiler.
When your application starts up and attempts to communicate with an endpoint, it must generate a serialization assembly to convert your objects back and forth to XML. The runtime will cache the assembly for as long as your application is running, unless you define otherwise. There are a few reasons the assemblies may be removed from the cache, so just be aware.
We force the cache to be always on, since we change client endpoints and credentials dynamically. Changing endpoint URIs is one of the triggers that can clear the assembly from the cache. We do it to support multi-tenant, so you may not need these settings.
WSDL documents are added to a .net core project by using the WCF Web Service Reference extension. You must install this extension, as it doesn't come installed in Visual Studio by default.
Problem
Some problems arise when generating the assemblies on application startup. A few of the WSDL documents are rather large and result in a 630,000 line c# reference file. Generating the serialization assembly for such a large file during runtime can take approximately one minute. That's not too bad if it's only on application startup. However, if you use IIS to host the application, the app pools restarts based on activity level and time. If the timeout is set to the default of 20 minutes, your application could incur the JIT compilation penalty for regenerating the serialization assemblies after 20 minutes of inactivity. That is unacceptable from a performance standpoint.
Solution
We run the core communication layer as an ASP.NET Core site hosted in a Windows service. We avoid the problem with IIS app pool recycling and inactivity timeouts by running as a Windows service because the service only restarts when the VM restarts or our continuous delivery agent performs an upgrade. Since this is an internal system service, we don't need to host it as an external web service in IIS. If you do want to host your application in IIS, you can set the timeouts to larger numbers to mitigate the assembly regeneration problem.
WCF support in .net core and .net standard is still being ported over from the .net framework so there are some features that are not yet available but everything is there to support SymXchange in a .net core application today.
