Do you need to build a customized 4D connection dialog? Interested in connecting your client application to different servers? These are two scenarios that 4D v18 lets you to handle. This blog post is for you if you want to create a custom remote connection dialog and connect it to merged 4D servers. Keep reading!
Why should I write my own connection dialog?
There are several use cases for modifying 4D’s built-in connection dialog:
- CUSTOMIZATION
You want to customize the standard dialog for remote connections to the server.
- MULTIPLE SUBSIDIARIES
When deploying your application and creating several distinct databases. For example, a different database for each subsidiary of a group. In the connection database, you can manage which servers and databases users can connect to and allow them to connect directly.
- ARCHIVE DATABASE
Another way of using a custom dialog is to choose which archived fiscal year database users can access.
- APPLICATION PORTAL
If you deploy several products and want your users to use a single “portal” application to connect to each product.
Use case
A software publisher has a server farm hosted in the cloud with each server corresponding to a specific business need. Previously, they deployed as many remote applications as the number of users that could access the servers. Now, they can they can deploy a single remote application for all servers with a “directory” database. Using HTTP requests or remote datastores, each server sends its status and connection information to the “directory” server. The connected merged application can then query the directory database, view a list of available servers, and connect to one.
How to do that?
CREATING CONNECTION DATABASE
First, you need to create a connection database containing your own connection dialog. The OPEN DATABASE command has been extended to permit connecting to a 4D Server. Generate a 4DLink file containing the server location and port, then pass it as a parameter to the command. The standalone application will automatically stop its code and connect to the server, becoming a typical remote application.
Here’s a code snippet from a server selection dialog where Form.selectedServer contains the 4D Server information:
If (Form.selectedServer#Null)
C_TEXT($xml)
C_OBJECT($link)
$xml:="<?xml version=\"1.0\" encoding=\"UTF-8\"?><database_shortcut is_remote=\"true\" server_database_name=\"FA_RemoteConnexionServ\" server_path=\""+Form.selectedServer.IP+":"+Form.selectedServer.portID+"\"/>"
$link:=Folder(fk user preferences folder).file("server.4dlink")
$link.setText($xml)
OPEN DATABASE($link.platformPath)
End if
When your connection database is ready, you just need to build a compiled database.
MERGING TARGET DATABASE
Only merged client applications can connect to merged servers. Therefore, we developed a new mechanism in the build application process to allow embedding the connection database into the merged client application.
We’ve created the new BuildApp keys, DatabaseToEmbedInClientWinFolder and DatabaseToEmbedInClientMacFolder, to contain the paths of the compiled connection database. This way, when building the final client/server application, the build application process will embed the compiled connection database into the client application and change its name.
This application can run without a data file or any licence. However, if you need a data file, you can place a “Default Data.4DD” file in a “Default Data” folder near the compiled structure. In this case, the licence for a standalone merged application is integrated during the build application process.
This is a merged client application structure without an embedded database (“legacy client”):
This is a sample of BuildApp keys to embed a connection application:
<DatabaseToEmbedInClientMacFolder>
::connectionApp_Build:Compiled Database:connectionApp:
</DatabaseToEmbedInClientMacFolder>
This is a compiled connection database:
And finally, this is a merged client application structure:
HOW DOES IT WORK?
At runtime, the merged client application will open the embedded connection database and then allow the user to select the merged server to connect to. If a default data file is used, it’s in read-only mode.
Note that the automatic update process from the merged server is still available. When the merged connection application connects to the server, if its version is not in the server’s range, an automatic update is launched as it would if the application was a standard merged client application!