C ALLBACKS

Apart from being the result of REST-enabled calls to the DataSnap Servers, JSON is also used when implementing callback methods. DataSnap 2010 supports client-side callback functions, executed in the context of a server method. This means that during the execution of a server method (which is called by the DataSnap client), the server can call a callback function which was passed as argument to the server method by the client.

choString method in order to add a callback function to it. The definition of the method EchoString should be modified as follows:

function EchoString(Value: string; callback: TDBXcallback): string;

The TDBXcallback type is defined in the DBXJSON unit. Before we can implement the new EchoString method, we should first see how the callback method can be defined at the client side (after all, it is a client method which can be called by the server).

At the client side, we must declare a new class, derived from TDBXCallback, and override the Execute method.

type

public

function Execute(const Arg: TJSONValue): TJSONValue; override; end;

Inside the Execute method, we get the Arg argument of type TJSONValue, which we can clone and then get our hands on the actual contents. The Execute method could also return

function TCallbackClient.Execute(const Arg: TJSONValue): TJSONValue; var Data: TJSONValue; begin Data := TJSONValue(Arg.Clone); ShowMessage('Callback: ' + TJSONObject(Data).Get(0).JSonValue.value); Result := Data end;

For this example, the callback method will show the value that was passed to the EchoString method, before the method actually returns (i.e. while the method is still being executed). The implementation of the new EchoString method at the server side should now put the string value inside a TJSONObject and pass it to the callback.Execute method, as follows:

function TServerMethods2.EchoString(Value: string; callback: TDBXcallback): string; var msg: TJSONObject; pair: TJSONPair; begin Result := Value; msg := TJSONObject.Create;

pair := TJSONPair.Create('ECHO', Value); pair.Owned := True;

msg.AddPair(pair); callback.Execute(msg);

end;

Note that the callback function is executed (at the client side) and will return before the actual EchoString method finished at the server side.

Finally, the call to the EchoString method at the client side also needs to change, since we now need to pass a callback class an instance of our new TCallbackClient - as second argument. var MyCallback: TCallbackClient; begin MyCallback := TCallbackClient.Create; try Server.EchoString(Edit1.text, MyCallback); finally MyCallback.Free; end; end;

This simple example demonstrates how to use client-side callback methods in DataSnap 2010.

7.

DATASNAP AND .NET WHERE YOU WANT

IT (MORE)

Delphi Prism 2010 is used to build a DataSnap .NET client for the Win32 servers

so far. In order to build the Delphi Prism 2010 DataSnap Client, make sure a DataSnap Server is running so we can connect to it during design-time already.

Start Delphi Prism 2010, and do View | Server Explorer to view the Delphi Prism Server Explorer. We should first make a connection here, to verify that we can actually work with the DataSnap Server.

The Server Explorer is a treeview with a root node called Data Connections. Right-click on Data Connections and select Add Connection. In the dialog that follows, select DataSnap from the list of data sources (note: you need to click on Change if a datasource is already preselected).

to build only DataSnap data connections, of course.

Click on Continue to get to the next page of the dialog. Here, we can specify the details to connect to the DataSnap Server. In the Protocol drop-down combobox, we can select tcp/ip or http. Next, we should specify the Host (i.e. the machine name where the DataSnap Server is running this can be localhost if you are testing on the same local machine). Then you need to specify the Port number. By default this will be Port 80 for HTTP and Post 211 for

this white paper you will know that both values could (or should) be different at least make sure to specify the same value here that you specified in the transport component(s) on the ServerContainerUnitDemo unit.

The next property contains the Path. This is only important if you want to connect to a Web Broker based DataSnap Server (where you need to specify the URLPath to get to the DataSnap Web Server the part after the http://..../ domain part, that is).

ication User name and Password, in case the DataSnap Server is using HTTPAuthentication.

Click on the Test Connection button to verify that a connection can be made to the specified og if everything was specified correctly.

When you click on OK, a new entry for the DataSnap connection will be added to the Data find subnodes for Tables, Views and Stored Procedures. The Tables and Views are empty, but the Stored Procedures will contain all exposed Server Methods from the DataSnap Server. Including our custom server methods EchoString, GetEmployees and ServerTime.

We can now test some of the server methods from the Server Explorer. For example, right- click on the EchoString method and select View Parameters. This will give you a new window parameter. Now, right-

EchoString method from the DataSnap Server, showing the result just below the stored procedure parameters window:

ow we can retrieve and use the data from the Employees table, by using the GetEmployees method. This Stored Procedure an empty list of stored procedure parameters. Again, right-click on this window and select returned by the GetEmployees method: