21 | This is the project landing page and documentation for the DigiWF process infrastructure. For more information visit https://digiwf.oss.muenchen.de
22 | Report Bug
23 | ·
24 | Request Feature
25 |
26 |
27 |
28 |
29 | ## About The Project
30 |
31 | This Project is the landing page of DigiWF. For more information and facts about the development of our project - the DigiWF workflow automation and integration platform - please visit https://digiwf.oss.muenchen.de.
32 |
33 |
46 |
47 |
48 | ## Roadmap
49 |
50 | - [ ] Add architecture documentation
51 | - [ ] Link all repositories that will be open source
52 |
53 | See the [open issues](https://github.com/it-at-m/digiwf-project/issues) for a full list of proposed features (and known issues).
54 |
55 |
56 |
57 |
58 |
59 |
60 | ## Contributing
61 |
62 | Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are **greatly appreciated**.
63 |
64 | If you have a suggestion that would make this better, please open an issue with the tag "enhancement", fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement".
65 | Don't forget to give the project a star! Thanks again!
66 |
67 | 1. Open an issue with the tag "enhancement"
68 | 2. Fork the Project
69 | 3. Create your Feature Branch (`git checkout -b feature/AmazingFeature`)
70 | 4. Commit your Changes (`git commit -m 'Add some AmazingFeature'`)
71 | 5. Push to the Branch (`git push origin feature/AmazingFeature`)
72 | 6. Open a Pull Request
73 |
74 |
32 |
33 |
34 |
35 |
54 |
--------------------------------------------------------------------------------
/components/DwfTwitterButton.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 | mdi-twitter
5 |
6 |
7 |
8 |
--------------------------------------------------------------------------------
/content/about/contact.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Contact us!
3 | description: ''
4 | category: 'About'
5 | position: 3
6 | ---
7 |
8 | Todo
9 |
--------------------------------------------------------------------------------
/content/about/impress.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Impress
3 | description: Legal information for this page.
4 | category: 'About'
5 | position: 4
6 | ---
7 |
8 | # Content Responsibility
9 |
10 | IT@M
11 | Agnes Pockels Bogen 21
12 | 80992 München
13 | E-Mail: opensource@muenchen.de
14 |
--------------------------------------------------------------------------------
/content/about/roadmap.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Roadmap
3 | description: 'What do we plan in the next 3 month.'
4 | category: 'About'
5 | position: 1
6 | ---
7 | All tickets shown on this roadmap can be viewed (and also commented on) in our [github repo](https://github.com/it-at-m/digiwf-project/labels/Epic).
8 |
9 |
11 | The current DigiWF Roadmap (April to September)
12 |
--------------------------------------------------------------------------------
/content/about/rules.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Code of Conduct
3 | description: ''
4 | category: 'About'
5 | position: 2
6 | ---
7 |
8 | # Contributor Covenant Code of Conduct
9 |
10 | ## Our Pledge
11 |
12 | We as members, contributors, and leaders pledge to make participation in our
13 | community a harassment-free experience for everyone, regardless of age, body
14 | size, visible or invisible disability, ethnicity, sex characteristics, gender
15 | identity and expression, level of experience, education, socio-economic status,
16 | nationality, personal appearance, race, religion, or sexual identity
17 | and orientation.
18 |
19 | We pledge to act and interact in ways that contribute to an open, welcoming,
20 | diverse, inclusive, and healthy community.
21 |
22 | ## Our Standards
23 |
24 | Examples of behavior that contributes to a positive environment for our
25 | community include:
26 |
27 | * Demonstrating empathy and kindness toward other people
28 | * Being respectful of differing opinions, viewpoints, and experiences
29 | * Giving and gracefully accepting constructive feedback
30 | * Accepting responsibility and apologizing to those affected by our mistakes,
31 | and learning from the experience
32 | * Focusing on what is best not just for us as individuals, but for the
33 | overall community
34 |
35 | Examples of unacceptable behavior include:
36 |
37 | * The use of sexualized language or imagery, and sexual attention or
38 | advances of any kind
39 | * Trolling, insulting or derogatory comments, and personal or political attacks
40 | * Public or private harassment
41 | * Publishing others' private information, such as a physical or email
42 | address, without their explicit permission
43 | * Other conduct which could reasonably be considered inappropriate in a
44 | professional setting
45 |
46 | ## Enforcement Responsibilities
47 |
48 | Community leaders are responsible for clarifying and enforcing our standards of
49 | acceptable behavior and will take appropriate and fair corrective action in
50 | response to any behavior that they deem inappropriate, threatening, offensive,
51 | or harmful.
52 |
53 | Community leaders have the right and responsibility to remove, edit, or reject
54 | comments, commits, code, wiki edits, issues, and other contributions that are
55 | not aligned to this Code of Conduct, and will communicate reasons for moderation
56 | decisions when appropriate.
57 |
58 | ## Scope
59 |
60 | This Code of Conduct applies within all community spaces, and also applies when
61 | an individual is officially representing the community in public spaces.
62 | Examples of representing our community include using an official e-mail address,
63 | posting via an official social media account, or acting as an appointed
64 | representative at an online or offline event.
65 |
66 | ## Enforcement
67 |
68 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
69 | reported to the community leaders responsible for enforcement at .
70 | All complaints will be reviewed and investigated promptly and fairly.
71 |
72 | All community leaders are obligated to respect the privacy and security of the
73 | reporter of any incident.
74 |
75 | ## Enforcement Guidelines
76 |
77 | Community leaders will follow these Community Impact Guidelines in determining
78 | the consequences for any action they deem in violation of this Code of Conduct:
79 |
80 | ### 1. Correction
81 |
82 | **Community Impact**: Use of inappropriate language or other behavior deemed
83 | unprofessional or unwelcome in the community.
84 |
85 | **Consequence**: A private, written warning from community leaders, providing
86 | clarity around the nature of the violation and an explanation of why the
87 | behavior was inappropriate. A public apology may be requested.
88 |
89 | ### 2. Warning
90 |
91 | **Community Impact**: A violation through a single incident or series
92 | of actions.
93 |
94 | **Consequence**: A warning with consequences for continued behavior. No
95 | interaction with the people involved, including unsolicited interaction with
96 | those enforcing the Code of Conduct, for a specified period of time. This
97 | includes avoiding interactions in community spaces as well as external channels
98 | like social media. Violating these terms may lead to a temporary or
99 | permanent ban.
100 |
101 | ### 3. Temporary Ban
102 |
103 | **Community Impact**: A serious violation of community standards, including
104 | sustained inappropriate behavior.
105 |
106 | **Consequence**: A temporary ban from any sort of interaction or public
107 | communication with the community for a specified period of time. No public or
108 | private interaction with the people involved, including unsolicited interaction
109 | with those enforcing the Code of Conduct, is allowed during this period.
110 | Violating these terms may lead to a permanent ban.
111 |
112 | ### 4. Permanent Ban
113 |
114 | **Community Impact**: Demonstrating a pattern of violation of community
115 | standards, including sustained inappropriate behavior, harassment of an
116 | individual, or aggression toward or disparagement of classes of individuals.
117 |
118 | **Consequence**: A permanent ban from any sort of public interaction within
119 | the community.
120 |
121 | ## Attribution
122 |
123 | This Code of Conduct is adapted from the [Contributor Covenant][homepage],
124 | version 2.0, available at
125 | https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
126 |
127 | Community Impact Guidelines were inspired by [Mozilla's code of conduct
128 | enforcement ladder](https://github.com/mozilla/diversity).
129 |
130 | [homepage]: https://www.contributor-covenant.org
131 |
132 | For answers to common questions about this code of conduct, see the FAQ at
133 | https://www.contributor-covenant.org/faq. Translations are available at
134 | https://www.contributor-covenant.org/translations.
135 |
--------------------------------------------------------------------------------
/content/about/vision/vision.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Vision Statement
3 | description: The DigiWF Vision
4 | category: 'Vision'
5 | categoryIcon: 'mdi-lightbulb-on'
6 | position: 1
7 | ---
8 |
9 |
10 |
13 | The DigiWF Vision
14 |
15 |
16 | In an agile environment, we want a selection of patterns and technologies - including building blocks - to be provided that enable developers to build exactly the low-code functionality that is needed in the organization at that moment. That is the goal of DigiWF. We do not provide a proprietary out-of-box solution that is customized, but enable a development organization to build itself a customized solution. In doing so, we rely on reusable low-code functionalities that we make usable via BPMN and DMN. Thus, the platform can be started small and scaled quickly if required.
17 |
--------------------------------------------------------------------------------
/content/de/about/contact.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Contact us!
3 | description: ''
4 | category: 'About'
5 | position: 3
6 | ---
7 |
8 | Todo
9 |
--------------------------------------------------------------------------------
/content/de/about/impress.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Impress
3 | description: Legal information for this page.
4 | category: 'About'
5 | position: 4
6 | ---
7 |
8 |
9 | # Content Responsibility
10 |
11 |
12 |
13 | IT@M
14 | Agnes Pockels Bogen 21
15 | 80992 München
16 | E-Mail: opensource@muenchen.de
17 |
18 |
--------------------------------------------------------------------------------
/content/de/about/roadmap.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Roadmap
3 | description: 'Was wir in den nächsten Monaten planen...'
4 | category: 'About'
5 | position: 1
6 | ---
7 | Alle Tickets, die auf dieser Roadmap dargestellt sind, können in unserem [github Repo](https://github.com/it-at-m/digiwf-project/labels/Epic) eingesehen (und auch gerne
8 | kommentiert werden).
9 |
10 |
12 | Die aktuelle DigiWF Roadmap (April bis September)
13 |
--------------------------------------------------------------------------------
/content/de/about/rules.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Code of Conduct
3 | description: ''
4 | category: 'About'
5 | position: 2
6 | ---
7 |
8 |
9 | # Vereinbarung über Verhaltenskodex für Mitwirkende
10 |
11 | ## Unsere Verpflichtung
12 |
13 | Wir als Mitglieder, Teilnehmende und Verantwortliche unserer Gemeinschaft
14 | verpflichten uns, allen Teilnehmenden an dem Projekt und unserer Gemeinschaft
15 | eine belästigungsfreie Beteiligung, unabhängig von Alter, Körpergröße,
16 | Behinderung, ethnischer Zuordnung, Geschlechtermerkmalen, -identität und -ausdruck,
17 | Grad der Erfahrung, Bildung, sozialem Status, Nationalität, persönlicher
18 | Erscheinung, Rasse, Religion oder sexueller Identität und Orientierung
19 | zu ermöglichen.
20 |
21 | Wir verpflichten uns, in einer Weise zu handeln und zu interagieren, die zu
22 | einer offenen, einladenden, vielfältigen, inklusiven und gesunden Gemeinschaft
23 | beiträgt.
24 |
25 | ## Unsere Standards
26 |
27 | Beispiele für Verhaltensweisen, die zu einem positiven Umfeld für unsere
28 | Gemeinschaft beitragen, sind:
29 |
30 | - Einfühlungsvermögen und Freundlichkeit gegenüber anderen Menschen zeigen
31 | - Unterschiedliche Meinungen, Standpunkte und Erfahrungen respektieren
32 | - Konstruktives Feedback geben und würdevoll annehmen
33 | - Verantwortung übernehmen und uns bei denjenigen entschuldigen, die von unseren
34 | Fehlern betroffen sind, und aus den Erfahrungen lernen
35 | - Konzentration auf das, was nicht nur für uns als Individuen, sondern für die
36 | gesamte Gemeinschaft das Beste ist
37 |
38 | Beispiele für inakzeptables Verhalten sind:
39 |
40 | - Die Verwendung sexualisierter Sprache, Bilder oder Symbolik sowie unerwünschte
41 | Versuche sexueller Annäherung
42 | - Beleidigende oder abwertende Kommentare, persönliche oder politische Angriffe
43 | und Trollen
44 | - Öffentliche oder private Belästigungen
45 | - Das Veröffentlichen von privaten Informationen Anderer, wie zum Beispiel
46 | physische oder elektronische Adressen, ohne deren ausdrückliche Erlaubnis
47 | - Anderes Verhalten, welches in einem professionellen Umfeld begründet als
48 | unangemessen betrachtet werden kann
49 |
50 | ## Verantwortlichkeiten bei der Durchsetzung
51 |
52 | Die Gemeinschaftsleitung ist verantwortlich dafür, unsere Standards für ein
53 | akzeptables Verhalten klarzustellen und wird angemessen und fair
54 | korrigierende Maßnahmen ergreifen um auf jegliches Verhalten, das sie für
55 | unangemessen, bedrohlich oder beleidigend hält, zu reagieren.
56 |
57 | Die Gemeinschaftsleitung hat das Recht und die Verantwortung, Kommentare,
58 | Commits, Code, Wiki-Bearbeitungen, Support-Tickets und andere Beiträge, die
59 | nicht mit diesem Verhaltenskodex vereinbar sind, zu entfernen, zu bearbeiten
60 | oder abzulehnen, und wird die Gründe für eine Mäßigung mitteilen, wenn es
61 | angebracht ist.
62 |
63 | ## Geltungsbereich
64 |
65 | Dieser Verhaltenskodex gilt für alle Gemeinschaftsbereiche und gilt auch, wenn
66 | eine Einzelperson die Gemeinschaft offiziell in öffentlichen Bereichen vertritt.
67 | Beispiele für die Repräsentation unserer Gemeinschaft sind die Verwendung einer
68 | offiziellen E-Mail-Adresse, das Posten über ein offizielles Social-Media-Konto
69 | oder das Auftreten als ernannte Vertretung bei einer Online- oder
70 | Offline-Veranstaltung.
71 |
72 | ## Durchsetzung
73 |
74 | Fälle von missbräuchlichem, belästigendem oder anderweitig inakzeptablem
75 | Verhalten können unter der für die Durchsetzung
76 | zuständigen Gemeinschaftsleitung gemeldet werden. Alle Beschwerden werden
77 | zeitnah und fair geprüft und ermittelt.
78 |
79 | Die gesamte Gemeinschaftsleitung ist verpflichtet, die Privatsphäre und die
80 | Sicherheit derjenigen, die einen Vorfall gemeldet haben, zu respektieren.
81 |
82 | ## Durchsetzungsrichtlinien
83 |
84 | Die Gemeinschaftsleitung wird sich bei der Bestimmung der Konsequenzen für
85 | jede Handlung, die ihrer Ansicht nach gegen diesen Verhaltenskodex verstößt, an
86 | diese Richtlinien über die Auswirkungen in der Gemeinschaft halten:
87 |
88 | ### 1. Berichtigung
89 |
90 | **Auswirkungen in der Gemeinschaft**: Verwendung unangemessener Sprache oder
91 | anderes Verhalten, das in der Gemeinschaft als unprofessionell oder unwillkommen
92 | gilt.
93 |
94 | **Folge**: Eine private, schriftliche Verwarnung der Gemeinschaftsleitung,
95 | die Klarheit über die Art des Verstoßes und eine Erklärung dafür bietet, warum
96 | das Verhalten unangemessen war. Eine öffentliche Entschuldigung kann verlangt
97 | werden.
98 |
99 | ### 2. Verwarnung
100 |
101 | **Auswirkungen in der Gemeinschaft**: Eine Verletzung durch einen einzelnen
102 | Vorfall oder eine Reihe von Handlungen.
103 |
104 | **Folge**: Eine Warnung mit Konsequenzen bei wiederholtem Fehlverhalten. Keine
105 | Interaktion mit den beteiligten Personen, einschließlich unaufgeforderter
106 | Interaktion mit denjenigen, die den Verhaltenskodex durchsetzen, für einen
107 | bestimmten Zeitraum. Dazu gehört die Vermeidung von Interaktionen in
108 | Gemeinschaftsräumen sowie in externen Kanälen wie sozialen Medien. Ein Verstoß
109 | gegen diese Bedingungen kann zu einem vorübergehenden oder dauerhaften Verbot
110 | führen.
111 |
112 | ### 3. Vorübergehender Ausschluss
113 |
114 | **Auswirkungen in der Gemeinschaft**: Eine schwerwiegende Verletzung von
115 | Gemeinschaftsstandards, einschließlich anhaltend unangemessenen Verhaltens.
116 |
117 | **Folge**: Ein zeitlich begrenztes Verbot jeglicher Art von Interaktion oder
118 | öffentlicher Kommunikation mit der Gemeinschaft. Während dieses Zeitraums ist
119 | keine öffentliche oder private Interaktion mit den beteiligten Personen erlaubt.
120 | Auch keine unaufgeforderte Interaktion mit denjenigen, die den Verhaltenskodex
121 | durchsetzen. Ein Verstoß gegen diese Bedingungen kann zu einem dauerhaften
122 | Verbot führen.
123 |
124 | ### 4. Dauerhafter Ausschluss
125 |
126 | **Auswirkungen in der Gemeinschaft**: Aufzeigen eines Musters von Verletzungen
127 | der Gemeinschaftsstandards, einschließlich anhaltend unangemessenen Verhaltens,
128 | Belästigung einer Person oder Aggression gegen oder Herabsetzung von Gruppen von
129 | Personen.
130 |
131 | **Folge**: Ein dauerhaftes Verbot jeglicher Art von öffentlicher Interaktion
132 | innerhalb der Gemeinschaft.
133 |
134 | ## Bezug
135 |
136 | Dieser Verhaltenskodex basiert auf dem [Contributor Covenant][homepage],
137 | Version 2.0, verfügbar unter
138 |
139 |
140 | [homepage]: https://www.contributor-covenant.org
141 |
142 |
--------------------------------------------------------------------------------
/content/de/about/vision/vision.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Vision Statement
3 | description: Die Vision hinter DigiWF.
4 | category: 'Vision'
5 | categoryIcon: 'mdi-lightbulb-on'
6 | position: 1
7 | ---
8 |
9 |
10 |
13 | Die DigiWF Vision
14 |
15 |
16 | In einem agilen Umfeld wollen wir, dass eine Auswahl an Mustern und Technologien - auch Bausteinen - zur Verfügung gestellt wird, mit deren Hilfe Entwickler in der Lage sind, genau die Low Code Funktionalitäten zu entwickeln, die in dem Moment in der Organisation gebraucht werden. Das ist das Ziel von DigiWF. Wir stellen keine proprietäre out-of-box Lösung zur Verfügung, die durch Customizing angepasst wird, sondern befähigen eine Entwicklungsorganisation sich selbst eine maßgeschneiderte Lösung zu bauen. Dabei setzen wird auf wiederverwendbare Low-Code Funktionalitäten, die wir über BPMN und DMN nutzbar machen. So kann mit der Plattform klein gestartet und bei Bedarf schnell skaliert werden.
17 |
18 |
19 |
--------------------------------------------------------------------------------
/content/de/ecosystem/contribution/contribution.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Contributions
3 | description: Wie kann man sich an der Entwicklung von DigiWF beteiligen?
4 | category: 'Contributions'
5 | categoryIcon: 'mdi-gift-open-outline'
6 | position: 1
7 | ---
8 |
9 | ## Dokumentation
10 |
11 | ### Dokumentation von Integrationsartefakten
12 |
13 | Die Dokumentation von (offiziellen) Integrations Artefakten soll einerseits in dem jeweiligen Repository erfolgen.
14 | Andererseits hier in der offiziellen Gesamtdokumentation. Um nicht doppelt Inhalte pflegen zu müssen gelten folgende
15 | Regeln:
16 |
17 | 1. Die Dokumentation erfolgt ausschließlich in englischer Sprache. Auch in andere Übersetzungen (wie beispielsweise
18 | Deutsch) wird die englische Dokumentation eingebunden.
19 | 2. Die Dokumentation liegt im jeweiligen Repo im Ordner `docs`.
20 | 3. Die Abschnitte der Dokumentation wird in einzelne Dokumente aufgeteilt. Diese werden dann in das `readme.md` im
21 | Repo, als auch in die zentrale Dokumentation eingebunden.
22 | 4. Für jede Sprache muss im Ordner `[Sprache]/resources/modules` eine Seite erstellt werden. Die Markdown Dateien aus
23 | den Repos werden über die Komponente `DwfMarkdownLoader` eingebunden. Element Templates können über
24 | `DwfElementTemplateDocs` dargestellt werden.
25 | 5. Für den Integrationsartefakt wird ein Eintrag auf der Seite `[Sprache]/resources/modules/modules.md` erstellt
26 | (auch hier bitte für alle Übersetzungen). Um eine Karte auf der Übersichtsseite darzustellen muss die Komponente
27 | `DwfIntegrationArtifact` in das bereits vorhandene `` Element eingefügt werden.
28 | 6. Im Ordner `docs` sollten (mindestens) folgende Inhalte liegen: Quickstart, Architekturüberblick (möglichst mit
29 | Bild), alle
30 | Operationen (Element Templates) in eigenen Dateien. Bitte vor allem die Input und Output Parameter der Element
31 | Templates dokumentieren (siehe hierfür auch `DwfElementTemplateDocs`).
32 | 7. Bilder müssen mit absoluten Pfaden eingefügt werden, um sie auch hier korrekt anzeigen zu können. In github gibt
33 | es dazu die Funktion "copy permalink" (siehe Screenshot unten). Ob das Bild über Markdown oder HTML eingebunden
34 | wird ist egal. Bei einer Einbindung über HTML wäre es schon, die Größe zu begrenzen.
35 | 8. Wichtigster Punkt: Bitte schau, das alles funktioniert und gut aussieht. Beispielsweise, dass der Text nicht über
36 | die Karten ragt. Das Bilder möglichst einen Maximalwert in der Breite haben (z.B. 960px), usw.
37 |
38 |
39 | Es ist wichtig bei Änderungen der Dokumentation im Repo die zentrale Dokumentationsseite nochmal zu bauen und
40 | auszubringen. Da es sich um eine statische Seite handelt, bekommt die nichts von Änderungen in einem anderen Repo /
41 | auf einem anderen Server mit.
42 |
43 |
44 | Wenn man in den Dateien im Ordner `docs` auf Überschriften verzichtet und diese stattdessen auf der
45 | Beschreibungsseite platziert, so wird automatisch auf der rechten Seite ein Inhaltsverzeichnis generiert.
46 | Überschriften innerhalb der referenzierten Dokumente können hier nicht gezeigt werden.
47 |
48 |
49 |
50 |
55 | Absolute Pfade zu Bildern
56 |
57 |
58 | ### Spezielle Komponenten
59 |
60 | #### DwfIntegrationArtifact
61 |
62 | Über die Komponente `DwfIntegrationArtifact` können auf der Übersichts Seite für die Integrationsartefakte "Kacheln"
63 | erstellt werden.
64 |
65 | ``` html
66 |
72 |
73 | ```
74 |
75 | Attribute:
76 | - `icon` = Der [Material Design Icons](https://materialdesignicons.com/) Code für das Icon, das oben links in der Ecke dargestellt werden soll.
77 | - `name` = Der Name des Integrationsartefakts.
78 | - `description` = Die Beschreibung des Integrationsartefakts. Bitte darauf achten, dass die Beschreibung möglichst
79 | kurz die Leistung darstellt, aber nicht so lang ist, dass andere Inhalte aus der Karte "gepresst" werden.
80 | - `github` = Die URL zum github Repository.
81 | - `docs` = Der relative Pfad auf die Beschreibung, die in dieser Dokumentation abgelegt ist. Er wird in der Regel
82 | mit `/resources/modules/` beginnen, gefolgt vom Namen der Markdowndatei (ohne Dateiendung). Wenn die Datei an
83 | anderer Stelle abgelegt wurde, dann muss natürlich auch der Pfad entsprechend angepasst werden. Der Pfad für die
84 | Übersetzungen wird automatisch angepasst. Es muss also beispielsweise für die Deutsche Übersetzung kein `de`
85 | vorangestellt werden.
86 |
87 |
88 |
93 | Integration Artifact Card (Beispiel)
94 |
95 |
96 | #### DwfMarkdownLoader
97 |
98 | Über die Komponente `DwfMarkdownLoader` können Markdown Dateien geladen werden, die auf anderen Servern liegen.
99 |
100 | ``` html
101 |
103 | ```
104 |
105 | Bindet man Markdown Dokumente aus github ein, so bietet es sich an, hier die "raw" Ansicht zu wählen.
106 |
107 | #### DwfElementTemplateDocs
108 |
109 | Über die Komponente `DwfElementTemplateDocs` können Element Templates geladen werden, die auf einem anderen Server
110 | liegen. Das Template wird dann als Liste angezeigt, wobei jede Zeile einem Property entspricht.
111 |
112 | ``` html
113 |
114 | ```
115 |
116 |
117 |
121 | Element Template Tabelle (Beispiel)
122 |
123 |
--------------------------------------------------------------------------------
/content/de/history.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: DigiWF Prozess & Integrations Plattform
3 | description: ''
4 | category: 'Landing'
5 | position: 1
6 | ---
7 |
8 | 2019 haben wir begonnen, die Prozessautomatisierung in der öffentlichen Verwaltung der Landeshauptstadt München auf Basis der [Camunda](https://camunda.com/) BPMN Process Engine voranzutreiben. Relativ früh wurde unter dem Projektnamen DigiWF eine eigene Aufgabenliste auf Basis von [VueJs](https://vuejs.org/) und [VuetifyJs](https://vuetifyjs.com/) implementiert. Außerdem wurden erste Integrationsmodule wie Mail oder DMS in die Backend-Infrastruktur eingebaut.
9 |
10 |
11 |
16 | Die Kern Komponenten
17 |
18 |
19 | Heute ist DigiWF zu einer viel genutzten Plattform geworden. Vor allem das Integrationskonzept ist mittlerweile ausgereift und jedes System, das über eine Schnittstelle verfügt (und wenn es keine Schnittstelle hat, dann bindet man einfach einen RPA-Client an) lässt sich ohne großen Aufwand anbinden. Möglich wird dies durch ein modulares Baukastenkonzept über eine Sammlung von Spring Boot Startern. Probleme wie das Dateihandling werden zu einem Standardproblem, das auf allen Eingangskanälen gleichermaßen (gleich leicht) gelöst werden kann.
20 |
21 | Wenn eine solche Plattform wächst, stellt sich früher oder später die Frage, wer die Arbeit machen soll. DigiWF wurde konsequent so aufgebaut, dass Menschen, die in der Lage sind, automatisierte Workflows zu erstellen (aber nicht programmieren können), dies selbst tun können. Ermöglicht wird dies durch eine eigene „Low Code“-Komponente – die Co-Creation. Dort können Prozesse und Entscheidungstabellen auf Basis von BPMN und DMN erstellt werden. Backend-Systeme (sofern für diese ein Integrationsartefakt verfügbar ist) werden deklarativ über Input- und Output-Templates angebunden. Neben den Prozessen können auch Formulare für Benutzeraufgaben per Drag & Drop erstellt werden.
22 |
23 | Wenn Sie – ähnlich wie in der Landeshauptstadt München – viele Prozesse mit vielen Benutzeraufgaben haben. Und dann ein
24 | heterogene Backend-Landschaft, die Sie in Ihre Prozesse integrieren müssen, dann sollten Sie unbedingt eine nehmen
25 | schau mal bei DigiWF. Kontaktieren Sie uns einfach per [E-Mail](mailto:opensource@muenchen.de) oder über einen der Social-Media-Kanäle.
26 |
--------------------------------------------------------------------------------
/content/de/resources/documentation/concept/eventbustopics.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Event Bus Topics
3 | description: Wie man mit DigiWF kommuniziert?
4 | category: 'Konzept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 5
7 | ---
8 |
9 | Die DigiWF-Anwendungen kommunizieren mit einem `Event Bus`, um Ereignisse auszutauschen, die innerhalb der DigiWF-Plattform auftreten.
10 | Intern verwendet die DigiWF-Anwendung Spring Cloud Stream als Abstraktionsschicht, um mit dem "Event Bus" zu interagieren. Daher ist der `Event Bus` austauschbar, solange ein Spring Cloud Stream Binder existiert.
11 |
12 | In diesem Artikel erklären wir die Namenskonventionen für unsere Themen und listen die derzeit existierenden Themen auf.
13 |
14 | ## Naming conventions für Event Bus Topics
15 |
16 | ```
17 | ---
18 | ```
19 |
20 | Jeder DigiWF Topic-name besteht aus diesen 3 Teilen:
21 |
22 | - **prefix** wird verwendet, um die Themen einer bestimmten Anwendung zuzuordnen. Im Zusammenhang mit DigiWF ist dieses Präfix normalerweise `dwf`.
23 | - **domain** Jedes DigiWF-Thema gehört zu einer bestimmten Domäne. Der Name der Domäne kann dem Anwendungsnamen ähnlich sein.
24 | - **usage-context** Wenn eine Domain mehr als 1 Thema hat, wird ein zusätzlicher `` zum Namen des Themas hinzugefügt. Der `` ist optional.
25 | - **environment** ist das Suffix, das die Umgebung beschreibt, in der die Anwendungen laufen.
26 |
27 | Examples:
28 |
29 | - `dwf-cocreation-ENV` ist das Haupttopic der Co-Creation-Plattform. An dieses Thema werden Deploymentevents gesendet.
30 | - `dwf-cocreation-deploy-ENV` ist das zweite Topic der Co-Creation-Plattform. An dieses Topic werden Deployment-Success-Events gesendet.
31 |
32 | ## Verfügbare Event Bus Topics
33 |
34 | Derzeit existieren die Umgebungen `dev`, `test`, `demo` und `local-01`. `dev`, `test` und `demo` sind unsere CI/CD-Stages und `local-01` wird für die Entwicklung verwendet.
35 |
36 | ### Domäne digiwf-engine
37 |
38 | Die digiwf-engine verwendet den Spring Cloud Stream Function Router, um Ereignisse basierend auf dem `type` Header an die entsprechenden Spring Cloud Funktionen weiterzuleiten.
39 | Daher benötigt jede Nachricht, die an `dwf-digiwf-engine-` gesendet wird, den Header `type`.
40 |
41 | ```
42 | dwf-digiwf-engine-
43 | ```
44 |
45 | Die folgenden Werte für den Header `type` werden derzeit unterstützt:
46 |
47 | | Header Type | Payload Type | Beschreibung |
48 | |---------------------|-------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
49 | | correlateMessageV01 | `CorrelateMessageTOV01` | Verwenden Sie `CorrelateMessageTOV01` als Wert für den Header type, um eine Nachricht mit einer Prozessinstanz zu korrelieren. |
50 | | startProcessV01 | `StartInstanceTOV01` | Verwenden Sie `startProcessV01` als Wert für den Header type, um eine neue Prozessinstanz mit dem Prozessschlüssel und den Daten zu starten. |
51 |
52 |
53 | > **Anmerkung:**
54 | > Wir benutzen springwolf, um asyncapi Dokumentationen zu generieren. Schauen Sie sich die asyncapi-Dokumentation der Dienste unter */springwolf/asyncapi-ui.html* an.
55 |
56 | ### Domäne cocreation
57 |
58 | Prozesse, Entscheidungstabellen und JSON-Schema-Formulare, die in der Cocreation-Plattform entwickelt werden, werden mit einem Deployment-Event, das an das Topic `dwf-cocreation-` gesendet wird, in der digiwf-Engine deployed.
59 |
60 | ```
61 | dwf-cocreation-
62 | ```
63 |
64 | Der digiwf-engine Service ist ein Consumer des Themas `dwf-cocreation-` und stellt die Artefakte (bpmn-, dmn- oder json-Form) aus eingehenden Bereitstellungsereignissen für die camunda-Engine bereit.
65 | Die digiwf-engine verwendet den Spring Cloud Stream Function Router, um Events basierend auf dem Header `type` an die entsprechenden Spring Cloud Funktionen weiterzuleiten.
66 |
67 | Die folgenden Werte für den Header `type` werden derzeit unterstützt:
68 |
69 | | Header Type | Payload Type | Beschreibung |
70 | |----------------|-------------------------|--------------------------------------------------------------------------------------------------------------------------------|
71 | | deploy | `DeploymentEvent` | Verwenden Sie `deploy` als Wert für den Header type, um Prozesse und Entscheidungstabellen in der digiwf-Engine einzusetzen. |
72 | | deploySchema | `SchemaDeploymentEvent` | Verwenden Sie `deploySchema` als Wert für den Header type, um JSON-Schema-Formulare an die digiwf-Engine zu übergeben. |
73 |
74 | ```
75 | dwf-cocreation-deploy-
76 | ```
77 |
78 | Nach jedem Deployment sendet die digiwf-engine ein Deployment-Status-Ereignis an das Topic `dwf-cocreation-deploy-`, das die Abonnenten des Topics über den Erfolg oder Misserfolg des Deployments informiert.
79 |
80 | > **Anmerkung:**
81 | > Wir benutzen springwolf, um asyncapi Dokumentationen zu generieren. Schauen Sie sich die asyncapi-Dokumentation der Dienste unter */springwolf/asyncapi-ui.html* an.
82 |
--------------------------------------------------------------------------------
/content/de/resources/documentation/concept/filehandling.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Umgang mit Dateien
3 | description: Wie können (große und kleine) Dateien auf der Prozessplattform verwaltet werden?
4 | category: 'Konzept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 3
7 | ---
8 |
9 |
10 | Der Umgang mit Dateien stellt eine Prozess- und Integrationsplattform naturgemäß vor Herausforderungen. Dateien
11 | können sehr groß sein, oder in großer Anzahl auftreten und stellen somit ein potenzielles Ressourcenproblem dar.
12 | Deshalb werden bei DigiWf grundsätzlich keine Dateien in den Speicher geladen oder durch Prozess geschleift. Das
13 | File Handling findet in den Integrations Layern (entweder GUI oder Backend statt).
14 |
15 |
16 |
21 | Datei Handling in den beiden Integrationsschichten
22 |
23 |
24 | Ein grundlegendes Element bei der Behandlung von Dateien (unabhängig davon, ob sie über die GUI oder angebundene
25 | Backend Komponenten in das System gelangen) ist der Datei Speicher. Im Fall von DigiWF ist das ein `S3-Service`.
26 | Hier kann eine Cloudlösung wie AWS oder ein on prem Dienst verwendet werden. Die Kommunikation mit dem Dienst an
27 | sich wird über eine generisch gültige Schnittstelle abstrahiert.
28 |
29 | Grundsätzlich ist es möglich (und bei mehrfacher Nutzung der Plattform empfehlenswert), mehr als einen `S3 Bucket`
30 | als Dateispeicher bereitzustellen. Allerdings nicht im selben `S3 Service` - hier gibt es eine 1:1 Beziehung zwischen
31 | Service und `S3 Bucket`. Trotzdem kann - je nach
32 | Fachlichkeit - hier nach Domäne, Prozess oder
33 | Abteilung ein eigener `S3
34 | Bucket` mit einem eigenen `S3 Service` an die Plattform angebunden werden. Das heißt bei einer größeren Installation
35 | (beispielsweise Unternehmensweit) wird man in der Regel n `S3 Services` angebunden haben.
36 |
37 |
38 |
39 |
40 | ## Datei Handling im Application Integration Layer
41 | Klassische Fälle, in denen Dateien im `Application Integration Layer` behandelt werden müssen, sind:
42 | - E-Mail (mit Anhängen)
43 | - Datei und Aktenablage in einem Document Management System
44 | - Erzeugen von Dateien, wie beispielsweise PDF Generierung
45 |
46 | ### Eingehende Dateien
47 |
48 |
52 | Datei Handling bei eingehenden Dateien
53 |
54 |
55 | In der Abbildung oben ist zu sehen, wie mit eingehenden Dateien umgegangen wird.
56 |
57 | 1. Eine Datei wird erzeugt oder von außen empfangen.
58 | 2. Um die Dateien zu speichern, wird eine `presigned URL` [^1] am `S3 Service` für die Speicherung abgefragt und
59 | erzeugt. Eine `presigned
60 | URL` ist eine zeitlich begrenzt gültige URL, für eine bestimmte Operation (z.B. `POST`, `PUT`, usw.) die verwendet
61 | werden kann um Dateien direkt an einen `S3 Bucket`zu schicken, ohne eingeloggt sein zu müssen. Wie lange eine solche URL gültig kann eingestellt werden. Für den
62 | hier dargestellten Anwendungsfall funktionieren auch sehr kurze Gültigkeitszeiträume, da es sich hier um eine
63 | rein maschinelle Verarbeitung handelt. Zusätzlich zur URL wird an dieser Stelle noch eine Referenz- oder Datei ID
64 | erzeugt und zurückgegeben.
65 | 3. Mit der URL wird die Datei nun direkt in den S3 Speicher geschrieben. Das geht ohne Umweg über einen weiteren
66 | Service.
67 | 4. Die Datei Referenz wird über den `Event Bus` an den Prozess übergeben. Ab dieser Stelle ist der Prozess dafür
68 | verantwortlich diese Datei ID sorgsam aufzubewahren, denn nur mit dieser Referenz kann man die Datei noch über
69 | den `S3 Service` finden und entsprechend laden.
70 |
71 | ### Ausgehende Dateien
72 |
73 |
77 | Datei Handling bei ausgehenden Dateien
78 |
79 |
80 | In der Abbildung oben ist zu sehen, wie mit ausgehenden Dateien umgegangen wird.
81 |
82 | 1. Grundvoraussetzung um eine Datei (oder einen ganzen Ordner) aus dem `S3 Bucket` zu holen ist die Referenz- oder
83 | Datei ID. Will man mehrere
84 | Dateien / Ordner laden - und beispielsweise an eine E-Mail anhängen - so werden auch entsprechend viele Referenz IDs
85 | benötigt. D.h. die Kardinalität zwischen Datei / Ordner und Referenz ID ist immer 1:1.
86 | 2. Mit der Referenz ID kann am `S3 Service` eine `presigned URL` für die Operation `GET` erfragt werden. Auch hier
87 | gilt - für jede Datei wird eine eigene `presigned URL` benötigt.
88 | 3. Mit der `presigned URL` kann wiederum die Datei direkt aus dem `S3 Bucket` geladen werden.
89 | 4. Die Datei(en) werden an die Mail gehängt und verschickt.
90 |
91 |
92 | Es ist übrigends davon abzuraten, eine presigned URL direkt heraus zu geben (beispielsweise per Mail zu
93 | verschicken). Wie oben beschrieben ist eine solche URL nur eine bestimmte Zeit gültig. D.h. wenn dieser Zeitraum
94 | abgelaufen ist, dann kann über die URL nicht mehr auf die Datei zugegriffen werden. Wenn dann auch noch die
95 | Prozessinstanz beendet wurde, hat man auch nicht mehr so einfach Zugriff auf die Referenz ID.
96 |
97 |
98 |
99 |
100 |
101 | ## Datei Handling im GUI Integration Layer
102 | Dateien kommen natürlich nicht nur aus angebundenen Verfahren, sondern können auch über die grafische
103 | Benutzeroberfläche ins System gelangen. Auch hier wird das Filehandling über den S3 Service abgewickelt. Wichtig ist
104 | hierbei, dass die Kommunikation nicht - wie bei den Integrationsartefakten - über den `Event Bus` erfolgt, sondern
105 | per `REST` Aufruf, da die Oberflächenkomponenten keinen direkten Zugang zum `Event Bus` haben.
106 |
107 |
108 |
112 | Datei(en) aus dem Frontend heraus speichern.
113 |
114 |
115 | Hier wird beschrieben, wie aus der Formularkomponente `File Upload Control` heraus eine Datei gespeichert wird. Der
116 | Weg ist aber prinzipiell auch für eigene Formulare oder andere Oberflächen nutzbar.
117 |
118 | 1. Es wird eine `presigned URL` am `S3 Service` angefragt. Dazu werden folgende Parameter übergeben:
119 | - `refID` Die Referenz, unter der die Datei später abgerufen werden kann
120 | - `filename` Der Name der Datei, die gespeichert werden soll.
121 | - `endOfLife` Es kann ein Löschdatum mitgegeben werden. Zu diesem Zeitpunkt wird die Datei dann automatisch aus
122 | dem S3 Speicher gelöscht. Das ist vor allem dann sinnvoll, wenn Daten nur eine bestimmte Zeit aufbewahrt werden
123 | dürfen.
124 | - `expiredInMinutes` Die Zeitspanne in Minuten, für die der Link gültig ist. Nach ablauf dieser Zeit kann er
125 | nicht mehr verwendet werden.
126 | 2. Der `S3 Service` erzeugt über den S3 Storage eine entsprechende `presigned URL`. Was dort genau passiert, ist im
127 | Sequenzdiagramm unten ersichtlich. Diese URL wird an das `File Upload Control`zurückgegeben.
128 | 3. Über die `presigned URL` kann nun die Oberflächenkomponente die Datei direkt an den S3 Storage übergeben.
129 |
130 | Wenn man mehr als eine Datei speichern will, so muss dieser Vorgang natürlich entsprechend oft wiederholt werden.
131 |
132 | ### Authorization beim Umgang mit Dateien aus dem Frontend
133 |
134 | Während in der Integrationsschicht relativ klar ist, wer auf welche Datei zugreifen kann, ist dies im Frontend
135 | deutlich schwieriger zu entscheiden, da hier potenziell erst einmal jeder auf die Schnittstelle zugreifen kann.
136 |
137 |
138 |
142 | Datei(en) aus dem Frontend heraus speichern - detaillierte Ansicht.
143 |
144 |
145 |
146 |
151 | Datei(en) aus dem Frontend heraus laden - detaillierte Ansicht.
152 |
153 |
154 |
155 |
156 |
157 | [^1]: siehe https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html
158 |
159 |
160 |
161 |
--------------------------------------------------------------------------------
/content/de/resources/documentation/concept/integration.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: System Integration
3 | description: Wie können die Integrationsartefakte oder Services aus den Prozessen heraus aufgerufen werden?
4 | category: 'Konzept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 2
7 | ---
8 |
9 | Eine Basis Funktionalität von DigiWF ist es, die Prozesse mit der Backend Infrastruktur zu verbinden. Hierbei ist es
10 | zweitrangig, wo die Anwendungen liegen, die in einem Workflow verwendet werden sollen. Sie können sowohl on prem
11 | gehostet werden, als auch in der Cloud laufen. Wichtig ist, dass sie eine Schnittstelle haben - bzw. wenn sie keine
12 | haben, kann die Anwendung immer noch über einen RPA Dienst angebunden werden.
13 |
14 | ## Die DigiWF Integrationsarchitektur
15 |
16 |
20 | High Level Integrations Architektur
21 |
22 |
23 | Ganz abstrakt haben wir im `Application Integration Layer` eine Sammlung von Services, die mit dem `Event Bus`
24 | verbunden sind. Dabei ist es erst einmal egal, wo diese Services laufen, bzw. in welcher Technologie sie
25 | implementiert sind. Wichtig ist, dass sie mit dem `Event Bus` kommunizieren können. Die "Art" der Services ist auch
26 | nicht auf eine Verbindung zwischen der Plattform und einem bereits bestehenden System beschränkt. Hier können auch
27 | diverse Microservices direkt angebunden werden.
28 |
29 | Im `run` weiß auch der `Business Process Layer` (DigiWF Core) nichts von irgend einem Integrations Service. Die
30 | beiden sind tatsächlich lose gekoppelt. Im `build` dagegen müssen die Services, bzw. die Service Operationen, die
31 | man aus einem Prozess heraus aufrufen will sehr wohl bekannt sein. Die Verbindung passiert hier durch ein `Element
32 | Template` [^1]. Im Prinzip ist solch ein Template ein Input / Output Mapping. D.h. Die Daten aus dem Prozess werden
33 | auf die erwarteten Daten der Operation gemappt und umgekehrt.
34 |
35 | ## Interaktion aus dem Prozess heraus
36 |
37 |
42 | Beispielhafte Nutzung eines Integrationsartefaktes aus einem BPMN Prozess heraus
43 |
44 |
45 | Um wiederverwendbare Operationsaufrufe aus BPMN Prozessen heraus erstellen zu können, ist es sinnvoll diese in
46 | Subprozessen zu kapseln. Die Abbildung oben zeigt dies exemplarisch. Ein Send & Reply Pattern erscheint hier als ein
47 | Service Task, den Prozessmodellierer einfach in den Prozess aufnehmen kann. Hier könnte auch ein generisches
48 | Fehlerhandling abgebildet werden. Wichtig ist, dass der Subprozess ein eigenes `Element Template` hat. D.h. die
49 | eingehenden Parameter entsprechen den Werten, die der Subprozess zum Aufruf erwartet. Die ausgehenden
50 | Parameter sind diejenigen, die der Subprozess am Ende zurückgibt.
51 |
52 | ## Eigene Integrationsartefakte erstellen
53 |
54 |
59 | Beispielhafte Nutzung von Spring Boot Startern um einen eigenen Integrationsartefakt zu
60 | erstellen
61 |
62 |
63 | Um es möglichst einfach zu machen, eigene Integrations Artefakte oder Micro Services zu erstellen, bieten wir
64 | Basisfunktionalitäten in Form von `Spring Boot Startern` [^2] an. Diese können einfach über das entsprechende
65 | Dependency Management (Maven, Gradle, etc.) in das Projekt eingebunden werden. Danach stehen sie zur Nutzung bereit.
66 | D.h. sie können über die `application.yaml` des Projektes (hier `your-own-mail-integration`) konfiguriert werden.
67 | Das ist sinnvoll, um zwar die individuellen umgebungsspezifischen Parameter für ein System setzen zu können - aber
68 | trotzdem die standardisierte Nutzung nichts selbst implementieren zu müssen.
69 |
70 | Im Beispiel oben wird ein `your-own-mail-integration` Service erstellt. Dieser behandelt eingehende und ausgehende
71 | Mails. Wenn man den `digiwf-mail-integration-starter` einbindet, so bekommt man automatisch eine Anbindung an den S3
72 | Service mit. Mails können ja Datei Anhänge enthalten, die man nicht im Prozess haben will. D.h. bei eingehenden
73 | Anhängen werden diese vorab im Datei Speicher gespeichert und die Referenz an den Prozess weiter gegeben. Bei
74 | ausgehenden Mails ist es genau anders herum. Der Prozess stellt eine Referenz auf die Datei(en) zur Verfügung, mit
75 | der diese aus dem Datei Speicher geladen werden und an die E-Mail gehängt werden können. Diese Logik - Dateianhänge
76 | über den Datei Speicher zu verarbeiten - ist bereits komplett `digiwf-mail-integration-starter` und
77 | `digiwf-s3-integration-client-starter` enthalten. D.h. um einen Mail Server anzubinden, muss im besten Fall nichts
78 | mehr programmiert werden. Man erstellt nur ein Spring Boot Projekt (z.B. über [^3]), bindet die Starter ein und kann
79 | mit der richtigen Konfiguration sofort arbeiten.
80 |
81 | [^1]: Siehe https://docs.camunda.io/docs/components/modeler/desktop-modeler/element-templates/about-templates/
82 | [^2]: Siehe https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using.build-systems.starters
83 | [^3]: Siehe https://start.spring.io/
--------------------------------------------------------------------------------
/content/de/resources/documentation/concept/overview.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: DigiWF Architektur Übersicht
3 | description: Was ist DigiWF aus 20K Meter Höhe.
4 | category: 'Konzept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 1
7 | ---
8 |
9 | DigiWF ist das Bindeglied zwischen Ihren Frontend- und Backend-Systemen. Alles, was Sie über eine Netzwerkverbindung erreichen können, können Sie an DigiWF anhängen und deklarativ in Ihren BPMN-Prozessen verwenden. Wir sind die Brücke zwischen dem Entwicklerteam und den Prozessdesignern.
10 |
11 | ## Das DigiWF Plattform Konzept
12 |
13 |
17 | Interaction DigWF Core & the surrounding systems
18 |
19 |
20 | DigiWF stellt vier Kernkompetenzen zur Verfügung:
21 |
22 | - Einen Prozesslayer (DigiWF Core), in dem natürlich die Prozessinstanzen und Entscheidungstabellen (DMN) auf Basis von Camunda BPMN ausgeführt werden. Aber auch die Formularbeschreibungen gespeichert, oder User Tasks ausgeführt werden.
23 | - Einen Integrations Layer Richtung frontend. Hier werden zur Laufzeit Schnittstellen und / oder Formulare zur Verfügung gestellt, die man in eigenen (Frontend) Anwendungen nutzen kann. Alternativ kann die fertige Tasklist verwendet werden, um User Tasks abzuarbeiten, oder den Stand eines Workflows anzuzeigen.
24 | - Einen Integrationslayer richtung Backend. Über den kann alles was eine Schnittstelle hat angebunden werden. Hat es keine Schnittstelle, kann immer noch ein RPA Dienst verwendet werden. Um schnell eigene Verfahren in die Prozesse einbinden zu können, werden eine Reihe von "ready to use" Bausteinen in Form von Spring Startern zur Verfügung gestellt. Diese können genutzt werden, um wiederkehrende Problemstellung - wie beispielsweise der Umgang mit ein- oder ausgehenden Dateien (z.B. E-Mail mit Anhang) - standardisiert zu lösen. Einfach Starter einfügen und die API nutzen.
25 | - Einen Co-Creation Bereich, um auch nicht technischen Nutzern die Möglichkeit zu geben ihre Prozesse, entscheidungstabellen und Formulare modellieren und sogar auf der Plattform ausbringen zu können. Dafür wurde eine eigene Web IDE erstellt, die einfach über den Browser genutzt werden kann.
26 |
27 | ## Core Modules
28 |
29 |
36 | Die Kern Komponenten
37 |
38 |
39 | Das Bild oben zeigt eine mögliche "ausgewachsene" DigiWF-Architektur einschließlich selbst erstellter Artefakte. Alles in
40 | Blau wird vom DigiWF-Projekt bereitgestellt, aber wir sind offen für Integrationen. Es könnten also folgende Artefakte
41 | erstellen und integriert werden:
42 |
43 | - eigene Frontends (Die Technologie ist nichjt wirklich entscheidend - wenn man aber beispielsweise unsere
44 | Formurlarkomponente verwenden will, dann geht das mit VueJs am besten)
45 | - eigene Integrationsartefakte zur Kommunikation mit der On-Premise- oder Cloud-Infrastruktur
46 | - eigene (Mikro-)Services
47 |
48 | Es kann jede beliebige Technologie verwenden werden. Bestens unterstützt wird man aber, wenn im Frontend VueJS (mit
49 | VuetifyJs) und in den Integrations- oder anderen Services Spring Boot verwendet wird. Es gibt nur zwei Voraussetzungen:
50 |
51 | - Die Frontend-Technologie muss über einen GraphQL-Client verfügen
52 | - Das Backend (Dienste, Integrationsartefakte) muss in der Lage sein, mit einer der von [Spring Cloud Streams]
53 | (https://spring.io/projects/spring-cloud-stream) unterstützten Binder-Implementierungen zu kommunizieren.
54 |
55 |
56 | Wenn eine andere Event Bus Infrastruktur verwendet werden soll, als Apache Kafka, so kann dies in der DigiWF
57 | Konfiguration erfolgen.
58 |
59 |
60 | Of course - if you'll use Spring Boot in your backend components and VueJs as front end technology, you can use all cross-section components (like Spring Boot Starters, NPM components, ...) we have created for our components.
61 |
62 | ### DigiWF Core
63 | DigiWF Core ist das Herzstück von DigiWF und besteht aus 5 Diensten. Zur Interaktion mit Frontend-Anwendungen gibt
64 | es eine Graph-QL API. Zusätzlich eine sehr generische API, die über einen Event Bus mit verschiedenen
65 | Backend-Systemen kommuniziert.
66 |
67 |
68 |
72 | Die DigiWF Core Services
73 |
74 |
75 | Das Hauptziel von DigiWF ist es, eine deklarative Möglichkeit für Prozessdesigner zu schaffen, mit einer technischen Infrastruktur zu interagieren. Dafür haben wir einige unterstützende Dienste rund um den Opensource [camunda](https://camunda.com/)-Workflow erstellt:
76 |
77 | - Prozessdienst: Dies ist der Service, in den Camunda eingebettet ist. Es wird hauptsächlich verwendet, um die
78 | BPMN-Workflows auszuführen.
79 | - Serviceinstanz: Dies behandelt jede Art von Serviceinstanzen. Eine Serviceinstanz kann ein Prozess sein, muss aber
80 | nicht.
81 | - Task Service: Dieser Service übernimmt alles, was wir für menschliche Aufgaben benötigen (Autorisierung, Mapping, Rückkanal, ...).
82 | - Formular- und Validierungsservice: Alles, was wir im Zusammenhang mit Formularen benötigen, wird hier verarbeitet.
83 | Wir speichern die Formulardefinition und führen alle Arten von Formularvalidierungen durch.
84 | - Servicedefinitionsservice: Dieser Service ist für die Definition eines Services und die entsprechenden
85 | Konfigurationen
86 | zuständig.
87 |
88 | ### DigiWF Integration
89 |
90 |
96 | Ein Beispiel, wie ein benutzerdefiniertes Integrationsartefakt basierend auf unseren Startern
97 | erstellt werden kann
98 |
99 |
100 | Um ein beliebiges Backend-System zu integrieren, kann dies über die Integrationsschicht getan werden. Die
101 | DigiWF-Integration ist einerseits eine Reihe vordefinierter Integrationsartefakte wie S3, Mail, JMS oder andere. Auf der anderen Seite ist die DigiWF-Integration eine Toolbox, die hilft, so schnell wie möglich eigene Integrationsartefakte zu erstellen. Dies wird durch die konsequente Verwendung von Spring Boot Startern zur Implementierung von Basisfunktionalitäten gewährleistet.
102 |
103 | ### DigiWF Tasklist
104 | Dies ist ein einfaches Frontend zur Interaktion mit laufenden Prozessinstanzen. Jede Benutzeraufgabe kommt auf der
105 | Aufgabenliste vor und kann abgeholt werden (natürlich nur, wenn man das Recht dazu hat). Über die Taskliste können
106 | Sie den Status „Ihrer“ Prozesse einsehen und neue Instanzen starten. Wem ein so hochgradig standardisiertes Frontend
107 | nicht gefällt, kann "ready to use" Komponenten wie den Form Renderer verwenden und in die eigene, schöne Web Anwendung
108 | integrieren.
109 | Oder man kann die API direkt verwenden und ein schickes Frontend in der gewünschten Technologie selbst erstellen.
110 |
111 | ### DigiWF Co-Creation
112 | Die DigiWF Co-Creation ist der Low-Code-Bereich. Hier kann ein Prozessdesigner BPMN-Prozesse zeichnen,
113 | mit Entscheidungstabellen (DMN) herum tüfteln oder Webformulare per Drag and Drop erstellen. Auch das Deployment in
114 | verschiedenen Infrastrukturen ist über diese Web-App möglich.
115 |
116 |
119 | Der DigiWF Form Builder
120 |
121 |
122 | [comment]: <> ()
123 |
124 | [comment]: <> (This is a hint field!)
125 |
126 | [comment]: <> ()
127 |
128 | [comment]: <> ()
129 |
130 | [comment]: <> (This is a warn field!)
131 |
132 | [comment]: <> ()
133 |
134 | [comment]: <> ()
135 |
136 | [comment]: <> (This is a neutral field!)
137 |
138 | [comment]: <> ()
139 |
140 |
--------------------------------------------------------------------------------
/content/de/resources/documentation/concept/selfservice.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Co-Creation
3 | description: Wie können Prozesse und Formulare neu auf die Plattform gebracht, bzw. wie können sie angepasst werden?
4 | category: 'Konzept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 4
7 | ---
8 |
9 | To be done.
10 |
--------------------------------------------------------------------------------
/content/de/resources/modules/emailintegration.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: E-Mail Integration Artifact
3 | description: E-Mail Integration Artifact
4 | category: 'Integration Artifacts'
5 | categoryIcon: 'mdi-toy-brick'
6 | position: 100
7 | ---
8 |
9 |
10 |
11 |
12 |
13 | ## Element Templates
14 |
15 |
16 |
17 |
18 |
19 |
--------------------------------------------------------------------------------
/content/de/resources/modules/modules.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Integration Artifacts Übersicht
3 | description: Eine Übersicht über alle DigiWF Integrationsartefakte
4 | category: 'Integration Artifacts'
5 | categoryIcon: 'mdi-toy-brick'
6 | position: 1
7 | ---
8 |
9 |
12 |
13 |
14 |
17 |
18 |
--------------------------------------------------------------------------------
/content/de/resources/modules/okewointegration.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: OK.EWO Integration Artifact
3 | description: OK.EWO Integration Artifact
4 | category: 'Integration Artifacts'
5 | categoryIcon: 'mdi-toy-brick'
6 | position: 99
7 | ---
8 |
9 |
10 |
11 |
12 |
13 | ## Element Templates
14 |
15 |
16 |
17 |
18 |
--------------------------------------------------------------------------------
/content/de/resources/tutorials/deploy-artifacts-to-digiwf-engine.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to communicate with digiwf-engine?
3 | description: Deployment of bpmn, dmn and jsonschema forms to the digiwf-engine with kafka
4 | category: 'Tutorials'
5 | categoryIcon: 'mdi-school'
6 | position: 2
7 | ---
8 |
9 | Dieses Tutorial soll Ihnen zeigen, wie Sie Artefakte (bpmn-, dmn- und jsonschema-Formulare) über das entsprechende Kafka Topic an die digiwf-Engine verteilen können.
10 | Darüber hinaus können Sie unsere Dokumentation [hier](/de/resources/documentation/concept/eventbustopics) einsehen.
11 |
12 | Zur Integration mit der digiwf-engine müssen Sie Events an die Kafka Topics senden, auf die die digiwf-engine hört.
13 | Intern verwendet die digiwf-engine einen benutzerdefinierten Spring-Cloud-Stream Funktionrouter, der die eingehenden Ereignisse auf der Grundlage des `type` Headers an die entsprechenden Topics weiterleitet.
14 | Mit diesem Ansatz kann das gleiche Topic für verschiedene Eventtypen verwendet werden.
15 | Die unterstützten Eventtypen sind in der [Dokumentation](/de/resources/documentation/concept/eventbustopics) aufgeführt.
16 |
17 | > Hinweis: Wenn Sie in Ihren Kafka Messages den Header `type` nicht angeben, kann die digiwf-Engine die Message nicht an die passende Consumer-Funktion weiterleiten. Dies gilt auch, wenn Sie einen unbekannten Wert für den `type` Header setzen.
18 |
19 |
20 | ## Artefakt deployment
21 |
22 | Um Artefakte für die digiwf-Engine bereitzustellen, senden Sie ein Bereitstellungsereignis an das Topic `dwf-cocreation-` (ersetzen Sie *ENV* durch eine gültige Umgebung) mit dem Header `type` und dem Wert `deploy` für *.bpmn* und *.dmn* Dateien. Verwenden Sie für JSON-Schemaformulare den Header `type` mit dem Wert `deploySchema`. Verwenden Sie für Prozess-Konfigurationen den Header `type` mit dem Wert `deployConfiguration`.
23 |
24 | Das Deployment-Ereignis besteht aus einer eindeutigen `deploymentId` und `versionId`. Das `Ziel` stellt die Umgebung dar, in der Sie das Ereignis bereitgestellt haben. Der `artifactType` ist entweder `BPMN`, `DMN`, `FORM` oder `CONFIGURATION` und die `file` ist die in einen String konvertierte Datei.
25 |
26 | ```json
27 | {
28 | "deploymentId": "8d15da94-b4cb-43de-abb5-bca085af0da0",
29 | "versionId": "26326aa2-f3d4-4783-bbd8-7099d4bfd4a4",
30 | "target": "DEV",
31 | "file": "...",
32 | "artifactType": "BPMN"
33 | }
34 | ```
35 |
--------------------------------------------------------------------------------
/content/de/resources/tutorials/kafka-topics-tutorial.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to communicate with digiwf-engine?
3 | description: Tutorials and Guides
4 | category: 'Tutorials'
5 | categoryIcon: 'mdi-school'
6 | position: 2
7 | ---
8 |
9 | Dieses Tutorial soll Ihnen zeigen, wie Sie die Integration mit der digiwf-Engine unter Verwendung der Kafka-Topics vornehmen können.
10 | Darüber hinaus können Sie unsere Dokumentation [hier](/de/resources/documentation/concept/eventbustopics) einsehen.
11 |
12 | Zur Integration mit der digiwf-engine müssen Sie Events an die Kafka Topics senden, auf die die digiwf-engine hört.
13 | Intern verwendet die digiwf-engine einen benutzerdefinierten Spring-Cloud-Stream Funktionrouter, der die eingehenden Ereignisse auf der Grundlage des `type` Headers an die entsprechenden Topics weiterleitet.
14 | Mit diesem Ansatz kann das gleiche Topic für verschiedene Eventtypen verwendet werden.
15 | Die unterstützten Eventtypen sind in der [Dokumentation](/de/resources/documentation/concept/eventbustopics) aufgeführt.
16 |
17 | > Hinweis: Wenn Sie in Ihren Kafka Messages den Header `type` nicht angeben, kann die digiwf-Engine die Message nicht an die passende Consumer-Funktion weiterleiten. Dies gilt auch, wenn Sie einen unbekannten Wert für den `type` Header setzen.
18 |
19 |
20 | ## Prozesse starten
21 |
22 | Um Prozesse mit der digiwf-engine zu starten, müssen Sie ein Startprozess-Event an das Topic `dwf-digiwf-engine-ENV` (ersetzen Sie *ENV* durch eine gültige Umgebung) mit dem Header `type` und dem Wert `startProcessV01` senden.
23 |
24 | Das Prozessstart-Event kann einen Business Key in der Variablen `key` und zusätzliche Daten in der Variable `data` enthalten. Die Variable `data` wird in der digiwf-engine mit einer Map dargestellt. Daher können Sie Informationen dynamisch nach einem Schlüssel (String) Wert (beliebiges Objekt) Schema hinzufügen.
25 |
26 | > Der Business Key ist eine spezielle Prozessvariable, die vollständig indiziert ist und normalerweise domänenspezifische Informationen enthält. Weitere Einzelheiten finden Sie in [diesem Blogbeitrag] (https://camunda.com/blog/2018/10/business-key/).
27 |
28 | ```json
29 | {
30 | "key": "my-process",
31 | "data": {
32 | ...
33 | }
34 | }
35 | ```
36 |
37 | | Feld | Datentype | Erforderlich |
38 | |------|---------------------|--------------|
39 | | key | String | Optional |
40 | | data | Map | Optional |
41 |
42 |
43 | ## Nachrichten korrelieren
44 |
45 | Um eine Nachricht mit einer Prozessinstanz zu korrelieren, müssen Sie ein Korrelationsnachrichtenereignis an das Topic `dwf-digiwf-engine-ENV` (ersetzen Sie *ENV* durch eine gültige Umgebung) mit dem Header `type` und dem Wert `CorrelateMessageTOV01` senden.
46 |
47 | Das Korrelationsnachrichtenereignis sollte als `processInstanceId` die Instanz-ID Ihres Prozesses, einen optionalen Nachrichtennamen und einen optionalen Business Key enthalten. Zusätzlich können Sie eine Korrelation angeben. Die Correlation- und Payloadvariablen werden als Schlüssel (String) Wert (beliebiges Objekt) Map dargestellt.
48 |
49 | ```json
50 | {
51 | "processInstanceId": "my-process-instance-id",
52 | "messageName": "MessageEvent",
53 | "businessKey": "my-business-key",
54 | "correlationVariables": {
55 | ...
56 | },
57 | "correlationVariablesLocal": {
58 | ...
59 | },
60 | "payloadVariables": {
61 | ...
62 | },
63 | "payloadVariablesLocal": {
64 | ...
65 | }
66 | }
67 | ```
68 |
69 | | Feld | Datentype | Erforderlich |
70 | |---------------------------|---------------------|--------------|
71 | | processInstanceId | String | Erforderlich |
72 | | messageName | String | Optional |
73 | | businessKey | String | Optional |
74 | | correlationVariables | Map | Optional |
75 | | correlationVariablesLocal | Map | Optional |
76 | | payloadVariables | Map | Optional |
77 | | payloadVariablesLocal | Map | Optional |
78 |
--------------------------------------------------------------------------------
/content/de/resources/tutorials/overview.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Tutorials and Guides
3 | description: Tutorials and Guides
4 | category: 'Tutorials'
5 | categoryIcon: 'mdi-school'
6 | position: 1
7 | ---
8 |
9 |
10 |
--------------------------------------------------------------------------------
/content/de/roadmap.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: DigiWF Roadmap
3 | description: ''
4 | category: 'Landing'
5 | position: 2
6 | ---
7 |
8 | DigiWF ist derzeit ein intern entwickeltes Projekt. Wir erstellen Repos für neue Artefakte direkt auf GitHub. Alle
9 | älteren Repositories werden Schritt für Schritt von unserem internen Git in diesen öffentlichen Git-Bereich
10 | (https://github.com/it-at-m) übertragen. Dies ist ein zeitaufwändiger Prozess - bleib also bitte geduldig und
11 | folge uns auf den Social Media Kanälen, um in Kontakt zu bleiben.
12 |
13 | - Integrationsartefakt für JMS (enthält Spring Boot Starter, Pipeline zum Maven-Repo)
14 | - NPM-Paket für den Formulareditor (enthält Pipeline im NPM-Repo)
15 | - VS-Code-Plugin-Formular-Editor
16 | - Übertragen des Self-Service-Portals auf github
17 | - Spring Boot Starter für die Dateiübertragung über Integrationsartefakte
18 | - Spring Boot Starter zur automatischen Registrierung von Integrationsartefakten in DigiWF
19 |
--------------------------------------------------------------------------------
/content/ecosystem/contribution/contribution.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Contributions
3 | description: How to participate in the development of DigiWF?
4 | category: 'Contributions'
5 | categoryIcon: 'mdi-gift-open-outline'
6 | position: 1
7 | ---
8 |
9 | ## Documentation
10 |
11 | ### Documentation of integration artifacts
12 |
13 | The documentation of (official) integration artifacts should be done in the respective repository in github and in the official central documentation (here). In order to not have to maintain content twice, the following rules apply:
14 |
15 | 1. Documentation shall be in English only. Also, for all translations (German for example) the English documentation is to be integrated.
16 | 2. The documentation is located in the respective repository in the folder 'docs'.
17 | 3. The documentation should be split into single sections. These section should then be included in the `readme.md` inside the repository, as well as here in the central documentation.
18 | 4. For each language, a file must be created under `[language]/resources/modules`. The Markdown files from the repos are included via the component `DwfMarkdownLoader`. ElementTemplates can be included via the component `DwfElementTemplateDocs`.
19 | 5. For the integration artifact an entry is created on the page `[language]/resources/modules/modules.md` (again,
20 | please do this for all translations). To display a map on the overview page the component
21 | `DwfIntegrationArtifact` must be inserted into the already existing `` element.
22 | 6. Inside the folder `docs` should be (at least) the following contents: quickstart, architecture overview (if possible
23 | with picture), all operations (element templates) in separate files. Please document especially the input and output parameters of the element templates.
24 | 7. Images inside the pages must be inserted with absolute paths to display them correctly in the central documentation (here). In github there is a function "copy permalink" (see screenshot below). It doesn't matter if the image is included via Markdown or HTML. If embedded via HTML, please be so kind as to limit the size.
25 | 8. Most important point: Please make sure that everything works and looks good. For example, that the text does not overlap the cards. That images have a maximum width value if possible (e.g. 960px), etc.
26 |
27 |
28 | It is important to rebuild and deploy the central documentation page when making changes to the documentation in the repo. Since it is a static page, it does not get any changes from another repo / on another server.
29 |
30 |
31 | If you omit headers in the files in the folder 'docs' and place them on the description page instead, a table of contents is automatically generated on the right side. Headers within the referenced documents cannot be shown here.
32 |
33 |
34 |
35 |
39 | Absolute paths to images
40 |
41 |
42 | ### Special Components
43 |
44 | #### DwfIntegrationArtifact
45 |
46 | Using the component 'DwfIntegrationArtifact' you can create "tiles" on the overview page for the integration artifacts.
47 |
48 | ``` html
49 |
55 |
56 | ```
57 |
58 | Attributes:
59 | - `icon` = The [Material Design Icons](https://materialdesignicons.com/) code for the icon to be displayed in the top left corner.
60 | - `name` = The name of the integration artifact.
61 | - `description` = The description of the integration artifact. Please make sure that the description is as short as possible to represent the service, but not so long that other content is "squeezed" out of the map.
62 | - `github` = The URL to the github repository.
63 | - `docs` = The relative path to the description stored in this documentation. It will usually start with `/resources/modules/`, followed by the name of the markdown file (without file extension). If the file was stored elsewhere, then of course the path must be adjusted accordingly. The path for the translations is adjusted automatically. So for example for the German translation no `de` must be prefixed.
64 |
65 |
66 |
71 | Integration Artifact Card (Sample)
72 |
73 |
74 | #### DwfMarkdownLoader
75 |
76 | The component `DwfMarkdownLoader` can be used to load Markdown files that are located on other servers.
77 |
78 | ``` html
79 |
82 | ```
83 |
84 | If you want to load Markdown documents from github, it is recommended to use the "raw" view.
85 |
86 | #### DwfElementTemplateDocs
87 |
88 | The component `DwfElementTemplateDocs` can be used to load and show ElementTemplates on other servers. The template will be shown as a list, with every line referring to a property inside the template.
89 |
90 | ``` html
91 |
94 | ```
95 |
96 |
97 |
101 | Element template table (example)
102 |
--------------------------------------------------------------------------------
/content/history.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: DigiWF Process & Integration platform
3 | description: ''
4 | category: 'Landing'
5 | position: 1
6 | ---
7 |
8 | In 2019 we started to drive process automation in the public administration of the state capital Munich based on the [Camunda](https://camunda.com/) BPMN process engine. A separate task list based on [VueJs](https://vuejs.org/) and [VuetifyJs](https://vuetifyjs.com/) was implemented relatively early on under the project name DigiWF. In addition, the first integration modules such as mail or DMS were built into the backend infrastructure.
9 |
10 |
11 |
15 | The Core Components
16 |
17 |
18 | Today DigiWF has become a frequently used platform. Above all, the integration concept is now mature and any system that has an interface (and if it doesn't have an interface, then you just connect an RPA client) can be connected without much effort. This is made possible by a modular building block concept via a collection of Spring Boot starters. Problems such as file handling become a standard problem that can be solved equally (equally easily) on all input channels.
19 |
20 | When such a platform grows, sooner or later the question arises as to who should do the work. DigiWF has been consistently built so that people who are able to create automated workflows (but can't program) can do so on their own. This is made possible by a separate "low code" component - the co-creation. There, processes and decision tables can be created on the basis of BPMN and DMN. Backend systems (if an integration artefact is available for them) are declaratively connected via input and output templates. In addition to the processes, forms for user tasks can also be created using drag & drop.
21 |
22 | If you - similar to the state capital Munich - have many processes with a lot of user tasks. And then a
23 | heterogeneous backend landscape that you have to integrate into your processes, then you should definitely take a
24 | look at DigiWF. Simply contact us by [email](mailto:opensource@muenchen.de) or one of the social media channels.
25 |
--------------------------------------------------------------------------------
/content/resources/documentation/concept/eventbustopics.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Event Bus Topics
3 | description: How to communicate with DigiWF?
4 | category: 'Concept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 5
7 | ---
8 |
9 | The DigiWF applications communicate with an `Event Bus` to exchange events that occur within the DigiWF plattform.
10 | Internally the DigiWF application use spring cloud stream as an abstraction layer to interact with the `Event Bus`. Therefore, the `Event Bus` is interchangeable as long as a spring cloud stream binder exists.
11 |
12 | In this article we explain our topic naming conventions and list the currently existing topics.
13 |
14 | ## Naming conventions for Event Bus Topics
15 |
16 | ```
17 | ---
18 | ```
19 |
20 | Every DigiWF topic name consist of these 3 parts:
21 |
22 | - **prefix** is used to group the topics to a specific application. In the context of DigiWF this prefix is usually `dwf`.
23 | - **domain** Every DigiWF topic belongs to a specific domain. The name of the domain may be similar to the application name.
24 | - **usage-context** If a domain has more than 1 topic an additional `` is added to the topics name. The `` is optional.
25 | - **environment** is the suffix describing the environment the applications run in.
26 |
27 | Examples:
28 |
29 | - `dwf-cocreation-ENV` is the main topic of the cocreation plattform. To this topic deployment events are sent.
30 | - `dwf-cocreation-deploy-ENV` is the second topic of the cocreation plattform. To this topic deployment success messages are sent.
31 |
32 | ## Available Event Bus Topics
33 |
34 | Currently, the environments `dev`, `test`, `demo` and `local-01` exist. `dev`, `test` and `demo` are our CI/CD stages and `local-01` is used for development.
35 |
36 | ### Domain digiwf-engine
37 |
38 | The digiwf-engine uses the spring cloud stream function router to route events based on the `type` header to the according spring cloud functions.
39 | Therefore, every message that is sent to `dwf-digiwf-engine-` requires the header `type`.
40 |
41 | ```
42 | dwf-digiwf-engine-
43 | ```
44 |
45 | The following values for the header `type` are currently supported:
46 |
47 | | Header Type | Payload Type | Description |
48 | |---------------------|-------------------------|--------------------------------------------------------------------------------------------------|
49 | | correlateMessageV01 | `CorrelateMessageTOV01` | Use `CorrelateMessageTOV01` header type to correlate a message to a process instance. |
50 | | startProcessV01 | `StartInstanceTOV01` | Use `startProcessV01` header type to start a new process instance with the process key and data. |
51 |
52 |
53 | > **Note:**
54 | > We use springwolf to generate asyncapi documentations. Checkout the services asyncapi docs under */springwolf/asyncapi-ui.html*.
55 |
56 | ### Domain cocreation
57 |
58 | Processes, decision tables and json schema forms that are developed in the cocreation plattform are deployed to the digiwf-engine with a deployment event that is sent to the `dwf-cocreation-` topic.
59 |
60 | ```
61 | dwf-cocreation-
62 | ```
63 |
64 | In the cocreation plattform the user can choose the environment their artifact is deployed to.
65 | Based on their environment decision the deployment event is dynamically routed to the according topic.
66 | This happens in the bpm-server application.
67 |
68 | The digiwf-engine application is a consumer of the `dwf-cocreation-` topic and deploys the artifacts (bpmn, dmn or json form) from incoming deployment events to the camunda engine.
69 | The digiwf-engine uses the spring cloud stream function router to route events based on the `type` header to the according spring cloud functions.
70 |
71 | The following values for the header `type` are currently supported:
72 |
73 | | Header Type | Payload Type | Description |
74 | |----------------|-------------------------|--------------------------------------------------------------------------------------------|
75 | | deploy | `DeploymentEvent` | Use the `deploy` header type to deploy processes and decision tables to the digiwf-engine. |
76 | | deploySchema | `SchemaDeploymentEvent` | Use the `deploySchema` header type to deploy JSON schema forms to the digiwf-engine. |
77 |
78 | ```
79 | dwf-cocreation-deploy-
80 | ```
81 |
82 | After every deployment the digiwf-engine sends a deployment status event to the `dwf-cocreation-deploy-` topic that informs subscribes of the topic about the success or failure of the deployment.
83 |
84 | > **Note:**
85 | > We use springwolf to generate asyncapi documentations. Checkout the services asyncapi docs under */springwolf/asyncapi-ui.html*.
86 |
--------------------------------------------------------------------------------
/content/resources/documentation/concept/filehandling.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Handling files
3 | description: How can (large) files be handled in processes?
4 | category: 'Concept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 3
7 | ---
8 |
9 |
10 |
11 | Dealing with files inherently presents challenges for a process and integration platform. Files can be very large, or occur in large numbers, and thus present a potential resource problem. Therefore, DigiWf does not load files into memory or loop them through the process. File handling takes place in the integration layers (either GUI or backend).
12 |
13 |
14 |
18 | File handling in the two integration layers
19 |
20 |
21 | A fundamental element in the handling of files (regardless of whether they enter the system via the GUI or connected backend components) is the file store. In the case of DigiWF, this is an 'S3 service'. Here a cloud solution like AWS or an on prem service can be used. Communication with the service itself is abstracted via a generically valid interface.
22 |
23 | In principle, it is possible (and recommended if the platform is used multiple times) to provide more than one `S3 bucket` as file storage. However, not in the same `S3 Service` - here there is a 1:1 relationship between service and `S3 Bucket`. Nevertheless - depending on the subject matter - a separate `S3 Bucket` with its own `S3 Service` can be connected to the platform here according to domain, process or department. This means that with a larger installation (for example, company-wide) you will usually have n `S3 Services` connected.
24 |
25 |
26 |
27 |
28 | ## File handling in the Application Integration Layer
29 | Classic cases where files need to be handled in the `Application Integration Layer` are:
30 | - E-mail (with attachments)
31 | - File and record storage in a document management system
32 | - File generation, such as PDF generation
33 |
34 | ### Incoming Files
35 |
36 |
40 | File handling for incoming files
41 |
42 |
43 | The figure above shows how incoming files are handled.
44 |
45 | 1. A file is created or received from outside.
46 | 2. To store the files, a `presigned URL` [^1] is requested and generated at the `S3 service` for storage. A `presigned URL` is a temporary URL for a specific operation (e.g. `POST`, `PUT`, etc.) that can be used to send files directly to an `S3 bucket` without having to be logged in. How long such a URL is valid can be set. For the use case shown here, even very short validity periods work, since this is purely machine processing. In addition to the URL, a reference or file ID is generated and returned at this point.
47 | 3. With the URL the file is now written directly into the S3 memory. This is done without a detour via another service.
48 | 4. The file reference is passed to the process via the `Event Bus`. From this point on the process is responsible for keeping this file ID carefully, because only with this reference can the file still be found via the `S3 service` and loaded accordingly.
49 |
50 | ### Outgoing Files
51 |
52 |
56 | File handling for outgoing files
57 |
58 |
59 | The figure above shows how outgoing files are handled.
60 |
61 | 1. Basic requirement to fetch a file (or a whole folder) from the 'S3 Bucket' is the reference or file ID. If you want to load multiple files / folders - and attach them to an email for example - you will also need a corresponding number of reference IDs. I.e. the cardinality between file / folder and reference ID is always 1:1.
62 | 2. With the reference ID a `presigned URL` can be requested at the `S3 Service` for the operation `GET`. The same applies here - a separate `presigned URL` is required for each file.
63 | 3. With the `presigned URL` the file can be loaded directly from the `S3 Bucket`.
64 | 4. The file(s) will be attached to the mail and sent.
65 |
66 |
67 | By the way, it is not recommended to give out a presigned URL directly (e.g. to send it by mail). As described above, such a URL is only valid for a certain time. I.e. if this period has expired, then the file can no longer be accessed via the URL. If then also the process instance was terminated, one has also no longer so simply access to the reference ID.
68 |
69 |
70 |
71 |
72 |
73 | ## File handling in GUI Integration Layer
74 | Of course, files do not only come from connected procedures, but can also enter the system via the graphical user interface. Here, too, file handling is handled via the S3 service. It is important to note here that communication does not take place via the 'event bus' - as is the case with the integration artifacts - but via a 'REST' call, since the user interface components do not have direct access to the 'event bus'.
75 |
76 |
77 |
81 | Saving file(s) from the frontend.
82 |
83 |
84 | Here is described how to save a file from the form component `File Upload Control`. However, the way is in principle also usable for own forms or other interfaces.
85 |
86 | 1. A `presigned URL` is requested at the `S3 Service`. The following parameters are passed:
87 | - `refID` The reference, under which the file can be retrieved later.
88 | - `filename` The name of the file to be saved.
89 | - `endOfLife` A deletion date can be specified. At this time the file will be deleted automatically from the S3 memory. This is especially useful if data may only be kept for a certain time.
90 | - `expiredInMinutes` The time span in minutes for which the link is valid. After this time has expired, it can no longer be used.
91 | 2. The `S3 Service` creates a corresponding `presigned URL` via the S3 storage. What exactly happens there can be seen in the sequence diagram below. This URL is returned to the `File Upload Control`.
92 | 3. Using the `presigned URL`, the user interface component can now transfer the file directly to the S3 storage.
93 |
94 | If you want to store more than one file, you have to repeat this process accordingly.
95 |
96 | ### Authorization when handling files from the frontend
97 |
98 | While in the integration layer it is relatively clear who can access which file, this is much more difficult to decide in the frontend. this is much more difficult to decide, since here potentially everyone can access the interface first.
99 |
100 |
101 |
105 | Saving file(s) from the frontend - detailed view.
106 |
107 |
108 |
109 |
114 | Loading file(s) from the frontend - detailed view.
115 |
116 |
117 |
118 |
119 |
120 | [^1]: see https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html
121 |
122 |
123 |
124 |
--------------------------------------------------------------------------------
/content/resources/documentation/concept/integration.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: System Integration
3 | description: How can I integrate systems into the processes?
4 | category: 'Concept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 2
7 | ---
8 |
9 | A basic functionality of DigiWF is to connect the processes with the backend infrastructure. Here it is
10 | secondary where the applications are located that are to be used in a workflow. They can be hosted on prem, as well as running in the cloud. The important thing is that they have an interface - or if they don't have one, the application can still be connected via an RPA service.
11 |
12 | ## The DigiWF integration architecture
13 |
14 |
18 | High Level Integrations Architecture
19 |
20 |
21 | Quite abstractly, we have in the 'Application Integration Layer' a collection of services that are connected to the 'Event Bus'. It does not matter where these services run or in which technology they are implemented. The important thing is that they can communicate with the `Event Bus`. The `type` of services is also not limited to a connection between the platform and an already existing system. Various microservices can also be directly connected here.
22 |
23 | In `run`, the `Business Process Layer` (DigiWF Core) also knows nothing about any integration service. The two are actually loosely coupled. In `build`, on the other hand, the services or the service operations that are to be called from a process must be known. The connection happens here by an `element template` [^1]. In principle such a template is an input / output mapping. I.e. the data from the process are mapped to the expected data of the operation and vice versa.
24 |
25 | ## Interaction from the process
26 |
27 |
32 | Example use of an integration artifact from a BPMN process
33 |
34 |
35 | In order to be able to create reusable operation calls from BPMN processes, it makes sense to encapsulate them in subprocesses. The figure above shows an example of this. A Send & Reply pattern appears here as a service task that process modelers can easily include in the process. Generic error handling could also be mapped here. It is important that the subprocess has its own 'element template'. I.e. the incoming parameters correspond to the values that the subprocess expects to be called. The outgoing parameters are those that the subprocess returns at the end.
36 |
37 | ## Create your own integration artifacts
38 |
39 |
43 | Example use of Spring Boot starters to create your own integration artifact
44 |
45 |
46 | To make it as easy as possible to create your own integration artifacts or micro services, we provide basic functionality in the form of `Spring Boot Starters` [^2]. These can be easily integrated into the project using the appropriate dependency management (Maven, Gradle, etc.). After that they are ready for use. I.e. they can be configured via the `application.yaml` of the project (here `your-own-mail-integration`). This is useful to be able to set the individual environment specific parameters for a system - but still not have to implement the standardized usage anything by yourself.
47 |
48 | In the example above, a `your-own-mail-integration` service is created. This handles incoming and outgoing mail. If you include the `digiwf-mail-integration-starter`, you automatically get a connection to the S3 service. Mails can contain file attachments, which you do not want to have in the process. I.e. with incoming attachments these are stored in advance in the file memory and the reference is passed on to the process. For outgoing mails it is the other way around. The process provides a reference to the file(s), which is used to load them from the file store and attach them to the mail. This logic - to process file attachments via the file store - is already completely included in `digiwf-mail-integration-starter` and `digiwf-s3-integration-client-starter`. I.e. to connect a mail server, in the best case nothing more has to be programmed. You just create a Spring Boot project (e.g. via [^3]), include the starters and you are ready to work with the right configuration.
49 |
50 | [^1]: See https://docs.camunda.io/docs/components/modeler/desktop-modeler/element-templates/about-templates/
51 | [^2]: See https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using.build-systems.starters
52 | [^3]: See https://start.spring.io/
53 |
54 |
--------------------------------------------------------------------------------
/content/resources/documentation/concept/overview.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: DigiWF Overview
3 | description: What is the DigiWF architecture from an astronauts view.
4 | category: 'Concept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 1
7 | ---
8 |
9 | DigiWF is the glue between your frontend and backend systems. Everything you can reach over a network connection, you can attach to DigiWF and use it declarative in your BPMN processes. We're the bridge between the developer team and process designers.
10 |
11 | ## The DigiWF Platform Concept
12 |
13 |
17 | Interaction DigWF Core & the surrounding systems
18 |
19 |
20 | DigiWF provides four core competencies:
21 |
22 | - **A process layer (DigiWF Core)**, in which of course the process instances and decision tables (DMN) based on Camunda BPMN are executed. But also the form descriptions are saved, or user tasks are executed.
23 | - **An integration layer towards the frontend**. Interfaces and/or forms are made available here at runtime, which can be used in your own (frontend) applications. Alternatively, the completed task list can be used to process user tasks or display the status of a workflow.
24 | - **An integration layer towards the backend**. Everything that has an interface can be connected via it. If there is no interface, an RPA service can still be used. In order to be able to quickly integrate your own methods into the processes, a number of "ready-to-use" modules are provided in the form of Spring Starters. These can be used to solve recurring problems - such as handling incoming or outgoing files (e.g. e-mails with attachments) - in a standardized way. Just insert a starter and use the API.
25 | - **A co-creation area** to give non-technical users the opportunity to model their processes, decision tables and forms and even to deploy them on the platform. A separate Web IDE was created for this purpose, which can be used easily via the browser.
26 |
27 | ## Core Modules
28 |
29 |
35 | The DigiWF Modules + possibilities to integrate custom components
36 |
37 |
38 | The picture above shows a possible "full blown" DigiWF architecture including self crafted artifacts. Everything in
39 | blue is provided by the DigiWF project, but we're open for integrations. So you could create and integrate:
40 |
41 | - your own frontends
42 | - your own integration artifacts to communicate with your on premise or cloud infrastructure
43 | - your own (micro) services
44 |
45 | You can use any technology you want. There're only two preconditions:
46 |
47 | - your frontend technology must have a GraphQL client
48 | - your backen (services, integration artifacts) must be able to communicate with one of [Spring Cloud Streams](https://spring.io/projects/spring-cloud-stream) supported Binder implementations.
49 |
50 |
51 | If you want use another EventBus infrastructure than Apache Kafka, you have to configure this in your DigiWF configurations.
52 |
53 |
54 | Of course - if you'll use Spring Boot in your backend components and VueJs as front end technology, you can use all cross-section components (like Spring Boot Starters, NPM components, ...) we have created for our components.
55 |
56 | ### DigiWF Core
57 | DigiWF Core is the heart of DigiWF. As you can see in the section above it consists of 5 services. It has a GraphQL
58 | API to interact with frontend applications and a very generic API, that communicates with various backend systems over an event bus.
59 |
60 |
61 |
65 | The DigiWF Core Services
66 |
67 |
68 | The main goal of DigiWF is to create a declarative way for process designers to interact with a technical infrastructure. For this we've created some supporting services around the opensource [camunda](https://camunda.com/) workflow:
69 |
70 | - Process Service: This is the service where Camunda is embedded. It is used mainly to execute the BPMN workflows.
71 | - Service Instance: This handles any kind of service instances. A service instance can be a process, but does not
72 | have to do.
73 | - Task Service: This service handles everything we need for human tasks (authorization, mapping, back channel, ...).
74 | - Form & Validation Service: Everything we need in connection with forms is processed. We save the form definition and perform all kinds of form validation.
75 | - Service Definition Service: This service is responsible for service definitions and the corresponding configurations.
76 |
77 | ### DigiWF Integration
78 |
79 |
85 | A sample how you can build a custom integration artifact based on our starters
86 |
87 | If you want to integrate any kind of backend system, you can do this via the integration layer. DigiWF integration is on one side a set of predefined integration artifacts like S3, Mail, JMS or other. On the other side is DigiWF integration a toolbox, to help you to build own integration artifacts as quick as possible. This is ensured by the consistent use of Spring Boot starters to implement basic functionalities.
88 |
89 | ### DigiWF Tasklist
90 | This is a simple frontend to interact with running process instances. Every user task occurs on the tasklist and can be picked up (of course only if you have the right to). You can see the state of "your" processes and start new instances over the tasklist. If you don't like such a highly standardized frontend, you're free to use the components like the form builder and integrate them into your own beautiful web app. Or you can use the API directly and build all the fancy frontend stuff on your own, in the technology you like most.
91 |
92 | ### DigiWF Co-Creation
93 | The DigiWF Co-Creation section is the low code area. Here a process designer can draw BPMN processes, tinkering
94 | with decision tables (DMN) or create webforms per drag and drop. Deployment into different infrastructures is possible over this web app, too.
95 |
96 |
99 | The DigiWF Form Builder
100 |
101 |
102 | [comment]: <> ()
103 |
104 | [comment]: <> (This is a hint field!)
105 |
106 | [comment]: <> ()
107 |
108 | [comment]: <> ()
109 |
110 | [comment]: <> (This is a warn field!)
111 |
112 | [comment]: <> ()
113 |
114 | [comment]: <> ()
115 |
116 | [comment]: <> (This is a neutral field!)
117 |
118 | [comment]: <> ()
119 |
120 |
--------------------------------------------------------------------------------
/content/resources/documentation/concept/selfservice.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Self Service
3 | description: How can new processes or forms brought to the plattform?
4 | category: 'Concept'
5 | categoryIcon: 'mdi-floor-plan'
6 | position: 4
7 | ---
8 |
9 | To be done.
10 |
--------------------------------------------------------------------------------
/content/resources/modules/emailintegration.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: E-Mail Integration Artifact
3 | description: E-Mail Integration Artifact
4 | category: 'Integration Artifacts'
5 | categoryIcon: 'mdi-toy-brick'
6 | position: 100
7 | ---
8 |
9 |
10 |
11 |
12 |
13 | ## Element Templates
14 |
15 |
16 |
17 |
18 |
--------------------------------------------------------------------------------
/content/resources/modules/modules.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Integration Artifacts Overview
3 | description: An overview of the DigiWF Integration Artifacts
4 | category: 'Integration Artifacts'
5 | categoryIcon: 'mdi-toy-brick-outline'
6 | position: 1
7 | ---
8 |
9 |
10 |
11 |
14 |
15 |
18 |
19 |
20 |
21 |
--------------------------------------------------------------------------------
/content/resources/modules/okewointegration.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: OK.EWO Integration Artifact
3 | description: OK.EWO Integration Artifact
4 | category: 'Integration Artifacts'
5 | categoryIcon: 'mdi-toy-brick'
6 | position: 99
7 | ---
8 |
9 |
10 |
11 |
12 |
13 | ## Element Templates
14 |
15 |
16 |
17 |
18 |
--------------------------------------------------------------------------------
/content/resources/tutorials/deploy-artifacts-to-digiwf-engine.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Deploy artifacts to digiwf-engine?
3 | description: Deployment of bpmn, dmn and jsonschema forms to the digiwf-engine with kafka
4 | category: 'Tutorials'
5 | categoryIcon: 'mdi-school'
6 | position: 2
7 | ---
8 |
9 | This tutorial should show you how to deploy artifacts (bpmn, dmn and jsonschema forms) to the digiwf-engine using the corresponding kafka topic.
10 | Additionally, you can check out our documentation [here](/resources/documentation/concept/eventbustopics).
11 |
12 | To integrate with the digiwf-engine you have to send events to the kafka topics the digiwf-engine listens to.
13 | Internally the digiwf-engine uses a custom spring cloud stream function router that routes the incoming events to the according topics based on the `type` header.
14 | With this approach the same topic can be used for different event types.
15 | The supported event types are listed in the [documentation](/resources/documentation/concept/eventbustopics).
16 |
17 | > Note: If you do not set the Header `type` in your kafka messages the digiwf-engine cannot route the message to the suitable consumer function. This also applies if you set an unknown value for the `type` header.
18 |
19 |
20 | ## Artifact deployment (bpmn, dmn, json schema and process configurations)
21 |
22 | To deploy artifacts to the digiwf-engine send a deployment event to the `dwf-cocreation-` topic topic (replace the *ENV* with a valid environment) with the header `type` and the value `deploy` for *.bpmn* and *.dmn* files. For json schema forms use the header `type` with the value `deploySchema`. For process configurations use the header `type` with the value `deployConfiguration`.
23 |
24 | The deployment event consists of a unique `deploymentId` and `versionId`. The `target` represent the environment you deployed the event to. The `artifactType` is either `BPMN`, `DMN`, `FORM` or `CONFIGURATION` and the `file` is the file converted to string.
25 |
26 | ```json
27 | {
28 | "deploymentId": "8d15da94-b4cb-43de-abb5-bca085af0da0",
29 | "versionId": "26326aa2-f3d4-4783-bbd8-7099d4bfd4a4",
30 | "target": "DEV",
31 | "file": "...",
32 | "artifactType": "BPMN"
33 | }
34 | ```
35 |
--------------------------------------------------------------------------------
/content/resources/tutorials/kafka-topics-tutorial.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to communicate with digiwf-engine?
3 | description: Tutorials and Guides
4 | category: 'Tutorials'
5 | categoryIcon: 'mdi-school'
6 | position: 2
7 | ---
8 |
9 | This tutorial should show you how to integrate with the digiwf-engine using the kafka topics. Additionally, you can check out our documentation [here](/resources/documentation/concept/eventbustopics).
10 |
11 | To integrate with the digiwf-engine you have to send events to the kafka topics the digiwf-engine listens to.
12 | Internally the digiwf-engine uses a custom spring cloud stream function router that routes the incoming events to the according topics based on the `type` header.
13 | With this approach the same topic can be used for different event types.
14 | The supported event types are listed in the [documentation](/resources/documentation/concept/eventbustopics).
15 |
16 | > Note: If you do not set the `type` in your kafka messages the digiwf-engine cannot route the message to the suitable consumer function. This also applies if you set an unknown value for the `type` header.
17 |
18 |
19 | ## Start process
20 |
21 | The digiwf-engine uses internally a custom spring cloud stream function router that routes incoming message to the according topic.
22 | Therefore, you have to send a start process event to the `dwf-digiwf-engine-ENV` topic (replace the *ENV* with a valid environment) with the header `type` and the value `startProcessV01` to start a new process.
23 | The `type` headers value is used in the digiwf-engine to route the start process event to the suitable consumer function.
24 |
25 | The start process event may contain a business key in `key` variable and additional data in the `data` variable. The `data` variable is represented in the digiwf-engine with a map. Therefore, you can add information dynamically following a key (String) value (any object) schema.
26 |
27 | > The business key is special process variable that is fully indexed and usually contains domain specific information. For more details checkout [this blog post](https://camunda.com/blog/2018/10/business-key/).
28 |
29 | ```json
30 | {
31 | "key": "my-process",
32 | "data": {
33 | ...
34 | }
35 | }
36 | ```
37 |
38 | | Field | Datatype | Required |
39 | |-------|---------------------|----------|
40 | | key | String | Optional |
41 | | data | Map | Optional |
42 |
43 |
44 | ## Correlate message
45 |
46 | The digiwf-engine uses internally a custom spring cloud stream function router that routes incoming message to the according topic.
47 | Therefore, you have to send a correlate message event to the `dwf-digiwf-engine-ENV` topic (replace the *ENV* with a valid environment) with the header `type` and the value `CorrelateMessageTOV01` to correlate a message to a process instance.
48 | The `type` headers value is used in the digiwf-engine to route the correlate message event to the suitable consumer function.
49 |
50 | The correlate message event should contain as `processInstanceId` the instance id of your process, an optional message name and an optional business key. Additionally, you can provide correlation. The correlation and payload variables are represented as a key (string) value (any object) map.
51 |
52 | ```json
53 | {
54 | "processInstanceId": "my-process-instance-id",
55 | "messageName": "MessageEvent",
56 | "businessKey": "my-business-key",
57 | "correlationVariables": {
58 | ...
59 | },
60 | "correlationVariablesLocal": {
61 | ...
62 | },
63 | "payloadVariables": {
64 | ...
65 | },
66 | "payloadVariablesLocal": {
67 | ...
68 | }
69 | }
70 | ```
71 |
72 | | Field | Datatype | Required |
73 | |---------------------------|---------------------------|----------|
74 | | processInstanceId | String | Required |
75 | | messageName | String | Optional |
76 | | businessKey | String | Optional |
77 | | correlationVariables | Map | Optional |
78 | | correlationVariablesLocal | Map | Optional |
79 | | payloadVariables | Map | Optional |
80 | | payloadVariablesLocal | Map | Optional |
81 |
--------------------------------------------------------------------------------
/content/resources/tutorials/overview.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Tutorials and Guides
3 | description: Tutorials and Guides
4 | category: 'Tutorials'
5 | categoryIcon: 'mdi-school'
6 | position: 1
7 | ---
8 |
9 |
10 |
--------------------------------------------------------------------------------
/content/roadmap.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: DigiWF Roadmap
3 | description: ''
4 | category: 'Landing'
5 | position: 2
6 | ---
7 |
8 | - Integration artifact for JMS (includes Spring Boot Starter, pipeline to Maven repo)
9 | - NPM Package for Form Editor (includes pipeline in NPM repo)
10 | - VS Code Plugin Form Editor
11 | - Transferring Self Service Portal to github
12 | - Spring Boot Starter for file transfer over integration artifacts
13 | - Spring Boot Starter to autoregister integration artifacts in DigiWF
14 |
--------------------------------------------------------------------------------
/digiwf-project.iml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
--------------------------------------------------------------------------------
/layouts/default.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
58 |
--------------------------------------------------------------------------------
/layouts/error.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
9 |
13 |
14 |
15 |
16 |
17 | Go Home
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
51 |
--------------------------------------------------------------------------------
/locales/de.json:
--------------------------------------------------------------------------------
1 | {
2 | "index": {
3 | "foo": "This is a test"
4 | },
5 | "documentation": {
6 | "lastchange": "Letzte Änderung",
7 | "toc": "Inhaltsverzeichnis",
8 | "prev": "vorherige Seite",
9 | "next": "nächste Seite"
10 | },
11 | "footer": {
12 | "about": {
13 | "vision": "Vision Statement",
14 | "title": "Das Projekt",
15 | "roadmap": "Roadmap",
16 | "coc": "Code of Conduct",
17 | "contact": "Kontakt",
18 | "impress": "Impressum"
19 | },
20 | "ecosystem": {
21 | "title": "Öko-System",
22 | "contribution": "Contributions"
23 | },
24 | "resources": {
25 | "title": "Quellen",
26 | "architecture": "Konzeption",
27 | "modules": "Integrations Artefakte",
28 | "tutorials": "Tutorials"
29 | },
30 | "social": {
31 | "title": "Stay tuned!",
32 | "text": "Folge uns auf github, twitter oder slack."
33 | }
34 | },
35 | "toolbar": {
36 | "language": {
37 | "aria": "Hier kann die Sprache umgestellt werden."
38 | }
39 | },
40 | "social": {
41 | "github": {
42 | "aria": "Öffnet den Github Projekt Space in einem eigenen Browser Tab."
43 | },
44 | "twitter": {
45 | "aria": "Öffnet den DigiWF Twitter Account in einem eigenen Browser Tab."
46 | },
47 | "slack": {
48 | "aria": "Öffnet Slack, oder die Registrierungsseite von Slack in einem eigenen Browser Tab."
49 | }
50 | },
51 | "tutorials": {
52 | "view": "Tutorial ansehen"
53 | }
54 | }
55 |
--------------------------------------------------------------------------------
/locales/en.json:
--------------------------------------------------------------------------------
1 | {
2 | "index": {
3 | "foo": "This is a test"
4 | },
5 | "documentation": {
6 | "lastchange": "Last Change",
7 | "toc": "Table of contents",
8 | "prev": "previous page",
9 | "next": "next page"
10 | },
11 | "integrationartifact": {
12 | "name": "Integration Artifact",
13 | "description": "Description",
14 | "github": "Github",
15 | "documentation": "Docs"
16 | },
17 | "footer": {
18 | "about": {
19 | "vision": "Vision Statement",
20 | "title": "About",
21 | "roadmap": "Roadmap",
22 | "coc": "Code of Conduct",
23 | "contact": "Contact us",
24 | "impress": "Impress"
25 | },
26 | "ecosystem": {
27 | "title": "Ecosystem",
28 | "contribution": "Contributions"
29 | },
30 | "resources": {
31 | "title": "Resources",
32 | "architecture": "Concept",
33 | "modules": "Integration Artifacts",
34 | "tutorials": "Tutorials"
35 | },
36 | "social": {
37 | "title": "Stay tuned!",
38 | "text": "Star us on github, follow on twitter or chat on slack."
39 | }
40 | },
41 | "toolbar": {
42 | "language": {
43 | "aria": "You can switch the language here."
44 | }
45 | },
46 | "social": {
47 | "github": {
48 | "aria": "link to our github account"
49 | },
50 | "twitter": {
51 | "aria": "opens our twitter account in a new tab"
52 | },
53 | "slack": {
54 | "aria": "opens our slack channel in a new tab"
55 | }
56 | },
57 | "tutorials": {
58 | "view": "View tutorial"
59 | }
60 | }
61 |
--------------------------------------------------------------------------------
/nuxt.config.js:
--------------------------------------------------------------------------------
1 | import colors from 'vuetify/es5/util/colors'
2 |
3 | export default {
4 | // Target: https://go.nuxtjs.dev/config-target
5 | target: 'static',
6 |
7 | router: {
8 | base: ''
9 | },
10 |
11 | // Global page headers: https://go.nuxtjs.dev/config-head
12 | head: {
13 | titleTemplate: '%s - digiwf-project',
14 | title: 'digiwf-project',
15 | htmlAttrs: {
16 | lang: 'en'
17 | },
18 | meta: [
19 | { charset: 'utf-8' },
20 | { name: 'viewport', content: 'width=device-width, initial-scale=1' },
21 | { hid: 'description', name: 'description', content: 'DigiWF process infrastructure based on Camunda workflow engine. Opensource project by it@M, Landeshauptstadt München. Public money, public code.' },
22 | { name: 'format-detection', content: 'telephone=no' }
23 | ],
24 | link: [
25 | { rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' }
26 | ]
27 | },
28 |
29 | // Global CSS: https://go.nuxtjs.dev/config-css
30 | css: [
31 | ],
32 |
33 | // Plugins to run before rendering page: https://go.nuxtjs.dev/config-plugins
34 | plugins: [
35 | ],
36 |
37 | // Auto import components: https://go.nuxtjs.dev/config-components
38 | components: true,
39 |
40 | // Modules for dev and build (recommended): https://go.nuxtjs.dev/config-modules
41 | buildModules: [
42 | // https://go.nuxtjs.dev/typescript
43 | '@nuxt/typescript-build',
44 | // https://go.nuxtjs.dev/vuetify
45 | '@nuxtjs/vuetify'
46 | ],
47 |
48 | // Modules: https://go.nuxtjs.dev/config-modules
49 | modules: [
50 | // https://go.nuxtjs.dev/content
51 | '@nuxt/content',
52 | '@nuxtjs/i18n',
53 | '@nuxt/http'
54 | ],
55 |
56 | // i18n configuration
57 | i18n: {
58 | locales: [
59 | { code: 'en', iso: 'en-GB', file: 'en.json', name: 'English' },
60 | { code: 'de', iso: 'de-DE', file: 'de.json', name: 'Deutsch' }
61 | ],
62 | defaultLocale: 'en',
63 | langDir: 'locales',
64 | vueI18n: {
65 | fallbackLocale: 'en',
66 | dateTimeFormats: {
67 | en: {
68 | short: {
69 | year: 'numeric',
70 | month: 'short',
71 | day: 'numeric'
72 | }
73 | },
74 | de: {
75 | short: {
76 | year: 'numeric',
77 | month: 'numeric',
78 | day: 'numeric'
79 | }
80 | }
81 | }
82 | }
83 | },
84 |
85 | // Content module configuration: https://go.nuxtjs.dev/config-content
86 | content: {},
87 |
88 | // Vuetify module configuration: https://go.nuxtjs.dev/config-vuetify
89 | vuetify: {
90 | customVariables: ['~/assets/variables.scss'],
91 | theme: {
92 | dark: false,
93 | themes: {
94 | dark: {
95 | primary: colors.blue.darken2,
96 | accent: colors.grey.darken3,
97 | secondary: colors.amber.darken3,
98 | info: colors.teal.lighten1,
99 | warning: colors.amber.base,
100 | error: colors.deepOrange.accent4,
101 | success: colors.green.accent3
102 | }
103 | }
104 | }
105 | },
106 |
107 | // Build Configuration: https://go.nuxtjs.dev/config-build
108 | build: {
109 | }
110 | }
111 |
--------------------------------------------------------------------------------
/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "digiwf-project",
3 | "version": "1.0.0",
4 | "private": true,
5 | "scripts": {
6 | "dev": "nuxt",
7 | "build": "nuxt build",
8 | "start": "nuxt start",
9 | "generate": "nuxt generate",
10 | "lint:js": "eslint --ext \".js,.vue\" --ignore-path .gitignore .",
11 | "lint": "npm run lint:js"
12 | },
13 | "dependencies": {
14 | "@nuxt/content": "^1.15.1",
15 | "@nuxt/http": "^0.6.4",
16 | "@nuxtjs/i18n": "^7.3.0",
17 | "core-js": "^3.25.1",
18 | "marked": "^4.1.0",
19 | "nuxt": "^2.15.8",
20 | "vuetify": "^2.6.10"
21 | },
22 | "devDependencies": {
23 | "@babel/eslint-parser": "^7.19.1",
24 | "@nuxt/types": "^2.15.7",
25 | "@nuxt/typescript-build": "^2.1.0",
26 | "@nuxtjs/eslint-config-typescript": "^10.0.0",
27 | "@nuxtjs/eslint-module": "^3.1.0",
28 | "@nuxtjs/vuetify": "^1.12.3",
29 | "eslint": "^8.23.1",
30 | "eslint-plugin-nuxt": "^3.2.0",
31 | "eslint-plugin-vue": "^9.2.0",
32 | "sass-loader": "^10.2.1",
33 | "webpack": "^4.46.0"
34 | }
35 | }
36 |
--------------------------------------------------------------------------------
/pages/_.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |