4.1.3 Creating and Invoking a Pipeline

The typical PSRP sequence for creating and invoking a successful pipeline on the server is shown in the following table:

Step

Client

Direction

Server

1

The RunspacePool is in the Opened state on the client (section 4.1.1).

The client constructs a CREATE_PIPELINE message (section 2.2.2.10).

The client fragments the message into multiple fragments as needed (section 2.2.4).

The client initializes the pipeline state (section 3.1.1.3.2) to Running.

The client sends the first fragment to the server using a wxf:Command message (section 3.1.5.3.3).

>

The server extracts the PID from the message (section 2.2.1) and stores this value as the pipeline's GUID (section 3.2.1.3.1).

The server initializes the pipeline state (section 3.2.1.3.2) to NotStarted.

The server processes and validates the message.

2

<

The server sends a success message (section 3.2.5.3.4) if validation is successful.

3

If the pipeline message is fragmented into multiple fragments, the rest of the fragments (starting from second fragment) are sent individually using a wxf:Send message (section 3.1.5.3.5).

>

<

The server collects all the fragments until the end fragment (section 2.2.4) is received.

For each wxf:Send message received from the client, the server sends a wxf:SendResponse message (see section 3.2.5.3.6) to the client.

The server processes all the fragments and understands the pipeline to execute.

If a runspace in the RunspacePool is available (section 3.2.1.2.10), the RunspacePool assigns the runspace to the pipeline for execution.

4

<

The server changes the pipeline state (section 3.2.1.3.2) to Running.

Note this state change information is not sent to the client.

The server starts executing the pipeline.

5

The client sends a wxf:Receive message to start receiving data from the pipeline on the server. After each received wxf:ReceiveResponse message (see section 3.2.5.3.8), the client sends another wxf:Receive message until the server indicates that the pipeline is completed (step 8). Sending of input (steps 6 and 7) can happen in parallel.

>

<

The server sends the pipeline result messages (if any): PIPELINE_OUTPUT (section 2.2.2.19), 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), and INFORMATION_RECORD (section 2.2.2.26) using wxf:ReceiveResponse (section 3.2.5.3.8).

6

The client can send any PIPELINE_INPUT messages (section 2.2.2.17) to the pipeline using a                                                                                                                                      wxf:Send message (section 3.1.5.3.5) if the CREATE_PIPELINE message indicated that the pipeline takes input.

>

The server processes the message and dispatches the input to pipeline execution.

7

If the CREATE_PIPELINE message indicated that the pipeline takes input, the client sends an END_OF_PIPELINE_INPUT message (section 2.2.2.18) using a wxf:Send message (section 3.1.5.3.5) after sending all (possibly zero) the PIPELINE_INPUT messages to the server.

>

The server processes the END_OF_PIPELINE_INPUT message and notifies the pipeline execution that no more input is expected.

8

<

After the pipeline execution is complete:

  • The server removes the entry for this pipeline in the RunspacePool's pending pipelines queue (section 3.2.1.2.11).

  • The server changes the pipeline state (section 3.2.1.3.2) to Completed.

  • The server constructs the Completed PIPELINE_STATE message (section 2.2.2.21) and sends it to the client using wxf:ReceiveResponse (section 3.2.5.3.8).

9

The client changes the pipeline state (section 3.1.1.3.2) to Completed.

Show: