Hi,

It doesn’t exist originally because in short the Table 125 “Conversion rules” in https://reference.opcfoundation.org/Core/Part4/v105/docs/7.7.3 for the FilterOperator ‘Cast’ doesn’t have any defined conversion for String->ByteString. That was the original purpose of the DataTypeConverter. (Though seems the spec would allow server-specific ones for that). SDK does repurpose the DataTypeConverter for other uses, but that is the history, but regardless it is a best-effort helper, it cannot handle all types, but may serve as a starting point e.g. for UI that for e.g. a “Write component” just has a textbox.

In theory one such conversion could maybe be added. However, it is ambiguous what it should do. One could e.g. transform the String to it’s UTF-8 Bytes (or any other possible encoding). One could assume it being in Hex. One could assume it to be Base64. As far as I know, it is not even possible to 100% correct-guess between Hex and Base64 (since 0x…. would also be possibly a valid Base64-string). And since it would be actually used somewhere, that other end most likely has clearly defined requirements about the ByteStrings content, but the SDK cannot know that. Thus, personally at least currently I think it may be better that the conversion just throws instead of potentially doing the wrong thing.

Also I’ll note that version of the SDK is a bit old, though it wont change the above. But e.g. assuming recent enough version there are:
com.prosysopc.ua.stack.builtintypes.ByteString.fromHex(String)
com.prosysopc.ua.stack.utils.CryptoUtil.base64Decode(String) (or the one in core Java) -> com.prosysopc.ua.stack.builtintypes.ByteString.valueOf(byte…)
that you can use since the application (or it’s user) would know more. If you are building an UI, you could even have options that allow entering all different ways (treat as UTF-8 bytes, Hex, Base64 and possibly more).