Currently, it is not possible to call an OPC UA method, including structured data types arguments. This has been a requirement for a while, but has been moved further to the next future. OPC UA standards and specification include very often the use of OPC UA methods in a following manner: the client calls the method with a structured OPC UA data type argument. The server (or better to say the PLC behind the server) accepts the call and writes the received data into a Variable Data type in the OPC UA tree. This help confirming that the method call was successful, down to the PLC. By using the same structure as method argument data type and variable type within the tree structure (which is generated from the data type), modelling the OPC UA tree is consistent, re-usable and avoid errors by manually copying the structure element by element potentially many times - as many as the structure is used. This is why types and structures are created for.
The current ACMfg implementation of method calls allows only flat Base Data type arguments. If a structured data type is included as an argument, the OPC UA clients "sees" a BLOB that is then can be passed to an integration flow and parsed. The product lab recommendation is to used here DFDLs. Unfortunately, DFDL modeling has to be done manually, on each new or modified data type structure and requires error-prune counting of bits and bytes by downloading the XML type structure from the OPC UA server. Of course, this is a possibility, but requires a dramatically increased implementation effort, which make ACMfg less attractive to clients, because of the higher TCO and dependency on external implementors and skills. Moreover, DFDL usage in the App Connect community is very rare, the performance might be potentially affected and the DFDL roadmap - unclear.
The idea: provide an implementation for using structured data types arguments in the following way:
1. provide an Integration Toolkit-supported generation of a message type for each structured data type argument by following the reference to the Data Type Structure in the Types part of the OPC UA tree (potentially recursively) and generating a message. This could be also an XML/XSD that then could be imported into the Integration Toolkit.
2. Use the message in the method node for parsing / unparsing the structured data type arguments as well as in the integration flow
Preliminary, the point 1 functionality could be provided short-term as an asset, before it is integrated into the product in one of the following releases.
I provide a test case in the zip file as an attachment with the nodeset output from SiOME (Siemens free downloadable tool for OPC UA modeling) as well as an implementation of the typical pattern described above with the Open Source based Python OPC UA server. It can be used with a client, like UAExpert to see the described functionality as well as to run the tests.
I am happy to support in case of questions.
BTW, this is an important request for a client project implemented jointly by my company GEC and IBM.
Greetings
Plamen
Thank you for taking the time to raise this enhancement request and also for the time taken to explain the idea to our Product Management team. We understand that you have been able to successfully utilise DFDL in order to meet this use case so we will not be pursuing further.