A Case to Diagnose Elliott SOAP Web Services Errors with Log Files
Modified Date: 08/23/2024
On the surface, this seems to be a network level error at the very low level and is not related to Elliott web services. We have seen this kind of problem with TLS requirements not being met and causing this message. But if that is the case, the above message should be consistent and can be duplicated. Since the above error is inconsistent, it is not likely the message is due to certain setup problems with the network, firewall, or Windows server.
Version: 8.5 & Up
When a web developer calls Elliott SOAP web services, he/she should place a try catch block so if there is an error with the web services call, the error can be caught at the front-end user interface. The problem can be reported to Netcellent for proper diagnostics. The following is a sample error message from the client side try catch block:
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Since the above message does not give us enough information to diagnose any further, we have to go to the web services server to find log information. When you report this problem to us, please let us know the date/time when this message happened. It will be extremely helpful for us to find the entry in the log file.
On the web services server, there are three areas where we can look for log information:
Elliott SOAP Web Services Log
You can find Elliott SOAP web services log files in the <WSInstallPath>\Log folder. Look for the requestresponse log files. See the following example:
Elliott SOAP web services supports up to 10 archive log files. If your config file is set to capture all web services activity, then you could end up capturing too much log information. Hence, all 10 log files are filled up quickly. By the time we investigate the issue, the entry we need to see may be overridden already. To avoid this problem, you may need to change the web services configuration to only capture the important information that's needed to diagnose the problem you are experiencing. To change the configuration, please go to the <WSInstallPath>\Config folder and bring up the ElliottService.custom.config file. See sample screen below:
Bring up the config file in a text editor like Notepad or Notepad++ and find the entry that defines the logging:
Since the issue in this example happened with EliorderService.asmx, we set the flag to "B" to record both request and response. On the other hand, when we go to the proper log file and try to find the entry, we found the entry of "TrialAllocation" call before submitting the CreateOrder call.
The CreateOrder call is missing from the sample log file which is puzzling. Hence, we proceed to check the Windows IIS Log file in the next section.
Windows IIS Log
Typically, you can find your Windows IIS log in the following folder: C:\inetpub\logs\LogFiles\W3SVC2. See sample screen below:
In this case, when we go to the proper IIS log file and try to find the entry, we only find the entry corresponding to the TrialAllocation and did not see the CreateOrder entry. See sample entries below:
So our last hope is try to find the log in the Windows Event Log (see next section).
Windows Event Log
Bring up Windows Event Viewer and navigate to Windows Log -> Application. Try to find the error entry. See sample screen below:
The error source from ".NET Runtime" is of particular interest to us. So we drill down further.
Please copy the detail message. The following is a sample of this detail message that you can send to Netcellent for further diagnositcs:
Application: w3wp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
at Fujitsu.COBOL.Runtime.IO.FileSystem.ExternalFileHandler.JMP5CLEX(IntPtr, UInt16, Byte*, Byte*, Byte*, Byte*)
at Fujitsu.COBOL.Runtime.IO.FileSystem.ExternalFileHandler.CallFileSystem()
at Fujitsu.COBOL.Runtime.IO.FileSystem.JMP5VIOSF.yclssys(Fujitsu.COBOL.Runtime.ProgramControl.RCB, Fujitsu.COBOL.Runtime.IO.FileControl.ACBX, Fujitsu.COBOL.Runtime.ProgramControl.PCB)
at Fujitsu.COBOL.Runtime.IO.FileSystem.JMP5VIOSC.JMP5VIOS(Fujitsu.COBOL.Runtime.ProgramControl.RCB, Fujitsu.COBOL.Runtime.IO.FileControl.FMB1cm, UInt32, System.Object)
at Fujitsu.COBOL.Runtime.IO.RecordFile.RecordFileCommon.IOclose(Fujitsu.COBOL.Runtime.ProgramControl.RCB, Fujitsu.COBOL.Runtime.IO.FileControl.FMB1cm)
at Fujitsu.COBOL.Runtime.IO.RecordFile.IndexedFile.ycbpacbx(Fujitsu.COBOL.Runtime.ProgramControl.ILI)
at Fujitsu.COBOL.Runtime.IO.RecordFile.IndexedFile.JMP5CLOS(Fujitsu.COBOL.Runtime.ProgramControl.ILI)
at Elliott.ELBORDER._Procedure(Fujitsu.COBOL.COBOLData)
Exception Info: System.Reflection.TargetInvocationException
at System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[], System.Signature, Boolean)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(System.Object, System.Object[], System.Object[])
at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
at System.Reflection.MethodBase.Invoke(System.Object, System.Object[])
at ELIORDER.MoveLineLsFirst(System.String ByRef, Int32 ByRef, System.String ByRef)
at ElliottWS.Utility.ActiveX.EliordiqParser.GetSerialNumber(System.String, Int32)
at ElliottWS.Utility.ActiveX.EliordiqParser.ParseLineItemTable(LineItemRecord[] ByRef, System.String, Int32)
at ElliottWS.EliordiqService.OrderInquiryOrderNo(OrderInquiryOrderNoInput)
at ElliottWS.EliordiqService+_Closure$__10-0._Lambda$__0(System.Object)
at ElliottWS.EliordiqService+_Closure$__10-0._Lambda$__R3(System.Object)
at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart(System.Object)
This Windows Event Log explains why we are not getting the log in Web Services and IIS: because the IIS process crashed with the following message:
The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
After further research, if found out the ElliottService.custom.config file has "UseSerialNumber" flag set to "Y" while customer is not using serial number.
<!-- SERIAL NUMBER CONFIGURATION
-->
<!-- UseSerialNumber tells the web
service if the user is using serial
number
EliordiqService will return the serial numbers when invoice is queried if
the serial number is used in the system. Note: if the system is not using
serial
number and this flag is set to yes, web service will return error -->
<add key="UseSerialNumber"
value="Y"/>
It was changed to "N" on 8/15/24. Since then, there's no more IIS crash in Windows Event log so it appears that was the culprit:
EMK