Blog
Token
About Us
AiDOOS Wiki
Project Cost Estimation

Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All
CRM
Salesforce
ERP
SAP
Storage and Backups
Purestorage Netapp Nutanix
Cloud
AWS
Computing
IBM
Database
MongoDB MySQL PostgreSQL
DevOps
Docker Kubernetes Jenkins GitLab
Mobile
React Native Android
Web
React Angular PHP
Programming
Python
CRM-Salesforce
Salesforce Developers

Location Classes with Force Containment

The meaning of "location classes with force containment" is requiring source location classes to be completely contained by the destination location classes. For example, if a skilled labor team has drywall and painting skills, we want that team to service job sites in need of drywall or painting skills, and not job sites in need of drywall, painting, AND electrical. The reason is obviously that a second team will have to cover the electrical work.

We abandon the vehicle-fueling station problem presented in the Sources and Destinations and Location Classes examples. Instead, let us consider three (3) teams of skilled technicians and six (6) job sites needing skilled labor. How would we submit a distance matrix to find which teams are closest to the job site most relevant to their skills? In this case, we'll make use of the force_containment parameter.

Our teams can have one or all of the following skills:

Available Skills Class
Painting 0
Drywall 1
Framing 2
Concrete 3
Electrical 4
Plumbing 5
HVAC 6

To frame the problem further, listed below are our teams and their skills with associated classes for each:

Team Skills
team-paint+concrete+hvac paint ( 0 ), concrete ( 3 ), and hvac ( 6 )
team-drywall+electrical drywall ( 1 ) and electrical ( 4 )
team-concrete+plumbing framing ( 2 ) and plumbing ( 5 )

Our job sites in this example are:

Job Sites Skill Needs
jobsite-paint+hvac paint ( 0 ) and hvac ( 6 )
jobsite-paint+concrete+hvac paint ( 0 ), concrete ( 3 ), hvac ( 6 )
jobsite-drywall drywall ( 1 )
jobsite-drywall+electrical drywall ( 1 ) and electrical ( 4 )
jobsite-paint+framing+plumbing paint ( 0 ), framing ( 2 ), plumbing ( 5 )
jobsite-all All

Unlike the prior examples where we broke down the problem into visual examples, the number of combinations here is too large to visualize simply. This is where the power of our Distance Matrix service shines!

To handle this complexity, all you need to do is apply the same location_class parameters as in the other examples, but this time we will add the force_containment parameter to ensure that when a job site needs multiple skills, ALL of those skill needs are met.

The complete request we will send to the Distance Matrix endpoint is given below.

Expand to view request sample

The complete response we receive from the Distance Matrix endpoint is given below. As expected, we only have travel_costs which show going from sources to destinations where all of the destinations location_class needs are met. The results we get are:

  • team-concrete+plumbing is not eligible for any job site because the only job site in need of concrete and plumbing work also needs all the other types of skilled work (HVAC, paint, etc.), which this team does not possess. Thus there are no travel_costs returned for them.
  • team-drywall+electrical is eligible for the jobsite-drywall or jobsite-drywall+electrical because they are the only team which can handle both types of work.
  • team-paint+concrete+hvac is eligible for two job sites — jobsite-paint+concrete+hvac and jobsite-paint+hvac — because they have the overlapping skills needed.
  • The remaining job sites do not appear in the response because there are no teams which can fulfill all the skill needs and thus no viable solution is available.
Expand to view response sample
Salesforce Developers

Location Classes

What if we want to find the distance and travel times between locations when we know where we're starting and going, but also where we need the locations to match in some way? In this case, we'll make use of the location_class parameter.

Let's consider the exaggerated real-world example started in the Sources and Destinations example. In that example, we had the current locations for a fleet of three (3) vehicles and locations of three (3) available fueling stations. In this example, we'll add the twist that each vehicle takes a particular type of fuel, and only certain fueling location offers this kind of fuel. We start by assigning an arbitrary class number to each fuel type:

Fuel Type Class
Gas 0
Diesel 1
Electric 2

To frame the problem further, below is our fleet and fueling locations each with their designated location class:

Fleet (location class) Fueling Locations (location class)
vehicle-gas ( 0 ) fueling-gas ( 0 )
vehicle-diesel ( 1 ) fueling-gas+diesel ( 0 and 1 )
vehicle-electric ( 2 ) fueling-electric ( 2 )

