From a brief look into this technology, it doesn't seem like any universal decode should be needed here. SOAP/XML over HTTP(S) seems to be the communication protocol, so as long as SSL decryption can be applied, the standard Web/SOAP/XML decode of the DC RUM could be used.
Separate question is what kind of operations could be identified this way. This depends on the format and content of the documents/messages sent from client to server and back. An in-depth analysis of the messages is required to judge it. Possible outcome may vary from precise identification of specific named transactions (if such names could be derived from the content analysis) to rather low-level, technical operations with little relation to the business transactions (if the data formats were designed so), to basically no visibility if the messages were encrypted (this is also possible).
Did you consider approaching this app with the Dynatrace RUM, as an alternative?
Hi Kris, thanks for the answer. We have a running Free Trial using Dynatrace. The issue with Dynatrace RUM is that the application does not use a web client we can inject into. It uses a proprietary XFD client that runs in (only) an IE browser and uses http purely for transport. It is some kind of proprietary use of a part of the .NET framework which is reserved for custom use. If you google or wikipedia XFD it has a little bit about it. We are going to try and install a OneAgent on the actual user desktop and treat it like a server and see what that reveals. My NAM (DCRUM) idea is 'Plan B'. The customer is also apparently asking Abbott Informatics Software if they might consider making adjustments to their application so that Dynatrace could monitor it.