...
Beslutet tas i sammanhanget av den infrastruktur vi har idag och hur omgivande miljöer/lösningar ser ut. Dvs inga krav på HA tillämpningar som exempel. När ny infrastruktur finns på plats 2023 är det antagligen relevant att titta på möjligheterna att flytta in detta där i den i takt med att lösningarna som nyttjas har kommit att bli mer kritiska samt större i omfattning och flöden.
...
Arkitektur för servrar (Beslut #1)
A Köra vidare i PoC deployment | B Greenfield | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | Vi sätter inte upp nya serverar utan använder samma som används i ärendehanteringen för Lön & Pension | Vi sätter upp nya servrar för Dev,Test och Prod | ||||||||||||
Pros and cons |
|
| ||||||||||||
Estimated cost |
|
|
Finns på plats. 
Sattes inte upp optimalt från början, utan utvecklades under projektets gång.Olika typer av deploy av Camundas processmotor (Beslut #2)
A. Köra vidare med embeded process engine | B. Greenfield enligt Camunda med remote process engine | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | Processmotorn deployas i ett Spring Boot-projekt tillsammans med övrig Java-kod. Detta är så vi har gjort i ÄHS för Lön & Pension | Processmotorn körs i en egen docker-container och deployas separat från övriga kod. | ||||||||||||
Pros and cons |
|
| ||||||||||||
Estimated cost |
|
|
...
Grad av separering för Camunda för internt och externt nyttjande (Beslut nr 3).
Låta Camunda stödja både CaseManagement och SupportCenter från samma instans eller ha en för resp (CaseManagement resp SupportCenter) dvs en uppdelning i internt och exteternt.
...
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
A. Ha både intern och extern instans på samma servrar | B. Separera intern och extern instans på olika servrar | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | Vi använder samma servrar för externt och internt bruk, men med olika Camunda-instanser för varje applikation. | Olika servrar används och vi deployar till olika beroende på vart Camunda ska vara tillgängligt ifrån. | ||||||||||||
Pros and cons |
|
| ||||||||||||
Estimated cost |
|
|
...
Vi måste dessutom besluta hur ofta historikdata måste rensas, för den måste regelbundet rensas för att inte historikdatabasen ska växa sig för stor. Om det är så att man vill spara historikdata längre tid,från flera månader tillbaka eller ännu längre, så bör vi fungera på att använda en separat databas skild från Camundas vanliga databas för runtime-data.
Mer om history cleanup: https://docs.camunda.org/manual/7.16/user-guide/process-engine/history/#history-cleanup
A. NONE | B. ACTIVITY | C. AUDIT | D. FULL | E. CUSTOM | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | Historik är avslagen och ingen data skrivs till historikdatabasen. | Här loggas vilken väg i en process som har tagits och vilka aktiviteter som har körts. | Samma som Activity men du får även historik över variabler. | Förutom allt i Activity så får du också historik över User Taks och när en användare har kört dom. Du får också tillgång till historik över DMN-tabeller och vilka regler som har körts där. | Du kan också bygga en egen custom level med hjälp av Java-kod om inte någon av dom vanliga historiknivåerna duger. | ||||||||||||||||||||||||||||||
Pros and cons |
|
|
|
|
| ||||||||||||||||||||||||||||||
Estimated cost |
|
|
|
|
|
\uD83C\uDF1F Outcome
Beslut 1: Vi kör vidare i befintliga servrar men flyttar dessa till nytt nät (alt A).
Beslut 2: Greenfield enligt Camunda med remote process engine (alt B).
Beslut 3: Ha både intern och extern instans på samma servrar (alt A).
Beslut 4: Full (alt D).