Hi,

Please note that unlike the FileDirectoryType, FileType’s Methods are implemented by the SDK. Due to their complexity, I also recommend using those, unless you encounter any error (in which case let us know). For FileTypeNode you can call setFile(File object) that the node represents. SDK handles all filehandles etc.

For the FileTypeImpl in client side is a bit complicated, I’ll return to that in later post.

Assuming you are using the Prosys OPC UA Browser, you can r-click on a FileType node in the address space, and it has Read file and Write file options, which will then open a standard “load/save” file dialogs.

The UA Browser (same for the the old Prosys OPC UA Client as well) can only pretty much call basic types for the arguements, i.e. ByteString most likely does not yet work, please use https://www.unified-automation.com/products/development-tools/uaexpert.html instead. But generally you should not need them due to the above.

(and seems the code tag did fail with indentation, but that is probably good enough for now….)

Sorry, I don’t understand.

A bit too broad question, so I’ll try to clarify it a bit, but basically some parts of your question doesn’t exactly make sense. Those parts would be covered by “we do not teach basic java programming” and “Do you know what client-server architecture means?”. It is also possible that I have misunderstood something.

I generally assume you would want to call these FileType UA Object’s UA Methods from the client side? (Since otherwise there is no point to make such objects in the server address space in the first place?). If you instead mean something else, let me know. Rest of this is assuming you mean calling them from the client side.

The pipe so to say is then:

File (Java Object, Client) -> FileTypeImpl (UA Object, Client; calling methods of it, with the code of prev post) -> Network -> FileTypeNode (UA Object, Server) -> File (Java Object, Server)

Please see the codegen manual for explanation of the generated classes and interfaces (but ask of course if something is not clear, it is quite complicated system anyway).

A FileTypeNode without a File object attached to it does nothing. So yes, you will need to create a Java File object that the node represents. (and the basic java programming part is that a File object in java is just an abstraction of a file, it might not e.g. even exist yet, basically it is just a filesystem path).

The reason it is like this is if a server would support so called node management, where a client can add Nodes, it could also add a FileType node usually. If we would just automatically create a backing file (somehow? since there isn’t direct 1:1 mapping on what it actually is, but let’s say we would assume the BrowseName is the file path) one could make it e.g. “C:\Windows\somethingimportannt” and then override it. That would not be good. Therefore instead the FileTypeNode is by default “unbound” from any File thus any method calls to it without a File attached will fail. This is also what I meant earlier that you will need to sanitize user inputs, so that e.g. something like this wont be possible.

You can chose to not use the above methods, but you would end up doing the pretty much same code by yourself. (and that would be “what client-server architecture means”). Those FileTypeImpl methods called is the OPC UA API, there is nothing else you can route to the server. Those methods are implemented inside the SDK in FileTypeNode.

I’ll try to be short, but this is like 5-10 years of SDK history that I would need to explain, as we try to be backwards-compatible, where possible, or at least make it so that changes wouldn’t be too difficult to migrate (not that it always works like that).

The old name of “Prosys OPC UA Browser” is “Prosys OPC UA Client” (see the confusion vs. SDK’s UaClient class), since you linked to that application’s forum I was assuming you meant that.

Generally none of our applications/samples are on the same level as UaExpert for Write/Call operations if the data is anything other than basic numbers, strings i.e. this means that you cannot call the method from SampleConsoleClient, i.e. there is no automatic conversion logic built in (yet), that would know to convert String -> ByteString. You will need to do that manually in code yourself. Basically the only conversions that do work are the ones listed in the OPC UA Specification, version 1.04, Part 4, Table 122 within section 7.4.3 for the event filter cast operator, since that is for what it original was done. But we should probably add some extra rules eventually. But anyway, for ByteString String the option is “X” in both ways in that table, i.e. no conversion possible.

Also it might be possible, that the old “Prosys OPC UA Client” might have allowed some “0x1234567890abcd” form for ByteStrings. Large part of that application had to be rewritten so that all our java based apps share the same UI framework (and that app was our oldest one), so it is possible that we did miss something. We should regradless add something like that eventually to the SDK and to the Browser.

You will need to do a ByteString object in code, with the static factory method ByteString.valueOf(byte[]). For these cases, normally you would already have the bytes e.g. from reading the File object in the client side, like the above code does. But you can use e.g. CryptoUtil.hexToBytes(String)

I make a separate answer post for your queries, as the explanation is long.