Let's imagine this problem as a distance matrix. Obviously, we're only interested in the distances from vehicles to fueling locations where the fuel types match, and not interested in the distances for:

  • A vehicle or fueling location to itself — where would it get fuel?
  • Vehicles to other vehicles — other vehicles don't have fuel to share
  • Fueling locations to other fueling locations — other stations don't have fuel to share
  • Fueling locations to vehicles — the station cannot go to the vehicle (although that would be cool)
  • Vehicles to fueling locations without the correct fuel — we'd be stranded at a gas station if we needed diesel

In the distance matrix template below, we've added a helpful zero-based "index" as a visual guide which is not part of the actual distance matrix inputs. There is also a new location_class which indicates the arbitrary class designation based on the type of fuel needed. Note that as a result of using an index-based approach, ORDER MATTERS . This is not an ideal design and is being updated in the next major revision of the API.

index 0 1 2 3 4 5
location class 0 1 2 0 [0, 1] 2
destinations vehicle-gas vehicle-diesel vehicle-electric fueling-gas fueling-gas+diesel fueling-electric
sources
0 0 vehicle-gas -- -- -- YES YES --
1 1 vehicle-diesel -- -- -- -- YES --
2 2 vehicle-electric -- -- -- -- -- YES
3 0 fueling-gas -- -- -- -- -- --
4 [0, 1] fueling-gas+diesel -- -- -- -- -- --
5 2 fueling-electric -- -- -- -- -- --

In order to limit our distance matrix request so that it mirrors our template above and only returns relevant distances, we specify the sources , destinations , and location_class parameters using the indices and classes of each entry.

The complete request we will send to the Distance Matrix endpoint is given below.

Expand to view request sample

The complete response we receive from the Distance Matrix endpoint is given below. As expected, we only have travel_costs which show going from sources to destinations where one of the location_class is included:

  • vehicle-gas to fueling-gas and fueling-gas+diesel
  • vehicle-diesel to fueling-gas+diesel
  • vehicle-electric to fueling-electric
Expand to view response sample
Read article
Salesforce Developers

Sources and Destinations

What if we want to find the distance and travel times between locations when we know where we're starting and going? In this case, we'd make use of the sources and destinations parameters.

Let’s consider an exaggerated real-world example to clarify the use of sources and destinations . Suppose we have the current locations for a fleet of three (3) vehicles and the locations of three (3) available fueling stations. The sources (where we are coming from) and destinations (where we are going to) parameters limit the size of the returned matrix to only the desired results. This makes post-processing by your code simpler because you can apply filters (a parallelized operation) to what are sometimes large, complex matrices.

To frame the problem, below is our fleet and fueling locations:

Fleet Fueling Locations
vehicle-1 fueling-1
vehicle-2 fueling-2
vehicle-3 fueling-3

Let's imagine this problem as a distance matrix. Obviously, we're only interested in the distances from vehicles to fueling locations, and not interested in the distances for:

  • A vehicle or fueling location to itself — where would it get fuel?
  • Vehicles to other vehicles — other vehicles don't have fuel to share
  • Fueling locations to other fueling locations — other stations don't have fuel to share
  • Fueling locations to vehicles — the station cannot go to the vehicle (although that would be cool)

In the distance matrix template below, we've added a helpful zero-based "index" as a visual guide which is not part of the actual distance matrix inputs. Note that as a result of using an index-based approach, ORDER MATTERS . This is not an ideal design and is being updated in the next major revision of the API.

index 0 1 2 3 4 5
destinations vehicle-1 vehicle-2 vehicle-3 fueling-1 fueling-2 fueling-3
sources
0 vehicle-1 -- -- -- YES YES YES
1 vehicle-2 -- -- -- YES YES YES
2 vehicle-3 -- -- -- YES YES YES
3 fueling-1 -- -- -- -- -- --
4 fueling-2 -- -- -- -- -- --
5 fueling-3 -- -- -- -- -- --

In order to limit our distance matrix request so that it mirrors our template above and only returns relevant distances, we specify the sources and destinations parameters using the index of each entry. For this example then, our sources and destinations parameters will look like this in the request:

The complete request we will send to the Distance Matrix endpoint is given below.

Expand to view request sample

The complete response we receive from the Distance Matrix endpoint is given below. As expected, we only have travel_costs which show going from sources to destinations:

  • vehicle-1 to fueling-1/2/3
  • vehicle-2 to fueling-1/2/3
  • vehicle-3 to fueling-1/2/3
