Статус пакетного геокодирования Azure Maps 202 12+ часов спустя

Я использую RestSharp для программного создания / создания / десериализации вызова API Карт Azure для пакетного геокодирования. В настоящее время тестирую процесс с пакетом из 5 адресов - я ожидал, что это быстро пройдет после всех сообщений о «10 тыс. Адресов за минуты». Но запрос, который я вчера успешно отправил, все еще недоступен, а только показывает статус «Принято 202», что документация говорит, что он все еще обрабатывается ... и в страница статуса.

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

Мой вызов POST генерируется с помощью приведенного ниже кода и возвращает статус ОК с необходимым заголовком Location с тем, что выглядит как действительная ссылка.

public RestRequest CreateBatchRequest()
{
    var request = new RestRequest($"{_batchAddressEndpoint}subscription-key={_apiToken}", Method.POST);
    request.AddQueryParameter("api-version", _version);

    var batchRequestBody = GenerateQueryBatch();

    var requestBodyJson = JsonConvert.SerializeObject(batchRequestBody);

    request.AddHeader("Content-Type", "application/json");
    request.AddParameter("undefined", requestBodyJson, ParameterType.RequestBody);

    return request;
}

protected AzureBatchRequest GenerateQueryBatch()
{
    var requestBody = new AzureBatchRequest();

    foreach (var address in Addresses)
    {
        var addressString = $"{address.Address}, {address.City}, {address.State}";

        if (!string.IsNullOrEmpty(_country))
            addressString = $"{address.Address}, {address.City}, {address.State}, {_country.ToUpper()}";

        requestBody.Queries.Add($"?query={addressString}&limit={_resultLimit}");
    }

    return requestBody;
}

Это дает мне параметр тела для запроса, который, похоже, соответствует документации (фактические адреса скрыты по соображениям конфиденциальности, но они были успешно геокодированы другими службами) ...

{
    undefined={"queries":[
        "?query=123 MAIN ST, LOS ANGELES, CA&limit=3",
        "?query=123 MAIN ST, PLEASANTVILLE, CA&limit=3",
        "?query=123 MAIN ST, STOCKTON, CA&limit=3",
        "?query=123 MAIN ST, SAN DIEGO, CA&limit=3",
        "?query=123 MAIN ST, REDDING, CA&limit=3"
    ]}
}

Я получаю значение заголовка Location и делаю с ним вызов GET, используя приведенный ниже код ...

public List<Coordinate> DeserializeBatchResponse(RestResponse response)
{
    var batchLink = response.Headers.Where(header => header.Name.Equals("Location")).FirstOrDefault();

    var request = new RestRequest(batchLink.Value.ToString(), Method.GET);

    var batch = SendRequest(request);

    if (batch.StatusCode == System.Net.HttpStatusCode.Accepted)
    {
        var isProcessing = true;

        while (isProcessing)
        {
            Thread.Sleep(TimeSpan.FromSeconds(60));

            request = new RestRequest(batchLink.Value.ToString(), Method.GET);

            batch = SendRequest(request);

            if (batch.StatusCode != System.Net.HttpStatusCode.Accepted)
                isProcessing = false;
        }
    }
}    

И он никогда не выходит из этого цикла. Когда я жестко кодирую URL-адрес, возвращенный из вчерашнего запроса POST, он ведет себя так же, как и то же самое при попытке в Postman изолировать от остальной части моего кода.

У кого-нибудь есть понимание?

ОБНОВЛЕНИЕ

Мы обнаружили, что после создания нового плана на более высоком уровне (уровень S1, а не уровень S0) не было заметной задержки для пакетных вызовов. Все еще не решение, как таковое, потому что это лишает нас возможности использовать продукт для производственных целей, но, возможно, это исправление для других, пока обновления, упомянутые в принятом ответе, не будут реализованы.


person jdmac020    schedule 19.12.2018    source источник


Ответы (1)


Этого следовало ожидать на данный момент при предварительном просмотре. Это скоро перестанет быть предварительным просмотром и будет происходить значительно быстрее.

person rbrundritt    schedule 19.12.2018
comment
Команда также рассматривает небольшое обновление для предварительного просмотра, чтобы улучшить его производительность, пока производственная версия находится в стадии завершения. - person rbrundritt; 26.12.2018