search

oneM2M / Issues-Questions

Issues & Questions concerning oneM2M specifications
0 stars 0 forks source link

mgmtCmd EXECUTE response? #4

Open Spongman opened 2 years ago

Spongman commented 2 years ago

in TS-0001 Table 10.2.8.18-1: \<mgmtCmd> EXECUTE it says "It shall also provide in the response the URL of the created resource"

ankraft commented 2 years ago

I thing the full text reads

It shall also provide in the response the URL of the created \<execInstance> resource.

This is similar to other async or non-blocking requests: The CSE creates a resource that holds the original request, has the state of the request and will later also hold the response of it. The request originator needs to know the URI of the created instance in order to check its status and retrieve a response later. That is this URI.

presumably this can be multiple if a is specified?

No, I don't think that \ is involved here. And even if it would be, then the response to a<group>/fopt would be a single aggregated response.

Spongman commented 2 years ago

but this is not in response to a CREATE request, it's an UPDATE on the mgmtCmd's execEnable:

The Execute procedure shall be used by an Originator in order to trigger execution of a specific management command on a managed entity, by employing an UPDATE method to the execEnable attribute of an existing resource on the Hosting CSE.

also, wrt. groups:

if the execTarget attribute of the addressed addresses a group, the Hosting CSE shall create corresponding resources for each target in the group and provide the corresponding URLs in the response

8.1.3 specifies the form of the response to an UPDATE request. where are these new execTarget URLs suppsoed to go?

ankraft commented 2 years ago

You are right. I remembered a different procedure.

In TS-0004, clause 7.4.16.2.3.2 Update (Execute), the procedure is explained in detail. Step 3:

3) The Receiver shall copy the following attributes from to each created: execMode, execFrequency, execDelay, execNumber, and execReqArgs. The execStatus of is set to INITIATED. The Receiver shall set the execTarget attribute of each sub-resource to the URI of each target resource.

Spongman commented 2 years ago

sure, but those copied attributes are placed in the new execTarget resource. the response to the UPDATE request, however, only contains attributes of the resource being updated - the mgmtCmd. again: where are the URLs of the new execTarget resources returned?

Spongman commented 2 years ago

also, how does one EXECUTE a single mgmtCmd at two different times to two different targets? is it possible to perform two different UPDATE requests that each update both the execTarget AND execEnable attributes simultaneously?

ankraft commented 2 years ago

sure, but those copied attributes are placed in the new execTarget resource. the response to the UPDATE request, however, only contains attributes of the resource being updated - the mgmtCmd. again: where are the URLs of the new execTarget resources returned?

I have to say that this seems to be missing for now. One can do a DISCOVERY request to find the \ resource, but this is not convenient at all. I agree, there should be a RO attribute that is a list of all the \ resources for a particular UPDATE (execution) request.

ankraft commented 2 years ago

also, how does one EXECUTE a single mgmtCmd at two different times to two different targets? is it possible to perform two different UPDATE requests that each update both the execTarget AND execEnable attributes simultaneously?

I think this should be possible. A new EXECUTE should create new \ resources for that request.

Spongman commented 2 years ago

yeah, doing a DISCOVERY to find out which execInstance was the one created by the previous UPDATE is obviously prone to sequencing errors if there are multiple simultaneous UPDATE calls in-flight.