Twilio Taskrouter:如何防止队列中的最后一个工作人员被重新分配被拒绝的任务? [英] Twilio Taskrouter: How to prevent last worker in queue from being reassigned rejected task?

问题描述

我正在使用 NodeJS 来管理 Twilio Taskrouter 工作流.我的目标是将任务分配给用 queueSid 标识的主队列中的空闲工作器，除非以下情况之一为真:

I'm using NodeJS to manage a Twilio Taskrouter workflow. My goal is to have a task assigned to an Idle worker in the main queue identified with queueSid, unless one of the following is true:

1. 队列中没有工作人员被设置为空闲

1. No workers in the queue are set to Idle

任务的保留已经被队列中的每个工作人员拒绝

Reservations for the task have already been rejected by every worker in the queue

在这些情况下，任务应该进入下一个由 automaticQueueSid 标识的队列.下面是我为工作流构建 JSON 的方法(它包含一个过滤器，这样来自代理的入站呼叫不应生成对同一代理的出站呼叫):

In these cases, the task should fall through to the next queue identified with automaticQueueSid. Here is how I construct the JSON for the workflow (it includes a filter such that an inbound call from an agent should not generate an outbound call to that same agent):

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;
}

这导致在任务到达队列后没有创建预留.我的事件记录器显示发生了以下事件:

This results in no reservation being created after the task reaches the queue. My event logger shows that the following events have occurred:

workflow.target-matched
workflow.entered
task.created 

这就是它得到的，只是挂在那里.当我更换线

That's as far as it gets and just hangs there. When I replace the line

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

与

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

然后为下一个可用的工作人员正确创建预订，或者如果呼叫进来时没有工作人员可用，则将其发送到 automaticQueueSid，所以我猜 skip_if 是工作正常.所以也许我写目标表达式的方式有问题?

Then the reservation is correctly created for the next available worker, or sent to automaticQueueSid if no workers are available when the call comes in, so I guess the skip_if is working correctly. So maybe there is something wrong with how I wrote the target expression?

我尝试通过将工作人员拒绝预订后设置为不可用来解决此问题，如下所示:

I tried working around this by setting a worker to unavailable once they reject a reservation, as follows:

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 已经生成了一个新的预留并将其分配给同一个工人，并且我的活动更新失败并显示以下错误:

But what seems to be happening is that as soon as the reservation is rejected, before worker.updateWorkerFromSid() is called, Taskrouter has already generated a new reservation and assigned it to that same worker, and my Activity update fails with the following error:

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

最终，worker 似乎自然地设置为 Offline 并且任务确实超时并移入下一个队列，如以下事件/描述所示:

Eventually, it seems that the worker is naturally set to Offline and the task does time out and get moved into the next queue, as shown by the following events/descriptions:

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 中，由在该队列中注册的可用工作线程处理.我不确定为什么要使用超时，因为我的工作流配置中没有包含超时.

After this point the task is moved into the next queue automaticQueueSid to be handled by available workers registered with that queue. I'm not sure why a timeout is being used, as I haven't included one in my workflow configuration.

我很困惑--如何在最后一个工作人员的预订拒绝后让任务成功移动到下一个队列?

I'm stumped--how can I get the task to successfully move to the next queue upon the last worker's reservation rejection?

更新:虽然@philnash 的回答帮助我正确处理了 worker.sid NOT IN task.rejectedWorkers 问题，但我最终还是在更新 worker 的可用性时使用 RejectPendingReservations 参数实现了这个功能.>

UPDATE: although @philnash's answer helped me correctly handle the worker.sid NOT IN task.rejectedWorkers issue, I ultimately ended up implementing this feature using the RejectPendingReservations parameter when updating the worker's availability.

推荐答案

Twilio 开发人员布道者在这里.

Twilio developer evangelist here.

rejectedWorkers 不是 TaskRouter 自动处理的属性.你参考 我的这个答案同事梅根，她说:

rejectedWorkers is not an attribute that is automatically handled by TaskRouter. You reference this answer by my colleague Megan in which she says:

例如，你可以更新 TaskAttributes 以获得一个被拒绝的 worker SID 列表，然后在工作流中说 worker.sid NOT IN task.rejectedWorkerSids.

For example, you could update TaskAttributes to have a rejected worker SID list, and then in the workflow say that worker.sid NOT IN task.rejectedWorkerSids.

因此，为了通过 rejectedWorkers 属性进行过滤，您需要自己维护一个属性，通过 在您拒绝预订之前更新任务.

So, in order to filter by a rejectedWorkers attribute you need to maintain one yourself, by updating the task before you reject the reservation.

让我知道这是否有帮助.

Let me know if that helps at all.

这篇关于Twilio Taskrouter:如何防止队列中的最后一个工作人员被重新分配被拒绝的任务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！