Die IDMC kann Mappings, Tasks und Taskflows in einem Git-Repository versionieren. Mit GitHub oder GitLab in der Cloud ist das schnell eingerichtet. In vielen Unternehmen steht der Git-Server aber im eigenen Netz, und da kommt die Cloud von außen nicht heran. Wie bindet man also ein On-Premise-Git an, und was ist mit den internen Zertifikaten des Git-Servers?

Die Antwort ist der Secure Agent. In diesem Artikel zeige ich euch, wie die Verbindung funktioniert, wie man sie einrichtet und wie der Secure Agent dem Zertifikat eures Git-Servers vertraut. Grundlage sind die Informatica-Dokumentation mit Stand Juli 2026 und mehrere Artikel aus der Informatica Knowledge Base. Die Beispiele zeigen einen Secure Agent unter Linux.

Was unterstützt wird

Laut Dokumentation lassen sich folgende Systeme selbst gehostet anbinden:

Repository Selbst gehostet Cloud
GitHub (Enterprise Server) ja ja
GitLab (Self-Managed) ja ja
Atlassian Bitbucket ja nur Data-Integration-Assets
Microsoft Azure DevOps nein ja

Azure DevOps Server wird also nicht unterstützt. Die Verbindung läuft ausschließlich über HTTPS. Mit dem IPU-Modell sind laut Informatica alle berechtigten Cloud-Dienste enthalten. In älteren Orgs mit feature-basierter Lizenz ist Source Control dagegen lizenzpflichtig, und für On-Premise-Repositorys nennt die Knowledge Base zusätzlich die Lizenz „GitRepoConnectApp_R1“. Fehlt die Funktion in eurer Org, klärt das vor dem Einrichten mit Informatica.

So funktioniert die Verbindung

Die IDMC selbst hat keine Netzwerkverbindung in euer Firmennetz. Die Arbeit übernimmt ein eigener Dienst auf dem Secure Agent, die GitRepoConnectApp. Er legt auf der Agent-Maschine einen lokalen Klon des Branches an, in dem die IDMC-Assets liegen. Checkt ein Benutzer in der Oberfläche ein Asset ein, schreibt der Dienst die Änderung in diesen Klon und pusht sie zum Git-Server.

Die IDMC-Cloud beauftragt die GitRepoConnectApp auf dem Secure Agent; der Agent hält einen lokalen Klon und verbindet sich über HTTPS mit dem Git-Server im Firmennetz
Source Control mit einem Git-Server im Firmennetz.

Wie beim Secure Agent üblich, gehen alle Verbindungen vom Agent aus. Der Git-Server muss weder aus dem Internet erreichbar sein noch braucht er eine Freigabe für die IP-Adressen von Informatica. Wie man einen Secure Agent installiert, habe ich in einem früheren Artikel beschrieben.

Der lokale Klon liegt standardmäßig unter apps/GitRepoConnectApp/data/git_repository/ im Installationsverzeichnis des Agents. Er enthält nur den konfigurierten Branch. Plant trotzdem genug Platz auf der Platte ein, falls das Repository groß ist.

Einrichtung

Zuerst muss der Dienst auf dem Agent laufen. Unter Administrator > Runtime Environments öffnet man bei der Secure Agent Group im Menü Actions den Dialog Enable or Disable Services and Connectors und prüft auf der Registerkarte Additional Services, dass „GitRepoConnectApp“ aktiviert ist. Die Einstellung gilt für jeden Agent der Gruppe.

Danach folgt die Konfiguration der Organisation unter Administrator > Settings > Source Control. Nach Enable Source Control trägt man für ein On-Premise-Repository folgende Werte ein:

  • Platform: On-Premise
  • Global Git Repository URL: die HTTPS-Adresse zum Klonen, etwa https://git.firma.local/dwh/idmc-assets.git
  • Global Git Branch Name: der Branch für die IDMC-Assets; er muss im Repository bereits existieren
  • Runtime Environment: die Umgebung, über die der Zugriff läuft; jeder Agent dieser Umgebung muss den Git-Server erreichen

Mit Allow Push to Git Repository legt man fest, ob die Organisation schreiben darf oder nur lesen. Beim Speichern fragt die IDMC nach Git-Zugangsdaten, prüft damit die Verbindung und legt bei Schreibzugriff eine kleine README-Datei im Repository an. Die Zugangsdaten speichert sie dabei nicht.

Die eigentliche Anmeldung erfolgt pro Benutzer. Jeder, der mit Source Control arbeitet, hinterlegt über das Benutzersymbol oben rechts unter Settings seinen Git-Benutzer und ein Personal Access Token. Das Token muss laut Doku volle Rechte auf private Repositorys haben. OAuth gibt es für On-Premise-Repositorys nicht.

Proxy

Seit dem Release vom März 2022 schickt die GitRepoConnectApp ihre Anfragen über den Proxy, der für den Secure Agent konfiguriert ist. Für die Cloud ist das richtig, für einen Git-Server im eigenen Netz meist nicht. Der typische Fehler lautet dann „GIT_REPO_CONNECT_APP_004 … Unable to tunnel through proxy“.

Die Lösung ist ein Eintrag in apps/agentcore/conf/proxy.ini. Dort trägt man den Git-Server als Ausnahme ein, mehrere Hosts werden mit | getrennt:

InfaAgent.NonProxyHost=localhost|git.firma.local

Danach startet man den Secure Agent neu.

Zertifikate

