After you create a risk firewall, you can use that risk firewall instance from other contexts and from other monitors. For example, you might want to register rule classes and add rule class instances in one context, send orders to that risk firewall from a different context or monitor, and handle orders approved by that risk firewall in yet another context or monitor. When you want to use a risk firewall that was created in another context or monitor you connect to that risk firewall.

To connect to a risk firewall, execute either of the following actions:

Both actions take these two parameters:

In addition, the connectCb() action takes a callback action as its third parameter. This callback is invoked after connection to the remote risk firewall.

The RiskFirewall instance returned by the connect() or connectCb() action provides a subset of the actions provided by RiskFirewall instances that are returned by create() or createCb() actions. The following table shows which actions are available from a risk firewall that is connected to a risk firewall instance in another context or monitor. Only a locally created risk firewall may register rule classes, add rule instances, and modify the configuration of the risk firewall instance. A remote connection to a risk firewall is limited to only essential actions, such as sending and receiving orders. This policy ensures a level of protection from modifications by risk firewall connections to remote risk firewall instances.

To determine whether the risk firewall in the current context is connected to a remote risk firewall instance, execute the RiskFirewall.isRemote() action.

Connection to a remote risk firewall is asynchronous. Consequently, some risk firewall actions that are normally available on a risk firewall that is connected to a remote risk firewall might not be available until the connection is completely in place. If your application requires notification when the connection to the remote risk firewall is in place, execute connectCb() and specify a callback.

You can execute connect() or connectCb() to connect to a remote risk firewall that has not yet been created. However, a risk firewall you connect to must be created before the configurable timeout period has expired, otherwise an error will be returned. The configuration parameter that specifies the timeout period is CONFIG_TIMEOUT_DURATION and the default value is 5.0 seconds.

There can be any number of connections to a risk firewall instance.

Any error callbacks that were set on the RiskFirewallFactory prior to using it to connect to the remote risk firewall are used if there is an error when connecting to the risk firewall.

However, any parameters that were set on the RiskFirewallFactory prior to using it to connect to the remote risk firewall are ignored. The only exception to this is the CONFIG_TIMEOUT_DURATION parameter. You can set this on a factory and its value is used for the connection to the remote risk firewall.

A risk firewall that is connected to a remote risk firewall instance has the same configuration parameter settings as the risk firewall instance it is connected to. You cannot set parameters on a risk firewall that is connected to a remote risk firewall. This protects remote risk firewall instances from modifications by risk firewall connections. To change the configuration parameters for a risk firewall that is connected to a remote risk firewall you must change the configuration parameters directly on the remote risk firewall instance itself. When you update the configuration parameters for a risk firewall instance any risk firewalls connected to that remote instance inherit the updated settings.

Connecting to a risk firewall instance in the same context is useful when you have two or more EPL monitors in the same context. For example, you can create a risk firewall instance in monitorA and in monitorB you can connect to the risk firewall in monitorA. You can then send orders from monitorB. A connected risk firewall takes care of the communication between the two monitors.