Skip to main content

Transactions

Dime.Scheduler keeps a trail of all the interactions it initiates with the connected backoffice systems like Business Central, Exchange, and webhook connections. The audit trail is available inside Dime.Scheduler itself.

What constitutes a transaction

When Dime.Scheduler successfully posts the data into the connected system, it marks that transaction as successful. What that means exactly will be different for each backoffice system. All Dime.Scheduler looks at to mark a transaction as successful is a 200 HTTP status code.

In the connector for Business Central, a successful transaction means that an item has been posted to the Dime.Scheduler Appointments table, which is then picked up by internal workflows inside Business Central. This is a robust pattern that maximize the resilience of the solution. For other backoffice systems, this proxy may not exist and the processing is done immediately during the request. As always, it entirely depends on your particular setup.

What makes a transaction successsful

We repeat: all Dime.Scheduler looks at to mark a transaction as successful is a 200 HTTP status code in the response. This does not necessarily mean the new planning information was actually processed successfully. All it means is that Dime.Scheduler was able to communicate successfully with the desired endpoint.

Processing the planning data in the backoffice system

When a decoupled solution is deployed (like the staging 'Dime.Scheduler Appointments' table approach in BC), a different type of complexity arises. Even though the backoffice acknowledges that the appointment has been received correctly by returning a 200 code in the response back to Dime.Scheduler, this doesn't necessarily mean that the connected system has successfully processed the appointment internally.

While the item may appear in the staging table, it is possible that the new planning data couldn't be written back to the desired tables. There are many reasons why that might be. For example, in the image below, the assigned resource is missing a 'Unit of Measure' in Business Central:

DS Appointments

As a result, the status of this appointment in BC is Error. So even when Dime.Scheduler considers the item to be sent successfully to Business Central, the appointment may not have processed exactly right in the backoffice system.

tip

More information how to troubleshoot this kind of issues can be found here.

Luckily, Dime.Scheduler makes it easy to create notifications for appointments so planners are aware of this event:

DS Appointments

To summarize, here is how the transaction system is designed in Dime.Scheduler in tandem with Business Central:

Automatic retries

Dime.Scheduler's job is done when the backoffice system returns a 200 status code. In the event that any other HTTP status code is returned, the automatic retry policies may kick into gear to make a few more attempts to reach out to the backoffice system. For transient errors like request timeouts (408), throttling (429), bad gateway (502), unavailable services (503), gateway timeouts (504), and many other kinds of errors, it's possible this was just a one-time or temporary event, in which case a second or third attempt might succeed.

There are three sources where transactions may originate from:

  • Service: initiated by the user in the regular flow of planning appointments on the planning board.
  • Website: when triggered by the retry button in the transactions page.
  • Timer job: Automatic retries for appointments in a failed status.

As soon as some modification is done to the planning, Dime.Scheduler will make the call to the connected systems. In case this transaction fails, the automatic retry job that runs automatically behind the scenes will retry to send all appointments in those states that could possibly return a successful response. It will make 5 attempts, after which it will suspend ongoing retries, assuming the sixth attempt wouldn't make any difference.

If all else fails, or if the administrator made a change to the connector or to the backoffice system itself, they can also manually retry in the detail page of the appointment. The transaction source will indicate 'website' for this action.