Logging DataSnap 2009 client/server communication
DataSnap 2009 uses custom JSON-based protocol for on-the-wire communication between clients and servers. It is very easy to intercept and log messages being exchanged in DataSnap 2009. As a starting point for adding logging to a simple DataSnap server application, I'm going to use "DelphiDataSnapEchoServer" descibed in my previous post and available electronically from Code Central.
On the main server form there are three core "DataSnap Server" components: "DSServer1", "DSServerClass1" and "DSServerTransport1". The TDSServer component is the heart of a DataSnap server. While you can have mulitple TDSServerClass and TDSServerTransport components in a DataSnap 2009 server application, you only need one instance of TDSServer. It provides public methods "Start" and "Stop" that control when the server application starts and stops acting as a DataSnap server and very convinient "AutoStart" property. If set to "true" (its default value) the DataSnap server is started automatically on application startup. The TDSServer contains also a number of events. The "OnConnect" and "OnDisconnect" are fired when a new client conntects or disconnects to a server. Note that there could be multiple client applications connected at the same time to a server instance.
We need to implement "DSServer1.OnTrace" event to add logging to our server application. Double-click on the event in the Object Inspector and the following empty event handler will be generated:
function TFormServer.DSServer1Trace(TraceInfo: TDBXTraceInfo): CBRType;
begin
// ...
end;
In order to be able to compile the server application add to the "uses" clause in the "interface" section of the main form: "DBXCommon" (for "TDBXTraceInfo") and "DBCommonTypes" (for "CBRType").
The tracing information is passed to the event handler via "TraceInfo" record that contains the "Message" string field, "TraceFlag" and "TraceLevel" integer fields and "CustomCategory" string field, that is used when "TraceFlag" is set to "TDBXTraceFlags.Custom" value. To keep the logging implementation simple, I'm going to add to the server form a TMemo component to display tracing messages and a helper "Log" method to the form itself:
procedure TFormServer.Log(s: string);
begin
MemoLog.Lines.Add('[' + DateTimeToStr(Now) + '] -> ' + s);
end;
function TFormServer.DSServer1Trace(TraceInfo: TDBXTraceInfo): CBRType;
begin
Log(TraceInfo.Message);
end;If you now build both server and client and start the server without debugging and then client, you should see in the server window the actual JSON communication between client and server.
Comments
-
Monday, 24 April 2017and this is with XE10 Berlin Update 1, Im having issues with memory corruption, i found one issue in the Firedac Framework of bad unicode char conversion with buffer overruns, now looking for more of the same in DS...
-
Tuesday, 3 March 2009
There's something wrong in the log. The third-to last log entry claims to have read the following data (formatted so you have some hope of reading it):
{
"method": "execute",
"params":
[
{ "handle":[1]},
{"data":[14,,Hello World!#192] }
]
}
The second parameter, named "data", is an array with three elements. The first is a number, 14, the second is empty (which is not valid JSON), and the third is some strange not-quoted string with what appears to be a Delphi character escape (the #192 part).
So there seem to be two problems here: the empty guy and the weird string.
If this is really the data being sent from the client, it isn't using JSON
On the other hand, if the client sent a valid JSON request, which got turned into a set of objects on the server, and the server converted those objects back to JSON for logging purposes, then then "object-to-JSON" logic is broken.
What's the deal?
-Jay -
Tuesday, 3 March 2009
@Jay,
A string that is passed into the OnTrace event handler has already been prepended with additional data like the number of bytes read. I would not except all trace information to be valid JSON. It is more for debug purposes. -
Tuesday, 3 March 2009
Pawel,
That sort of makes sense, but if, as you say, it is for debugging, then wouldn't it make sense for all strings to be quoted, instead of only some? After all...
{ "data": "[2]" }
is very different from...
{ "data": [2] }
Quotes matter!
How is the log supposed to be used for debugging if it presents data in a form that is ambiguous? Why not just use JSON? That way, you could rely on the log to accurately describe the data being passed around.
-Jay -
Please login first in order for you to submit comments
- Page :
- 1
@ Jay
This is interesting - i have found the same thing. The actual JSON however with wireshark contains these odd characters #192 and what seems to be random characters in front of the actual data (in the above case a "," character mine is a ":" or other random group of characters.