Listening Service auf privaten Jitterbit-Agenten

Einführung

Der Listening Service ist eine Funktion privater Agenten, die eine Integrationsoperation ausführen kann, wenn ein Ereignis an einem Endpunkt auftritt, und die Verarbeitung von Operationen über einen Cluster von Agenten verteilen kann.

Der Service funktioniert nur auf privaten Agent-Gruppen und nur mit den folgenden Konnektoren und Aktivitäten:

Voraussetzungen

Um den Listening Service zu nutzen, benötigen Sie Folgendes:

• Private Agenten Version 10.78 / 11.16 oder später.

• Eine ungerade Anzahl von Agenten in einer Agent-Gruppe wird empfohlen, ist aber nicht erforderlich. Bei einer geraden Anzahl kann eine Netzwerkunterbrechung die Gruppe in zwei Hälften teilen, und keine Hälfte hat genug Agenten, um den Cluster am Laufen zu halten. Eine ungerade Anzahl stellt sicher, dass eine Seite immer genug Agenten behält. Mindestens 3 Agenten in der Agent-Gruppe werden ebenfalls empfohlen, um vollständig von den Lastenausgleichs- und Fehlertoleranzfunktionen des Listening Service zu profitieren.

• \((N / 2) + 1\) von insgesamt \(N\) Agenten in der Agent-Gruppe, abgerundet auf die nächste ganze Zahl, müssen ausgeführt werden und dem Cluster beigetreten sein. \(N\) zählt alle in der Agent-Gruppe registrierten Agenten, unabhängig davon, ob sie ausgeführt werden oder nicht. Beispielsweise erfordert eine Gruppe von 4 Agenten 3 laufende Agenten, und eine Gruppe von 5 Agenten erfordert ebenfalls 3.

• TCP-Ports 5701 und 5801 auf allen Agent-Hosts offen.

  Hinweis

  Je nach System können die folgenden Befehle verwendet werden, um offene Ports auf einem Agenten zu testen:

  • telnet <agent address> <port>
  • netcat -vz <agent address> <port> oder nc -vz <agent address> <port>
  • Test-NetConnection <agent address> -Port <port> (PowerShell)

  Stellen Sie sicher, dass Ihr Antivirus und Ihre Firewall Verbindungen über die Ports 5701 und 5801 zulassen, um genaue Tests durchzuführen.

• Alle Agenten im selben Netzwerk.

Wenn Sie die folgende Fehlermeldung in Studio erhalten, kann dies daran liegen, dass Sie nicht alle Anforderungen erfüllt haben:

Listening-Service aktivieren

Der Listening-Service ist standardmäßig deaktiviert. Man muss den Listening-Service auf allen privaten Agents in einer Gruppe und sowohl auf dem Vorgang als auch auf der Aktivität des Projekts aktivieren.

Agents aktivieren

Um den Service zu aktivieren, führe diese Schritte auf allen privaten Agents in der Gruppe aus:

1. Bearbeite JITTERBIT_HOME/Resources/jitterbit-agent-config.properties.

2. Füge diese Zeilen hinzu:

   1 2 3

   agent.sdk_framework.listener.enabled=true agent.sdk_framework.listeners.matchEventsQueueToAvailableCores=true # agent.sdk_framework.listeners.eventsQueue=N

   • Zeile 1: Aktiviert den Service.

   • Zeile 2: Legt die Größe der Ereigniswarteschlange automatisch fest.

   • Zeile 3: (Optional) Entferne den Kommentar, um die Größe der Ereigniswarteschlange manuell festzulegen, wobei \(N\) kleiner oder gleich der Anzahl der Prozessorkerne auf dem Agent-Host ist. (Falls verwendet, kommentiere Zeile 2 aus.)

3. Starte den Agent neu.

Vorgänge und Aktivitäten aktivieren

Standardmäßig ist das Event-Listening deaktiviert. Um das Event-Listening für Vorgänge und Aktivitäten zu aktivieren, führe diese Schritte aus:

1. Öffne das Projekt und suche den Vorgang, der die Listening-Aktivität enthält. Die Listening-Funktion einer Aktivität wird durch ein Symbol oben rechts angezeigt: für aktiviert oder für nicht aktiviert.

2. Falls der Vorgang noch nicht bereitgestellt wurde, stelle ihn bereit. Nach der Bereitstellung wird der Umschalter Ereignisse deaktiviert am unteren Rand des Vorgangs angezeigt:

   

