2017-08-18 1 views
2

Ich habe eine Azure Function App (mit der neueren .net class library Ansatz), die ich mit einem statischen Konstruktor initialisieren, um generierte Ressourcen zu teilen.Azure Function statische Konstruktor Fehlerprotokollierung

Offizielle Dokumentation empfiehlt, Ressourcen wie eine HttpClientin a web api zu teilen.

In der Diskussion am Ende der Dokumentation unter Azure Functions C# script developer reference wird die Platzierung einer HttpClient in einer statischen Variablen erwähnt, um eine erneute Instanziierung bei jeder Anforderung zu verhindern, da sie threadsicher ist.

Ich frage mich zwei Dinge.

  1. Ist ein statischer Konstruktor ok für die Initialisierung meiner teuren zu 'Setup' Ressourcen von allen Anfragen verwendet?

  2. Wenn dieser Ansatz in Ordnung ist, wie sollte die Fehlerprotokollierung in einem statischen Konstruktor konfiguriert werden, wenn die Initialisierung dieser Ressourcen fehlschlägt?

Hier ist meine Klassendefinition

public static class HttpSubmissionTrigger 
{ 
    private static readonly SendGridClient sendGridClient; 
    private static readonly Func<IDictionary<string, object>, string> template; 
    private static readonly EmailAddress senderEmail; 
    private static readonly string emailTitle; 
    private static readonly HttpResponseMessage errorResponse; 

    static HttpSubmissionTrigger() 
    { 
      // ... initialization of above static members here 
    } 

    public static async Task<HttpResponseMessage> Run(...) 
    { 
     // ... use static members here to send emails, respond to client 
    } 
} 

ich die Fehlerprotokollierung in meinem Run Verfahren unter Verwendung der DI des TraceWriter durchführen, die gut funktioniert. Ich kann dies verwenden, um Fehler in der Azure-Portalkonsole für die Funktion anzuzeigen. Statische Konstruktoren können jedoch keine Parameter haben, sodass diese Vorgehensweise bei der Ressourceninitialisierung nicht funktioniert.

Es gibt eine weitere Referenz auf diese Frage in der Azure function docs, aber die Antwort war, die Frage hier zu stellen.

Antwort

2

Sie sind nicht auf den statischen Konstruktor beschränkt, um Initialisierungslogik für gemeinsam genutzte Ressourcen auszuführen. Ein Ansatz, von einigen möglichen, wäre, eine Klasse zu haben, die diese Ressourcen für Sie verwaltet, wo Sie statische Initialisierung durchführen würden, wenn Ihre Funktion aufgerufen wird, Logger und andere relevante Informationen weitergibt und entsprechende Überprüfungen sicherstellt Initialisierung.

Die Funktion Filter verfügen wir bald mit diesen Szenarien wird auch helfen werde loslassen: https://github.com/Azure/azure-webjobs-sdk/wiki/Function-Filters

+0

So sind die Filter sind derzeit für webjobs und wird in Kürze für Funktionen zur Verfügung stehen? Ich habe die Option bemerkt, sie global zu deklarieren, was in Azure Functions keine logische Folge hat (richtig?). Wird diese Geschichte konkretisiert? Dies könnte ein guter Ansatz sein, um mehrere Funktionen mit einer Auth-Schicht abzudecken. – seangwright

Verwandte Themen