Народ, у меня появилась идея провести нам вместе небольшой мозговой штурм и составить своего рода ТЗ к внешнему хранилищу для Salesforce. Возможно определенные знания каждого в своей области помогут выработать общие требования, на основании которых кто-нибудь решится это написать.
Итак, как я вижу данную систему:
На стороне Salesforce
1. будут созданы классы - Domain objects
2. будет написан Mapper, который будет отвечать за сохранение и получение объеков из внешней системы
На внешней стороне будет создан web service который будет обрабатывать запросы от Mapper.
Теперь как это будет работать -
1. На стороне Salesforce можно будет создать apex класс, который будет содержать атрибуты для хранения данных. 2. Создаем экземпляр данного класса (объект), заполняем параметрами и скармливаем Mapper для сохранения во внешнем хранилище.
3. Mapper сериализует наш объект в JSON и отправляет данные скажем по REST API на внешнее хранилище.
4. Приемник на внешнем хранилище принимает данные и вот тут тоже момент - десериализует и сохраняет в SQL базе данных, или пихает сразу в NoSQL базу данных в виде JSON (в MongoDB например) и возвращает ID из базы в Mapper.
Получается такая своего рода самописная ORM под Salesforce.
Теперь вопросы:
1. Помогите перевести на нормальный язык ООП то что я выше написал (по поводу доменных объектов, мапперов смотрел сюда - http://habrahabr.ru/post/198450/)
2. Как поступать со связями
3. Какие проблемы вы видите в сериализации.
4. REST/SOAP
5. На внешнем хранилище что лучше использовать SQL/NoSQL (для простоты и возможности поиска)
Жду ваших соображений.
Может есть какие-нибудь красивые статьи про написания ORM своими руками?
Как бы так упростить/автоматизировать работу внешнего хранилища, чтобы не пришлось что-то писать под новые Domain objets на Salesforce.
С DML более менее понятно, что с SOQL/SOSL ?
Не самый лучший вариант.
Вроде Gres писал об этом в теме Salesforce Social Coding:
разве это не об этом же?
Я так понимаю не совсем. Это следующий шаг - у меня маппинг доменной сущности на базу данных, а у Gres маппинг доменной сущности на DTO - это более высокий уровень абстракции.
У меня не используются никакакие сторонние сервисы для хранения данных.
Готов поучаствовать в реализации, если опишешь, что ты хочешь видеть в итоге, определенные Use cases and user stories.
Можно создать организацию на Гитхабе и контрибьютить по мере возможности, если у кого-то конечно есть желание.
class ContactDomain {
public String Firstname { get; set; }
public String Lastname { get; set; }
public ContactDomain(...) {
...
}
}Дальше использует этот класс в коде
ContactDomain contact = new ContactDomain(...);
Использует Mapper для сохранения нашего объекта на внешнее хранилище
(тут происходит основная магия - и на внешний сервис уходит POST запрос с сериализированным contact)
Mapper.save(contact);
Для поиска использовать что-то такое
(вот тут самое сложное!)
формируется запрос на внешний сервер, который должен его перевести в запрос удаленной базы, вытянуть данные и возвратить в Salesforce.
List<ContactDomain> contats = Mapper.select(ContactDomaing.class).where('{"firstname":"somename"}');В общем какая-то такая идея.
Самая основная мысль тут чтобы сделать Mapper и внешний сервис как можно более универсальными чтобы клиенту было достаточно создать DomainObject с любым набором данных и больше ни о чем не беспокоиться.
Пока звучит красиво, но чувствую для реализации мозг придется вывихнуть! Особенно на внешней стороне!!!
!!! как вариант я только вспомнил - можно попробовать воспользоваться движком Elastiсsearch - он предоставляет отличный REST API для работы с ним. Можно будет просто пихать туда данные и искать удобно (движек как раз используется для быстрого полнотекстового поиска - можно будет убить двух зайцев).
Т.е. ты хочешь предоставить некоторое API для разработчиков заказчика, но это не будет готовым решением для самого заказчика?
При твоем варианте использования сложностей я вообще не вижу.
Создается класс с любой структурой, сериализуется, отправляется, сохраняется для простоты в nosql хранилище.
Для поиска тоже самое.
Впринципе все элементарно.
А если кому-то хочется решить проблему персональных данных для своих заказчиков, используйте принцип mitm.
Задумался сегодня а что это за зверь такой OData, который использует Salesforce для своих external data storage?
В вот он оказывается кто http://www.odata.org/
An open protocol to allow the creation and consumption of queryable and interoperable RESTful APIs in a simple and standard way.
В общем это то что нужно!
Находим библиотеку, которая реализует этот протокол, ставим на внешний сервер и всё! Гоняем данные из Salesforce. Не нужны страшные танцы с бубном на стороне внешнего сервера. Остается только написать свой connector на стороне Salesforce. Остается только найти библиотеку которая реализует OData на стороннем сервере.
(на python, ruby или go), но не для "богов" на java или тем более .net для которых еще отдельную стойку в датацентре покупать надо.по сравнению с Java и .net можно сказать что ДА
