Как отключить проверку существования BLOB-объекта в привязке вывода функции Azure

У меня есть аннотации функций Azure, определенные ниже. Триггер большого двоичного объекта считывает данные из процессов учетной записи хранения и использует возвращаемое значение для записи вывода в контейнер больших двоичных объектов с именем файла.json, определенным в привязке.

Это работает, как ожидалось; однако при записи данных в контейнер больших двоичных объектов. Привязка вывода проверяет наличие Blob-объекта с помощью запроса GET и в конечном итоге получает код ответа 404 перед выполнением запроса PUT. Это было зафиксировано в Application Insights.

Есть ли способ изменить это поведение? Снимок экрана аналитики журнала здесь

ПРИВЯЗКИ ФУНКЦИЙ

public class ProcessZipFiles2Cosmos {
    
    @FunctionName("ProcessZipFiles2Cosmos")
    @StorageAccount("blobStorageAccount")
    @BlobOutput(name = "blob_redacted_json", path = "nonpii/{filename}.json")
    public static String run(
        @BlobTrigger(name = "files", dataType = "binary", path = "transactedreturn/{name}", connection = "blobStorageAccount") byte[] content,
        @BindingName("name") String filename,
        @CosmosDBOutput(name = "cosmos_transacted", databaseName = "tax-return-data-ops", collectionName = "TransactedReturns", 
                        connectionStringSetting = "AzureCosmosDBConnection") OutputBinding<String> cosmosItem,
        final ExecutionContext context) {
        
        // function body
    }
}

FUNCTION.JSON

{
   "scriptFile":"../transactedreturn-1.0.0-SNAPSHOT.jar",
   "entryPoint":"com.hrblock.clzconverter.ProcessZipFiles2Cosmos.run",
   "bindings":[
      {
         "type":"blobTrigger",
         "direction":"in",
         "name":"files",
         "path":"transactedreturn/{name}",
         "dataType":"binary",
         "connection":"blobStorageAccount"
      },
      {
         "type":"cosmosDB",
         "direction":"out",
         "name":"cosmos_transacted",
         "databaseName":"tax-return-data-ops",
         "connectionStringSetting":"AzureCosmosDBConnection",
         "collectionName":"TransactedReturns"
      },
      {
         "type":"blob",
         "direction":"out",
         "name":"$return",
         "path":"nonpii/{filename}.json",
         "connection":"blobStorageAccount"
      }
   ]
}

azure azure-functions azure-blob-storage azure-java-sdk azure-log-analytics
person sai n    schedule 26.10.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Когда вы говорите переопределить это поведение, я понимаю, что вы хотите обойти проверку существования, которая в конечном итоге вызывает ошибку 404 (как я ее вижу), выполняемую привязкой Blob. Хотя это было бы возможно, на самом деле это не служило бы какой-либо реальной цели. Неужели ожидаемый 404 действительно так плох?

Что касается того, почему это происходит, я предполагаю, что это происходит при проверке существующего контейнера или других ресурсов, необходимых для вашего конкретного Blob. Трудно сказать, где именно это происходит, исходя только из того, что мы знаем, но в комментариях в SDK WebJobs специально вызывает ExistsAsync, чтобы ограничить ожидаемые коды состояния 40x. Если погрузиться в репозиторий Microsoft.Azure.Storage.Blob, в котором реализован ExistsAsync, вы увидите ExistsImpl ожидается код состояния 404, чтобы определить, существует ли ресурс.

Чтобы обойти ошибку 404, вы можете просто использовать _ 7_, и просто идите вперед и создайте то, что вам нужно, без проверки существующих ресурсов. Однако справедливое предупреждение: это может в конечном итоге вызвать гораздо больше проблем, чем ожидаемый 404 (и, честно говоря, 404 вряд ли вызывает какие-либо проблемы, так как он обрабатывается SDK и библиотекой хранилища).

person eli    schedule 27.10.2020
comment
Да, я хотел избежать этой проверки и перезаписи, если она уже существует или, по крайней мере, ее нет в 404 для этого запроса при использовании Log Analytics для сбора журналов. Я согласен с вами, когда большой двоичный объект записывается в контейнер, это проверка на существование, но мне все равно, существует ли ресурс; Не обновляю; Хотел вслепую перезаписать. Я могу сделать индивидуальную реализацию записи Blob. Но у меня нет способа эффективно записывать журналы внутри аналитики журналов и мне нужно реализовать настраиваемую телеметрию для захвата задержек для каждого запроса, отправляемого в службу. - person sai n; 28.10.2020