Fast jeder interne Git-Server hat ein Zertifikat einer firmeneigenen Zertifizierungsstelle. Die kennt das Java des Secure Agents nicht, und jede Git-Aktion scheitert mit einer Meldung wie dieser:

org.eclipse.jgit.api.errors.TransportException: Secure connection to https://git.firma.local/dwh/idmc-assets.git could not be established because of SSL problems

Ältere Knowledge-Base-Artikel empfehlen, das Zertifikat mit keytool direkt in die cacerts der Java-Installationen des Agents zu importieren. Der aktuelle Artikel 000104900 (Stand August 2026) rät ausdrücklich davon ab. Stattdessen stellt Informatica das Werkzeug InstallCert V2 bereit, das die Truststores des Agents selbst findet.

InstallCert V2 einrichten

Das Werkzeug liegt als InstallCert_V2_JDK17.zip am Knowledge-Base-Artikel 000104900. Man entpackt es in das bin-Verzeichnis des neuesten JDK 17 des Agents:

cd /opt/infaagent/apps/jdk
ls -d */                        # neuestes JDK 17 heraussuchen
cd <jdk17-verzeichnis>/bin
unzip ~/InstallCert_V2_JDK17.zip

Im Zip stecken InstallCert-V2.jar, logging.properties und config.properties. In der config.properties bleiben alle ungenutzten Einträge auskommentiert. Für unseren Fall reichen zwei Werte:

host.name=git.firma.local
agent.install.path=/opt/infaagent

Mit host.name holt sich das Werkzeug das Zertifikat per TLS-Handshake vom Git-Server, standardmäßig über Port 443. Einen anderen Port setzt man mit port.number. Durch agent.install.path sucht es die JDKs des Agents und importiert das Zertifikat in alle gefundenen Truststores. Liegt das Zertifikat als Datei vor, kann man stattdessen mit external.certsPath einen Ordner angeben. Läuft der Handshake nur über einen Proxy, gibt es dafür die Einträge https.proxyHost, https.proxyPort, https.proxyUser und https.proxyPassword.

Gestartet wird das Werkzeug mit dem Java aus demselben Verzeichnis:

./java -Djava.util.logging.config.file=logging.properties -jar InstallCert-V2.jar config.properties

In der Ausgabe steht für jeden Truststore eine Zeile Installing certificates to truststore: … und der Alias, unter dem das Zertifikat eingetragen wurde. Zum Schluss prüft das Werkzeug die Verbindung noch einmal.

Truststore der GitRepoConnectApp prüfen

Hier lohnt ein zweiter Blick. Ich habe mir das Werkzeug genauer angesehen: Die JDKs des Agents ermittelt es aus der Datei lcm-env.sh des Dienstes Administrator. Die GitRepoConnectApp hat aber eine eigene lcm-env.sh, und ein älterer Knowledge-Base-Artikel importiert das Zertifikat ausdrücklich zusätzlich in das JDK, das dort eingetragen ist. Welches, verrät die Variable AGENT_JAVA_HOME:

cd /opt/infaagent/apps/GitRepoConnectApp
ls                              # neueste Versionsnummer heraussuchen
grep AGENT_JAVA_HOME <version>/.lcm/lcm-env.sh

Der Truststore dieses JDK ist <AGENT_JAVA_HOME>/lib/security/cacerts. Taucht er in der Ausgabe von InstallCert V2 auf, ist alles erledigt. Falls nicht, trägt man ihn in der config.properties ein und startet das Werkzeug noch einmal:

javax.net.ssl.trustStore=<AGENT_JAVA_HOME>/lib/security/cacerts
javax.net.ssl.trustStorePassword=changeit

Anschließend muss die GitRepoConnectApp neu starten, damit sie den geänderten Truststore liest. Das geht unter Administrator > Runtime Environments beim Agent über Stoppen und Starten des Dienstes oder durch einen Neustart des ganzen Agents:

cd /opt/infaagent/apps/agentcore
./infaagent.sh shutdown
./infaagent.sh startup

Hinweis: Bei einem Upgrade des Secure Agents übernimmt das Update-Skript eure eigenen Zertifikate aus der alten cacerts in die neue. Das funktioniert laut Knowledge Base aber nur, solange das Passwort der cacerts auf dem Standardwert changeit bleibt. Ändert es also nicht.

Stolpersteine

Ein paar Punkte, an denen die Einrichtung gerne hängt:

  • Der Git-Benutzer beim Speichern der Einstellungen braucht Schreibrechte, falls Allow Push to Git Repository aktiv ist. Mit reinem Lesezugriff scheitert das Anlegen der README-Datei.
  • Der Branch muss vorher im Repository angelegt sein.
  • Die Repository-URL lässt sich später nur ändern, wenn vorher alle Assets von Source Control getrennt wurden.
  • Der Dienst kann mit einem OutOfMemoryError: Java heap space aussteigen, laut Knowledge Base schon beim Speichern der Einstellungen. Dann hilft es, die Eigenschaft JVM_MAX_MEMORY der GitRepoConnectApp (Standard 256 MB) in den System Configuration Details des Secure Agents zu erhöhen, etwa auf 1024m.
  • Laut Informatica sollte nur eine Entwicklungsorganisation in ein Repository pushen. Test und Produktion holen sich die Stände nur ab.

Das war es auch schon. Mit dem Dienst auf dem Agent, der Proxy-Ausnahme und dem richtigen Truststore arbeitet die IDMC mit eurem internen Git genauso wie mit GitHub in der Cloud.

Quellen

Falls ihr Fragen dazu habt oder vor einer ähnlichen Einrichtung steht, schreibt mir gerne.