3. Um das Event-Listening für den Vorgang zu aktivieren, klicke auf den Umschalter Ereignisse deaktiviert.

   Wichtig

   Das Aktivieren oder Deaktivieren des Event-Listening für einen Vorgang wirkt sich auf alle Listening-fähigen Aktivitäten im Vorgang aus.

Listening-Service überwachen

Man kann den Status des Listening-Service mit der Management Console oder der REST API überwachen.

Mit der Management Console überwachen

Nachdem ein Vorgang mit einer Listener-Aktivität bereitgestellt wurde, werden der Vorgang und seine Listening-Aktivitäten auf der Registerkarte Listeners der Seite Projekte der Management Console angezeigt:

Mit der REST API überwachen

Man kann eine HTTP-GET-Anfrage an den Listening-Service senden, um Statusinformationen anzuzeigen. Die folgenden Informationsendpunkte sind verfügbar:

curl -XDELETE localhost:46912/axis/v1/cdk/internal/starter/stats

Beispiele

Zeige den Cluster-Leader-Agent an:

curl --silent localhost:46912/axis/v1/cdk/internal/leader | python -m json.tool

{
    "AgentClusterMemberUUID": "67a77314-46c7-4243-9193-bc143ece5ed0",
    "OrgId": "20980",
    "AgentId": "281020",
    "AgentHost": "192.168.64.18",
    "AgentName": "Agent 1",
    "AgentGroupId": "171230",
    "AgentGroupName": "Agent Group A"
}

Zeige den Cluster-Status an:

curl --silent localhost:46912/axis/v1/cdk/internal/cluster | python -m json.tool

{
    "clusterTime": 1725895381981,
    "currentNumberOfMembers": 2,
    "state": "ACTIVE",
    "hasMinimumSize": true,
    "minimumMembersRequired": 2
}

Zeige Statistiken an:

curl --silent localhost:46912/axis/v1/cdk/internal/starter/stats | python -m json.tool

{
    "sdk-retryable-events-queue": 0,
    "sdk-inflight-messages-0": 0,
    "sdk-processing-events-queue-0": {
        "stats": null,
        "lastProcessedEvent": -1,
        "queueSize": 0
    }
}

Mitglieder anzeigen:

curl --silent localhost:46912/axis/v1/cdk/internal/members | python -m json.tool

[
    {
        "isLeader": "true",
        "minClusterSize": "2",
        "inetSocketAddress": "192.168.64.18",
        "uuid": "67a77314-46c7-4243-9193-bc143ece5ed0",
        "version": "5.0.5",
        "isLiteMember": "false",
        "leaderNodeState": "STARTED",
        "ipv4": "true",
        "inetAddress": "192.168.64.18",
        "port": "5701",
        "ipv6": "false",
        "host": "rocky89",
        "AgentName": "Agent 1",
        "AgentId": "281020"
    },
    {
        "isLeader": "false",
        "minClusterSize": "2",
        "inetSocketAddress": "192.168.64.25",
        "uuid": "efbfab6a-0326-43c0-a4f7-f14a26a36d25",
        "version": "5.0.5",
        "isLiteMember": "false",
        "ipv4": "true",
        "inetAddress": "192.168.64.25",
        "port": "5701",
        "ipv6": "false",
        "host": "192.168.64.25",
        "AgentName": "Agent 2",
        "AgentId": "281030"
    }
]

Persistenz aktivieren

An einen Agent gesendete Nachrichten können in einer Datenbank gespeichert werden. Falls der Agent ausfällt, bietet die Datenbank einen persistenten Speicher für Nachrichten, die erneut gesendet werden können, wenn der Agent wieder online ist.

Standardmäßig speichert die interne PostgreSQL-Datenbank diese Informationen, aber nur für Single-Agent-Cluster. Bei Clustern mit mehr als einem Agent müssen Sie die Persistenz manuell aktivieren.

Sie können auch eine externe JDBC-fähige Datenbank oder einen Redis-Server verwenden.

Multi-Agent-Persistenz (interne PostgreSQL)

Um die Multi-Agent-Persistenz in der internen PostgreSQL-Datenbank zu aktivieren, führen Sie diese Schritte auf allen privaten Agents in der Gruppe aus:

1. Bearbeiten Sie JITTERBIT_HOME/Resources/jitterbit-agent-config.properties.

2. Fügen Sie diese Zeilen hinzu:

   agent.sdk_framework.queueStore.enabled=true
   agent.sdk_framework.queueStore.type=dbinternal
   agent.sdk_framework.persistence.enabled=true
   agent.sdk_framework.persistence.type=dbinternal
   

