Skip to main content

Trailboss

note

I use Twilio, RE, and Remote Expert interchangeably. All of these refer to this repository which contains the new chat SDK meant to replace Anywhere Expert (AE).

Trailboss is the name of a few different services spread across multiple repositories. It was originially developed to help us control the traffic being onboarded during our migration. I'll go through the three main ways trailboss is used, in the order that we developed them over time.

Traffic-Control​

There's a microservice in our messaging-services repository called traffic-control. This was our first pass at developing a traffic controller to help migrate experts to the new platform. All that this microservice does is take a request that looks something like:

curl --location 'https://trailboss.com' \
--header 'Content-Type: application/json' \
--data '{
    "queue": "CHAT:VERIZON:GENERAL-CONVERSATION",
    "userId": "some-random-uuid"
}'

And then it consults a list of configurations that look like this:

'CHAT:VERIZON:GENERAL-CONVERSATION:EN-US': {
    isWithinScheduledHours: (date: Date) => isWithinDefaultHours(date),
    MAX_PERCENTAGE_TO_DIVERT: 100,
    GOAL_WAIT_TIME_SECONDS: 200,
    OOH_PERCENTAGE_TO_DIVERT: 75,
},

And then if:

  1. The queue name exists (meaning we have a configuration for the partner/queue/chat)
  2. The current wait time in Twilio is under GOAL_WAIT_TIME_SECONDS
  3. The user is chosen to be routed based on the MAX_PERCENTAGE_TO_DIVERT
  4. The user is within Twilio scheduled hours
  5. And finally the user falls under the out of hours number to divert as well

Then trailboss returns true indicating we should route this user to Twilio. This is all very complicated, and we later changed it which I'll talk about in the new solutions. There are a few experiences using this technique to divert traffic, those experiences are:

These experiences will eventually have to strip out trailboss. In order for that to happen, any experience that is hosted by one-service (I believe all of the above are hosted by one-service) will need to wait for one-service to migrate from AE to RE. Once one-service completes that migration, these experiences can remove trailboss and rewrite all the code calling the chat SDK to use whatever API one-service provides.

Trailboss-helper​

There's a small repository that was a wrapper around all the trailboss routing functionality that lives here. This repository basically does everything that was being done by the experiences above. There's only one experience using this helper:

This experience is also hosted by one-service. Once one-service migrates off of AE, this experience will need to have trailboss-helper stripped out and have all calls to the chat SDK rewritten to the new API.

Misc.​

Finally, we have a couple of miscellaneous repositories that have the remote-expert-sdk but were integrated directly or via a different mechanism.

Techcoach​

Techcoach had Twilio added directly to it and is toggled on and off via a feature flag. You can find the specific commit that added it here. Inside that commit, you can see that the Tweek flag that controls it is:

"soluto_home_web/twilio_adk/is_enabled",
  {
    propName: "isTwilioSdkEnabled",
  };

Toggling this Tweek flag will enable or disable Twilio. Eventually, this will need to have AE stripped out of it and migrated to Twilio only.

A.com​

TODO: Matt could you fill in some info here?

Anywhere Expert​

All of the above was very complex and difficult to manage. Because of this (and because we kept breaking experiences while adding trailboss), we came up with a different solution that allowed us to remotely inject the new SDK into these experiences. We're able to do this because we have access to all the code for anywhere-expert.

Bar has created a video describing this injection process which you can watch [here](TODO: Bar can you fill this in?). Since we're able to inject the SDK in to any experience remotely, this basically takes care of all migration issues and allows us to toggle on different partners and queues that we're ready to enable. This is all controlled through some feature toggles via Barvidently. The keys are defined here.

There are two keys that control which partners and queues are enabled.

The key that controls the partner is re_sdk_message_pool_to_partner, and the JSON for this looks like:

{
  "featureKey": "re_sdk_message_pool_to_partner",
  "defaultValue": {
    "att": "AE_PARTNER",
    "cox": "AE_PARTNER",
    "cricket": "AE_PARTNER",
    "koodo": "AE_PARTNER",
    "liberty": "AE_PARTNER",
    "telus": "AE_PARTNER",
    "us_cellular": "AE_PARTNER",
    "verizon": "verizon",
    "verizon_smb": "AE_PARTNER"
  },
  "rules": []
}

If the mapped value is AE_PARTNER then that partner will always route to AE. Otherwise, if it's mapped to the appropriate typed string defined here then it will route to Twilio.

The key that controls the queues is re_sdk_expertise_to_message_topic, and the JSON for this looks like:

{
  "featureKey": "re_sdk_expertise_to_message_topic",
  "defaultValue": {
    "5g": "AE_MESSAGING_TOPIC",
    "bis2": "AE_MESSAGING_TOPIC",
    "daas": "AE_MESSAGING_TOPIC",
    "device-replacement-onboarding": "DEVICE-REPLACEMENT-ONBOARDING",
    "free-plan": "AE_MESSAGING_TOPIC",
    "general-conversation": "GENERAL-CONVERSATION",
    "home-tech-protection": "AE_MESSAGING_TOPIC",
    "mdpp": "AE_MESSAGING_TOPIC",
    "mpp": "AE_MESSAGING_TOPIC",
    "prepaid": "AE_MESSAGING_TOPIC",
    "saves-desk": "AE_MESSAGING_TOPIC",
    "saves-desk-vph": "AE_MESSAGING_TOPIC",
    "security-advisor": "AE_MESSAGING_TOPIC",
    "service-onboarding": "AE_MESSAGING_TOPIC",
    "smart-display-support": "AE_MESSAGING_TOPIC",
    "smart-home": "AE_MESSAGING_TOPIC",
    "supervisor": "AE_MESSAGING_TOPIC",
    "vph": "AE_MESSAGING_TOPIC"
  },
  "rules": []
}

If the mapping goes to AE_MESSAGING_TOPIC then it will route to AE. Otherwise, if the mapping is set to one of the typed values defined here then it will route to Twilio.

Finally, there's a key that whitelists which app keys are allowed to route to Twilio. An app key is a unique identifier used by AE that determines which app is being used. You can find out which app key is associated with an app by inspecting the call to fetch AE when you load an experience that has it. Inside the call that fetches it you should be able to find the app key. Once you have that app key, if you want it to be able to route it to Twilio, you can add it to the feature flag re_sdk_whitelisted_app_keys. The JSON for that looks like this:

{
  "featureKey": "re_sdk_whitelisted_app_keys",
  "defaultValue": [
    "workspace-app-fabio-demo",
    "8b7554e6-85c1-4fe8-ae3a-c5b2250e1d9e",
    "15c83981-4976-4af5-9ff6-83182ebda28d",
    "6678a5fd-ccf5-4dd8-8f45-08529193b44f",
    "e8cfc434-03f6-41fa-8b78-fb4aed3b6f27"
  ],
  "rules": []
}

Using these 3 feature flags, you can toggle different Partners/Queues/App keys to route to Twilio if you want. The code that handles all this lives in Anywhere Expert SDK and can be primarily found in a couple of files:

  • anywhere-expert-sdk/packages/core/src/umd/umd-unsafe-entry.tsx
  • anywhere-expert-sdk/packages/core/src/umd/trailboss/shouldRouteToTwilio.ts
  • anywhere-expert-sdk/packages/core/src/umd/components/SDK.tsx
  • anywhere-expert-sdk/packages/core/src/umd/re-sdk-wrapper.ts