Expand to view response sample
Read article
Salesforce Developers

Traffic Windows

Traffic windows refer to the time segments that have an effect on traffic costs. Obviously, heavy traffic will result in higher overall traffic costs.

The Optimization API returns all traffic windows by default. However, you can limit the size of the response by setting start and end times. With start and end times, the Optimization API will only return traffic windows which “touch” the start and end times. This example illustrates that use case.

Suppose you’re only interested in two-time windows that correspond to the morning commute. In this example, we set the start_local_time parameter to 9:00 am and the end_local_time parameter to 12:00.

In the response, the Optimization API has found two traffic windows (indexed 0 and 1) that intersect with these times. It uses this data to reduce the size of the matrix. You can review a sample traffic window below. Note that a single window consists of an index, a start time, and an end time. These windows are referenced by the travel cost object.

Note that the travel cost object refers to the actual matrix that the Optimization API calculates. It consists of the travel distance in meters and the travel cost for each window. The sample JSON provides comments to explain the output.

Expand to view request sample
Expand to view response sample
Read article
Salesforce Developers

Weekday Traffic

This request payload uses the same four locations as the Basic Distance Matrix example but sets the weekend parameter to false .

Expand to view request sample
Expand to view response sample
Read article
Salesforce Developers

Routing Optimization

The Routing Optimization service is powered by an optimization engine designed to handle a huge variety of problems and aims to help you find your optimal business solution by giving you control over how your problem is solved. Your creativity only limits the variety of problems!

Basics

Routing optimization is a more complex version of point-to-point routing where the goal is instead to solve one of the most mathematically complicated problems known to humanity. Building the routes seen above is the outcome of submitting a simple (minimize distance) routing problem to our Routing Optimization service. So, how does one construct a routing problem? There are a few key ingredients one needs first:

  • VEHICLES — the cars, trucks, bikes, or pedestrians that comprise your fleet.
  • LOCATIONS — the physical places your vehicles are routed to provide service.
  • ORDERS — the requests for your services at a specific location over some time.
  • ITEMS — the units of work ordered at a location, e.g., a package delivery, one LTL pickup, four hours of service.
  • CONSTRAINTS — the knobs that tune the solution objective, e.g., maximize revenue, minimize vehicles.

Minimizing the total number of vehicles and total travel time are often a primary goal in most, if not all, routing optimization problems. However, there are other business objectives and tradeoffs to consider. For example, a salesperson might visit five more high-value leads in a day, but at the cost of reduced visits with high-priority customers. Instead of hiding tradeoffs from you, the Routing Optimization service gives you control via constraints that provide the ultimate — sometimes daunting — flexibility and power in solving your problem.

Constraints

Imagine the case where you want a routing solution that penalizes lateness to scheduled appointments. However, maybe you have the luxury of being an excellent customer service company and can be "a little late" without fear of damaging a customer relationship. In which case, it is acceptable to visit a big account lead before an appointment even if that means being late. In which case, you are looking for a solution like:

"Find the optimal routes for my sales team where they have penalized 25 penalty points for every 15 minutes they are late to a scheduled appointment."

Constraint Penalties

Behind the scenes, this is what our patented mathematical optimization algorithms do when they seek out the best solution based on the constraints you provide. Where the "best" solution is the one that captures most, and sometimes all, of your desired business logic and outcomes.

Constraints are given control over the routing solution by accruing penalty points every time the solution violates a constraint in some way. The concept is that the solution with the lowest number of penalty points is the best solution. Using constraints in this way results in having to tune your solutions, and is a bit of an art for your developers. However, once they get the hang of it, the options are limitless.

Visit the Constraint Library and the associated examples for each to see the full details.

For real-world business needs, the Routing Optimization service takes the approach of running a sophisticated optimization algorithm for a reasonable amount of time before returning a solution. To achieve this, we divide problems into synchronous and asynchronous jobs depending on the size and difficulty of the problem (request formats for asynchronous and synchronous calls are the same):

  • Synchronous jobs are for smaller requests (less than 50 locations) and are processed immediately.
  • Asynchronous jobs are for larger requests (more than 50 locations), and a jobid is returned once a request is received and validated. The user can then poll the API for job status and retrieve the results when the job completes. Once it completes, the responses are purged after 24 hours.
Read article