This type of monitoring will allow customers or technical support to get notified and act on particular cases. 

There are various mechanisms provided by the Fluent platform that support business monitoring:

• Log events
  Custom rules can create specific log events that can be polled and consumed regularly by the monitoring or reporting systems. The log events can contain the required information and can be used to provide an audit trail for particular entities.
  More information see: Log Action & Events
• Webhook notifications
  Like log events, webhooks can notify a monitoring or reporting system of business exception scenarios.
  More information see: webhooks
• Reporting via GraphQL
  The Fluent GraphQL API can be used to extract & generate specific reports, for example, a report which lists orders that have been "stuck" in a particular status for a period of time. These can also be displayed in the Admin Console.
  More information see: Bulk Extracts with GraphQL

• Event polling (ORCHESTRATION & ORCHESTRATION_AUDIT)
  For certain scenarios, such as inventory loading, specific events are being generated, which allow monitoring the progress of a process or exception scenarios. The Fluent Event API provides various filter parameters which will allow to "monitor" particular cases
  More information see: Event API - Event Queries & Inventory Load Verification & Duration

Similar to business monitoring, a 3rd party monitoring or reporting system can be used to alert and provide the corresponding information exposed by the Fluent platform.

To support technical monitoring, the following mechanisms can be used:

• Log events
  Custom rules can create specific log events which can be polled and consumed on a regular basis by the monitoring or reporting systems. The log events can contain the required information of the technical issue e.g., a particular exception that occurred.
• Webhook notifications
  Similar to log events, webhooks can be used to notify a monitoring or reporting system of technical exception scenarios.
• Exception events
  Exception events can be polled via the Events API on a regular basis by a monitoring or reporting system using the category and from/to filters. The retrieved information can be used for alerting & monitoring mechanisms. These events usually contain information on specific rules which have failed and the corresponding entities and also contain low-level stack traces.
  

1{{fluentApiHost}}/api/v4.1/event?category=exception&from={{fromDate}}&to={{toDate}}&count={{count}}

• API responses
  Each API call against the Fluent platform (REST or GraphQL) will return to corresponding response codes & messages if the API call is unsuccessful. It is the responsibility of the source system to handle any error response. Some of the API calls are being recorded in specific audit events.
  More information see: Event API - Event Queries
• Event polling (ORCHESTRATION & ORCHESTRATION_AUDIT)
  Similarly to business monitoring the Event API can be used to extract specific ORCHESTRATION and ORCHESTRATION_AUDIT events to identify events that have not triggered a ruleset. For example, where the event status resulted in a NO_MATCH.
  More information see: Event API - Event Queries

In case of any business or technical issues which require manual intervention, the issue needs to be thoroughly  investigated, and it is clear what the root cause is via:

• ORCHESTRATION and ORCHESTRATION_AUDIT events (any exception events, unexpected NO_MATCH events, ...)
• understanding of the workflow execution (and how the ORCHESTRATION and ORCHESTRATION_AUDIT events relate to it)
• GraphQL queries of the relevant entities
• understanding of the relevant custom plugin code & platform rules which form part of the execution

Manual intervention can be done via the following:

• (Re-) Sending of an event
  Events can be manually sent into the platform via the Event API. This will re-trigger the corresponding business logic (and execute the workflow rulesets). 
  

1POST {{fluentApiHost}}/api/v4.1/event/sync

1{
2  "name": "{{ruleset_name}}",
3  "accountId": "{{fluentAccountId}}",
4  "retailerId": "{{retailer_id}}",
5  "entityId": "{{entity_id}}", // for legacy entities such as ORDER, FULFILMENT, LOCATION... (order, location, fulfilmentOption domains)
6  "entityRef": "{{entity_ref}}", // for new entities such as VIRTUAL_POSITION, INVENTORY_CATALOGUE, BILLING_ACCOUNT... (gi, billing account, return order domains)
7  "entityType": "{{entity_type}}",
8  "attributes": {
9    // custom payload goes here
10  }
11}

1{
2  "name": "VirtualCatalogueEvent", 
3  "retailerId": "{{retailer_id}}",
4  "entityRef": "BASE:{{retailer_id}}",
5  "entityType": "VIRTUAL_CATALOGUE",
6  "rootEntityRef": "BASE:{{retailer_id}}",
7  "rootEntityType": "VIRTUAL_CATALOGUE",
8  "attributes": {
9    "ref": "{{ip_ref}}",
10    "inventoryCatalogueRef": "DEFAULT:{{retailer_id}}"
11  }
12}

• Manual Event with Run-Once Workflow
  In some cases, it is necessary only to execute specific rules or parts of a workflow (without triggering further logic in the workflow. This can be achieved via events with a run-once workflow.
  More information see: Manual Event with Run-Once Workflow
• Direct GraphQL
  Some scenarios require direct modification of data without executing any business logic. This can be achieved via GraphQL mutations:
  More information see: Graphql mutation