Hosting

Das Hosting einer GP-Komponente teilt sich in die Bereiche der Benutzeroberflächen, Workflows und Services auf.

Hosting von UIs

Das Hosting der PresentationEngine erfolgt derzeit über den IIS. Dabei hat diese einen dedizierten Anwendungspool namens Schleupen Presentation. In den konkreten Worker-Prozessen (w3wp.exe) sind die Bestandteile der einzelnen GP-Komponenten enthalten. 

Ausgeführt werden diese Worker-Prozesse auf Hosts mit der DeploymentRolle PresentationServer.

Hosting von Workflows

Hingegen werden Workflows über MassTransit in den Prozessen "Schleupen.CS.PI.BPE.Workflows.MassTransit.WorkflowHostCli.exe" gehostet (WorkflowHost), die wiederum durch den sogenannten ProcessHost verwaltet werden. Diese werden im folgenden als ProcessHost-Jobs oder kurz als Jobs bezeichnet.

Der ProcessHost ist ein Windows-Dienst, der auf einem Host mit der Deploymentrolle WorkflowBackendServer ausgeführt wird.

Unter %ProgramData%\Schleupen.CS\ProcessHost\Jobs liegen die Beschreibungen, die bestimmen, welche Jobs durch den ProcessHost gestartet werden.

Der ProcessHost startet dann anhand dieser Jobbeschreibungen die Prozesse: 

Ein Jobbeschreibung hat dabei z.B. folgenden Inhalt:

{
  "name": "Schleupen.CS.its_Workflows",
  "executable": "C:\\Program Files\\Schleupen\\Schleupen.CS.PI.BPE.Workflows.MassTransit\\WorkflowHosting.Net\\Schleupen.CS.PI.BPE.Workflows.MassTransit.WorkflowHostCli.Net.exe",
  "args": "--Name Schleupen.CS.its",
  "level": "Workflows"
}

Wichtig ist, dass auch Services, die auf Web-APIs basieren, auch über den ProcessHost gehostet werden.

Reihenfolge

CSDeploy muss sicherstellen, dass zu jedem Zeitpunkt der Installation die passenden Jobs laufen. Die korrekte Reihenfolge des Startens der Jobs beim Starten und Stoppen wird hierfür durch den Level angegeben.

Hierbei existieren folgende vordefinierte Werte:

• Services.ServiceRegistry
  • Services der Service-Registry, die mit Consul (von HashiCorp, gekapselte Service-Registry der Web-APIs) kommunizieren. Derartig gekennzeichnete Jobs werden als erstes gestartet.
• Services.Deployment
  • Services, die während der Installation benötigt werden.
• Services
  • Alle anderen Services (WebAPI).
• Workflows.Marktkommunikation
  • Workflows, die für die Marktkommunikation (MaKo-Bausteine) relevant sind.
• Workflows
  • Alle anderen Workflows.

In der Regel wird für Länder / GP-Komponenten Services zu verwenden. Install-CSWorkflows generiert automatisch die passenden Level für die Workflow-Jobs.

Workflows

Der Beispiel-Parameter "Schleupen.CS.its" für die "WorkflowHostCli.exe" fungiert dabei als Filterkritierium der Workflows, die sich unter dem Verzeichnis %Programdata%\Schleupen.CS\Workflows durch die Installation abgelegt werden und in dem "WorkflowHostCli.exe" dann gehostet werden.

In diesen Workflow-Verzeichnissen liegen jeweils u.a. die Assemblies mit den MassTransit-StateMachines und den Datenverträgen.

Der ProcessHost startet dann anhand dieser Jobbeschreibungen die Prozesse: 

Das WorkflowHostCli.exe startet dabei jeweils einen "MassTransit-Host"​​' pro Workflow-Typ:

IBusControl busControl = Bus.Factory.CreateUsingRabbitMq(cfg =>
{
    cfg.Host(new Uri(RabbitMqConstants.Endpoints.HostAddress), "<a workflow type>", h =>
    {
        ...
    });

    cfg.ReceiveEndpoint("<a workflow type>", e =>
    {
        ...
    });
    ...
});

Damit ist ein Job-Prozess Consumer der entsprechenden RabbitMQ-Queue der gehosteten Workflow-Typen.

Resilienzmechanismen

• Retry-Mechanismus von MassTransit mit folgendem Verhalten: exponential backup. Nach Ablauf wird die Nachricht in den Deadletter-Store verschoben.
• Verwendung der Transactional Outbox von MassTransit-
• Circuit Breaker bei der Zustellung von Nachrichten an die Consumer, siehe: Killswitch.

Anmerkung: Wir befinden uns derzeit auf dem Weg der Containerisierung! Das bedeutet, dass sich hier Änderungen von dieser Darstellung ergeben können. 

Hosting von Services

Die WCF-Services werden analog zu Services von Ländern gehostet und abgelegt: Siehe Hosting Länder.

WebAPIs, die auf .net 8 und höher basieren werden per ProcessHost gehostet. Den entsprechenden Jobs wird automatisch ein von ASP.NET Core zu verwendender Port übergeben. Hierzu wird das Argument  --WebAPIPort verwendet.

Resilienzmechanismen

Im Folgenden werden die Resilienzmechanismen des ProcessHosts beschrieben.

Health/Readiness

Es wird regelmäßig ein Health-Check der Jobs ausgeführt, der auf .NET Sockets basiert. Dieser verwendet den mit --Port angegebenen Port. Wenn das Ergebnis fehlerhaft ist, wird der entsprechende Job durch den ProcessHost neu gestartet.

Der Readiness-Check wird u.a. beim Starten verwendet.

Start

Es werden immer nur maximal so viele Jobs gleichzeitig gestartet, wie durch folgende Formel definiert: [Anzahl CPUs]/2. Dadurch soll die durchgängige Lauffähigkeit des System gewährleistet werden. Dies kann in der "app.config" mit  Wert Schleupen.CS.PI.DP.Hosting.ProcessHost.ConcurrentStartRateLimit übersteuert werden.

Logging

Logdateien sind unter %ProgramData%\Schleupen.CS\ProcessHost zu finden.

Das Logging kann mittels "NLog.config" konfiguriert werden. Diese liegt unter %ProgramData%\Schleupen\Windows Services\schleupen.cs.pi.dp.hosting.processhost\NLog.config

Monitoring

Der aktuelle Status der Jobs kann mit dem Cmdlet Get-CSProcessHostJobStatus angezeigt werden:

​​​​​​

Entwicklung

Als Entwickler kann es nötig sein, die Jobs manuell zu starten oder zu stoppen. Dazu gibt es folgende Cmdlets:

Start-CSProcessHostJob -Name "Schleupen"
Stop-CSProcessHostJob-Name "Schleupen" -Wait
Restart-CSProcessHostJob -Name "Schleupen" -Wait

Der Level kann hier auch angegeben werden. Dann werden nur Jobs berücksichtigt, die den angegeben Level haben.

Der Windows-Dienst kann ebenfalls per Cmdlet neu gestartet werden:

Restart-CSProcessHost
Restart-CSProcessHost -Start
Restart-CSProcessHost -Stop

Whitelist

Für Entwickler besteht die Möglichkeit, eine Whitelist in der Windows-Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Schleupen\System, ProcessHostWhitelist anzugeben. Dies ist immer eine mit ; separierte Liste der Job-Namen.

Diese filtert dann die zu startenden Jobs. Dies ermöglicht ein schnelleres Starten nur der für den Entwickler relevanten Jobs.