3. Starten Sie den Agent neu.

Multi-Agent-Persistenz (externe JDBC oder Redis)

Um die Multi-Agent-Persistenz mit einer externen JDBC-fähigen Datenbank oder einem Redis-Server zu aktivieren, führen Sie diese Schritte auf allen privaten Agents in der Gruppe aus:

1. Bearbeiten Sie JITTERBIT_HOME/Resources/jitterbit-agent-config.properties.

2. Falls die Datenbank eine JDBC-Verbindung verwendet, fügen Sie diese Zeilen hinzu:

   Persistente Speichereinstellungen für JDBC-fähige Datenbank (Beispiel)

   agent.sdk_framework.queueStore.enabled=true
   agent.sdk_framework.queueStore.type=db
   
   agent.sdk_framework.persistence.enabled=true
   agent.sdk_framework.persistence.type=db
   
   agent.sdk_framework.datastore.db.url=jdbc:sqlserver://harmony:1433;database=cloud
   agent.sdk_framework.datastore.db.user=sa
   agent.sdk_framework.datastore.db.password=******
   agent.sdk_framework.datastore.db.databaseName=cloud
   agent.sdk_framework.datastore.db.dialect=org.hibernate.dialect.SQLServerDialect
   agent.sdk_framework.datastore.db.driver_class=com.microsoft.sqlserver.jdbc.SQLServerDriver
   

   Falls die Datenbank Redis ist, fügen Sie diese Zeilen hinzu:

   Persistente Speichereinstellungen für Redis (Beispiel)

   agent.sdk_framework.queueStore.enabled=true
   agent.sdk_framework.queueStore.type=redis
   
   agent.sdk_framework.persistence.enabled=true
   agent.sdk_framework.persistence.type=redis
   
   agent.sdk_framework.datastore.redis.url=redis://redis:6379
   
   #Optional - pool configuration
   
   agent.sdk_framework.datastore.redis.maxTotal=8
   agent.sdk_framework.datastore.redis.maxIdle=8
   agent.sdk_framework.datastore.redis.minIdle=0
   agent.sdk_framework.datastore.redis.blockWhenExhausted=true
   agent.sdk_framework.datastore.redis.maxWaitMillis=-1
   agent.sdk_framework.datastore.redis.testOnBorrow=false
   agent.sdk_framework.datastore.redis.testOnReturn=false
   agent.sdk_framework.datastore.redis.jmxEnabled=true
   

3. Starten Sie den Agent neu.

Fehlerbehebung

Weitere Informationen zur Fehlerbehebung finden Sie in folgende Abschnitten im Leitfaden zur Fehlerbehebung für private Agents:

• „Cluster hat die erforderliche Mindestgröße nicht erreicht"

• Listening-Service-Nachrichten nicht zugestellt

Cluster-Wiederherstellung nach Agent-Ausfall

Falls ein Agent mit aktivierter Persistenz ausfällt, können Sie ihn manuell mit diesen Schritten wiederherstellen:

1. Bearbeiten Sie JITTERBIT_HOME/Resources/jitterbit-agent-config.properties auf dem Host des ausgefallenen Agents.

2. Fügen Sie diese Zeile hinzu:

   agent.sdk_framework.listener.running.mode=restore
   

3. Starten Sie den Agent.

4. Verwenden Sie die REST-API, um den Status des Agents abzufragen.

5. Wenn der Status für leaderNodeState RESTORED ist, beenden Sie den Agent.

6. Bearbeiten Sie JITTERBIT_HOME/Resources/jitterbit-agent-config.properties erneut, und entfernen oder kommentieren Sie die in Schritt 2 hinzugefügte Zeile.

7. Starten Sie den Agent.

Nicht zugestellte Nachrichten

Der Wiederholungsmechanismus für die Cluster-Nachrichtenzustellung löscht nicht zugestellte Nachrichten nach einer bestimmten Zeit. Um den Zeitraum zu ändern oder die Nachrichtenlöschung zu unterdrücken, führen Sie diese Schritte aus:

1. Bearbeiten Sie JITTERBIT_HOME/Resources/jitterbit-agent-config.properties.

2. Suchen Sie die folgende Zeile, und ändern Sie den Wert für \(N\) (in Minuten):

   agent.sdk_framework.retry.deleteRetryableMessageAfter=N
   

   Tipp

   Um alle Nachrichten unbegrenzt zu speichern, verwenden Sie den Wert -1 für N.

3. Starten Sie den Agent neu.