Konfiguracja farmy serwerów frontend AMODIT

Komunikacja w farmie serwerów

Jeżeli AMODIT jest zainstalowany na więcej niż jednym serwerze IIS lub witrynie, to zmiana wprowadzona na jednym serwerze np. w procedurze, regule czy użytkowniku nie będzie widoczna na innych serwerach do czasu wygaśnięcia cache na tych serwerach albo do resetu puli aplikacji.

Podobna zasada dotyczy działania mechanizmu SignalR. Komunikat wysyłany z jednego serwera nie będzie docierał do użytkowników przypisanych do innego serwera.

AMODIT ma wbudowane mechanizmy komunikacji pomiędzy serwerami w farmie ale wymagają one skonfigurowania.

Poniżej przykład farmy serwerów

• Dwa serwery aplikacyjne pracujące jako farma serwerów (amoditap1, amoditap2)
• Na każdym serwerze dwie instancje AMODIT 
  • dla zwykłych użytkowników (amoditap1v, amoditap2v)
  • dla administratorów (amoditap1vadm, amoditap2vadm)
• odrębny serwer z bazą danych (amoditdb)

Konfiguracja

Parametr systemowy LoadBalancedServers

JSON z tabelą zawierającą listę serwerów w postaci

[ {name: "amoditap1v", url: "http://amoditap1v:81"},
  {name: "amoditap1vadm", url: "http://amoditap1v:82"}, 
  {name: "amoditap2v", url: " http://amoditap1v:81"}, 
  {name: "amoditap2vadm", url: " http://amoditap1v:82"}]

UWAGA – w tym przykładowym środowisku, na każdym z serwerów są 2 witryny – normalna i do dostępu administracyjnego. Te witryny muszą mieć oddzielne wpisy.

web.config

W każdej witrynie w web.configu należy podać odpowiednie, unikalne wartości dla klucza WebSiteName, zgodne z nazwą z parametru „name” podaną w wyżej wspomnianym JSON. To jest potrzebne po to, aby „siebie” nie synchronizować.

<add key="WebSiteName" value="amoditap1v"/>

Dostęp

Komunikacja jest poprzez endpoint api/server – powinien on być dostępny anonimowo albo do witryny musi mieć dostęp konto puli aplikacji <location path=”api/server”>…