Olena/test
Page for Testing
Pulse
You can:
- Download the report data as a CSV file by selecting Download Widget from the the more menu.
- Make changes to the source widget by selecting Edit from the the more menu.
- Sort options, define objects, and define statistics you want to display.
- View different chart types available in the expanded widget:
Starting with release 9.0.001, new options are available in the Customize menu:
- Row Density:
- Comfy (default) or Compact
- Row Color Contrast:
- Low (default) or High
- Reset Column Width - resets columns width to default values.
table
| header 1 | header 2 | header 3 |
|---|---|---|
| row 1, cell 1 | row 1, cell 2 | row 1, cell 3 |
| row 2, cell 1 | row 2, cell 2 | row 2, cell 3 |
| Header text | Header text | Header text |
|---|---|---|
| Example | Example | Example |
| Example | Example | Example |
| Example | Example | Example |
Interaction Server Cluster Limitations
Nodes are irreplaceable
No Interaction Server node in the cluster is capable to process interactions submitted to another node. Therefore, each node has to be deployed as primary/backup pair and the reliability is provided by the standard Genesys primary/backup functionality.
The node, for which both primary and backup Interaction Servers are down or the single node database is down, cannot process the interactions and no other nodes can process the interactions. The same situation is with the node's event log. If event log database is not accessible for a significant time period, then events are lost.
Interaction Queue FIFO Issue
The order of the interactions could be broken because each primary/backup pair works with its own database and the proxy requests interactions from the same queue in a round robin fashion. This limitation is more important for long living interactions and large backlogs. For deployments with low volume and no backlog it is not very important.
On the Diagram 1, two nodes handle the same type of interactions using the same business process and both handle the same queue Q1. Both servers maintain order and provide response to pull request to proxy in the correct order. But the order as seen by the client may be not correct as proxy have no way of knowing or handling the order correctly (it does not understand the semantics of order definition) and, therefore, cannot request the appropriate server (for example, to get older interactions or interactions with higher priority as defined by the Interaction view order).
The same situation is true for URS, where each node pushes interactions from its own database in the correct order, but the order of routing of interactions by the URS is different.
In certain situations, for example, when URS and interaction view use the same order by priority, URS can rectify the situation by processing interactions internally in the correct order, and, therefore, allowing one of the servers to push more interactions with higher priority.
If URS or ORS or any other client that pulls the interactions from interactions view does not impose their own order of processing, but rely solely on the order provided by Interaction Server (or, in this case, by the proxy), the misbalance between the servers may increase in time, because there is no any synchronization point unless the queues become empty. In other words, the situation with broken queue order may be acceptable for short living interactions, like chat, and less acceptable for long living interactions, like email.
Obviously, if different nodes process different types of interactions, and as a result, only one server in the cluster maintains the order of some specific queue, there is no such problem. For example, on the Diagram 2, the client pulls from different queues defined for different solutions and both streams are provided in the correct order.
Duplicate Interaction IDs
Due to possibility of providing its own interaction id by the client, it is possible to submit interactions with the same id to different nodes at some point when the cluster cannot check that there is a duplicate. This issue is not present if interaction identifiers are generated by the cluster itself (by any node in the cluster) or by eServices components (since they all follow a schema that provides uniqueness within a single configuration environment). If customers are willing to generate ids themselves, they have to guaranty that ids are unique.
No Definite Reply to Some Operations Regarding Interaction Existence
If some node in the cluster is down (even for a short time, for example, due to switchover or host restart) the proxy cannot definitely tell if some interaction exists or does not exist. In this case, the proxy generates a new error (Interaction is not accessible) when it cannot contact all the nodes in the cluster. In the picture on the right, the proxy is not able to get any reply from the third node, and while first and second node provided negative reply, the proxy cannot definitely tell the client that interaction is not found.
In certain cases, a proxy might already have information about which server processed the interaction with specific id in its cache. In this case, the proxy only contacts the server that it knows processes the interaction. In this case, even if some nodes are down, the proxy still can reply with the definitive answer (Interaction does not exist). But, generally, the proxy may restart or the new proxy can be instantiated and in this case its cache is initially empty and it still needs to broadcast to all servers to try and find the interaction.
Limited Scope for URS
Due to the fact that URS is connected directly to each primary/backup Interaction Server in the cluster, it only sends requests (including ESP requests) to the server it received the EventRouteRequest from, and therefore, has a limited scope for the requests. For example, ESP request FindInteraction can only access interactions in the context of a single node. However, in many situations this might be acceptable since the context of such URS requests is logically limited to the same scope.
Increased Limits for Some Operations
For certain requests, for example, RequestFindInteractions, RequestGetWorkbinContent, that use configured limits for the maximum number of interactions that Interaction Server can return in request, those limits are not enforced, as, by design, the proxy forwards the same request to all relevant servers and then merges the replies. The number of returned interactions can be multiple of the number of nodes in the worst case scenario.
If only one node handles the specific media type, then limits are enforced just like with a single Interaction Server deployment.
Invalid Order of Interactions in Some Requests
The EventWorkbinContent or EventInteractionsFound event, in cases when multiple servers return the result, contains interactions out of order after proxy merges the results. This is due to the fact that ordering and filtering are handled by the database and not by the server or proxy which do not understand semantics of the condition and order. The desktop should sort the result in this case.
Event Log Limitations
There are two options for configuring the event logs in the cluster:
- Configure one event logger database for the entire cluster and let all the server in the cluster write to this single database.
- Configure separate event logger databases for each primary/backup pair in the cluster and then process multiple databases at some point later.
The fist option has some limitations:
- Since each server writes its own pair of events EventAgentLogin/EventAgentLogout, if some triggers are implemented in the database, including standard triggers that remove agent events on EventAgentLogout either with or without delay, then the first EventAgentLogout event removes all the event records while agent may still be logged in on other servers. This situation is rarely a problem however, since proxy logs agents in on all servers and logs them out on all servers at the same time.
- The ETL or any consumer of event log has to expect the multiple overlapping pair of EventAgentLogin/EventAgentLogout to handle the agent sessions correctly.
Note, that since specific interactions are processed by a specific server, the issue of overlapping event pairs does not exist for interactions or ESP reporting events.
The second option requires event log consumer to process multiple databases and merge the event streams taking into account the same problem of overlapping agent state events.
Licensing
Each server in the cluster checks out the number of licenses specified in its configuration. Each primary/backup pair in the cluster uses its own unique license group id (DBID of the primary server) and only shares the licenses between the pair.
Different nodes do not share licenses and the entire cluster requires the number of licenses equal to the sum of all configured licenses for every primary/backup pair.
Capture Points
Capture points are configured per node and the limitation is that each capture point can only access interactions that are processed by the node for which it is configured. That is certainly acceptable for nodes exclusively configured to handle specific media type/solution and no other node handles the same media type. In this case, all capture point operations should work. Including operations that request information from the server.
In case when there are multiple nodes that handle the same media type and for each node there is a capture point configured, these capture points can be used to capture interactions and produce notifications towards external systems, provided they can work with the source in parallel. This might be true for JMS Capture Points that are configured to connect to the same JMS queues, for File Capture points that are configured to monitor different directories and for Web Service Capture Points for which some sort of load balancing is configured.
As a consequence of limited visibility to only one node for each Capture Point, the requests that are intended to request data from Interaction Server might not work correctly. For example, the request to Get Interaction/Task properties might be received by the capture point other than the one that created the interaction and as a result the request fails, even though the interaction might still exist in the database of the other node.
Stat Server Java Extensions
In the cluster deployment, SSJE can only receive data from one Interaction Server.
Proxy Disconnect/Mass Agent Logout/Panic Signal
The functionality implemented in Interaction Server to shield reporting clients from massive agent logout due to proxy disconnect is not working in case when proxy application is connected to Interaction Server proxy. The server does not see the disconnect of the proxy which is connected to Interaction Server proxy. All that the server sees are individual disconnect events for each client that was connected to or handled by the disconnected proxy. Because of that the server does not know how many clients are disconnected and cannot check again the threshold to generate the panic signal to reporting clients. This can be mitigated by connecting Stat Server to all Interaction Server in the cluster directly. Stat Server has the same functionality of aggregating the reporting event streams from multiple servers as Interaction Server proxy does.
ESP configuration must be symmetrical
All servers serving the same tenant and media type should have connections to the same ESP servers to avoid a situation then one Interaction Server can execute particular ESP request and the other server cannot.
System Monitoring/Ping Request
The proxy does not support Ping request. The components that monitor Interaction Server have to be connected directly to individual Interaction Server in the cluster.
Implementation limitations
The proxy processes many requests by routing them to one or many Interaction Servers, based on data contained in the request. The proxy gets the TenantID, media type, and InteractionID from the request (including ESP requests) in a generic way. Based on values of these attributes the proxy selects the Interaction Server.
In case when one of the attributes required by proxy to route some specific request is not present when expected or provided with incorrect type or with incorrect value the error message is generated by the Interaction Server proxy, and not by the Interaction server. Most of the time, the generic message "Interaction is not accessible" is generated.
Snapshots are not supported.