ISD endpoint
- Jonathan Draugelis
Query Remaps:$area query is remapped to $area:like
$area:like query is slower than the $area query but queries can disregard split regions.
example: In an $area:like query 49505 will return 49505 And 49505-Kent
Specific $table.field query is remapped to $and query:
Only $table.field in the exact format below are remapped
query format remapped:
{"$table.field":[{"mi_bridges_id_matches.site_id__c": [...]},{"mi_bridges_id_matches.agency_id__c": [...]}]}
remapped to: {$and:[{location_id: [...]},{organization_id: [...]}]}
ID Remaps:
$in remapping
Query of exact type to be remapped:{"id" : {"$in" : ["number1", "number2", ...]}}
Remapping works as follows:
First endpoint will search the mi_bridges_id_matches table to find any external_id__c (aka ServiceSite_Id) ids that match a provided number.
If a match is found then the id will be remapped to the OR id that corresponds with the external_id__c found. This allows the client to use historical ids and relate them to OR ids.
Also when a mapping is found the API will return the mi_bridges (visionlink ) data for reference.
As an example if client queries {"id":{"$in":[5]}}
This will be remapped to {"id":{"$in":[4]}} and below object will return in the api:
Api response:
[
{
"id": 4,
"organization_id": 971,
"location_id": 972,
...
"visionlink_services": [
{
"or_service_id": "4",
"or_location_id": "972",
"or_organization_id": "971",
"ServiceSite_Id": "5",
"Service_Id": "9491",
"Site_Id": "3219",
"Agency_Id": "3789",
"Name": "north berrien senior center",
"agency_name__c": ""
}
]
}
]
$and remapping
Query to be remapped:
NOTE: Client can have one, all or any combination of the id types: organization_id, location_id, id
NOTE: order of id names does not matter
NOTE: order numbers within arrays does not matter
NOTE: ids will be remapped if distance_info is included or not{"$and": [{"organization_id": ["number", "number", ...]}, {"location_id": ["number", "number", ...]}, {"id":["number", "number", ...]}]}
$and query also allows for distance_info {"$and": [{"distance_info": {"type":"value","name":"value"}},{"organization_id": ["number", "number", ...]}, {"location_id": ["number", "number", ...]}, {"id":["number", "number", ...]}]}
Remapping works as follows:
Endpoint will search the mi_bridges_id_matches table to find visionlink resources that match each type of the ids provided. Either all of the ids in a resource hierarchy are remapped or none of the ids in the resource hierarchy are remapped.
example - remapping found:
query: {"$and": [{"organization_id": [3789]}, {"location_id":[3219]},{"id":[5]}]}
There is a visionlink resource with Agency_Id = 3789 Site_Id = 3219 and ServiceSite_Id = 5
A complete resource hierarchy was found therefor all ids will be remapped to:{"$and": [{"organization_id": [971]}, {"location_id":[972]},{"id":[4]}]}
example - one remapping found:
query: {"$and": [{"organization_id": [111, 3789 ]}, {"location_id":[3219, 222]},{"id":[333, 5]}]}
There is a visionlink resource with Agency_Id = 3789 Site_Id = 3219 and ServiceSite_Id = 5
There is no a visionlink resource with any other combination of Agency, Site and Service ids.
A complete resource hierarchy was found and will be remapped. The remaining ids will be unchanged.
Actual query the api executes is below.{"$and": [{"organization_id": [971, 111]}, {"location_id":[972, 222]},{"id":[4,333]}]}
example - remapping NOT found:
query: {"$and": [{"organization_id": [3789]}, {"location_id":[3219]},{"id":[2]}]}
There is no visionlink with Agency_Id = 3789 Site_Id = 3219 and ServiceSite_Id = 3
Therefor no ids will be remapped. This allows new resources to return that are not referenced in visionlink data.
Field remaps and additions:
Under the phones joined table the number field is remapped to phone_number
Under the locations joined table the email field is added
Under the physical_address joined table the confidential field is added