I asked another SOAP related question some time ago, which asks for a working Soap Client and Server for Delphi XE and upwards.
Nobody had a solution out of the box, so I restored the Delphi 2007 era demo to working state for Delphi XE and XE2. I have the demos working, and I have an INDY VCL form based server (a standalone HTTP Server running on Indy) with a Soap server. The two parts of the server demo are a “custom method” (normal soap function call) and a “remote dataset”. It is the remote dataset that I am unable to get working.
The error that I have is in the client form when I set the client dataset active, the server sends back an exception when I do this line in the demo client:
ClientDataSet1.Open;
This in turn goes down into DBClient.pas code, TDataSet.OpenCursor invokes DoGetRecords which is trying to read from ProviderName = 'XMLTransformProvider1',
by this RIO invocation:
Result := AppServer.AS_GetRecords(ProviderName, Count, RecsOut, Options,
CommandText, Params, OwnerData);
// ProviderName = 'XMLTransformProvider1', Count = -1,
// CommandText = '', Params = NULL, OwnerData = Unassigned
This blows up with this exception shown in a typical MessageBox form:
`ERemotableException: XML Parse error...`.
ERemotableException
'XML Parse Error:
Reason: The system cannot locate the object specified.
'.
The server side exception call stack for the Indy Soap Data Module is shown here:
xmlutil.DocParseError(TMSDOMDocument($292C994) as IDOMDocument)
xmlutil.LoadDocFromFile(???)
Xmlxform.TXMLTransform.GetData
Xmlxform.TXMLTransformProvider.InternalGetRecords(???,???,[grMetaData],'',Null)
Provider.TCustomProvider.DoGetRecords(-1,0,1,'',Null,Null)
Provider.TCustomProvider.GetRecords(???,0,1,'',Null,Null)
SOAPDm.TSoapDataModule.GetRecords('XMLTransformProvider1',-1,0,1,'',Null,Null)
SOAPDm.TSoapDataModule.SAS_GetRecords('XMLTransformProvider1',-1,0,1,'',Null,Null)
Invoker.TInterfaceInvoker.Invoke(???,('IDataMod', 'DataMod_U', (('', ccReg, 0, 0, nil, nil, (), False), ('', ccReg, 0, 0, nil, nil, (), False), ('', ccReg, 0, 0, nil, nil, (), False), ('SAS_ApplyUpdates', ccStdCall, 3, 5, $401314, $628D50, (([pfConst], 'ProviderName', $4012DC), ([pfReference], 'Delta', $401314), ([], 'MaxErrors', $4010A0), ([pfOut], 'ErrorCount', $4010A0), ([pfVar,pfReference], 'OwnerData', $401314), ([], '', nil)), True), ('SAS_GetRecords', ccStdCall, 4, 7, $401314, $628D50, (([pfConst], 'ProviderName', $4012DC), ([], 'Count', $4010A0), ([pfOut], 'RecsOut', $4010A0), ([], 'Options', $4010A0), ([pfConst], 'CommandText', $4012DC), ([pfVar,pfReference], 'Params', $401314), ([pfVar,pfReference], 'OwnerData', $401314), ([], '', nil)), True), ('SAS_DataRequest', ccStdCall, 5, 2, $401314, $628D50, (([pfConst], 'ProviderName', $4012DC), ([pfReference], 'Data', $401314), ([], '', nil)), True), ('SAS_GetProviderNames', ccStdCall, 6, 0, $40BC38, $628D50, (([], '', nil)), True), ('SAS_GetParams', ccStdCall, 7, 2, $401314, $628D50, (([pfConst], 'ProviderName', $4012DC), ([pfVar,pfReference], 'OwnerData', $401314), ([], '', nil)), True), ('SAS_RowRequest', ccStdCall, 8, 4, $401314, $628D50, (([pfConst], 'ProviderName', $4012DC), ([pfReference], 'Row', $401314), ([], 'RequestType', $4010A0), ([pfVar,pfReference], 'OwnerData', $401314), ([], '', nil)), True), ('SAS_Execute', ccStdCall, 9, 4, nil, $628D50, (([pfConst], 'ProviderName', $4012DC), ([pfConst], 'CommandText', $4012DC), ([pfVar,pfReference], 'Params', $401314), ([pfVar,pfReference], 'OwnerData', $401314), ([], '', nil)), True), ('CustomMethod', ccStdCall, 10, 0, $4012CC, $62E668, (([], '', nil)), True)), (45872836, 16917, 16768, (153, 166, 192, 149, 84, 207, 120, 216)), $62E668, $628D50, 10),4,$2942270)
SOAPPasInv.TSoapPascalInvoker.Invoke(???,???,'',$28F3700,$28F36A0,???)
SOAPHTTPPasInv.THTTPSoapPascalInvoker.DispatchSOAP('/SOAPDMServerWAD.Sample/soap/IDataMod',???,$28F3700,$28F36A0,btSoap)
WebBrokerSOAP.THTTPSoapDispatcher.DispatchRequest(???,???,$29421C8)
HTTPApp.DispatchHandler($28E4140,THTTPSoapDispatcher($291687C) as IWebDispatch,$290FEA0,$29421C8,False)
HTTPApp.TCustomWebDispatcher.DispatchAction($290FEA0,$29421C8)
HTTPApp.TCustomWebDispatcher.HandleRequest(???,???)
HTTPApp.TDefaultWebAppServices.InvokeDispatcher
HTTPApp.TDefaultWebAppServices.HandleRequest
WebReq.TWebRequestHandler.HandleRequest($290FEA0,$29421C8)
IdHTTPWebBrokerBridge.TIdHTTPWebBrokerBridgeRequestHandler.Run(???,$28851B0,???)
IdHTTPWebBrokerBridge.TIdHTTPWebBrokerBridge.DoCommandGet(???,???,???)
IdCustomHTTPServer.TIdCustomHTTPServer.DoExecute($293AB30)
IdContext.TIdContext.Run
IdTask.TIdTask.DoRun
IdThread.TIdThreadWithTask.Run
IdThread.TIdThread.Execute
Classes.ThreadProc($28A1FE0)
What I believe is happening is that we’re getting an empty HTTP response. This would make perfect sense to me if nothing worked, and the HTTP url we’re accessing doesn’t work. The url we’re accessing is, and is accessible via a web browser:
http://localhost:8088/?intf=IDataMod
The XML that is coming back to the client that caused the error message looks like this:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>XML Parse Error:'#$D#$A#$D#$A'Reason: The system cannot locate the object specified.'#$D#$A#$D#$A#$D#$A'</faultstring>
<faultactor/>
</SOAP-ENV:Fault>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
My question is: What does that SOAP error really mean and why is it happening, and how do you fix it?
In this case, it means that the client has received notice that an exception occurred on the server side. Since the exception on the server side was caused by a problem with the demo code, the solution is to repair the demo server so that it operates correctly.
In the case of the SOAP server that shipped with Delphi 2007, in the SoapDataModule samples folder, the problem with it is that it has no error checking; if it fails to load the XML sample data (because the data folder has moved, or is missing), then it explodes with an unhandled exception on the server side.
SOAP has the nice property of automating your work for you; The client receives a notice that we recieved the soap call, and we get back soap exception instead of a real response. One can not blame SOAP here, and Delphi SOAP RTL is actually pretty friendly to use. But the underlying point to take away here is that the implementer of a soap service should do some sanity checking on the soap server when it is started up, so that errors can be repaired before they must be fatal to a SOAP request.
Lesson learned; When you construct a SOAP server consider configuration-error handling and fatal-error detection as a startup task before your first SOAP server session.