“Сюрпризы” в Apex. Часть 1

Для розробників Розробка з використанням Apex коду
1

В процессе разработки приложения для Salesforce столкнулся с несколькими “Cюрпризами” в Арех.

1. Для валидации данных, вводимых через UI, было необходимо определять тип поля, для которого они вводятся. Код был написан, покрыт тестами и спокойно работал пока не возникла необходимость расширения возможностей валидации и, соответственно, переделки тестового класса.

В исходном тестовом классе, который был написан несколько месяцев назад, для тестирования различных типов полей я использовал стандартные поля со стандартных объектов, и в частности для типа DOUBLE я использовал стандартное поле NumberOfEmployees с объекта Account.
image%201

Несколько месяцев назад тесты благополучно проходили. Каково же было мое удивление, когда несколько дней назад, запустив тестовый класс, я получил сообщение о том, что по типу DOUBLE тест не проходит. В процессе короткого инвестигейта проблемы оказалось, что за эти несколько месяцев тип этого поля в Арех поменялся с DOUBLE на INTEGER. Казалось бы, все логично – для этого поля Data Type = Number с количеством знаков после запятой равным нулю, какой же ему тип иметь кроме, как INTEGER? Но если мы создадим два кастомных поля с Data Type = Number, но с разным количеством знаков после запятой,

image%202

то мы увидим такую картину:

image%203

Оба кастомных поля имеют тип DOUBLE, независимо от количества знаков после запятой.
Поэтому, если Вы работаете в Арех с типами полей и у Вас в работающем ранее коде возникают неожиданные ошибки, то, возможно, причина в том, что изменился тип каких-то стандартных полей.

2. Какой тип в Арех может иметь поле sObject-a с Data Type = Picklist? Ответ очевиден – PICKLIST. Но не все так просто: для некоторых sObject-ов стандартные поля с Data Type = Picklist в Арех имеют тип COMBOBOX.

sObject Event

Если мы посмотрим на список стандартных полей, то увидим, что поле Subject имеетData Type = Picklist.

image%204

Однако в Арех данное поле имеет тип COMBOBOX.

image%205

Аналогично ситуация выглядит и для sObject Task.

image%204

и в Арех

image%205

Я столкнулся с данной ситуацией на Task и Event, но, возможно, есть и другие sObject-ы с похожей проблемой.

3. Иногда возникает необходимость определить required поля для sObject в Арех. Для этого нам необходимо определить:

  • допускает ли поле нулевое значение при сохранении записи

  • заполняется ли поле дефалтовым значением при создании записи

  • не является ли поле составным именем, например поле Name на Person Account

Соответственно код для проверки будет следующим:

Получаем Map с перечнем полей для объекта

Map<String, Schema.SObjectField> objectFields = Schema.getGlobalDescribe().get('ObjectName').getDescribe().fields.getMap();

Получаем описание интересующего нас поля

Schema.DescribeFieldResult fieldDescr = objectFields.get(`fieldName`).getDescribe();

Проверяем, является ли поле required

Boolean isFieldRequired = !fieldDescr.isNillable() && !fieldDescr.isDefaultedOnCreate() && !fieldDescr.isNameField();

Но как всегда есть подвохи:

  • так как у Account required поле это Name, то проверка будет такой
Boolean isFieldRequired = !fieldDescr.isNillable() && !fieldDescr.isDefaultedOnCreate();
  • у sObject Event и Task required поля невозможно определить в Арех – они не отвечают вышеперечисленным критериям. Для Event required поля это subject и durationinminutes, для Task это subject, priority, status.
4 Вподобання