2013-12-11 4 views
0

В учетной записи BC есть настраиваемое поле «Lock Flag», а именно в таблице S_ORG_EXT_X. Это поле доступно в Opportunity BC, используя соединение над таблицей. Спецификация соединения следующая: Opportunity.Account Id = Account.Id. Идентификатор учетной записи всегда заполняется при создании новых возможностей. Требование состоит в том, что для вновь созданных записей в Opportunity BC, если «Lock Flag» равен «Y», нам не следует разрешать создавать запись, и мы должны показывать собственное сообщение об ошибке.Определить новую запись в обработчике событий PreWriteRecord и проверить значение объединенного поля

Мое первоначальное предложение состояло в том, чтобы использовать Событие Runtime, которое вызывает бизнес-службу Data Validation Manager, в которой оценивается правило проверки и отображается сообщение об ошибке. Предполагая, что мы должны решить, записывать ли запись или нет, логику следует помещать в обработчик события PreWriteRecord, если WriteRecord имеет строку, уже отправленную в базу данных.

Основная проблема заключалась в том, как определить, является ли это новой записью или обновленной. У нас есть записи WriteRecordNew и WriteRecordUpdated, но они запускаются после записи записи на самом деле, поэтому она не мешает пользователю сохранять запись. Мой следующий подход состоял в том, чтобы использовать eScript: написать собственный код в сценарии сервера BusComp_PreWriteRecord и вызвать метод BC IsNewRecordPending, чтобы определить, является ли это новой записью, а затем проверить флаг и показать сообщение об ошибке, если это необходимо.

Но, к сожалению, я столкнулся с другой проблемой. Это объединенное поле «Lock Flag» не заполняется для вновь созданных записей возможностей. Помните, что речь идет о возможности BC, и поле помещается в таблицу S_ORG_EXT_X. Когда мы создаем новую возможность, мы выбираем учетную запись, к которой она принадлежит. Таким образом, он воспроизводится: OpportunityBC.GetFieldValue («Lock Flag») возвращает значение null для вновь созданной записи и возвращает правильное значение для ранее сохраненных записей. Для вновь созданных возможностей мы должны повторно запросить BC, чтобы увидеть «Lock Flag». Я нашел несколько документов, включая Oracle's recomendation, для использования свойства PreDefaultValue, если мы хотим отобразить значение объединенного поля сразу после создания записи. Наиболее подходящим выражением, которое я нашел, является Parent: BCName.FieldName, но это не так, потому что активным BO является Возможность и Возможность BC является основной.

Спасибо за ваше терпение, если вы дочитали до этого и, наконец, приходят на мои вопросы:

  1. Есть ли способ справиться PreWrite событие и определить, является ли новая запись или нет, без использования eScript и BC .IsNewRecordPending метод?

  2. Как получить значение объединенного поля для вновь созданной записи, особенно в обработчике событий PreWriteRecord?

Это Siebel 8,1

UPDATE: Я нашел ответ на первую часть моего вопроса. Теперь мне кажется так просто, что мне интересно, как я не делал этого изначально. Вот решение.

  1. Создать событие Runtime, инициированное на PreWriteRecord. Укажите вызов бизнес-службы Data Validation Manager.
  2. В DVM создать набор правил и правила, где условие

НЕ (BCHasRows ("Opportunity", "возможность", "[Id] = ' "+ [Id] +"'", «AllView»))

Всё. Мы ищем запись с тем же идентификатором строки. Если это новая запись, в базе данных еще ничего не должно быть (помните, что мы находимся в обработчике PreWriteRecord), а функция возвращает FALSE. Если мы обновляем некоторую строку, получаем TRUE. Обратный результат с НЕ мы делаем DVM для повышения ошибок для новых записей.

Что касается второй части моего вопроса, то кредиты передаются @RanjithR, который предложил использовать PickMap для заполнения объединенного поля (см. Ниже). Я проверил этот метод, и он работает нормально, по крайней мере, когда у вас есть соответствующий PickMap.

ответ

1

Мы, разработчики Siebel, использовали скрипты, чтобы правильно определить, является ли запись новой. Один способ, который вы могли бы попробовать, - использовать RuntimeEvents для установки атрибута profile во время события BusComp NewRecord, а затем проверить это в событии PreWrite, чтобы узнать, является ли запись новой. Тем не менее, всегда есть шанс, что пользователь может отменить запись, эти сценарии сложны.

Другой вариант, попробуйте использовать метод BC: IsNewRecordPending из события RunTime. Я этого не делал.

Для второй части запроса, я думаю, вы могли бы легко решить свою проблему с помощью PickMap.

On Opportunity BC, когда вы выбираете Аккаунт, просто добавьте еще одну карту, чтобы выбрать флаг Locked из Account и установите его в соответствующее поле на Opportunity BC. Когда пользователь выбирает Учетную запись, он также выберет флаг блокировки, и ваш скрипт будет работать в PreWriteRecord.

Могу ли я предложить другое решение, опять же, я его не пробовал.

Когда новые записи создаются, поле ModificationNumber будет установлен в 0. Каждый раз, когда вы изменили его, ModificationNumber будет увеличиваться на 1.

Установите DataValidationManager набора правил, вызвать его из PreSetFieldValue случае поля счета на Возможность BC. Проверьте LockFlag = Y AND (ModificationNumber IS NULL или ModificationNumber = 0)) и выполните ошибку throw. DVM должен выдавать ошибку при создании новых записей.

Опять же, лучшие практики говорят, что не используйте ModNumbers. Вы можете установить для ProfileAttribute сигнал NewRecord, а затем использовать этот атрибут в DVM. Но, пожалуйста, не забудьте очистить значение ProfileAttribute в WriteRecord и UndoRecord.

Дайте нам знать, как все прошло!

+0

Что касается расчетного поля, на самом деле я уже сделал это так, как вы предложили. Попробовав различные выражения PreDefaultValue, я начал думать, есть ли другой способ сделать это. Вскоре PickMap пришел мне на ум, и после тестирования я могу сказать, что он работает. Я также нашел способ проверить новую запись без создания сценариев и скоро обновить свой вопрос. В любом случае, спасибо за ваши предложения! –

+0

Привет, Ярослав, это отличный трюк с использованием BCHasRows, никогда не думал об этом. Но если вы запрашиваете во всех представлениях BC, он может начать показывать проблемы производительности в долгосрочной перспективе. Но, аккуратный трюк никогда: -D –

+0

Столбец ROW_ID имеет уникальный индекс. Конечно, запрос потребляет некоторые ресурсы, но я считаю, что не слишком много. :) –