Моделирование наследования в Dynamics CRM

Question

Мы моделируем объекты саморегуляции в MS Dynamics CRM 2015. Один из примеров - здания и часть зданий (Строительный комплекс ==> Индивидуальное здание ==> Вход ==> Этаж ==> Плоский).

Есть некоторые поля, такие как калькулятор стоимости или владелец здания. Если у вас есть здание с 300 квартирами, все здание может принадлежать одной компании или каждой квартире принадлежит отдельным лицам.

То, что мы ищем, - это какое-то наследование значений поля. Итак, для поля «Владелец» пользователь должен иметь возможность отмечать флажок, который «владелец» наследуется от его родительской записи.

У нас есть 20 или 30 полей, которые могут быть наследуемыми.

Мы хотим скопировать значение из родителя, потому что оно упрощает определение представлений и отчетов.

Вопросы: Было ли это сделано раньше, есть ли лучшие практики или готовый плагин где-нибудь?

Если я это делаю сам решение будет выглядеть так:

• Для каждого наследуемого поля, создать логическое поле xx_myfield_inherit
• Установите флажок и поле всегда вместе на форме.
• Создания некоторых Java-магия и плагин:
  • Если помечено, поместите поле в режиме только для чтения и копирование значения из родительского
  • Если значение изменяется, проверьте, есть ли дети с набором наследования (если сделано с OnChange триггером, что вероятно, будет работать рекурсивно, из коробки)
  • ...

Есть немало особых ситуаций в catch (не разрешать наследование, когда родительский элемент не установлен, обновлять наследование при изменении родительского объекта, отменить выбор наследования, когда родитель удален).

Я предполагаю, что это совершенно выполнимо, но сначала я хочу получить совет, есть ли лучшие решения.

Answer 1

30 есть много полей для создания отдельных полей «наследовать». Что касается удобства использования, стоит рассмотреть группировку тесно связанных полей.

Выполнение каскадных обновлений связанных записей на самом деле довольно распространено, и я часто использовал этот вид функций, в большинстве случаев для (почтовых) адресов между учетными записями, субсчетами и контактами.

Ваше решение должно выполнить следующие требования:

1. Когда создается новая запись, наследуемые поля должны быть предварительно заполнены.
2. При изменении унаследованных полей родительской записи эти изменения должны быть синхронизированы с дочерними записями.
3. Когда запись репаратирована, унаследованные поля должны обновляться со значениями нового родителя. (Если репарация не должна быть невозможной.)
4. Когда родитель записи удаляется, унаследованные поля должны быть либо оставлены как есть, либо очищены. (Это до вашего клиента, чтобы решить, что желаемое поведение.)
5. Когда пользователи имеют возможность делать записи активными и неактивными, у вас есть несколько дополнительных требования:
   • когда запись становится неактивной, все из его дочерние записи также дезактивируются (vv).
   • Неактивные записи не влияют на каскадные обновления.
   • Унаследованные поля должны быть обновлены после возобновления записи.

Для выполнения этих требований следующих пользовательские компонент:

1. Класс плагина зарегистрирован для следующих шагов:
   • PreValidate синхронных создать: этот компонент копирует поля из родительской записи.
   • Предварительное подтверждение синхронного обновления: этот компонент обновляет синхронизированные поля, когда запись репарации, когда родительские отношения удалены или когда изменяется поле «inherit».
   • PostUpdate асинхронное обновление: этот компонент обновляет дочерние записи при изменении одного или нескольких синхронизированных полей.
2. Javascript делает следующие:
   • Включение/отключение полей данных на OnChange из "унаследовать" -полей.
   • Получайте и предварительно заполняйте синхронизированные данные поля, если вы хотите обеспечить оптимальный пользовательский интерфейс.

Единственная сложная часть в этом растворе делает обновление каскадного в асинхронном шаге плагина, в основном потому, что обновления каскада вниз по дереву и CRM позволяет только это произойдет за 8 уровней глубоко в максимуме (по умолчанию).

Также имейте в виду, что асинхронные плагины, работающие в песочнице (которая является единственным вариантом в CRM Online), должны быть завершены в течение 2 минут. Этот предел не должен быть проблемой в большинстве случаев, поскольку ваш шаг плагина будет отвечать только за синхронизацию изменений с непосредственно связанными дочерними записями.

Итак, здесь можно спроектировать звуковое решение, которое будет хорошо работать. Вам просто нужно создать несколько пользовательских компонентов.