В учетной записи 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 является основной.
Спасибо за ваше терпение, если вы дочитали до этого и, наконец, приходят на мои вопросы:
Есть ли способ справиться PreWrite событие и определить, является ли новая запись или нет, без использования eScript и BC .IsNewRecordPending метод?
Как получить значение объединенного поля для вновь созданной записи, особенно в обработчике событий PreWriteRecord?
Это Siebel 8,1
UPDATE: Я нашел ответ на первую часть моего вопроса. Теперь мне кажется так просто, что мне интересно, как я не делал этого изначально. Вот решение.
- Создать событие Runtime, инициированное на PreWriteRecord. Укажите вызов бизнес-службы Data Validation Manager.
- В DVM создать набор правил и правила, где условие
НЕ (BCHasRows ("Opportunity", "возможность", "[Id] = ' "+ [Id] +"'", «AllView»))
Всё. Мы ищем запись с тем же идентификатором строки. Если это новая запись, в базе данных еще ничего не должно быть (помните, что мы находимся в обработчике PreWriteRecord), а функция возвращает FALSE. Если мы обновляем некоторую строку, получаем TRUE. Обратный результат с НЕ мы делаем DVM для повышения ошибок для новых записей.
Что касается второй части моего вопроса, то кредиты передаются @RanjithR, который предложил использовать PickMap для заполнения объединенного поля (см. Ниже). Я проверил этот метод, и он работает нормально, по крайней мере, когда у вас есть соответствующий PickMap.
Что касается расчетного поля, на самом деле я уже сделал это так, как вы предложили. Попробовав различные выражения PreDefaultValue, я начал думать, есть ли другой способ сделать это. Вскоре PickMap пришел мне на ум, и после тестирования я могу сказать, что он работает. Я также нашел способ проверить новую запись без создания сценариев и скоро обновить свой вопрос. В любом случае, спасибо за ваши предложения! –
Привет, Ярослав, это отличный трюк с использованием BCHasRows, никогда не думал об этом. Но если вы запрашиваете во всех представлениях BC, он может начать показывать проблемы производительности в долгосрочной перспективе. Но, аккуратный трюк никогда: -D –
Столбец ROW_ID имеет уникальный индекс. Конечно, запрос потребляет некоторые ресурсы, но я считаю, что не слишком много. :) –