This new feature improves the local resources management of 4D Client merged applications executed with Windows Remote Desktop Services. Lets’ see how.
Windows Remote Desktop Services allows users to open a Windows session or a RemoteApp, inside and outside the company network. By doing this, users can connect to their applications from everywhere through an internet connection. When the application is not optimized for Internet bandwidth usage, Remote Desktop Services are often used to limit it: no data is exchanged between the application and the server but only screen changes.
The STANDARD architecture
When a 4D Client merged application connects to a 4D Server merged application, a check is performed to verify that the application source code (compiled code, forms, external resources, etc., usually called “local resources”) on the Client side is the same as the Server side. If needed, the application source code is then downloaded from the 4D Server by the 4D Client merged application and stored in the user folder:
E.g. C:\Users\John Doe\AppData\Local\myApp\myApp_192_168_2_134_19813_157\
So, when several users open the same 4D Client merged application on a Windows server with Remote Desktop Services, local resources are downloaded by each user in its own user folder. There is then a copy of the same files in each user folder.
A new architecture at your disposal
To improve local data storing and transferring, 4D has developed a new option for projects in the BuildApp process to allow local resources mutualization. It is activated by this new BuildApp XML key:
The legacy behavior prevails if the new key has a “False” value or is missing.
And if this new key has a “True” value, the 4D Client merged application will use the local resources placed in this common path:
e.g. C:\Program Data\myApp\myApp_192_168_2_134_19813_157\
Note that the logs folder is still placed in the user folder to avoid concurrent writings.
Windows Remote Desktop Services administrators are often easy with the application update process, but we wanted to remind the best practices for performing updates. An Administrator shall:
1. Disconnect all users running the 4D Client merged application to update.
2. Forbid users access to the 4D Client merged application.
3. Update the 4D Server merged application.
4. If an automatic client update is activated: in the Administrator session, launch the 4D Client merged application and validate the automatic update process. At the end of the process, the 4D Client merged application will be launched, connected to the 4D Server merged application, and automatic local resources updates will be performed in the shared folder.
5. If automatic client update is deactivated: in the Administrator session, update manually the 4D Client merged application and launch it to connect to the 4D Server merged application and perform automatic local resources updates in the shared folder.
6. Allow users access to the 4D Client merged application.
This procedure will ensure that users are not launching several instances of the 4D Client merged application, avoiding concurrent writings to the shared local resources or writing rights errors.
Keep in mind
It was not a best practice to add/modify/delete files or folders in the local resources folder because of automatic updates from the Server. This is even more true with this new behavior because the local resources folder is shared between users and often read-only for standard users! Better use the user’s Documents folder or, eventually, the 4D User preferences folder.