Categoria: Azure

Sharepoint i Net 4.5

La API de sharepoint ha canviat i això requereix utilitzar oauth. Podem fer-ho amb el exemple que propociona al tutorial al docs:

https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/using-csom-for-dotnet-standard

  1. Ves al Portal de Azure AD: https://aad.portal.azure.com
  2. Selecciona Azure Active Directory i registres d’aplicacions a l’esquerra
  3. Selecciona New registration
  4. Introdueix un nom per a la aplicació i selecciona Register
  5. Aneu a Permisos de l’API per concedir permisos a la aplicació, seleccioneu “Add a permission”, tria SharePoint, Delegated permissions i selecciona AllSites.Manage
  6. Selecciona Concedir consentiment de l’administrador per consentir els permisos sol·licitats per l’aplicació
  7. Seleccioneu Authentication a l’esquerra
  8. Canvia “Allow public client flows” a Sí
  9. Selecciona Overview i guarda Application ID

Nota: si no seguíssim pas per pas les instruccions de configurar una aplicació a Azure ens podem trobar els següents errors:

A més a més poden sorgir altres errors:

  • El usuari no és vàlid, o no te renovada la contrasenya, o està inactiu: aquestes gestions no seràn possibles ja que no tenim previst fer prompt de la pàgina de AD per fer canvi de contrasenya, etc.

Després cal personalitzar la classe AuthenticationManager que donen al exemple ja que està pensada per a Net Core o superiors, però no NET Framework cal fer un seguit d’adaptacions. Aquí fetes, res del altre món:

Enroutament i React

Tenir l’aplicació ben enroutada no significa què després el enllaç amigable sigui funcional al 100%: si no es dins del context de la aplicació React. Per a aquesta raó s’haurà de dir al servidor HTTP que redireccioni qualsevol petició diferent a la ruta de index a la mateixa què el propi index que executa la aplicació.

En alguns casos com pot ser ASP MVC amb l’extensió de SPA, el propi host IIS o autohost de NET Core es configura per redireccionar aquestes peticions. En NodeJS passa exactament el mateix al desplegar-lo com una aplicació React Client.

En altres entorns no es ben bé així, com pot ser Apache o Azure Static Web Apps.

Apache:

Caldrà crear un fitxer .htaccess pròpi a la carpeta on es situï el build i dins caldrà especificar les següents línies

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /subdirectory
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule . /index.html [L]
</IfModule>

Azure Static Web Apps:

Caldrà crear un fitxer amb el nom staticwebapp.config.json i afegir les següents línies de configuració:

{
    "navigationFallback": {
        "rewrite": "index.html",
        "exclude": ["/static/*"]
    },
    "mimeTypes": {
        ".json": "text/json"
    }
}

Per a més informació:

Latència de una Azure Function

Revisió gener 2020: Aquesta entrada va ser escrita al 2018 en plena fase de desplegament. Actualment les Azure functions v2 i v3 ofereixen el always on què disminueix dràsticament la latència de les funcions. Les funcions escrites amb Net Framework només poden anar amb V1 que ara mateix està en camí a deprecated.

Des Azure fa un temps els webjobs de les WebApps d’Azure s’estan traslladant a funcions. Això el teu els seus avantatges, com no consumir recursos de les instàncies de WebApp i consumir-ne sota demanda.

Tot és correcte fins que les versions actuals de serveis no ofereixen quelcom bàsic: estar sempre actives. Això és vital qual la funció es dedica a llegir una cua: o pot estar desactiva sempre o pot estar osiosa esperant a respondre. Les Azure Functions al no tenir Always On són el primer cas: desactiva fins que es digui el contrari. Doncs es plantegen dos solucions: (A) fer un pas enrere i tornar a workers o (B) fer un mecanisme de mantenir sempre viu.

Imatge
La latència de les respostes del encadenat de processos és alt degut al temps de warm up de una Azure Function

La solució A implica desplegar una sèrie de llibreries que tenen ús crític de la CPU a una instància WebApp que ja de per si ja té pics de CPU. Descongestionar la instància de aquests pics és una prioritat.

La solució B implica refórmular el codi de lectura de cues per a que quan a la senyal de vida, una senyal que anomenarem keep_alive. Un altre funció Azure inserirà a la cua cada X (definirem el temps com una variable de configuració per a trobar el rendiment òptim) un missatge de keep_alive que els diferents processos encadenats en cues només hauran de retransmetre de la cua d’entrada a la de sortida.

És una forma de mantenir els processos de la cua ociosos, tampoc és una novetat. Són principis que vaig veure a clustering amb heartbeat/pacemaker o més simples, per evitar que el IIS decidís que era bon moment posar-se en repòs.

El problema és què pot saturar les cues (1), pot sobrecarregar els serveis (2) i pot implicar un consum extra (3). Així que caldrà trobar el equilibri entre mantenir una latència optima: una repetició de la senyal keep_alive que no desajusti el sistema i dispari els costos.

Imatge
En vermell: un keep alive cada 10 segons, en blau cada 20 segons, en verd cada 30.

Provem 3 períodes per a l’enviament de keep_alive: cada 30 segons, cada 20 segons i després cada 10. La Azure Function té aproximadament un període de 10 segons per a aixecar-se (warm up a actiu) i de repòs molt menor (al acabar ja passa a repòs).

El fet de mantenir-lo a 30 s’aconsegueix que les peticions intercalades entre les senyals de vida passin de pics de 120 a 60. Segueix sent un temps d’espera elevat per al client, que voldria resoldre les peticions en el menor temps possible.

Reduint el keep_alive a 20 segons reduïm els pics a 30 segons. La meitat de la meitat. I a 10 segons aconseguim que els pics es redueixin a menys de 10 segons.

El curiós de tot això és que són processos que a la versió de desktop mai vam aconseguir que arribessin a aquests números. Les Azure Functions amb una bona conjunció de SQL Server i optimització poden arribar a mostrar molt bons resultats.