Creating a Custom Server (.NET)
If you find that Relativity server doesn't meet your needs, you can very quickly create you own custom Data Abstract server using the project wizard in Visual Studio that out of the box provides the following features:
- Fully functional Data Abstract server that talks to a specified database
- Optional OData and Business Rules Scripting API support
- 3 application run modes - GUI mode (WinForms or WPF), command-line interface or Windows Service
- Windows Service management (installation/deinstallation)
- Single Instance check that ensures only one instance of the server is running
- Startup arguments parser
- Single exception intercept point (useful for logging etc.)
Create a Server
Creating a full featured custom server, as described above, can be achieved in a few simple steps.
1) Open Visual Studio and select File->New->Project
2) In the Template section, go to the the Data Abstract folder and then WPF Project
3) This opens the Template Wizard where you can do some custom configuration for the server.
4) Choose Client and a New Custom Data Abstract Server which will create a solution that creates both a client project and a server project. We'll explore that later. Press Next
5) The next step is to choose a Database Connection which will be used to generate a Database schema. Under Default Connections you will see the PCTrade-SQLite sample database that is supplied with Data Abstract. If you have previously created a Connection, like when using the Schema Modeler, it will be shown in the Connections Library section. If the connection you are looking for isn't available, you can use the last section to create a new database connection. (Not covered here)
Select PCTrade-SQLite and then click Next
6) The template wizard will then analyze the database connection and present the available tables in the next page of the wizard. Choose the ones you are interested in working with, here we are selecting them all. Click Next.
7) The final step allows you to add some customization to the server. You can choose the type of channel you wish to use for the Client & Server. If you wish you can optionally add OData support (which is an HTTP based data access protocol), though its easy to add that later if you desire, and add support for Business Rules Scripting.
Click on Finish and after a short time the wizard will have generated all the required files.
8) When the Wizard is finished, the solution will be opened, and in the Solution Explorer you will see the client and server projects. In the figure here, they projects have been collapsed. DA Custom Server is the client project, DA Custom ServerServer is the server project.
Exploring the files in the Server project
The generated server project contains all the files you need, if you built and ran the project now you would have a running custom server. In this section we will explore what all the files are so that you can understand what you can change / adapt for your own needs.
This is a quick overview of all of the files in the project.
| File | Description |
| App.config | Ordinal .NET application configuration file. Needed to explicitly allow the loading of the .NET Framework 2.0 or 3.5 assemblies into the .NET Framework 4.0+ application. |
| .daConnections file | Contains the underlying database connection parameters. Please note that this file contains database connection parameters, including username and password. |
| .daSchema file | Server Schema definition. Contains information about mapping the physical database tables into logical Schema tables exposed to the client applications. |
| RODL file | Contains definitions of all remote services exposed by this Data Abstract server. This file is used to generate Invoker and Interface code files, which should be regenerated if you make changes to the RODL file |
| _Intf and _Invk files | Invoker and Interface code files generated based on the server RODL file. |
| DataService_Impl file | Auto-generated implementation of the Data Abstract data access service. |
| LoginService_Impl file | Auto-generated implementation of the Data Abstract user authentication service. |
| Engine | Server engine. This component contains all server components needed for a Data Abstract server. |
| MainService | Class that defines the Windows Service that will host this Data Abstract server, if needed (i.e. if the server application will be run as Windows Service or Unix Daemon). |
| ProjectInstaller | Class that provides functionality needed for Windows Service management tools (i.e. service installation and deinstallation). |
| MainForm | Main server form. You might consider to change its ancestor class to ServerBaseForm, which provides more GUI functionality like a tray icon with a context menu. |
| licenses.licx | Plain-text list of classes that require licenses to be provided. This file is used at build time by the license compiler to build and embed the needed licensing information into the resulting assembly. |
| DA_Custom_ServerServer.cs | This code file contains the application server definition class inherited from the ApplicationServer class. |
| Program | Is the entry point into the server, and calls the run method of DA_Custom_ServerServer |
A deeper look at the most important components:
App.config
Ordinal .NET application configuration file. Needed to explicitly allow loading of the .NET Framework 2.0 or 3.5 assemblies into .NET Framework 4.0+ applications.
<? xml version =" 1.0 "?>
< configuration>
<!-- if you don't use the SQLite database, you can remove this file from the project -->
< startup useLegacyV2RuntimeActivationPolicy =" true ">
< supportedRuntime version = "v4.0 " sku = ".NETFramework,Version=v4.0 " />
</ startup>
</ configuration>
This is the recommended place to store application settings, connection strings etc. Please refer to MSDN article for more details.
.daConnections and .daSchema files
The .daConnections file and .daSchema file define database(s) connection parameters and server Schemas. Both files can be edited using Schema Modeler.
RODL file and Invoker and interface files
RODL file can be edited using Service Builder.
If Service Builder was launched via double-click on the RODL file in solution explorer, the Invoker and Interface files will be regenerated automatically to reflect all changes made to the RODL. Otherwise the developer has to generate the interface and invoker code using the Service Builder Codegen menu, and then paste that code into the appropriate files manually.
In most cases there is no need to add any custom methods to the DataService and LoginService definitions.
Data Access Service and Login Service implementations
Data Access Service implementation is generated automatically and can be used as is.
At the same time, one has to re-implement the Login method of the Login Service. This method calls code that checks user credentials and performs the authentication procedure. Authentication code generated by default is very simple and accepts any user credentials where user name and password match.
Engine
This component contains the very heart of the Data Abstract server.
It contains the network connectivity components responsible for data transfer over the wire, the session management component and the connection manager:
- Server Channel
- Message
- AES Message Envelope (optionally)
- Session Manager
- ConnectionManager (The class)
- Engine class
MainService
This is the classic Windows Service definition class. Please take a look at the code behind the file, this is where the server startup and shutdown procedures are implemented, and has calls added to the Engine class.
ProjectInstaller
This is another classic Windows Service-related component. This component is responsible for the Windows Service install and uninstall procedures and doesn't contain any Data Abstract-specific code.
DA_Custom_ServerServer.cs
Note: The name of this code file matches the server project name and might differ for your projects.
This code file contains the application server definition class inherited from the ApplicationServer class.
The ApplicationServer class is a helper class that provides an easily extensible way to create application servers that can be run as Windows Service, WinForms application, console application or Unix Daemon with just a few lines of code. This class is used not only in server applications created by the New Project Wizard; the Relativity Server, Olympia State Server and RO ZeroConf Hub also use the ApplicationServer descendant class to perform startup procedures.
Command Line Processing
Out of the box the server based application recognizes the following command-line arguments (not case-sensitive):
| Parameters | Description |
| -I, /I, --INSTALL | Install service |
| -U, /U, --UNINSTALL | Uninstall service |
| -Q, /Q, --QUIET | Suppresses messages on service installation and deinstallation |
| -C, /C, --COMMANDLINE | Runs in CLI mode |
| -D, /D, --DEBUG | Requests extended debug info (i.e. full stacktraces) |
| -H, /H, -?, /? | Shows command-line arguments help messages |