As shown in Figure 3, the IDL UI of DST has many features to serve operational workflows. DST users in AusBOM are retrained every time a new release is deployed. If DST moved to the enterprise with a browser-based client (note: this is simply an idea and does not imply in anyway about Bureau's inclination towards such an idea), its UI should work with features that are very similar to the desktop UI. One prototyping example is shown as Figure 4. Even though the core functions of the DST could be modified to IDL tasks working on a backend server, the web-based client would need to be developed from scratch and a map server would need to be set up for DST to operate as a web application.
Alternatively, a future enterprise DST can go with an IDL client, which will have almost the same look-and-feel UI as currently in operational use. The IDL client itself can display map-related information just as the desktop DST does. There’s no need to set up a map server. However, at the backend a database server would need to be added. This eliminates local file writing, such as writing the event log in JSON files (a prototype example shown in Figure 5), and warning transmission log in .sav files that are currently implemented in the desktop DST.
This change is one of the “must-be-done” items for the DST to go enterprise. It will ultimately manage synchronizing event logs, bulletin counters, and product generation for multiple users simultaneously using the DST. Currently in the desktop DST, the synchronizations are handled by file-locking and merging local files with remote files, which takes care of occasional dual users simultaneously using DST.
Of course, other issues may need to be addressed for the IDL client to run successfully on any machine. The L3Harris Solutions Delivery team can support assessing and performing code changes. For the DIY crowd, online documentation and tech support may provide the resources to make needed changes to the original IDL application.
On the backend, running IDL or ENVI tasks on GSF does require a license. If performance degrades when the number of IDL client users increase, you may need to scale up GSF by running the tasks on multiple nodes with a license on each node, which is beyond the scope of this article. More information about GSF can be found here.
Let’s recap before wrapping up this topic. It’s worth considering IDL client UI as an option when converting IDL legacy desktop applications to enterprise applications. The main reasons to use the IDL UI for this are:
No license is required to run IDL client in the IDL Virtual Machine.
Significant portions of the desktop application code can most likely be reused in developing its enterprise version.
Training costs for application users may be much less because the application UI may stay the same. Frontend users will likely not notice any changes.
If a browser-based client UI becomes necessary later, it should be easy to replace the IDL client because no changes are needed on GSF at the backend.