Здравствуйте. У нас в организации внедрен Salesforce. Организация небольшая, в Москве. Все настроено и прекрасно работает. Я занимаюсь администрированием Salesforce и поддержанием качества данных в базе.
Сейчас данные в систему поступают из источника данных и нормальной интеграции между источником данных и SFDC нет (в силу сложности данных) - все вносится подручными ETL-софтами, процесс занимает много времени, ручного труда на настройку софта и проверку данных. Задача написать полноценный модуль интеграции SFDC и нашего источника данных.
Подробное описание задачи здесь
(https://drive.google.com/open?id=0B4wu-ywV-PVDLUMwV0s0eFBMaFk&authuser=0).
Никакого конкретного варианта реализации нет - рассмотрим любые предложения.
От кандидатов хотим услышать:
А) порядок цен на решение этой задачи и возможность включения в решения моих хотелок (раздел хотелки в тз), примерная архитектура решения.
Б) территориальное расположение - конечно, хотелось бы быть ближе к исполнителю, но если не будет достойных вариантов в нашем регионе, я готов, впринципе, ездить к вам / вы к нам в офис.
В) квалификация - есть ли опыт решения непосредственно подобных задач,
если нет - то какие вообще задачи на Apex решал / сколько лет знаком с Salesforce.
Спасибо,
с уважением Сергей.
Все вопросы и предложения в личку, там дам телефон , емейл, скайп.
интересно было почитать как бы ты это сделал 
почему тянуть?
я рассматривал чисто с точки зрения что мы пишем только СФ код. Я бы делал через кастум REST webservice - кастум потому что логика нигде не используется кроме импорта, как вариант можно сделать через стандартный REST, специальным полем на объекте типа IsImported и триггером, так меньше работы но на каждый объект добавляется триггер и поле.
Ну и внешнее приложение само должно нам слать данные когда надо что-то обработать т.е. по варианту 2.
Давайте порассуждаем
Заодно тема немного попиарится и serguey.issakov будет польза.
То что ты Андрей написал, я бы делал все абсолютно наоборот! Данные забираются со стороны SF. "внешнее приложение само должно нам слать" - ничего оно нам не должно. Чтобы оно нам что-то слало, на стороне внешнего приложения придется писать логику посложнее чем на SF. Так что самый простой вариант, чтобы не напрягать сторонних разработчиков - это запросить у них данные и самим их обработать. В этом случае внешнему приложению не придется обрабатывать исключения, которые могут случиться на стороне SF, и SF, в случае чего, может запросить данные повторно. Я уже написал кратко об этом
Да, тут проще балк-джоб запилить.
Можно, конечно, сделать и с помощью загрузчика Jitterbit - инструмент трансформации данных позволяет делать лукап в базе, но придется разворачивать локальную копию данных сф, для возможности лукапа по ним.
Ну и, конечно, дьявол кроется в деталях. Кто знает, какую логику автор закладывает в поиска и сопоставления адресов, фамилий, номеров телефонов. Ведь на это и живут разработчики софта по интеллектуальному маппингу данных и нечеткому "умному" поиску :)
Ок. Поехали. ДлетерБит хорош ровно до момента пока не познакомишься с Кетл. По крайней мере пол года назад было именно так.
Итак зачем нам Кетл. Допустим по какому-то расписанию, мы должны вставить какие-то данные в СФ. Что он может. Он может вытягивать данные из разных источников, проверять на соответсвие и формировать выходной файл или прямо писать в базу. В принципе всю логику по поиску и проверки входных данных делаем именно в Кетле. В СФ можно реализовать дополнительные проверки.
Но если автор действительно хочет реализрвать чуть ли не искусственный интелект, то это скорее всего придется уже полностью делать на СФ.
Ну, как бы работать с расписаниями и управлять логикой трансформации данных джиттер тоже может. С Кетл не работал, пробовал информатику, но весь сок там начинается с платной версии :-/
Ну а так, практика показывает, что задачи по сложному маппингу проще делать за пределами форса - библиотеки для подобных задач гораздо проще найти для неАпекса
Хотя, возможно тут все просто и достаточно будет проверки по базовым правилам поиска совпадений.
Да. Информатика в платной версии хороша. Кетл хорош своей расширяемостью. Если я правильно помню, там для реализации специфических задач можно запускать свое приложение и передавать ему на вход данные которые Кетл выкачает из какого-либо источника
Да, ведь не зря распространена позиция "Data Steward"
Что-то я туплю. Кеттл - это же пентахо. Отчего жеж я говорю что не использовал? Ведь сейчас сижу и настраиваю :)
Использовали его на одном из проектов уже, на текущий момент самый гибкий из ETL-тулзов.
Вытащить, положить на ФТП, загрузить, переложить в другую папку ФТП, выгрузить результаты - все что угодно :)
Ок. Всем спасибо за участие, собственно, только я так и не понял, чем Apex лучше или хуже решения на Kettle или аналоге.
Правильно ли я понимаю что общее мнение, что проще и надежней реализовать подобное решение на внешнем ETL типа Kettle и просто принять как медицинский факт те неудобства которые с этим связаны:
А) 1.Или мы тащим в Kettle всю таблицу SFDC по которой делается поиск, что чревато ресурсоемкостью операций
2.Или мы запрашиваем через lookup SFDC тем самым съедая огромное количество внешних API коллов (2000 записей в сутки по 7 алгоритмам - не менее 14000 коллов только на выгрузку) и пытаемся это число уменьшить грамотно оптимизируя и группируя запросы или сокращая количество алгоритмов
Б) Соответственно риск ошибки внутри самого ETL тула типа heap space и т.п.
П.С. Я полагал, что задачи подобного рода являются чем-то обычным для интеграторов. Думал, что есть некий стандартный алгоритм для такого рода задач с набором стандартных вариаций для творческих личностей. -)
По поводу интеллектуального мэппинга, ИМХО (!), как это всегда оказывается, 99% процентов вариантов сходства может быть описано простейшими формулами типа like '%x%', оставшийся 1% это допустимая погрешность, которую юзеры исправят руками. Другое дело что введение человека в схему зачастую дороже искуственного интеллекта - последний не ноет, не болеет, не тормозит, и самое главное не обрастает разного рода "ноу-хау" которые делают его незаменимым.
Когда-то так думал, пока не столкнулся с темами маппинга оплат/продаж по данным дистрибьюторов. Хорошим там считается результат в 90 процентов, никак не 99
А в чем состоит ресурсоемкость операций? Скопировали пул необходимых данных в локальную БД и ищете в ней. При нахождении - берете необходимые айдишники и апдейтите/создаете записи в форсе.
