Почему поле с пометкой «Обязательно для бизнеса» не выдает ошибку при передаче нулевого значения через веб-службы?

В MS Dynamics CRM 2011, когда поле в объекте помечено как «требуемое для бизнеса», я могу создать объект с помощью SDK веб-службы без необходимости указывать значение. Я читал, что это широко известно (и по какой-то причине приемлемо), но я не вижу этого ни в одной документации MS. По-видимому, обязательные для бизнеса поля также будут принимать нулевые значения для доступа через плагины, импорт данных и рабочие процессы.

  • В чем причина этого? Буду признательна за любую ссылку на документацию MS.

  • Если ваш ответ на первый вопрос состоит в том, чтобы обеспечить гибкость, то почему другие ограничения, такие как ограничения длины поля в «Одной строке текста», соблюдаются, а ограничение «Необходимо для бизнеса» — нет?


web-services dynamics-crm-2011 required-field
person Mr Moose    schedule 14.03.2013    source источник

Ответы (1)


arrow_upward
4
arrow_downward

«Обязательное» поле — это концепция, которая применяется только на стороне клиента (например, в форме). Поскольку вы создаете объект с помощью SDK (или подключаемого модуля, или рабочего процесса), сценарии на стороне клиента не вызываются, поэтому требуемый статус поля не проверяется.

Так что это не столько гибкость, сколько невозможно сделать.

Другие ограничения, такие как длина поля, применяются на уровне БД. Следовательно, они будут вызываться через SDK, плагин и т. д.

Если вы хотите применить обязательные поля, это довольно просто — добавьте плагин для предварительного создания. Проверьте значения в желаемых значениях. Если не найдено, сгенерируйте исключение.

person glosrob    schedule 14.03.2013
comment
Я понимаю, о чем вы говорите, но я бы предпочел, чтобы проверка значений была привязана к определению объекта, а не жестко запрограммированные правила относительно того, что требуется. Единственный способ сделать это — запросить метаданные, а в плагине это будет медленно. - person Mr Moose; 14.03.2013
comment
Я согласен, что это не идеально (и было бы больно поддерживать) - я думаю, именно поэтому MS не делает этого из коробки (проблемы со скоростью) - person glosrob; 14.03.2013
comment
Кроме того, я слышал, что ограничения длины поля лишь частично применяются БД. Мне еще предстоит проверить это самому, но я слышал, что увеличение требуемых символов приведет к изменению типа столбца БД, а уменьшение - нет. поэтому я предполагаю, что в самой CRM должна быть какая-то проверка. - person Mr Moose; 14.03.2013
comment
Вот интересно - не слышал. Если длина поля уменьшена, возможно, для защиты существующих данных они не обновляют БД (в противном случае данные будут усечены). Кроме того, в любом случае это будет применяться на уровне БД, поэтому MS лучше проверить на уровне обслуживания и выдать более удобную ошибку. - person glosrob; 14.03.2013
comment
Как побочный момент, CRM применяет обязательные поля для некоторых объектов для некоторых полей, например. инцидент и идентификатор клиента. Но они «особенные», и я не верю, что мы можем это сделать. - person James Wood; 14.03.2013
comment
Для ясности glosrob говорит, например, о форме. На самом деле, Формы — это ЕДИНСТВЕННОЕ место, где Business Required оказывает какое-либо реальное влияние. Рабочие процессы могут игнорировать их (во время работы, а не при редактировании, поскольку при этом используется форма), импорт данных может игнорировать их (несмотря на то, что пользователю надоедает, он просто будет работать), и, конечно же, javascript в форме может изменить уровень требований, чтобы сделать вещи взаимозависимыми. а не жесткие зависимости в базе данных (если вы выберете вариант 1 для поля A, то требуется B, иначе требуется C) - person AdamV; 14.03.2013
comment
Я думаю, вы правы в том, что существующие данные являются причиной того, почему они не уменьшаются. Разрешение пользователю вносить эти изменения, не затрагивая существующие данные, вероятно, является причиной того, что базовый столбец также не может быть обнуляемым. Как я уже сказал, я просто ожидаю, что ВСЕ ограничения должны применяться на уровне обслуживания. - person Mr Moose; 14.03.2013