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.

💡

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:

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 namedstringValidations 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 six lifecycle states:

• Initiated: In this state, the Client Order and its respective Work Orders are registered in Platform Order Service and are awaiting validation confirmation from the external plugin (if configured).
• Created: Once the Order is validated using the external plugins (if configured), the entries are created for Work Order. This state means one of the following:
  • The Order is validated but awaiting the ‘Ready To Process’ signal.
  • The Order is validated and is ‘Ready To Process’ but it is yet to be picked up by Order Orchestrator.
• In-progress: This state signifies that at least one Work Order of the Order is being processed, i.e., a job has been created for the Work Order by the orchestrator, and at least one Work Order is in the ‘In-progress’ state.
• On-hold: This state can be used by Apps to put the state transitions in cases where orders are temporarily withdrawn from their execution/fulfillment lifecycle. It is an additional option that can be opted out by the user. If this state is used, it will put Work Orders and associated Jobs on hold this means that the associated Job can not be assigned to Dispatch.
• Executed: This state signifies that all the Work Orders of the Order have been ‘Completed’.
• Closed: This state signifies one of the following:
  • The order was executed and all post-execution processes (for example, billing, payment, collection) for the Order have been ‘Completed’.
  • The Order validation 'Failed'.
  • The Order was ‘Canceled’ before the execution was started.

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.

State transition Rules

• The state transition to and from the Initiated state will be managed and triggered by the Platform Order Service only.
• If the Order is set to On Hold, the state of the job will be on hold and it will not get assigned for Dispatch.
• When the ready to process is set to false, all transitions to non-terminal states are restricted. This means that transitions such as "created to in-progress" and "created to on hold" will only occur when the "readyToProcess" is set to true, which can be achieved through an external update API.