Application Integration supports several types of listener-based connectors that can be used for event-based processing of messages and files. Process Designer exposes a wide range of attributes in the connectors so you can use many file listener properties when you configure a listener-based connection.
These connectors, like the AMQP Connector (message-based) and File Connector (file/storage-based), act as message brokers or file monitors that can be reused to make data objects, service calls, and events available to the Process Designer.
High availability, load balancing, and clustering for listener-based connectors
If the Process Server uses a Secure Agent group, the following listener-based connectors support high availability, load balancing, and clustering:
•Amazon S3
•Amazon SQS
•AMQP
•File
•FTP
•Kafka
•RabbitMQ
•Salesforce
You can use Secure Agent groups to deploy Process Server services using the following Secure Agent configurations:
Secure Agent load balanced configuration
Use this configuration to evenly distribute the workload across Process Server instances within a group. When you deploy an asset to a Secure Agent group, Informatica Intelligent Cloud Services performs load balancing. You can use the Secure Agent load balanced configuration to distribute requests if you process stateless requests or use the Secure Agent only to serve OData requests.
You can add multiple Secure Agents to a group to balance the distribution of tasks across Process Servers. At run time, Informatica Intelligent Cloud Services dispatches incoming requests to available Secure Agents in a round-robin manner.
Note: When the Process Server uses the Secure Agent group with the load balanced configuration, data duplication might occur. To avoid data duplication, Informatica recommends using the Secure Agent Cluster configuration on the Secure Agent group.
Secure Agent Cluster configuration
Use this configuration to provide high availability with Process Server instance clustering. You can cluster two or more agent groups into a single logical Process Server instance.
When the Process Server uses a Secure Agent cluster configuration, only one listener is active at any point of time. All Process Servers in the cluster share the PostgreSQL database of the master agent. When you deploy an asset to a Secure Agent Cluster, all Process Servers receive information about the process execution activity. The master Secure Agent receives information and informs the other Secure Agents. If a Secure Agent fails during process execution, the process fails over and continues to execute on another Secure Agent within the cluster.
In some fail-over situations, data duplication can occur. For example, there might be a short time lag between the time an agent shuts down and the time when another agent takes over. In this time period, if there is any in-flight data, the data might be duplicated in the agent that takes over the process execution.
If you use multiple listener-based connections, the Process Server distributes the routes across different Secure Agent machines in a Secure Agent group to ensure load balancing.
For more information about configuring the Process Server for high availability, load balancing, and clustering, see the Administrator help.
Starting and stopping listener-based connections
For listener-based connections that run on a Secure Agent or a Secure Agent group, you can start and stop event sources from the Connections page in Application Integration Console. You can also start and stop event sources in Kafka connections that have been published on the Cloud Server.
Application Integration updates the event source status on the Event Sources tab of the listener-based connections. You can view the status of each event source in the published connection. For a connection that runs a Secure Agent or a Secure Agent group, if the status of the event source is stopped, you can republish the connection and restart the event source. However, when you republish the connection, all the event sources in the connection start by default provided the Secure Agent is up and running. The status is updated on the Event Sources tab and on the Connections page in Application Integration Console. If you unpublish the connection, all the active event sources in the connection are stopped and the connection is removed from the Connections page in Application Integration Console. This behavior also applies to the event sources in Kafka connections that have been published on the Cloud Server.
Note: You can publish Kafka connections only on the AWS PODs on the Cloud Server.
When a connection runs on a Secure Agent group, if the event source is started for even one Secure Agent, the event source status is displayed as started. To stop an event source on a Secure Agent group, the event source must be stopped on all the Secure Agents in a group from Application Integration Console, only then the status of the event source is updated to stopped on the Event Sources tab. If you choose to stop an event source only on a selected Secure Agent for some reason, such as stability or connectivity issues with the endpoint, the event source is stopped on that specific Secure Agent. However, the status on the Event Sources tab is not updated because the event source is still running on the other Secure Agents in the group.
Note: The status is not displayed for invalid, unpublished, and outdated connections.
The following image shows the event source status for a listener-based connection:
Note: You might need to refresh the connection to view the updated status.
For more information about starting and stopping event sources in listener-based connections, see Monitor.