Query 2:
Some part is client-server architecture (or so I would say at least), other part of our design how the codegen classes + SDK operate (and how our SDK was before we made the codegen first place in version 2.x). This will be quite long, no way to avoid that.. this is still somewhat explained in the codegen manual in the codegen folder of the SDK zip you downloaded.

Per each OPC UA Type (using name XXXType here as example) we create 5 outputs: an interface named XXXType, 2 classes for client side XXXTypeImplBase (that implement the interface) and XXXTypeImpl (that subtypes the base) and 2 classes for server side XXXTypeNodeBase (implement the interface) and XXXTypeNode (that subtypes the base).

Java lacks partial classes that e.g. C# has. This means there is no way to modify generated code, other than writing to the file. Since we generate a lot, and sometimes we need to create more API and/or change how something internally works. For that reason we emulate partial classes by making one that we can change more freely (XXXTypeImplBase, XXXTypeNodeBase) and one we try to avoid the need to change (XXXTypeImpl, XXXTypeNode), thus you can put them in version control and keep the rest generated only during a build. Also the interface can be used to develop a component that needs to work on both sides. Also note that due to the type subtyping, it is not possible to simply develop an API where the impls would be done just be overriding, since that will not work for situations where a type is an InstanceDeclaration as part of a larger type (so typenodebase extends the supertype’s typenode etc.; is complicated…).

So both the XXXTypeImpl and XXXTypeNode are places where code can be written by the SDK user (or SDK internally for the standard model).

For server side it is more obvious, as usually the OPC UA Method implementations are written there. Additionally there is an initializer method (afterCreate) that can be used to init complex node hierarchies for initial values e.g. for state machine types. Also that allows the SDK server API to be backwards compatible better as the SDK has evolved, since we have like 20 types that add methods to the API from pre-codegen era and/or need some kind of an initialization that the OPC UA Standard model NodeSet2 XML doesn’t provide (that can be done in the afterCreate), plus UA Method implementations of course.

For the client side, well as far as the SDK goes, it is not used that much. There is few helper methods in FileTypeImpl. But there used to be a lot more, however the codegen has also evolved to create some convinience methods so pretty much internally we only need it for the FileTypeImpl. However it should still be noted that we need still an implementation for that interface, plus any of our users might have added their own custom helpers.

Additionally we could e.g. add the 2 methods that I posted to FileTypeImpl eventually. But we’ll do that once we have time and we are sure that is the best way for them to be part of the API (since they might take a really long time, since for e.g. transmitting 1GB File you will do like 100s of OPC UA Method Calls, it might not make sense to have a synchronized version of those).

Additionally due to the SDK design, even though the client and server side are both UaNodes, they pretty much need to be inherited from respective side base classes for things to work properly.

That is about the short version of it with some details skipped.

fileHandle output for the CreateFile: (1.04, Part 5, Annex C.3.4 “CreateFile”)

“fileHandle The fileHandle is returned if the requestFileOpen is set to True.
The fileNodeId and the fileHandle can be used to access the new file through the
FileType Object representing the new file.
If requestFileOpen is set to False, the returned value shall be 0 and shall be ignored by
the caller.”

and for the requestFileOpen Boolean parameter:

“
requestFileOpen Flag indicating if the new file should be opened with the Write and Read bits set in the
open mode after the creation of the file. If the flag is set to True, the file is created and
opened for writing. If the flag is set to False, the file is just created.
“

Thus if the requestFileOpen is true, you will need to do the following:

Long fileHandleAsLong = fileTypeNode.open(serviceContext.getSession(), EnumSet.of(FileTypeOpenMode.Read, FileTypeOpenMode.Write));
UnsignedInteger fileHandle = UnsignedInteger.valueOf(fileHandleAsLong);

Note that there is also modes FileTypeOpenMode.Append and FileTypeOpenMode.EraseExisting, but the spec text only mentions Write and Read bits so thus I’m not adding Append nor EraseExisting to the open.

It is important that it is the version of the open that takes in a session, since the file handles are session-specific.

If for some reason the open call fails, it will throw a StatusException, that should then be thrown also from the CreateFile most likely.

And just in case I’ll refer this post later, the fileHandle is used in all other calls to the FileType node. Basically it is a cursor/pointer within the file. It starts at “index” 0, and its position can be changed via SetPosition Method. Note that it is automatically advanced when doing Read/Write calls, but e.g. if any calls would fail due to e.g. small temporary connection break, you could return from the last known position (the current position can be get via GetPosition). Basically the FileType API is equivalent of Java’s RandomAccessFile.