In xRoute request, it seems like maximumWorkingTimeBetweenBreaks parameter is not considered in configurableWorkingHours

[marius.vladutoiu]

In the sample xml file attached, containing a xRoute request, in the tourRestrictions, configurableWorkingHours are added.
Regardless of the value that I set for the maximumWorkingTimeBetweenBreaks, no tour events of type Break are inserted (in the sample, it is set as low as 3600).
But as I look at this route result, there is a lot of working time, so I was really expecting some breaks to be inserted based on this parameterization (there is a lot of service time defined on each waypoint + driving time in between, so I was expecting breaks based on working time. I set the maximumDrivingTimeBetweenBreaks very high in the sample file on purpose to make sure that any breaks inserted are not due to that setting).

Note: the maximumDrivingTimeBetweenBreaks works fine, as soon as I make it a lower number (ex. 3600), several breaks are inserted.

A similar issue I seem to have with maximumTravelTimeBetweenDailyRests. It seems not to be considered for daily rest event insert. Also, if I set it too low compared to maximumDrivingTimeBetweenDailyRests (for example, set the maximumTravelTimeBetweenDailyRests to 18000), then even the Raw Request Runner stops with error "The tour information could not be calculated. The scheduling component returned an internal error."

Can you please help me understand what is happening? Is my understanding/expectation of these parameters wrong, or the way they are setup, or indeed some other issue?

XRoute-calculateRoute-request.xml

(6.78 KiB) Downloaded 21 times

[Bernd Welter]

Hi Marius,

agreed - that looks buggy. At least I have no direct explanation for that behaviour.
I created an internal ticket (268078)...

Code: Select all

 "tourRestrictions": {
      "configurableWorkingHours": {
        "breakRule": {
          "breakTime": 900.0,
          "maximumDrivingTimeBetweenBreaks": 32600.0,
          "maximumWorkingTimeBetweenBreaks": 3600.0,
          "workingTimeThreshold": 0.0
        },
        "dailyRestRule": {
          "dailyRestTime": 10800.0,
          "maximumDrivingTimeBetweenDailyRests": 70002.0,
          "maximumTravelTimeBetweenDailyRests": 60000.0,
          "dailyRestPosition": "ANYWHERE"
        }
      }
    },

Bernd

[Bernd Welter]

Here's some feedback from DEV (Yann via ADOS-268078):

The bug has been found.
[..]
But, this configuration is not really correct.
"maximumDrivingTimeBetweenBreaks": 32600.0,
"maximumWorkingTimeBetweenBreaks": 3600.0,
In this case, the maximumDrivingTimeBetweenBreaks is never used, because breaks will be always set because of maximumWorkingTimeBetweenBreaks.

More generally, if the maximumDrivingTimeBetweenBreaks >= maximumWorkingTimeBetweenBreaks, the maximumDrivingTimeBetweenBreaks should be ignored, because it will never happen.

For this special case, if it is the real settings of the customer, then a simple workaround would be to not set the attribute maximumDrivingTimeBetweenBreaks.
If only one of the 2 values is defined, there is no problem at all.

From my current understanding this underlying fix will be part of the next standard xServer 2.39.

[marius.vladutoiu]

Hi Bernd,

Thanks for the feedback. It would be great for this to be fixed as soon as possible.
Yes, I agree with your dev that if maximumDrivingTimeBetweenBreaks>=maximumWorkingTimeBetweenBreaks, then maximumDrivingTime BetweenBreaks should be ignored, because it will never happen.

But ideally they would be setup together. For example:

maximumDrivingTimeBetweenBreaks = 4.5 hours
maximumWorkingTimeBetweenBreaks = 5.5 hours

In this case, depending on the work/driving that needs to be done on the tour, either one of the setups could determine the break insert.

Just to clarify, in my example, I made the extreme configuration of maximumDrivingTimeBetweenBreaks = 9 hours, while maximumWorkingTimeBetweenBreaks = 1 hour, not because it would be a real setting of the customer, but because I smelled during my own testing that the maximumWorkingTimeBetweenBreaks was not kicking in at all (like in my realistic setup just described above), and so I made this extreme setup so that I could definitely prove to myself that maximumWorkingTimeBetweenBreaks would not kick in at all, only the maximumDrivingTimeBetweenBreaks.

So of course this is not a realistic setting, only done to prove that there might be a bug with maximumWorkingTimeBetweenBreaks, when also the maximumDrivingTimeBetweenBreaks is sent in the request.

Hope this makes sense. Meanwhile, until it's fixed, we'll have to see how to work around the issue (ideally both param would be sent).

But also, there was another point in my initial post, and I have not seen any reaction on that, regarding the similar parameter maximumTravelTimeBetweenDailyRests, which also seems to either not be considered at all, or even to return some kind of internal scheduling component error.

It would hep to also know in this area if there is an issue and how to overcome it until it's fixed.

[Bernd Welter]

Cheerio,

I reopened ADOS-268078...

Let's wait for the DEVs reaction.

Bernd

[Bernd Welter]

Yann added this:

For the 2nd part of the question:
There are plenty of rules that are defined to be sure that the tourRestrictions parameters are consistent.
One of them is that,
maximumDrivingTimeBetweenDailyRests ≤ maximumTravelTimeBetweenDailyRests + dailyRestTime.
With your test, an exception is thrown because 70002 > 18000 + 10800.

Unfortunately, it's quite long to list of the rules.
We have expanded the exception thrown to provide more details in an attempt to determine why the configuration is incorrect.
At least, an internal error code is returned that may help us to find the cause of the problem.

[marius.vladutoiu]

Based on the new info regarding rules, in order to test whether maximumTravelTimeBetweenDailyRests was considered correctly, I set my case up like this:
maximumDrivingTimeBetweenDailyRests = 7200
maximumTravelTimeBetwenDailyRests = 3600
dailyRestTime = 10800

so that 7200 ≤ 3600 + 10800

then indeed the breaks were inserted based on the maximumTravelTimeBetweenDailyRests kicking in faster than the maximumDrivingTimeBetweenDailyRests.
So then, that's ok, I understood where the issue was, although, I really don't understand the formula itself:

maximumDrivingTimeBetweenDailyRests ≤ maximumTravelTimeBetweenDailyRests + dailyRestTime

As Yann said of the smaller break-related parameters:
"More generally, if the maximumDrivingTimeBetweenBreaks >= maximumWorkingTimeBetweenBreaks, the maximumDrivingTimeBetweenBreaks should be ignored, because it will never happen"

Following the same logic (which I totally agree with), it would have been enough to set the rule for this at:

maximumDrivingTimeBetweenDailyRests ≤ maximumTravelTimeBetweenDailyRests (since you can never drive between daily breaks more than the total travel time between daily breaks, which would see possible if you add in the mix this '+ dailyRestTime')

But anyways, one last thing here:
Maybe the list of such validations/rules to make sure all tourRestrictions parameters are consistent is long, but is it possible to at least get the main ones (or the most common sense ones)? Otherwise, the customer could set it up wrongly, and the error returned would be so generic that he would not know where the mistake to be corrected is (as in the case that I did). Then, based on the rules, we could do some common sense field validations directly in UI, so that user is warned of the potential mistakes while he is parameterizing, so that such mistakes would never even get into an actual request.
If not, we'll try some minimum common sense validations.

Thanks.
Marius

[Bernd Welter]

Hello Marius,

I forwarded youre last response to Yann who will look into this in the next days.
He requires some time for a proper reaction but he promised to return to your task...

Stay tuned,
Bernd