Продолжим создавать наше первое приложение на Salesforce "Library". Основа любого бизнес приложения - это база данных, над которой собственно вся логика и строится.
(картинку в начале статьи вставил в качестве интро для статьи, но потом понял что она подходит как нельзя кстати и даже имеет практическую ценность - это часть стандартной модели данных salesforce)
В Salesforce база данных представляет собой объектно-реляционную модель данных. Говоря простым языком, мы создаем и работаем с объектами. Достоинство это или недостаток, каждому свое. Мне сразу понравилась данная техника и продолжает нравится.
Представим какие данные нам потребуются для работы нашей библиотеки, на какие логические единицы можно разделить данные. Книги, авторы, читатели, карточка читателя, Пока остановимся на этих элементах. Добавлять остальные элементы, которые понадобятся будем по ходу разработки. Огромным плюсом salesforce является простота, с которой можно производить изменения в модели данных. При этом практические любые изменения можно делать даже на рабочем орге (проде) - salesforce просто не позволит вам что-то испортить. По крайней мере придется приложить усилия и мозги, чтобы что-то сломать :)
Немного пояснений и приступаем к созданию этих объектов.
- Book - собственно книга, гордость и основа библиотеки
- Author - авторы, которые подарили нам эти книги
- Book_Author - объект связывающий Книги и Авторов (многие-ко-многим)
- Card - читательский билет читателя
- Card_Item - запись в читательским билете, которая говорит нам о том какая книга и в каком состоянии по отношению к читателю они находится (читается, лижит на полке пылится или успешно возвращена в библиотеку) (тоже объект связи для Книги и Читателя, вернее его читательского билета)
- User - читатель, то зло, без которого ни одна библиотека существовать не может.
Связь многие ко многим в salesforce напрямую не реализована. Такую связи можно реализовать через объект связи (junction object). Об этом кстати есть вопросы на сертификации, в которых так и говорится - junction object - это объект с двумя master-details связями для организации связи многие ко многим. Кому интереснее, подробнее
здесь.
Объект User мы создавать не будем. Salesforce уже позаботился об этом и найти данный объект можно среди standard objects.
Остальные же объекты, которые мы собираемся создать называются custom objects. Важно знать эти понятия. Они являются основными категориями, которыми оперируют salesforce разработчики.
Как говорится, много букаф :) Теперь скриншоты.
Идем
your_name->Setup->Create->Objects->New Custom Object
После сохранения должны увидеть:
На этом экране видим что объект Book успешно создался. Обратите внимание на API Name Book__c - это название объекта с помощью которого вы будете обращаться к объекту из кода. Это имя является постоянным, даже если вы захотите поменять название самого объекта (object label).
Так же нас будут интересовать секции Standard Fields и Custom Fields & Relationships. Первая секция содержит список стандартных полей, которые имеет любой объект. У стандартных объектов, соответственно и набор стандартных полей побольше. У кастомных объектов стандартные поля в основном неизменяемые и заполняются системой автоматически (Created By, Last Modified By, Owner)
Создадим дополнительные поля (custom fields) что мы указали на схеме (ISBN, Date of Publication). Заметьте, что поле Name уже есть среди стандартных - является текстовым полем с длиной 255 символов. Поле Id нам тоже создавать не надо, оно есть хотя и не показано на странице объекта. Наверное это самое интересное и важное поле в любом объекте. Значение в нем является уникальным ДЛЯ ЛЮБОГО объекта на орге (в базе данных), и по этому значению можно очень легко получить доступ к объекту для просмотра и редактирования (подробнее про
salesforce object ID и работу с ним).
Создание custom field -> секция Custom Fields & Relationships -> new
Salesforce предоставляет длииииный список чтобы выбрать тип поля, который будет удовлетворять типу данных, который вы собираетесь хранить. Для ISBN я думаю стоит выбрать текстовое поле с длиной (сори что поленился изучить вопрос о длине ISBN, пусть будет с запасом) 26.
Выставляем галочки Required и Unique. Теперь наше поле стало обязательным для заполнения и уникальным, собственно что и логично исходя из предназначения кода ISBN.
Выставляем настройки FLS (Field-level security) для нового поля. Я обычно на dev орге обычно выставляю разрешение для всех. Так потом будешь уверен что не придется сидеть полдня в отладке кода из-за того что для пользователя данной поле закрыто.
Выставляем галочку для добавления данного поля на layout. Вернее галочка уже стоит у изменить ее нельзя. Это потому что мы установили что поле required. Для необязательных полей эту опцию можно редактировать. Пока включаем. Потом расскажу как что это такое и зачем нужно.
Поздравляю, вы создали первое кастомное поле. Страница объекта должна теперь содержать информацию об этом объекте.
Создаем остальные объекты, только без полей, которые должны ссылаться на другие объекты. О порядке связывания объектов напишу в следующей статье.
Объект Author создайте точно также как и Book. Никаких дополнительных полей создавать не будем. Хватит созданного по умолчанию поля Name куда будем заносить имя и фамилию автора. Конечно правильнее было бы создать поля First Name, Last Name и еще какие, но пока упростим задачу.
Объект Card ("Читательский билет") тоже создадим, но на применим одну хитрость. Поле Name сделаем автоматически генерируемым. В секции "Enter Record Name Label and Format" для "Data Type" выберите "Auto Number", для Display Format "C-{00000}", для "Starting Number" введите 0. Теперь поле Name будет недоступно для редактирования, будет генерироваться автоматически при создании объекта и будет содержать С-00000, С-00001, С-00002, ... . Это очень удобно, когда непонятно какое значение должно содержать поле Name, а оно есть всегда и удалить его не получится.
В объекте Card создадим поле "Status" типа Picklist. Поле типа Picklist должно содержать одно из предустановленных значений, которые указываются в свойствах поля данного типа. На странице редактирования объекта поле данного типа представляется в виде выпадающего списка. Наше поле "Status" будет содержать значения, предположим, "Regular", "Vip", "Blocked", "Expired"
Объект User создавать не будем, так как в salesforce есть такой стандартный объект. Более того это наверное самый основной объект в salesforce, который содержит информацию обо всех пользователях и на основании которого работает система аутентификации. Когда вы создавали свой орг, система уже создала для вас запись в объекте User и вашими данными. И если вы планируете открывать доступ к вашему оргу (приложению) для других пользователей (как читатели, сотрудники библиотека для нашего приложения), то вся работа будет связана именно со стандартным объектом User.
