Начал изучать Google Maps API здесь:
https://developers.google.com/maps/documentation/javascript/tutorial?hl=ru
все просто и понятно.
Затем нашел вот этот ресурс:
http://stackoverflow.com/questions/3122038/how-do-i-integrate-salesforce-with-google-maps
который меня несказно порадовал.
Просто обратите внимание на сл вещи в том коде:
- геолокация (перевод адреса в широту\долготу) первых трех контактов производится с сервера, и их данные записываются в контакт, чтобы в сл раз не пришлось делать геолокацию!
- если контактов в выборке более трех, - то оставшаяся геолокация переносится на клиента.
- обратите внимание как передаются контакты в JS: return JSON.serialize(contacts).
есть чему поучиться
Хороший пример использования Google Maps API.
Но он больше сделан для учебных целей. Google Maps API - это открытый API, который не предусматривает передачу закрытых данных, поэтому однозначно всю работу с ним нужно перенести на клиент в javascript - рендерить карту на лету. Я как-то делал такое на одном из проектов - из контактов берется адрес и на лету скармливается Google Maps, который успешно строит карту.
Если нужно заполнить данные о геолокации для контакта в базе данных, то лучше это сделать с помощью триггера при insert или update для contact объекта. Получаем на каждую операцию один callout.
Как-то так. Но пример работы с API хороший, можно взять на вооружение.
Но, еще один совет. Если хочешь реально разобраться с API, то лучше после всех этих примеров сесть и сделать все с нуля самому, читая официальную документацию Google.
Пример из жизни - я так делал галерею на сайте из google Picasa. Все найденные примеры в интернете либо были перегружены ненужным функционалом либо были откровенно ламерские. Написание того что нужно с нуля в итоге вылилось мне в 20 строчек кода на Javascript. Но пришлось повозиться с некоторыми параметрам пока разобрался.
Только сейчас начинаю понимать, что нам дает JSON серилизация: фактически мы передаем из АПЕКСа в JS целые объекты (т.е. записи), которые JS в браузере может крутить-вертеть как хочет. Мне кажется в этом есть интересный потенциал.
JSON вообще штука классная. Попробовав этот формат данных, ни с каким XML связываться не захочется!
А мне вот наоборот XML больше импонирует. Может опыта меньше)
Тут дело не в опыте 
Просто XML больше технология для бизнес приложений. Особенно свойственно Java и .net.
JSON больше для веб разработки. Тем более что для Javascript он очень близок! Его проще использовать чем парсить XML.
К вопросу о геолокации. Недавно попросили поправить баг в одном проекте. Ну как баг...Есть карта, на ней нужно выводить маркеры адресов аккаунтов системы. Был прямо на странице запрос, который селектил аккаунты, а потом в цикле посылал запрос с адресом ( со стандартной комбинации полей собирался) к геолокатору, и отрисовывал маркер. Там же, в цикле. Так я узнал, что у геолокатора есть лимиты на количество обращений в секунду. В цикле по сути задавался таймаут для следующего рекурсивного вызова обращения к геолокатору, таким образом, каждый следующий запрос обрабатывался, когда сервис говорит, что он свободен. и т.д. А аккаунтов, стало быть 2000. Ну так вот, за час на странице отрисовалось около сотни. Сочтя такую ситуацию неприемлемой, запилил геолокацию в батч. Но и там столкнулся с похожей проблемой. Во время обработки большого числа записей, многие остаются нерассчитанными,потому что геолокатор возвращает статус busy. СФ слишком быстро отправляет их на обработку.
Кто как решал такую проблему?
Во первых надо делать реверс адреса в координаты при создании аккаунта или при изменении адреса, а не каждый раз при отрисовке карты! И хранить координаты вместе с адресом в объекте.
Ну а с теми аккаунтами что есть и которым надо просчитать учитывая лимиты нужно делать сочетание батч + scheduler. запускаешь батч, который получает координаты, как только пришел busy останавливать батч и запускать scheduled через нужный промежуток времени, который опять же запустьт тот же батч по следующим записям.
Но можно выгрузить все адреса из SF, написать скрипт на любом нормальном языке и поставить на ночь чтобы просчитывало. После получения всех координат залить все в SF.
Ну вот я сделал рекурсивный батч, который в конце себя, запускает себя же. Но обрабатывает он по одной записи за раз (есть галка обсчитано\необсчитано). Как только аккаунты с галками кончились - выполнение останавливается. Если локатор вернул busy - галка не снимается.Адрес изменился - галка снова поставилась. И батч защедулен. В триггере на создание, к сожалению, не вариант, ибо из мобилки может прийти куча аккаунтов и расчёт зафейлится (менеджер, например, насоздаёт за неделю клиентскую базу, потом синхронизируется). В итоге правда я сделал ход конём - карта гугловская, а координаты получаю через яндекс геолокатор. У него суточный лимит запросов в 10 раз больше, чем у гугловского, а записей под 4 тыщщи. И была надобность считать координаты для всех записей неоднократно.
Если честно, то это просто жесть. Уже относительно давно поддерживается тип полей Geolocation. Из плюсов:
1. Нативная валидация на полях (юзер френдли)
2. Храним координаты на нужном объекте, отрисовываем все за 1 запрос в гугл апи. Если хранить только адрес, то это лишний запрос идет всегда (для каждого объекта) для того чтобы получить координаты.
Сложность только в изначальной настройке, можно запилить через дата лоудер или, к примеру, сделать VF страничку для где можно тыкнуть пару кнопок и все автоматом асинхронно (или синхронно) заполнится. Адреса, же не так часто меняются. Хотя все зависит от бизнес требований, мы пошли по этому пути.
