У нас возникла очень странная проблема в нашем приложении Siebel 7.8.
В событии Application_Start мы определяем набор атрибутов профиля, которые определяют, разрешено ли зарегистрированному пользователю выполнять определенные операции или нет. Код примерно такой:
if (userHasSuperpowers) {
TheApplication().SetProfileAttr("CanFly", "Y");
} else {
// CanFly is not set, and GetProfileAttr("CanFly") returns ''
}
Все работает нормально, кроме одного из этих атрибутов профиля. Условия не выполняются, поэтому мы не устанавливаем его значение. Но когда мы проверяем это с помощью GetProfileAttr... он возвращает 'Y' вместо ''.
Я проверил код. Много. Я везде расставил трассировки и на 100% уверен, что при выполнении последней строки события Application_Start атрибут все еще пуст. Однако в первом событии Applet_Load после входа в систему (в апплете HLS Salutation Applet (HLS Home)) его значение уже изменилось на 'Y'. Почему!!? Я искал везде, но не могу найти нигде, где бы мы проводили SetProfileAttr. Я пока исключил:
- Каждый браузерный и серверный скрипт для всех наших апплетов, приложений, BC и бизнес-сервисов.
- Все бизнес-службы времени выполнения (те, которые определены непосредственно в приложении, а не в SRF).
- Поля бизнес-компонента
Personalization Profile. - SmartScripts (не то чтобы они имели значение в данном конкретном сценарии, я просто упомянул их, чтобы признать, что вы также можете установить атрибуты профиля).
- Рабочие процессы: каждый шаг, вызывающий
SIS OM PMT ServiceметодSet Profile Attribute. - Siebel волшебным образом устанавливает его значение. Имя атрибута профиля создается на заказ на испанском языке и содержит название нашего проекта и row_id. Я на самом деле не думаю, что Siebel использует то же имя для атрибутов своего профиля :).
Но подождите, это еще не все, самое интересное я оставил напоследок: проблема возникает только в нашей среде разработки!
- Это не проблема SRF: если мы продвигаем один и тот же SRF в нашу тестовую или производственную среду, он работает и возвращает ожидаемое значение.
- Это не проблема с данными: все еще с тем же SRF я могу использовать свой локальный толстый клиент, подключаясь к нашей базе данных разработки с тем же логином и паролем, и он тоже отлично работает.
- Это не проблема параллелизма: мы тестируем только одного пользователя, вошедшего в систему. И даже если бы у нас было больше, они не разделяли бы сеансы. И даже если бы они это сделали, значение не всегда было бы
'Y'. - Это не временный сбой или что-то из-за неправильной инкрементной компиляции или поврежденного SRF: мы наблюдаем это в течение как минимум 6 месяцев (очевидно, за это время у нас были десятки различных файлов SRF... все у них такая же проблема, но только в разработке, и только если вы используете сервер, а не выделенный клиент... серьезно...).
Где еще я могу искать установленный атрибут профиля? Я читал, что они могут быть сохранены в БД, но для этого вы должны определить их как поле в BC на основе на таблице расширения S_PARTY, верно?
Есть ли способ как-то отследить изменения атрибутов профиля? Может быть, поднять какой-то лог-уровень?
Как я могу узнать хотя бы то, что выполняется после Application_Start, до загрузки первого апплета?
Любые другие идеи? Я также пытался проверить файл спула SQL, но не нашел там ничего подозрительного (т. е. любой из запросов, которые мы используем для проверки условий, выполняется дважды с разными параметрами).
Обновление: следуя предложениям Ранджита Р., я также проверил:
- Другие ванильные бизнес-службы, которые также можно вызывать из рабочего процесса для установки атрибута профиля:
User Registration > SetProfileAttr,SessionAccessService > SetProfileAttrиISS Promotion Agreement Manager > SetProfileAttributes. - События времени выполнения, устанавливающие атрибуты профиля напрямую или с помощью бизнес-сервиса (у нас нет никаких событий времени выполнения, кроме ванильных).
- Бизнес-сервисы вызываются из DVM (у нас есть только стандартная проверка данных правила, и ни одно из них не применимо к нашим шинным компам).
Все равно не повезло...
