diff --git a/readme.md b/readme.md
index 86a1f9338e7831a8af8c7b4202815531260d25e4..5ad990990ee5504a371ecf3d381cf96ab8e81329 100644
--- a/readme.md
+++ b/readme.md
@@ -1,48 +1,71 @@
-# Keystore passwort
+# XTA-Adapter
+Der XTA-Adapter erzeugt neue OZG-Cloud-Vorgänge von XTA-Nachrichten.
 
-Das Keystore und Passwort müssen extra hinzugefügt werden. Keystore irgendwo im Dateisystem ablegen.
-Dazu eine Datei 'application-sec.yml' anlegen:
+Der XTA-Adapter läuft als cronjob und beendet sich, nachdem alle unterstützten Anträge vom XTA-Nachrichtenbroker (XTA-Server) abgeholt wurden.
+Jeder Antrag erzeugt einen neuen Vorgang im Vorgang-Manager. (Der Mantelantrag ist eine Ausnahme und kann mehrere Vorgänge erzeugen.)
 
-ozgcloud:
-  xta:
-    keystore:
-      store: file:<pfad zum keystore>
-      password: <geheim>
-      
-Den Dienst dann mit dem Spring-Profile 'sec' starten.
 
-# P12 Datei erzeugen und als Umgerbungsvariable umwandeln
-
-Wir haben eine pfx Datei bekommen und wandeln diese in eine P12 Cert Datei um:
-
-    keytool -importkeystore -srckeystore KOP_SH_KIEL_DEV.pfx -srcstoretype pkcs12 -destkeystore KOP_SH_KIEL_DEV.p12 -deststoretype PKCS12
+## Konfiguration vom Helm-Chart
+Die Standardeinstellung ist, dass der Adapter alle 5 Minuten startet:
+```yaml
+xta:
+  schedule: '*/5 * * * *'
+```
 
-Dann in Base64 umwandeln, damit es als Umgebungsvariable gesetzt werden kann:
+Es sollten Xta-Kennungen konfiguriert werden, für die Nachrichten abgeholt werden sollen, beispielsweise:
+```yaml
+identifiers:
+  - gae:meinekennung1@ozg-cloud.de
+  - vbe:123456789
+```
 
-    base64 KOP_SH_KIEL_DEV.p12
+Es wird ein `vorgang-manger` Service im Cluster angenommen:
+```yaml
+routing:
+  targetVorgangManagerName: vorgang-manager
+  fallbackStrategy: DENY
+  routingStrategy: SINGLE
+```
 
-# Lokale Installation
-Lokal das Root CA in keystore laden (https://ddatabox.dataport.de/public/download-shares/XUok5Wk3EDGWyYaoFGldOeJfGu0J8pke):
+Die URL des XTA-Servers muss konfiguriert werden, beispielsweise:
+```yaml
+xta:
+  server:
+    name: xta-test-server
+    address: xta-test-server-ozg4094.dev.by.ozg-cloud.de
+    protocol: https
+```
 
-    sudo keytool -trustcacerts -keystore /lib/jvm/java-1.17.0-openjdk-amd64/lib/security/cacerts -storepass changeit -importcert -alias dataportRoot -file DataportRootCA02.crt
+Der XTA-Adapter muss dem XTA-Server-Zertifikat vertrauen können.
+Dafür muss ein Root-Zertifikat `xtaRootCa` (in Base64-Kodierung) konfiguriert werden:
+```yaml
+xta:
+  rootCa: LS0tLS1CRUdJTiBDRVJUSUZ...
+```
+Der XTA-Adapter benötigt ein Client-Zertifikat, dass ihn zum Lesen der konfigurierten Xta-kennungen berechtigt.
+Das Client-Zertifikat muss in einem P12-KeyStore (in Base64-Kodierung) abgelegt werden:
+```yaml
+xta:
+  keystore:
+    file: MIIFCwIBAzCCBMEG...
+    password: password
+```
 
-Port forwarding aktivieren. Um eine Verbindung zum Nachrichtenbroker aufbauen zu können, muss diese über den Hetzner-Server geroutet werden:
+## Verwendung mit dem xta-test-server
 
-    ssh -L 3000:[Hetzner-Server-IP]:443 ozg-sh.de (ggf ssh -L 0.0.0.0:3000:[Hetzner-Server-IP]:443 ozg-sh.de)
+Der xta-test-server erlaubt mit einem validen Client-Zertifikat beliebige Nachricht-Typen mit beliebigen Kennungen zu senden und zu empfangen.
+Das CA-Zertifikat und Client-Zertifikat sollte aus dem entsprechenden Secrets des xta-test-servers heruntergeladen werden.
+Nähere Information hierzu sind in der internen-Dokumentation zu finden:
+https://git.ozg-sh.de/ozgcloud-doc/dokumentation/src/branch/master/Entwicklungsumgebung/Beistellungen/xta-test-server-SoapUI/README.md
+https://git.ozg-sh.de/ozgcloud-doc/dokumentation/src/branch/master/Entwicklungsumgebung#xta-adapter
 
-## Alternative Dataport Zertifikat Installation
-Zertifikate direkt vom Endpunkt anfragen: 
+## Verwendung mit dem Dataport-DEV-nachrichtenbroker
+Der Dataport-DEV-nachrichtenbroker ist nur erreichbar aus dem Landes-Netz.
+Um das Root-CA-Zertifikat `Dataport Root CA` zu erhalten, welches als `rootCa` konfiguriert werden kann, kann die Zertifikat-Kette direkt vom Endpunkt angefragt werden:
 ```shell
 openssl s_client -showcerts -connect li33-0005.dp.dsecurecloud.de:443 </dev/null
 ```
-und das `Dataport Root CA` Zertifikat unter `/etc/ssl/certs/dataport-root-ca.pem` abspeichern, dann `sudo update-ca-certificates` aufrufen.
-
-## deprecated
-
-DEPRECATED, da wir den HostNameVerifier deaktiviert haben: Hosts Datei erzeugen, damit der Hostname passt:
 
-    127.0.0.1 LI33-0005
+Das Zertifikat kann ggf. lokal unter `/etc/ssl/certs/dataport-root-ca.pem` installiert werden mit `sudo update-ca-certificates`.
 
-# SoapUi Projekt zum manuellen Abrufen des Nachrichtenbrokers
-Im Dokumentation Repo unter `Entwicklungsumgebung/Beistellungen/soapUiXTA` liegt ein SoapUi Projekt,
-dass manuelle XTA-Aufrufe des Nachrichtenbrokers ermöglicht.
+Ein Client-Zertifikat `KOP_SH_KIEL_DEV.p12`, das den Xta-Adapter zum Lesen von Xta-Kennungen berechtigt, muss beantragt werden.