Support for opc-twin module api direct method calls with input arguments (not requiring OPC Twin micro services)

[DidierDrogba2]

Hi, want to call some opcua-methods with the opc-twin restapi. The restapi and the authentication worked just fine for me, but every time I want to call a method with some arguments I get the same error. Methods which dont take any parameters work fine.

Example Request body (using postman):

Example Response:

Also if run the method with no argument the request will get to the server (and will fail there):

The api documentation says that the parameter arguments exprects an < MethodCallArgumentApiModel > array which contains the
keys dataType and value. All of these are optional.

[DidierDrogba2]

• this is the post url:
  https://{{OPC-SERVICEURL}}/twin/v2/call/myDeviceId?nodeId=urn%3Afreeopcua%3Apython%3Aserver%23i%3D2031

[cristipogacean]

@DidierDrogba2, can you check if calling this method works when using the engineering tool UI?

Everything you did seem to be fine. So maybe you want to double check if the nodesId (method&object) are correct and the method's attributes have the datatypes, order and count as expected by the server. If you can confirm that, we will have to validate if indeed this is a regression.

[DidierDrogba2]

I just checked and i definitely used the correct nodeId and attributes. But I got this issue with every method of my opc server(if the method gets one or more input arguments). I changed the method itself temporary so that no input arguments are required. You can see the response below (The same node I used before):

The engineering tool works too.

[NoTuxNoBux]

In case it is relevant: I'm also working on invoking methods on an OPC UA server using OPC Twin, and I got it to work both with a command without arguments, and one with a simple string argument.

However, I'm going through the TwinModuleClient that's part of the NuGet packages, not directly to the API. I then use client.NodeMethodCallAsync with the appropriate EndpointApiModel (with OPC UA TCP URI), and the MethodCallRequestApiModel which looks something like this:

ImmutableList<JsonElement> argumentList = ...;

new MethodCallRequestApiModel()
{
    MethodId = "ns=1;s=setLanguageMethod",
    ObjectId = "ns=1;s=Foo:Bar:System:Language",
    Arguments = argumentList.Select(x => new MethodCallArgumentApiModel() { DataType = "String", Value = jsonElementToVariantValueConverter.Convert(x) }).ToList(),
}

(The JsonElementToVariantValueConverter is a simple class that just checks ValueKind and does (VariantValue)element.GetString() if it is a string.)

If I serialize the above object, I get something like this:

{
    "MethodId": "ns=1;s=setLanguageMethod",
    "ObjectId": "ns=1;s=Foo:Bar:System:Language",
    "Arguments": [
        {
            "Value": {
                "PropertyNames": [],
                "Value": "english",
                "Values": [],
                "Count": 0,
                "IsListOfValues": false,
                "IsArray": false,
                "IsObject": false,
                "IsDecimal": false,
                "IsInteger": false,
                "IsInt64": false,
                "IsUInt64": false,
                "IsDouble": false,
                "IsFloat": false,
                "IsTimeSpan": false,
                "IsDateTime": false,
                "IsGuid": false,
                "IsBoolean": false,
                "IsString": true,
                "IsBytes": false
            },
            "DataType": "String"
        }
    ],
    "MethodBrowsePath": null,
    "ObjectBrowsePath": null,
    "Header": null
}

This probably happens because the Arguments property accepts VariantValues, but it might also be the case that this is resolved internally afterwards in the API client.

Not sure if that helps in any way, but I hope it does.

[hansgschossmann]

@NoTuxNoBux are you using the OPC Twin module standalone? Usage in context of Industrial-IoT is only tested as part of the end-to-end use via the REST API as pointed out in our documentation:
OPC Twin: The OPC Twin module enables connection from the cloud to OPC UA server systems on the factory network. OPC Twin provides access to OPC UA server systems through REST APIs exposed by the Industrial-IoT cloud microservices. In contrast to OPC Publisher, in OPC Twin, working in standalone mode (module only) isn't supported. The OPC Twin module must work in combination with the Industrial-IoT cloud microservices.

We have no plans to enable use of Industrial-IoT OPC Twin standalone functionality, but will offer a subset of its functionality as part of another product.

[NoTuxNoBux]

@NoTuxNoBux are you using the OPC Twin module standalone? Usage in context of Industrial-IoT is only tested as part of the end-to-end use via the REST API as pointed out in our documentation:

Partially, yes, mainly the API client library without the microservice, and I seem to have completely missed that information, thanks.

Right now since we have an Azure Function that needs to talk to the Twin, and the additional microservice seemed an unnecessary cost as it wraps the API client we could instantiate ourselves in a couple of lines, but we can still rather easily insert it as intermediary if it becomes problematic later on.

[marcschier]

Release 2.9.0 preview 2 of OPC Publisher was just released. It supports the OPC Twin API which can be invoked without cloud services. Documentation will be provided soon.

Regarding variant value: The variant value is just an object (it is similar to JObject or JDocument, but supports msgpack also), it can be any valid json in the payload in and out that conforms to the encoding rules for JSON in Part 6 of the OPC UA spec.