Jump to: navigation, search

grouping-timeout

Section: channel-twitter-*any-name*
Default Value: No default value
Valid Values: Any integer from 0 to 3600 (one hour)
Changes Take Effect: After restart
Modified: 9.0.012.35

Specifies the time span (in seconds) within which Tweets must arrive in order to be grouped together. New incoming Tweets are grouped together with any other Tweets of the same type from the same user that are currently in the interaction queue. If this option has an invalid value (including none) or the option is missing, grouping is not done. The Twitter interactions are grouped under the following Tweet types:

  • direct messages (DM)
  • replies
  • retweets
  • public tweets

For example, if a user sends three public Tweets within the timeout, all three Tweets are grouped in one post. However, there separate groups are formed if a user sends a public Tweet, a reply, and another Tweet within the timeout. Note that the group ID contains Twitter user ID (or sorted user IDs in case of DM) and a post ID that initiated the grouping. The oldest post of the same author and type within the grouping interval is selected as the group initiating post.

Sample Business Process: Twitter BP - Threaded Routing

This Business Process was introduced with Business process for use with Twitter 8.5.400.91. There are some special considerations that are specific deploying to this Business Process, described in Deploying below.

Twitter BP - Threaded Routing is a sample Business Process that submits grouped Twitter interactions to a configured agent group. It consists of ten strategies, four subroutines, and ten queues.

In broad terms, processing proceeds as follows:

  1. Twitter Inbound Strategy-TR:
    1. A query is sent to Interaction Server to see if there is already an interaction with the same Twitter Group ID farther along in the strategy.
    2. Then,
      • If such an interaction is found, it is updated with the content of (merged with) the newer interaction, and the newer interaction is terminated.
      • If no such interaction is found in the strategy, then the current interaction proceeds to the buffer stage.
  2. In the buffer stage, Twitter Inbound Buffer Strategy-TR holds the interaction for the period specified in the grouping-timeout option for the relevant Twitter channel. During this time, any other incoming interactions from this sender are added. When the specified period is up, the interaction is sent to Twitter Post Buffer Strategy-TR.
  3. Twitter Post Buffer Strategy-TR is similar to Twitter Inbound Strategy in Twitter BP. It:
    1. Initializes the required variables.
    2. Ensures that the interactions are delivered to agents in the order they were created.
    3. Checks whether the interaction already exists in the UCS database and, if not, creates it.
    4. Associates the interaction with the correct thread.
    5. Creates contacts in UCS.
  4. TwitterCalculationOfDesktopFlagsOtherPosts-TR calls in a cycle TwitterCalculationOfDesktopFlags-TR (which is similar to Twitter BP) for every item from the existing group of tweets.
  5. The remaining seven strategies are the same as the strategies with the same names (minus the appended -TR) used in Twitter BP.

If the No results option in Digital Messaging Server is missing or is set to an invalid value, Twitter BP - Threaded Routing works the same as Twitter BP.

Deploying

Twitter BP - Threaded Routing was introduced in the Business process for use with Twitter 8.5.400.91 Installation Package (IP). Prior to the release of that IP, it was possible to obtain Twitter BP - Threaded Routing as an Interaction Routing Designer (IRD) export package. If you previously installed Twitter BP - Threaded Routing by importing it into IRD, your procedure for deploying the Business process for use with Twitter 8.5.400.91 IP differs in a few places, indicated in the description below.

  1. First,
    • If you previously installed Twitter BP - Threaded Routing, run the Business process for use with Twitter IP using the general deployment procedure.
    • Otherwise, install all of the following:
      • Business process for use with Twitter
      • Social Media Plug-in for Workspace version 8.5.400.86 or higher
      • Cloud API Driver for Twitter 8.5.400.53 or higher
      • Cloud API Driver for Facebook 8.5.400.67 or higher (required only if you have both Facebook and Twitter channels in the same Digital Messaging Server).
  2. Deactivate the old Business Process strategies: In IRD, right-click Twitter BP and select Deactivate Strategies.
  3. In the Digital Messaging Server configuration options, in the section for the relevant Twitter channel (channel-Twitter-*any-name*), add the option,No results and give it a value in the range 10–3600. This is the timespan, in seconds, within which tweets must arrive in order to be grouped together.
  4. Check queues: Stop Digital Messaging Server, then use Genesys Administrator or Configuration Manager to check or set the following options:
    • Digital Messaging Server: [endpoints:*related_tenantId*]twitter_queue must have the value Twitter TR Inbound Queue.
    • Workspace Desktop Edition: [interaction-workspace]twitter.default-queue must have the value Twitter TR Outbound Init Queue.
    • Workspace Desktop Edition: [interaction-workspace]twitter.outbound-queue must have the value Twitter TR Outbound Queue.
  5. Now,
    • If you previously installed Twitter BP - Threaded Routing, install:
      • Social Media Plug-in for Workspace version 8.5.400.86 or higher
      • Cloud API Driver for Twitter 8.5.400.53 or higher
      • Cloud API Driver for Facebook 8.5.400.67 or higher (required only if you have both Facebook and Twitter channels in the same Digital Messaging Server).
    • Otherwise, proceed to the next step.
  6. Restart:
    • Digital Messaging Server.
    • Universal Routing Server
    • Universal Contact Server
    • Interaction Server
    • Workspace Desktop Edition
Important
For the MergeItxData method in the ESP block of Twitter Inbound Strategy to work properly, the settings/delay-updates option in Interaction Server should be set to false. With this setting, Interaction Server forces updates of interaction properties in the database each time it processes RequestChangeProperties.
This page was last edited on February 25, 2022, at 11:53.
Comments or questions about this documentation? Contact us for support!