Platform Order Attributes and Lifecycle

platform order attributes platform order attributes are divided into the following categories core these are pre defined attributes by the coreos platform although, some of these attributes are optional system these are system defined attributes that indicate the current order state these attributes can only be updated by the platform order orchestrator custom these attributes are defined and configured by the tenant depending on the use case with these attributes, the tenant can set up custom validations and mark them as indexed or non indexed indexed these are attributes that users can utilize to apply filters and retrieve specific data non indexed users are not permitted to apply filters on these attributes and query the order data category attribute name data type expected description core tenant id string the id of the tenant to whose realm the order belongs system order id uuid system generated order id (unique across tenants) core client name varchar core client id varchar client participant id core client order id varchar this is the reference id for the order that was generated by the client this may not be unique in the tenant’s universe core ready to process boolean by default, readytoprocess is set to true if it is set to false, the order will be created but it blocks job creation it can be updated from false to true only true move from created to in progress state automatically (by orchestrator) false order will remain in the "created" state and it will wait for an external command for moving it to in progress state core customer/consignee contact varchar users have the option to provide either contact details or a contact id if contact details are provided, the service will automatically generate and store a contact id, as contact details are considered personally identifiable information (pii) it's important to note that a contact phone number is expected to be a single phone number and not a list the attributes "name", "phone", and "email" are grouped together under the key "contact" core customer/consignee location id uuid although the address will be passed in a standard address format for consumption platform order service, it will be stored as a location in location service the corresponding location id will be stored here core work orders execution flow type enum specifies the order in which the multiple work orders of an order will be executed by the orchestrator start together complete together sequential (default) core cancellation requested boolean by default, this attribute will be false however, it can be set to true by the cancel api the result of the cancellation attempt (async process), will eventually get updated in the system attributes cancelationstatus and cancelationstatustimestamp cancellation requests should be rejected with a suitable error code if a cancellation request is already in process if a cancellation request leads to cancellation failure, this field should still retain its true status if a new cancellation request arrives after the previous request has been successful or failed, the request should be accepted and the cancellation status and cancellation status timestamp need to be reset system cancellation requested on (optional) timestamp system cancellation requested by (optional) varchar system cancellation status (optional) enum none default pending attempting success failed system cancellation failure reason code (optional) varchar system cancellation status timestamp (optional) timestamp if order canceled is true, this field indicates the date/time at which the order was canceled custom custom attributes 1 to n (indexed) key value custom attributes for an order with indexing the tenant will be able to configure validations, if required, for these attributes custom custom attributes 1 to n (non indexed) key value custom attributes for an order without indexing the tenant will be able to configure validations, if required, for these attributes system work order list (optional) list list of work order data system current state (optional) varchar stores the state of the order system current sub state (optional) varchar core ordersummary (optional) ordersummary>>invoicenumber (optional) string invoice number associated with the order could contain alphabets and numbers minlength 3 maxlength 64 pattern ^\[a za z0 9 ]$ ordersummary>>orderdescription string description of the order could contain details on the type of order, its contents, etc minlength 1 maxlength 256 pattern ^(\[a za z])(\[a za z0 9,\s])$ ordersummary>>totalweight (optional) total weight of the order information needed ordersummary>>totalitems (optional) number total number of containers in the order maximum 1000 ordersummary>>totalordercost the total cost of an order system schema version (optional) integer the version of the order schema configuration (for custom attributes) that was active at the time of order creation system createdat(optional) timestamp system updatedat (optional) timestamp system created by (optional) varchar system updated by (optional) varchar 💡 platform order orchestrator the platform order orchestrator allows tenants to pre configure workflows for executing work orders these workflows are based on the work order type and are designed to create subsequent jobs necessary for fulfilling larger work orders by utilizing the assigned workflow, current status, and external plugins, the platform order orchestrator determines the next action required for seamless execution creating platform custom order attribute to create a platform order custom attribute, call the post /config/attributes endpoint and pass the following parameters in the request body parameter description validation data type name name of the attribute minlength 1 maxlength 32 pattern ^\[a za z]{1,32}$ string description description of the attribute minlength 0 maxlength 256 pattern ^(\[a za z])(\[a za z0 9,\s] )$ string datatype the data type of the attribute valid values string, number, boolean, object, array, money string validation specifies all the validations that can be applied to order attributes indexed specifies whether the attribute is indexed filter or search operation based on a custom attribute is only allowed if this field is set as true boolean note some of the core platform order attributes can be updated these attributes are listed below dropdetails contact location ordersummary invoicenumber orderdescription totalweight totalitems totalordercost readytoprocess (false to true only) the following sample payload shows how to create platform order custom attributes named stringvalidations and intvalidations { "attributes" \[ { "name" "maxattempts", "datatype" "number", "indexed" false, "validation" { "required" false }, "defaultvalue" 1, "securitylevel" "open", "delete" false }, { "name" "stringvalidations", "description" "string", "indexed" true, "datatype" "string", "validation" { "range" { "min" 0, "max" 5 }, "regex" "string", "valueoneof" \[ "string123", "string124" ], "required" false } }, { "name" "intvalidations", "description" "int", "indexed" true, "datatype" "number", "defaultvalue" 1, "validation" { "range" { "min" 0, "max" 5 }, "valueoneof" \[ 0,1,2,3,4,5 ], "required" true } } ] } platform order lifecycle a platform order has the following lifecycle states and sub states initiated order created request has been accepted created order has been created in the system (i e workorder & container are created) inprogress\ scheduled a job is created for a work order of that order inprogress\ assigned job corresponding to work order has been added to a dispatch inprogress\ active job corresponding to the work order has been started onhold\ onhold tenant wants to restrict any further actions to be taken by the operations (for ex payment issues for an order / damage issue for an order) executed\ success all instruction of the work order has been successfully completed, now order is remaining for non operational activities (for ex billing) executed\ partial instruction of the work order has been partially completed, now order is remaining for non operational activities (for ex billing) executed\ failed all instruction of the work order has been failed, now order is remaining for non operational activities (for ex billing) executed\ canceled cancellation request has been processed, now order is remaining for non operational activities (for ex billing) closed\ success all instruction of the work order has been successfully completed & no further activities pending closed\ partial instruction of the work order has been partially completed, no further activities pending closed\ failed all instruction of the work order has been failed, no further activities pending closed\ canceled cancellation request raised by a client is processed, no further activities pending platform order service provides the tenant with an option to configure sub states under any of the six lifecycle states and the rules governing the corresponding state and sub state transition