A PreOperation plug-in on Create of the order table calculates a pricing tier that a separate PostOperation plug-in on the same message must use. The tier must not be stored in a column. How should the value be passed between the two steps?
Select an answer to reveal the explanation.
Short Explanation
SharedVariables is like a sticky note passed between the steps of your pipeline. The PreOperation step writes the note, and the PostOperation step reads it, all within the same request. Static fields are the trap here, because they leak between users and threads.
Full Explanation
IExecutionContext exposes SharedVariables, a collection that plug-ins registered on the same message and table can use to pass data between steps in a single pipeline execution, including from PreOperation to PostOperation. The PreOperation step adds the computed tier under an agreed key, and the PostOperation step reads it with the same key, so nothing is stored in a column. Static fields are a common mistake: plug-in instances are cached and reused across concurrent requests, so a static value written for one order could be read while processing another order, causing incorrect and unpredictable results. OutputParameters represent the response of the message and are populated by the core operation; PreOperation steps should not use them as a scratch area, and values placed there are not a supported channel between steps. Entity images are snapshots of the row's columns before or after the operation as configured at registration; they cannot carry arbitrary computed values. Exam caveat: when a step triggers a child pipeline, values set in the parent are reached through the parent context's SharedVariables rather than the child's own collection. Operational check: write the tier to SharedVariables in PreOperation, log it from the PostOperation step's trace, and confirm the two values match for a test order.