Twilio Taskrouter: Как предотвратить переназначение отклоненного задания последнему работнику в очереди? - PullRequest
Новая
       26

Twilio Taskrouter: Как предотвратить переназначение отклоненного задания последнему работнику в очереди?

0 голосов
/ 27 марта 2019

Я использую NodeJS для управления рабочим процессом Twilio Taskrouter. Моя цель состоит в том, чтобы задача, назначенная на неработающего работника в основной очереди, обозначалась queueSid, если не выполняется одно из следующих условий:

  1. Рабочие в очереди не установлены в режим ожидания

  2. Резервирования для задачи уже были отклонены каждым работником в очереди

В этих случаях задача должна перейти к следующей очереди, обозначенной automaticQueueSid. Вот как я создаю JSON для рабочего процесса (он включает в себя фильтр, так что входящий вызов от агента не должен генерировать исходящий вызов для того же агента): 

configurationJSON(){
    var config={
        "task_routing":{
            "filters":[
                {

                    "filter_friendly_name":"don't call self",
                    "expression":"1==1",
                    "targets":[
                        {
                            "queue":queueSid,
                            "expression":"(task.caller!=worker.contact_uri) and (worker.sid NOT IN task.rejectedWorkers)",
                            "skip_if": "workers.available == 0"
                        },
                        {
                            "queue":automaticQueueSid
                        }
                    ]

                }
            ],
            "default_filter":{
                "queue":queueSid
            }
        }
    }
    return config;
}

В результате резервирование не создается после того, как задача достигает очереди. Мой журнал событий показывает, что произошли следующие события: 

workflow.target-matched
workflow.entered
task.created

Это так далеко, как он получает и просто висит там. Когда я заменяю строку 

"expression":"(task.caller!=worker.contact_uri) and (worker.sid NOT IN task.rejectedWorkers)"

с 

"expression":"(task.caller!=worker.contact_uri)

Тогда резервирование корректно создается для следующего доступного работника или отправляется на automaticQueueSid, если на входе нет доступных работников, поэтому, я думаю, skip_if работает правильно. Так может быть что-то не так с тем, как я написал целевое выражение?

Я попытался обойти эту проблему, установив недоступность работника после того, как он отклонил резервирование, следующим образом: 

clientWorkspace
.workers(parameters.workerSid)
.reservations(parameters.reservationSid)
.update({
    reservationStatus:'rejected'
})
.then(reservation=>{
//this function sets the worker's Activity to Offline
    var updateResult=worker.updateWorkerFromSid(parameters.workerSid,process.env.TWILIO_OFFLINE_SID);
})
.catch(err=>console.log("/agent_rejects: error rejecting reservation: "+err));

Но, по-видимому, происходит то, что как только резервирование отклонено, перед вызовом worker.updateWorkerFromSid() Taskrouter уже сгенерировал новое резервирование и назначил его тому же работнику, и мое обновление Activity завершилось неудачно со следующей ошибкой : 

Error: Worker [workerSid] cannot have its activity updated while it has 1 pending reservations.

В конце концов, кажется, что для работника естественным образом установлено значение «Не в сети», и задание останавливается и перемещается в следующую очередь, как показано следующими событиями / описаниями: 

worker.activity.update
Worker [friendly name] updated to Offline Activity
reservation.timeout
Reservation [sid] timed out
task-queue.moved
Task [sid] moved out of TaskQueue [friendly name]
task-queue.timeout
Task [sid] timed out of TaskQueue [friendly name]

После этого задание перемещается в следующую очередь automaticQueueSid для обработки доступными работниками, зарегистрированными в этой очереди. Я не уверен, почему используется тайм-аут, поскольку я не включил его в свою конфигурацию рабочего процесса.

Я в замешательстве - как я могу заставить задачу успешно перейти в следующую очередь после отклонения резервирования последнего работника?

ОБНОВЛЕНИЕ: хотя ответ @ philnash помог мне правильно решить проблему worker.sid NOT IN task.rejectedWorkers, в конечном итоге я реализовал эту функцию с помощью параметра RejectPendingReservations при обновлении доступности работника.

1 Ответ

1 голос
/ 28 марта 2019

Разработчик Twilio здесь.

rejectedWorkers не является атрибутом, который автоматически обрабатывается TaskRouter. Вы ссылаетесь на этот ответ моего коллеги Меган , в котором она говорит:

Например, вы можете обновить TaskAttributes, чтобы иметь список отклоненных рабочих SID , а затем в рабочем потоке сказать, что worker.sid NOT IN task.rejectedWorkerSids.

Итак, чтобы отфильтровать по атрибуту rejectedWorkers, вам нужно сохранить его самостоятельно, обновив задачу перед тем, как отклонить резервирование.

Дайте мне знать, поможет ли это вообще.

...