Los SDK de Azure Storage, son bibliotecas cliente que simplifican la interacción de una aplicación con los servicios de almacenamiento de Azure, como Blob Storage, Queue Storage y File Storage. Estos SDKs proporcionan interfaces familiares para realizar operaciones comunes como subir, descargar, listar y eliminar blobs, gestionar colas y acceder a archivos, etc.
Con la evolución constante de las tecnologías en la nube, Microsoft ha impulsado la modernización de sus SDKs para Azure Storage, marcando como obsoletas (deprecated) muchas de las bibliotecas tradicionales utilizadas en proyectos empresariales.
A continuación, se adjunta la información publicada por Microsoft respecto a las librerías que han sido deprecadas:
En el contexto de Dynamics 365 for Finance & Operations (D365 F&O), esta transición representa un cambio crítico para los desarrolladores que integran funcionalidades de almacenamiento de archivos mediante Azure File Storage o Blob Storage. La migración a las nuevas librerías del Azure SDK for .NET no solo es necesaria para garantizar compatibilidad y soporte a largo plazo, sino que también aporta mejoras significativas en rendimiento, seguridad y experiencia de desarrollo. Sin embargo, este proceso conlleva una serie de desafíos técnicos específicos para los entornos de D365 F&O, incluyendo la interoperabilidad con X++, la configuración adecuada de autenticación y el uso correcto de System.Net.Http dentro de proyectos CLR compatibles.
Recientemente, me he visto embarcado en el proceso de migración de librerías Microsoft.WindowsAzure.Storage hacia las nuevas bibliotecas bajo el espacio de nombres Azure.Storage.Files.Shares. Por lo que, aprovecharé este conocimiento adquirido, para proporcionaros algunos ejemplos que os puedan servir de base a la hora de aplicar esta migración al ecosistema de D365 F&O mediante el lenguaje de programación X++.
Una cadena de conexión completa contra Azure Storage presenta el siguiente aspecto:
DefaultEndpointsProtocol=https;AccountName=Nombre_Cuenta;AccountKey=Password;EndpointSuffix=core.windows.net
Abordaremos la forma de conectar dividiendo la cadena de conexión en secciones más pequeñas. Para ello, crearemos una tabla de parámetros a la que llamaremos AzureParameters y que poseerá tres campos: uno para el nombre de cuenta, otro para la Password (preferiblemente encriptada), y un último campo para el directorio principal (root directory). Además, de su correspondiente formulario:
Para nuestro ejemplo, los nombres de los campos, así como los valores contenidos en los mismos, serán los siguientes (por supuesto, los datos de conexión mostrados a continuación son datos inventados):
FileStorageAccountName = “ERDTestAccount”
Corresponde al nombre de nuestra cuenta en Azure.
FileStorageAccountKey = “JEOKDjh85H+cjeJwhTd6Gh2keidP+gSpoFsJ74sR9aH6lfu3F/GJFdRE6B2TbEWX/QhdhfTgdHKr+AGuEY7n3b==”
Corresponde a la Password de nuestra cuenta en Azure.
FileStorageMainDirectory = “https://ERDTestAccount.file.core.windows.net/ERD_PROD”
Corresponde a la URL del recurso compartido en Azure.
A continuación, crearemos una clase de tipo data contract que nos facilite la asignación/recuperación de datos:
La clase service nos permite conectar con un recurso File Share de Azure Storage, testear la conexión, y realizar distintas operaciones en el manejo de ficheros. En nuestro ejemplo, subir un fichero de texto a Azure Storage.
Antes de realizar la migración, con las librerías Microsoft.WindowsAzure.Storage la clase service tenía este aspecto:
Tras realizar la migración a las librerías Azure.Storage.Files.Shares, presentaría los siguientes cambios:
Resumiendo, los cambios aplicados en ambas clases Service y que representan la evolución del código de una versión antigua del SDK de Azure (WindowsAzure.Storage) a una más reciente (Azure.Storage.Files.Shares), han sido los siguientes:
|
Aspecto |
Versión antigua (WindowsAzure) |
Versión nueva (Azure SDK moderno) |
|
Namespaces |
Microsoft.WindowsAzure.Storage |
Azure.Storage.Files.Shares, Azure.Storage.Files.Shares.Models |
|
Credenciales |
StorageCredentials |
StorageSharedKeyCredential |
|
Objeto principal de cliente |
CloudStorageAccount + CloudFileClient |
ShareClient directamente |
|
Conexión (connect()) |
Devuelve StorageCredentials |
Devuelve StorageSharedKeyCredential |
|
Método de test de conexión (testConnection()) |
Usa CloudStorageAccount.CreateCloudFileClient().GetShareReference(…) y Exists() |
Usa ShareClient.Exists(CancellationToken) |
|
Token de cancelación |
No se usa |
Se introduce CancellationToken explícitamente |
|
Subida de fichero (uploadFileTxt) |
Usa CloudFile.UploadText(…) directamente |
Usa MemoryStream, ShareFileClient.Create(), UploadRange() con HttpRange |
|
Referencia a directorio raíz |
Usa CloudFileDirectory desde CloudFileShare.GetRootDirectoryReference() |
Usa ShareDirectoryClient desde ShareClient.GetDirectoryClient(…) |
Cambios técnicos clave:
- Se abandona Microsoft.WindowsAzure.Storage (SDK clásico) por el nuevo SDK modular basado en Azure.Storage, más robusto, seguro, moderno y mantenido por Microsoft.
- Se introduce CancellationToken como buena práctica para operaciones en la nube (permite cancelar peticiones largas o colgadas).
- La nueva versión implementa ShareFileClient.Create() y UploadRange() manualmente, lo que permite un mayor control sobre el proceso de escritura (por ejemplo, carga por rangos, ficheros grandes, etc.).
- En vez de subir el texto directamente como en la versión antigua (UploadText), ahora se convierte en un MemoryStream que se transmite al API. Esto permite más flexibilidad (por ejemplo, añadir compresión, firmar, cifrar…).
Por supuesto, existen muchos otros tipos de operaciones que podemos aplicar con este nuevo SDK, y espero que este ejemplo os sirva de base en vuestras implementaciones.
