3.1.4.5 Getting Command Metadata

The higher layer triggers the sending of a GET_COMMAND_METADATA message (section 2.2.2.14) to get the metadata of commands (section 2.2.3.19) available in a RunspacePool. The RunspacePool MUST be in the Opened state (section 3.1.1.2). When sending this message and receiving responses from the server, the client uses similar data structures that are used for executing a pipeline (section 3.1.4.3).

The following activities happen as part of sending the GET_COMMAND_METADATA message and receiving responses from the server. The client expects certain specific messages from the server at each stage, as described below. If the client does not receive the expected messages at any stage, then the client terminates the Getting command metadata higher-layer triggered action and notifies the higher layer. If a wxf:Fault message is received at any stage, the client reports the failure to the higher layer and stops the Getting command metadata action in the same manner as described in section 3.1.5.3.13.

  1. The client creates a new pipeline data structure (section 3.1.1.3), assigns a unique GUID to this pipeline (section 3.1.1.3.1) and initializes the pipeline state (section 3.1.1.3.2) to Running.

    The client adds this pipeline instance to the RunspacePool's pipeline table (section 3.1.1.2.6).

    The client constructs a GET_COMMAND_METADATA message (section 2.2.2.14) and sends it to the server.

  2. If a wxf:CommandResponse message (section 3.1.5.3.4) is received, the client stores the CommandId (sections 3.1.1.3.4 and 3.1.1.1.2) and sends a wxf:Receive message to start receiving data from the server.

  3. At this stage, the client receives result messages from the server and sends the result data to the higher-layer. Only the following result messages are expected at this stage. If the client receives any other message, then the client MUST stop the pipeline (section 3.1.4.4). The messages expected at this stage are the following: PIPELINE_OUTPUT (section 2.2.2.19) containing either CommandMetadataCount (first Output received, see section 2.2.3.21) or CommandMetadata (subsequent Output received, see section 2.2.3.22), ERROR_RECORD (section 2.2.2.20), DEBUG_RECORD (section 2.2.2.22), VERBOSE_RECORD (section 2.2.2.23), WARNING_RECORD (section 2.2.2.24), PROGRESS_RECORD (section 2.2.2.25), INFORMATION_RECORD (section 2.2.2.26), PIPELINE_HOST_CALL (section 2.2.2.27), and PIPELINE_STATE (section 2.2.2.21).

    The CommandMetadataCount (section 2.2.3.21) MUST be the first Output (section 2.2.2.19) message received and it specifies the number of subsequent CommandMetadata (section 2.2.3.22) Output messages received by the client. The client SHOULD process only this number of CommandMetadata Output messages.

    When a PIPELINE_STATE message is received, or when the higher-layer stops the Getting command metadata action, the client stops executing these steps.

  4. If a PIPELINE_STATE message (section 3.1.5.4.21) is received, the client changes the pipeline state (section 3.1.1.3.2) as per the message received and notifies the higher layer.

  5. When the pipeline reaches the Completed or Failed state, the client removes the pipeline instance from the global pipeline table (section 3.1.1.1.2) and the RunspacePool's pipeline table (section 3.1.1.2.6).