Client Methods

Call a Method in the context of its owning Object, with values matching the advertised argument signature. You need a connected and authorized Session.

Milo 1.2.0-SNAPSHOT, Java 17. Source baseline 7faaf4f0516c.

Select ObjectId and MethodId

A CallMethodRequest contains both the ObjectId and MethodId. The ObjectId identifies the instance on whose behalf the operation runs. The MethodId identifies the callable Method. Browse the Object's HasComponent relationships and the Method's InputArguments and OutputArguments properties.

Do not substitute the Method's type-definition object. A server can share a Method node among objects and dispatch to different per-object handlers, so do not assume the same MethodId means the same object binding everywhere.

Executable and UserExecutable describe availability, but the Call result is authoritative. Server state or permissions can change after you read those attributes.

Use Call and inspect the result

This helper expects a square-root Method with one Double input and one Double output. The caller supplies the correct object and method NodeIds. The local fixture attaches it to NodeIds.ObjectsFolder. Another server's model will use different identifiers.

static double callSquareRoot(OpcUaClient client, NodeId objectId, NodeId methodId, double input)
    throws UaException {
  Variant[] inputs = {new Variant(input)};
  var request = new CallMethodRequest(objectId, methodId, inputs);

  CallResponse response = client.call(List.of(request));
  CallMethodResult result = requireNonNull(response.getResults())[0];
  if (!result.getStatusCode().isGood()) {
    throw new UaException(result.getStatusCode());
  }

  Variant[] outputs = requireNonNull(result.getOutputArguments());
  return (Double) outputs[0].value();
}

With an input of 16.0 the fixture method returns 4.0. A String input produces Bad_InvalidArgument with a corresponding Bad_TypeMismatch input result. The helper throws on a non-Good method result. Use the raw result when you need per-argument status for a UI or log.

The batch client.call(List<CallMethodRequest>) returns a CallResponse. Validate the service result, expected result count, and each CallMethodResult separately. A Good service result only means the Call service request was processed. getInputArgumentResults() explains per-argument status. Decode outputs only when the method result permits it, and check them against the signature.

High-level calls set ReturnDiagnostics=0 and do not request getInputArgumentDiagnosticInfos(). Request diagnostics with a custom CallRequest and RequestHeader through sendRequest(...) or sendRequestAsync(...). Servers may still omit them. A null or empty getInputArgumentResults() or getInputArgumentDiagnosticInfos() array does not mean the arguments passed validation.

Typed helpers and value types

UaObjectNode.getMethod(String) assumes the Object's namespace for the Method BrowseName. Use getMethod(QualifiedName) when the Method belongs to a different namespace, as with the fixture's sqrt(x) under the namespace-zero ObjectsFolder.

Inspect the Method's getInputArguments() and getOutputArguments() for names, DataTypes, ValueRanks, dimensions, and descriptions. An empty array can also mean the argument property could not be read. It does not prove the Method takes no arguments.

UaMethod.call(Variant[]) returns output Variants on success and throws UaMethodException for a non-Good operation result. The exception retains input-argument results and any supplied diagnostics, though UaMethod requests none. The asynchronous call completes exceptionally for both service and operation failure.

Build inputs in the declared order, using the correct Milo Java representation. A missing argument, extra argument, wrong scalar or array rank, or invalid value may fail differently. Correct types do not make a value valid. A server may still reject a negative speed or a state transition. For structures and ExtensionObjects, use Data types.

Failures, retries, and ownership

A method may perform side effects before a connection breaks. A timeout or exceptional completion does not prove it did nothing. Retry only when the operation is idempotent or the application protocol supplies a transaction identifier or another way to determine the outcome. A batch of methods is not atomic.

Method wrappers hold client and model references and need no separate shutdown. The caller owns the connection and any asynchronous work. Do not invoke a blocking method from an SDK callback if it can stall that callback's delivery path. Hand long work to a bounded application executor and preserve the result and its error cause.

Examples and reference

• MethodExample: Call a Method using its ObjectId and MethodId.

• MethodExample2: Resolve a UaMethod and inspect its argument metadata.

• Runnable fixture: WikiClientGuideTest

• Call service

• UaMethod and result conversion

• UaMethodException diagnostics

Related pages

Client SDK · Server methods · Data types