Workflow Bridge Profile Configuration General Tab
The General tab is displayed by default when creating or opening a Workflow Bridge profile.
Workflow Bridge profile
| Setting | Description |
|---|---|
Send Reply Over Bridge | Select this checkbox if the Collection workflow must send a reply back to the Forwarding workflow each time a Note! This only applies for the ConsumeCycleUDR, since the WorkflowState UDRs must always be acknowledged. There is no timeout handling for outstanding |
Force Serialization | This option is enabled by default and applies to situations where the Workflows are running on the same EC. You can disable it to increase performance, if you are certain that no configurations will be changed during the execution of these Workflows. Note! If this option is disabled, it is strongly recommended to NOT perform any configuration changes while the Workflows are running. |
Response Timeout (s) | Enter the time (in seconds) that the Workflow Bridge Forwarding agent will wait for a response for a WorkflowState UDR from the Workflow Bridge Real-time Collection agent. After the specified time, the Workflow Bridge Forwarding agent will time out and abort the workflow. The default value is "60". |
Bulk Size | Configure Bulk Size if you want data to be bulked by the Workflow Bridge Forwarding agent before being sent to the collection side. Enter the number of UDRs that should be bulked. The default value is "0", which means that the bulk functionality will not be used. |
Bulk Timeout (ms) | Enter the time (in milliseconds) that the Workflow Bridge Forwarding agent should wait in case the bulk size criteria is not fulfilled. Default value is "0" which is an infinite timeout. |
Number of Collectors | If you want to configure broadcasting or load balancing, i e if you want several different Workflow Bridge collecting workflow instances to be able to receive data from the forwarding workflow, you enter the number of collecting workflows you want to use in this field. The number of collecting workflows connected to the workflow bridge must not exceed the limit set by this value. In the case of a batch forwarding workflow, it must be started after the specified Number of Collectors are running or it will abort. Collecting workflows that are started after the limit has been reached will also abort. Real-time forwarding workflows do not require any collectors running when started, and the Number of Collectors represents an upper limit only. Validation of this configuration will also be performed. |
| Transport | Select the transport protocol that you prefer for the best performance, Aeron, TCP, or TCP(netty4). Note! If you select Aeron, you cannot use Bulk Size and Bulk Timeout. If you select TCP, Netty version 3 is used. If you select TCP(netty4), netty version 4 is used and you can set the advanced property highThroughput to false (in the Advanced tab) to save CPU usage (at the cost of lower throughput). Default is true. It can be wise to perform some test runs with the sort of traffic you will use later and especially check which one gives the best characteristics in terms of throughput and latency. You can always switch between Aeron or TCP/IP even on a system that is in service, but you must restart the workflow when doing this. |
| Load Balancing Strategy | Select the Load Balancing Strategy for preferred scalability and redundancy. The Load Balancing Strategy is used if you set the number of collectors to more than 1. There are two strategies: Static: LoadIDs from the UDRs are used to determine how data should be distributed via the workflows. See Workflow Bridge Example Real-Time to Real-Time Scenario with Load Balancing for how to use this. Dynamic: Select to distribute the load over all the available collectors. The LoadID from the UDR is used virtually and is not connected to any hardware at the collecting side. The LoadID settings of the workflows will be ignored during load balancing. When selecting Dynamic, another field called Virtual Destinations is displayed. The default setting of the Virtual Destination field is 1024. The LoadIDs in the UDR are mapped to virtual destinations distributed evenly on available consumer instances. The LoadIDs set in the Workflow Table are ignored. For instance, if Virtual Destinations is set to 1024, the UDR's LoadIDs must be populated with values from 0-1023. The Workflow Bridge engine will create the amount of virtual destinations that you have specified in the LoadID field. If starting another workflow, the virtual destinations will be redistributed evenly between the available workflows. In most cases the default setting 1024 of Virtual Destinations is sufficient and will work fine. In case you want to change this, it should be set as a number that is the power of two, such as 512, 1024, or 2048. The number of destinations may vary, so make sure the number is set high enough to get a decent distribution. Note! The Virtual Destinations field is only available if you have set Load Balancing Strategy to Dynamic. |
UDR Types | If you enter a UDR type into the list of UDR types then workflows are validated to only allow Workflow Bridge Cycle UDRs, and UDRs of that type, to be sent into the Workflow Bridge Forwarding Agent. Click the button to select the UDR types. If you leave this field blank any UDR type can be sent to the Workflow Bridge Forwarding Agent. Click the button to remove a UDR type. |
Note!
After a Workflow Bridge profile has been changed and saved, all running workflows that are connected to this profile must be restarted.