I'm wondering how the product or service order "rejected" state is being used by the community?
If the initial POST request fails (invalid payload, or server side errors) one could consider that a rejection of the order. The synchronous response would have the appropriate HTTP response code but as there is no order, there is no actual rejected state being communicated back. Simply a failure of order creation.I'm wondering what a rejection looks like after the order has been created and started processing? What conditions warrant that state being used as distinct from a failure?
My guess would be a validation error - for example customer is not qualified/eligible for the requested offering, requested service date is infeasible, product for MACD order doesn't belong to the customer, etc.
But other people may have different opinions.
In addition to what Jonathan says, we mostly use that for catalog validation errors. That is, that the information received in the order is consistent with the catalog configuration: the mandatory characteristics are available with the expected values, the specifications are active, etc.
We take the approach that the POST should give a low latency response. That means simple syntax validation, suffient to store the order, with an additional status "created"
The semantic validation (catalog, inventory, other business rules) is then performed assynchronously and results with either "rejected" or "acknowledged" status.
Several years ago we develoepd a state model, which allowed a Service Request to be accepted as a Service Order and handle multiple scenarios of successful completion or failure.
This model was too high level as a single state model and was refined by using sub-states. The following is an extract of this state model. This model has since been refined and improved.
This model is not synchronous as it requires post order acceptance to handle the various interim notifications and final success and failure scenarios. Hope this helps.